Reinsurance. Energy trading. Industrial manufacturing. Insurance software. Two SaaS scaleups. Six companies, six first 90-day engagements, five different industries. The codebases look different. The team structures are different. The business contexts are very different.
The three problems waiting for me in week one are always the same.
I don't mean similar. I mean structurally identical — the same root causes producing the same symptoms across organisations that share almost no other characteristics. After the sixth time, I stopped being surprised and started writing it down.
This post is what I found, why it happens, and what it costs the companies that don't address it before a technology leader walks in the door.
Problem One: The Architecture Nobody Owns
In every engagement, I ask the same opening question: "Who owns the technical architecture of this system?" In every engagement, the honest answer is the same: nobody, really.
There's usually someone who built it. At the Fortune 500s, that person left years ago. At the scaleups, they're the founding engineer who is now head-down in a feature team and hasn't thought about the top-level architecture in 18 months. There are decisions nobody can explain — not because the knowledge is lost, but because the decisions were never made explicitly. The system arrived at its current shape through a thousand small choices made locally, under pressure, without a coherent overall direction.
The symptom that makes it visible in week one: when I ask why a particular architectural decision was made, the answer is "that's just how it grew." When I ask how the current architecture handles the scale the business expects in 24 months, the room goes quiet.
This is not a technical problem. It's a governance problem. Architectures drift when no one holds accountability for the whole — when every team optimises locally and nobody is responsible for the emergent shape of the system. In large enterprises, it's a function of scale and team turnover. In scaleups, it's a function of moving fast early and never stopping to document what was decided and why.
The cost is not abstract. Architecture debt is the primary drag on every delivery estimate I've seen in these engagements. When teams don't understand the overall shape of the system, every change carries hidden integration risk. When the architecture isn't documented, every new engineer has to reverse-engineer it from code — an investment that pays zero forward dividend because there's nowhere to write it down that anyone will read.
The ADR gap
Architecture Decision Records — the lightweight practice of writing down significant decisions, the context behind them, and the alternatives considered — exist in none of the six organisations at the start of the engagement. By month three, they exist in all of them. The practice is not complex. The absence is simply because nobody owned the habit.
What I do in the first 30 days: a structured architecture walkthrough with every team that touches a significant part of the system. Not to audit — to document. The goal is a living architecture map that describes what exists, what the team believes they're building toward, and the explicit gaps between the two. Once that document exists, the conversations change. Problems that were invisible become visible. Trade-offs that were implicit become explicit. The architecture can be governed because it can be seen.
Problem Two: Engineering Capacity Is Being Consumed by Things That Aren't Engineering
In every engagement, one of the first exercises I run is a simple one: map where engineering time actually goes over the previous four weeks. Not where the roadmap says it should go. Where it actually went.
The results consistently produce the same shape. Roughly 30–40% of available engineering capacity is being consumed by three categories that aren't product development:
Unplanned reactive work. Production incidents, urgent bug fixes, customer escalations that get routed to engineering because there's no other path, integration debugging for external partners. This work is real — it can't be ignored — but it's not being tracked, not being managed, and not being reduced over time because it's treated as overhead rather than a solvable system problem.
Internal tooling and process gaps. Engineers spending hours per week on tasks that should be automated: manual environment provisioning, deployment processes that require human steps, monitoring that alerts but doesn't diagnose, test suites that require maintenance overhead that nobody budgeted for. These are costs that compound. The teams have adapted to them so thoroughly that they've stopped registering as waste.
Context-switching overhead from organizational misalignment. Engineering teams that are nominally working on a sprint but are actually answering questions from sales, preparing data exports for customers, supporting last-quarter features that weren't handed off properly, and attending meetings that require their presence but not their decision-making. This one is hardest to quantify and most damaging to morale.
The aggregate cost is significant. In the most extreme case — a 40-person engineering organisation at an energy software company — the analysis revealed that 38% of engineering time over the previous month had gone to these three categories. The team felt consistently overwhelmed and behind schedule. When we removed the invisible load from the numerator, the team was actually productive on planned work at a reasonable rate. The throughput problem was a load problem, not a performance problem.
| Category | Typical share of engineering time | Solvable in 90 days? |
|---|---|---|
| Unplanned reactive work | 15–25% | Partially — requires incident management process |
| Internal tooling and process gaps | 8–15% | Yes — platform engineering investment |
| Context-switching and org misalignment | 5–12% | Yes — team topology and stakeholder boundaries |
| Planned product development | 55–70% | This is the target floor |
The invisible budget
Engineering capacity consumed by unplanned work is almost never tracked in the organisations I enter. It doesn't appear in sprint velocity metrics. It doesn't appear in roadmap burn-down. It appears as "the team is slower than we expected" — a conclusion that leads to hiring pressure when the right answer is process investment. Measuring the load before adding headcount is the correct sequence.
What I do in the first 30 days: instrument the invisible. Every team starts tracking time in four buckets: planned product work, unplanned reactive work, internal process overhead, and meetings. Four weeks of data changes every conversation about capacity, hiring, and roadmap commitments. The measurement alone reduces reactive work — because once it's visible, engineers escalate less and managers triage more aggressively.
Problem Three: The Engineering Organisation Is Not Wired for the Business Stage
This one is the most uncomfortable to name, because it implies the organisation was structured wrong. It wasn't, necessarily. It was structured right for the stage it was at — and the business moved on without restructuring.
In the scaleups, the pattern is a flat, generalist team that was right for the product-market-fit stage and is now wrong for the scale stage. Engineers who should be specialising are still rotating across every part of the system. There's no platform capability, so every product team rebuilds infrastructure from scratch. The founding engineer leads through direct communication with everyone, which worked at 8 people and doesn't work at 25.
In the large enterprises, the pattern is the inverse: an organisation structured for stability and process compliance that needs to move faster than its governance allows. Approval chains that made sense for waterfall delivery create three-week delays in a world that needs two-week iterations. Centralised architecture review boards that protected legacy systems are now blocking cloud-native product teams.
In both cases, the organisation is fighting itself. The structure that exists is working against the outcomes the business needs. Engineers feel it — as friction, as bureaucracy, as "why does this take so long" — without having the language to name it.
The signal I watch for in week one: how long does it take from a decision to a deployed change? In every engagement, this number has been measured for the first time by the end of week two. In healthy organisations, it should be hours to a few days for most changes. In the organisations I enter, it's typically one to four weeks, with outliers much longer. The gap between where it is and where it should be is a direct function of how misaligned the organisational structure is with the business's actual needs.
Team Topologies as a diagnostic, not a prescription
Matthew Skelton and Manuel Pais's Team Topologies framework is the most useful single lens I've found for diagnosing organisational misalignment. The question isn't "should we reorganise?" — it's "what is the current organisation optimising for, and is that the right thing?" In every engagement, the answer to the second question is at least partially no.
What I do in the first 30 days: map the actual flow of work from idea to production, identify every handoff, and count the wait time at each one. The bottlenecks are almost always at team boundaries, not within teams. That tells you where the organisational wiring is wrong. The restructuring itself takes longer — 60 to 90 days at minimum — but you can't start without the map.
Why These Three, Every Time
The pattern isn't a coincidence. These three problems share a root cause: they require someone to hold accountability at the level above the individual teams. Architecture ownership is a cross-team concern. Capacity management is a leadership function. Organisational alignment requires someone with the authority and the perspective to see the whole.
When that accountability doesn't exist — when there's no CTO, or the CTO role has been held by someone without the bandwidth to operate at the system level — these three problems are structurally guaranteed. They're not failures of the individual engineers. They're the predictable result of a missing function.
The causal chain looks like this:
What This Means If You're About to Hire
If you're preparing to bring in a fractional or interim CTO — or running a permanent search — there are three things you can do before day one that will compress the first 90 days significantly.
First: pull four weeks of engineering time data by category, even roughly. Anything that gives you a directional picture of where time goes is useful. You don't need precision — you need to stop the shock of discovering the number in week three.
Second: ask each team lead to name the three architectural decisions they're most uncertain about. Not a full architecture review. Just the honest list of "we don't know if this was right." You'll get your map of where the architecture ownership gaps are.
Third: write down how long it actually takes to get a change from decision to production. Not the policy answer. The actual answer, for the last five meaningful changes. That number is your organisational health indicator.
None of these tasks require a technology leader to complete. They're acts of organisational self-awareness that make the first conversation — and the first 90 days — dramatically more productive.
The pattern in the first 90 days is always the same. What varies is how prepared the organisation is to address it.
If you're about to start a new technology leadership engagement — or if you're looking for someone to run one — let's talk. Book a 30-minute discovery call and we can work through whether the pattern I've described matches what you're experiencing.