‍

The first ninety days in a new technical leadership role are not primarily about making changes. They are about building an accurate picture of what exists, what it is costing the business and what the highest-priority decisions are. The leaders who move too quickly in this period, who arrive with a clear view of how things should be done and start acting on it before they understand the specific context, tend to create problems that take longer to resolve than the ones they were trying to address.

The ones who use the ninety days well come out of it with something more valuable than a list of findings. They come out with the credibility, the relationships and the diagnostic clarity to make good decisions from a position of genuine understanding rather than informed assumption.

Days One to Thirty: Understand Before You Assess

The first month is for listening and observing more than assessing. The goal is to understand the business context that the technology exists to serve, the commercial pressures the engineering team is operating under, and the history of the decisions that produced the current state of the codebase. That history matters because almost every decision that looks wrong in isolation was reasonable given the constraints of the moment it was made. Understanding those constraints is what separates an assessment that the team will trust from one that feels like criticism from someone who was not there.

The conversations that matter most in this period are with the people closest to the work. The engineers who have been there longest know where the bodies are buried, which parts of the system are genuinely fragile versus just unfamiliar and what has been tried before and why it did not work. Those conversations are worth more than any amount of code review conducted without that context.

The most common mistake a new technical leader makes in the first thirty days is confusing familiarity with understanding. Reading the codebase tells you what was built. Talking to the people who built it tells you why, and the why is almost always where the useful insight lives.

Days Thirty to Sixty: Build the Map

The second month is for turning the understanding built in the first into a structured picture of the technical landscape. This is not a formal audit, but it is the foundation that a formal audit would build on. The goal is to have a clear view of what systems exist, who owns them, what the most significant technical risks are and where the engineering team's capacity is actually going.

The capacity question is often the most revealing. A business where the engineering team is nominally working on a roadmap but spending forty percent of their time on unplanned work and incident management has a different set of priorities than one where that proportion is ten percent. The roadmap cannot be evaluated honestly without understanding what is competing with it for the team's attention .

This is also the period to build the picture of technical debt in business terms. Not as a list of things that should be refactored, but as a set of specific costs; the delivery velocity being lost to complexity, the risk being carried in systems with unclear ownership or poor test coverage and the incidents that have happened and that are likely to happen again if nothing changes.

A technical debt assessment that can be presented to a board in business terms is worth considerably more than one that requires translation. The goal in month two is to build that assessment, not to fix anything yet.

Days Sixty to Ninety: Align on Priorities

The third month is for turning the map into a plan and getting the organisation aligned around it. This involves two conversations that need to happen in the right sequence. The first is with the engineering team, presenting the findings, inviting challenge and building the shared understanding that will make the plan credible and executable. The second is with the board and executive team, presenting the business implications of the findings and proposing a prioritised set of investments with clear outcomes attached.

The board presentation is the one that most new technical leaders underinvest in. They spend the ninety days building a thorough technical picture and then present it in terms that are accurate but not actionable for the audience they are presenting to. A board that cannot connect the technical findings to the commercial risks and opportunities they care about cannot make good decisions from the presentation and tends to defer or dilute rather than act.

The priorities that come out of this presentation should be specific, time-bounded and connected to outcomes the business is already trying to achieve. Not a comprehensive remediation programme, but the two or three investments that carry the most material consequence if deferred and that have the clearest return in terms of delivery capacity, risk reduction or commercial enablement.

The Role of External Support

A new technical leader inheriting a complex codebase in a PE-backed business is operating under significant pressure. The expectation to have a clear view quickly, while simultaneously managing a team, engaging with a board and keeping the existing operation running, is real and substantial. External technical support in the first ninety days, whether through a structured review process or access to experienced technical advisors who have been through this before, can compress the time it takes to reach clarity and reduce the risk of the early decisions that will shape the next phase of the business.

At Gathered and Found, we work alongside new technical leaders and the businesses they join to provide the structured review, the independent perspective and the board-level communication support that makes the first ninety days as productive as possible.

At Gathered and Found, we support new technical leaders and the PE-backed businesses they join through the critical first ninety days. If you are navigating this transition or bringing in new technical leadership, get in touch.

‍