How I Would Assess Your Engineering Organisation in 2 Weeks

People sometimes ask me what I'd look at if I had two weeks inside their engineering organisation. Here's an honest answer.

Not a polished consulting framework - an honest account of the signals I actually prioritise, the questions I find most revealing, and the patterns that tell me more in thirty minutes than a week of workshops.

---

Day One: Follow the Work

Before I talk to anyone in leadership, I want to understand what actually happens when a team tries to ship something. I ask one question to start:

"Walk me through the last thing you released. From when someone decided it needed to happen to when a real user could use it."

The answer to this question contains almost everything I need. How people tell the story reveals how they understand the system. The pauses reveal where the pain is. The things they skip over reveal what they've normalised.

I listen for:

• How long the story is (longer usually means more handoffs)
• When governance appears (early = enabling, late = gating)
• Who else had to be involved (cross-team dependencies are flow killers)
• How confident they are that it actually worked (observability tells this story)

---

The Deployment Conversation

I then ask the engineering leaders, not the teams: "How often do you deploy to production?"

The first answer is almost always optimistic. I push for specificity - for the last month, not the average. I ask who approves the deployment. I ask what happens if it goes wrong. I ask how long it takes to recover.

The deployment pipeline is the heartbeat of an engineering organisation. Its rhythm - how frequent, how reliable, how automated - tells you more about the organisation's technical health than any architecture diagram.

In high-performing organisations, deployment is boring. It happens constantly. Nobody is particularly stressed about it. When something breaks, the organisation can see it immediately and fix it quickly.

In struggling organisations, deployment is an event. There are release managers. There are late nights. There are post-release war rooms. And there is, underneath it all, a quiet fear that the next release might be the one that goes badly.

That fear is a signal. Not of bad engineers - of a system that has not been designed for safety.

---

The Questions That Matter

Beyond the deployment conversation, there are five questions I return to in almost every assessment:

1. What would happen if your best engineer left tomorrow? This reveals how much institutional knowledge is concentrated in individuals rather than documented in systems. Bus factor - the number of people whose departure would cause serious disruption - is a leading indicator of organisational brittleness.

2. How do teams find out when something is wrong in production? The answer should be "automatically, before customers do." If the answer involves customers reporting issues, or involves specific engineers who "know how to read the logs," you have an observability problem and a knowledge concentration problem simultaneously.

3. What's currently blocked, and why? I ask this of every team I spend time with. The list is usually longer than anyone in leadership knows. The reasons cluster around a small number of recurring patterns: shared environments, approval queues, unclear ownership, architectural coupling. These clusters point to the real constraints.

4. What would you change if you could change one thing? The most illuminating version of this question is asked of engineers at all levels, not just leads. Engineers deep in the work usually know exactly what the constraint is. They often don't feel safe saying it.

5. How does engineering connect to what the business cares about? The answer reveals whether teams are building features or delivering outcomes. Feature factories - organisations that measure success by throughput rather than customer impact - are visually indistinguishable from outcome-oriented organisations, right up until the moment when the product stops growing.

---

What I'm Looking For

Across two weeks, I'm assembling a picture along the five BVSSH outcomes:

Better - Is the codebase getting healthier or more fragile over time? Is technical debt visible, owned, and managed - or invisible and growing? Are defect rates tracked and trending in the right direction?

Value - Are teams aligned to customer outcomes, or to delivery throughput? Do they know whether what they shipped actually worked? Are OKRs or equivalent measures connected to what teams actually build?

Sooner - What does the full lead time look like from idea to production? Where are the queues? What's the deployment frequency, and what's the ceiling and why?

Safer - What's the change failure rate? How long does recovery take? Are changes being deployed in ways that limit blast radius? Is security a gate or a practice?

Happier - What's the attrition rate? Are engineers growing? Do they have agency? Is psychological safety present - meaning, do people feel safe raising problems?

---

What "Good" Looks Like

By the end of two weeks, I'm not looking for perfection. I'm looking for self-awareness and direction of travel.

The best organisations I've worked with are not the ones scoring highest on every dimension. They're the ones that:

• Know where they are with honesty
• Understand why they're there
• Have a clear theory about what to change and in what order
• Are actually changing it, measurably

That combination - self-awareness, theory, action, measurement - is the hallmark of a system that improves. Everything else is just a snapshot.

If you want to know where your organisation sits, the two weeks are available.