Maebh Booth

What we assess

1. Legibility. Service ownership, catalogue completeness, and where knowledge is concentrated across the organisation.
2. Flow health. Deployment frequency, lead time, change failure rate, MTTR.
3. Stack coherence. How fragmentation across stacks and platforms affects cognitive load and standards consistency.
4. Absorption capacity. Pace of delivery, cognitive load, and whether strategy reaches teams and insight reaches leadership.
5. Toolchain integration. Whether key systems are connected and feeding measurement, or signals are locked inside isolated tools.
6. Quality practice. Whether there is a testing strategy and quality is built into delivery. Covers test coverage across the stack, the balance of automated and manual testing, and whether QA capability is embedded in teams or held in a separate function with its own cost and dependency profile.

How it works

Two weeks. Week 1: mapping where metrics live and talking to engineering managers, tech leads, and a sample of engineers. Week 2: analysis, scoring, and report. Each dimension is scored with a confidence level based on what measurement actually exists.

What you get

1. Effectiveness scorecard — organisation-wide and per team
2. Measurement source map with confidence levels per signal
3. Measurement maturity rating on a 0–5 scale
4. Prioritised recommendations and 90-day plan skeleton

What we assess

1. Team design and fit. Whether team topology, boundaries, and ownership are set up for where the organisation is going.
2. Decision rights. Where decisions actually get made, at what level, and whether the formal model matches the lived one.
3. Cross-team dependencies. How much work requires cross-boundary coordination and whether the mechanisms for managing it are working.
4. Workforce composition. Whether the skills mix — permanent vs contract, specialist vs generalist — has kept pace with changes in strategy.
5. Strategic alignment. Whether engineering leaders can articulate the technology strategy and the operating model is visibly connected to direction.
6. Stated vs lived model. The gap between the model on paper and how the organisation actually functions.

How it works

Two weeks. Week 1: reviewing org structure, team charters, and operating model documentation, then talking to engineering leaders and a cross-section of people across the organisation. Week 2: analysis and report, drawing from both the documented model and what people are actually experiencing.

What you get

1. Operating model assessment — where the design supports the strategy and where it works against it
2. Decision rights review — where authority is unclear, duplicated, or at the wrong level
3. Dependency map — the cross-team coordination burden and where it is most costly
4. Prioritised recommendations and 90-day plan skeleton

What we assess

1. Estate visibility. Whether the organisation has a clear, current picture of what exists, what state it is in, and where significant technical debt sits.
2. Architecture coherence. Whether architectural decisions are being made deliberately and recorded, or the architecture is drifting through accumulated choices nobody revisited.
3. Platform and tooling strategy. Whether there is a deliberate platform layer and whether build vs buy decisions are made with a consistent framework.
4. Direction credibility. Whether there is a target state, whether it is clearly articulated, and whether there is a believable path from here to there.
5. AI position. Whether the organisation has a considered position on AI in the technical stack, or adoption is reactive and uncoordinated.

How it works

Two weeks. Week 1: reviewing architecture documentation, ADRs, roadmaps, and tech strategy, then talking to technical leads, architects, and engineering managers. Week 2: analysis and report, surfacing where documentation and what people are building toward diverge.

What you get

1. Technology direction assessment — current state, target state, and the credibility of the path between them
2. Architecture coherence review — where decisions are deliberate and where the architecture has drifted
3. AI position summary — current stance and what a deliberate position would require
4. Prioritised recommendations and 90-day plan skeleton

What we assess

1. Tooling landscape. What AI tools are in use, by whom, for what, and what actual coverage looks like across teams.
2. Adoption intentionality. Whether adoption is driven by a strategy or has accumulated organically, and whether tools are being applied to the right problems.
3. Governance and guardrails. What controls exist, what risks are being managed, and what can currently happen without anyone knowing.
4. Value measurement. Whether outcomes are being tracked or just adoption numbers, and whether the organisation can attribute value to what it is spending.
5. Financial exposure. Cost visibility, vendor lock-in risk, and whether anyone has modelled what spend looks like as usage scales.

How it works

Two weeks. Week 1: mapping what AI tools are in use and what governance exists, then talking to engineering leads, finance or procurement contacts, and a sample of people actually using the tools. Week 2: analysis and report, assessed against both what policies describe and what usage data reveals.

What you get

1. AI tooling and cost inventory — what is in use, by whom, at what cost, and what value is measured against it
2. Governance gap analysis — where controls are missing or untested
3. Vendor risk summary — lock-in exposure and cost trajectory at scale
4. Prioritised recommendations and 90-day plan skeleton

What we assess

1. Role clarity and expectations. Whether people know what is expected of them, and whether those expectations have kept pace with how the organisation has changed.
2. Career framework alignment. Whether the framework supports the actual behaviours and skills the work requires, and connects through to recruitment, reward, and development.
3. Strategic communication. Whether engineers hold the strategy in their minds and understand why the work they're doing matters.
4. Voice and inclusion. Whether engineers feel genuinely listened to, and whether their input reaches the people who make decisions.
5. Enabling environment. What the culture at leadership level looks like in practice, and whether it creates the conditions for the engineering organisation to do its best work.

How it works

Two weeks. Week 1: reviewing role definitions, career frameworks, and any existing people or culture data, then talking to engineering leaders, people managers, and a cross-section of engineers. Week 2: analysis and report, drawing from both what frameworks describe and what people actually experience day to day.

What you get

1. People model assessment — where expectations, career frameworks, and culture are aligned and where the gaps are
2. Communication and inclusion review — how well strategy reaches teams and ground-level insight reaches leadership
3. Leadership environment summary — what the culture at leadership level is creating for the rest of the organisation
4. Prioritised recommendations and 90-day plan skeleton