This misalignment happens because the organisation lacks a shared, explicit standard. Without it, an EM defaults to shipping code instead of resolving cross-team dependencies, or they rely on an inherited team they cannot actually grow. The system never demanded they act as a leader. This creates an inconsistent management layer where engineers stall in their careers under one manager and thrive under another, creating a culture with unnecessary friction.

Managing managers one by one does not scale. Beyond a certain size, leadership is not about ad hoc individual coaching; it becomes explicit organisational design, defining and standardising the management layer to ensure consistency across the engineering organisation.

Standardising outcomes

Introducing a standardised competency framework creates friction: some long-term managers will push back, arguing that the goalposts are moving and that the organisation operated successfully without this extra bureaucracy. This pushback is a predictable response to protect their time and autonomy.

Raising the bar will cause a short-term drop in velocity. Not only by people adapting to the new standard, but also by attrition. Some managers will decide to leave the organisation, while others will fail to meet the new expectations and be managed out. A senior leader must accept this trade-off: sacrificing short-term delivery capacity to secure a consistently higher baseline of management quality that will benefit the entire organisation.

However, this transition requires deliberate investment: senior leadership reduces this friction by coaching managers on how to apply the framework, temporarily redirecting their energy to work effectively with the new standard.

To maintain autonomy and avoid micromanagement, the framework must standardise expectations, not judgement. A scalable framework defines the expected outcomes (e.g. running coaching-focused 1:1s, creating development plans) while leaving the execution path to the manager. Include example behaviours for each expected outcome, ensuring they are guidelines rather than checklists. Later, the calibration process assesses whether the manager’s chosen path delivered the expected outcome.

Avoiding the promotion checklist trap

Standard company-wide career stages inevitably fail engineering teams because they become promotion checklists rather than daily tools to increase impact. Decoupling role proficiency from the company-wide career stage removes this issue. Split proficiency into granular tiers (e.g. Fundamental, Established, Role Model) for each competency. This turns the framework into a continuous development tool, providing a shared language for coaching (e.g. proving an EM can be at a senior career stage but “Fundamental” in a brand-new competency).

Ensuring cross-functional impact

The goal of the framework is to create a scalable multiplier effect below the executive layer. Defining every single role creates unnecessary overhead. Exclude the VP and Director levels and target the layers managing 4-6 reports, where scalability is strictly required.

Leaders in an organisation define its culture. Standardising the Engineering management layer is powerful, but it creates friction if the rest of the functions in the Technology department operate to a different standard. Splitting the framework in two parts solves this. The foundation consists of shared core competencies applicable to all functions within the broader department (e.g. Engineering, Product Delivery, Design). The second part contains the specific role expectations purely for Engineering.

An engineering leader cannot define the specific expectations for product or delivery managers. However, having shared core competencies aligns the entire triad to a common baseline, reducing friction even if other functions have not yet defined their own frameworks.

Managing the new bottlenecks

Raising the management bar immediately strains the hiring budget. Recruiting to a higher standard becomes difficult if the existing compensation bands do not adapt to the new expectations.

Upgrading the management framework also exposes cracks in other tracks. If the individual contributor track lags behind, there is an imbalance. The progression from senior engineer to engineering manager becomes too wide or unclear, and the supposedly lateral move from staff engineer to engineering manager turns into a difficult diagonal move.

When you accept a short-term drop in velocity to improve your management layer, Product and Sales will feel the impact. If you build this standard in a silo, you guarantee political friction. You need to negotiate this transition with your peers from day one, pushing Product leadership to align their own expectations in parallel.

Standardising the engineering management layer fixes your scaling problem but reveals your next-order constraint: it forces the rest of the business to either adapt to your new baseline or exposes them as the new bottleneck.

Teams will generate code faster than they can review it, creating a PR overload that will trigger cognitive fatigue. Engineers, overwhelmed by the volume, will start rubber-stamping reviews.

The operational danger with AI is over-trust. Rubber-stamping introduces a silent architectural drift that bypasses traditional guardrails, degrading the integrity of the code. By the time the company realises, it has already damaged key business metrics.

Shift-left prototyping

In an agentic SDLC, product managers no longer wait for designers to prioritise requests or engineers to build a POC. Multi-modal models allow them to generate disposable prototypes, delivering even higher value when linked to the company’s context and design systems.

This is a systemic change. As the cost of a prototype drops to near zero, their number will spike. While this speeds up product discovery, it introduces a big risk: the pressure to release mock-ups. Leaders must build a culture that encourages rapid exploration while enforcing a hard boundary: these mock-ups never go to production. But culture is often not enough. Engineering must implement hard CI/CD boundaries that block prototype deployment, and partner with Product to define a strict process from disposable mock-up to production-ready architecture.

From code creator to system editor

The role of engineers moves from writing code to acting as a human-in-the-loop (HITL) assessing risk, guiding AI agents to generate PRs that align with the team’s approved architectural patterns.

Human engineers make assumptions based on unwritten specifications, consider context from leadership presentations, and flag edge cases during implementation. AI agents only build what is documented, they do not infer business context or edge cases. This is a massive shift in the SDLC. Pointing an internal MCP server at stale documentation or dropping an agents.md file into a repository is not enough. Product and senior engineering must carry the extra load of specifying architectural direction and edge cases upfront.

Because static analysis and unit tests are not enough to catch hallucinations, the pipeline needs multi-agent validation before the human-in-the-loop stage. Engineering teams can no longer just maintain standard CI/CD pipelines, they must build an agentic harness: a layered verification infrastructure of cross-model checks, semantic linters, and strict architectural constraints. Inside this harness, an independent agent scans the generated PR for hallucinated dependencies, loss of architectural context, or deviations from the defined guidelines. However, this introduces new trade-offs: it increases pipeline execution time and token spend. Engineering leaders must balance this against the cost of human review fatigue. This ensures the HITL focuses on validating strategic intent rather than chasing down the agent’s mistakes. Line-by-line code reading is no longer the default verification method, it becomes an escalation path only for sensitive areas like security, severe architectural drift, or complex incident debugging.

System health and the token economy

Higher PR throughput combined with higher hallucination risk inevitably increases the Change Failure Rate (CFR). Without a corresponding decrease in Mean Time To Recovery (MTTR), this delivery speed will cause customer disruption. As we move from human pace copilot usage to fully agentic pipelines, system health is defined by the tension between these two metrics.

This does not mean that defects have less impact simply because an agent can draft a fix faster; a critical failure is still disastrous. However, because agentic velocity multiplies the absolute number of deployments, reducing MTTR shifts from a standard operational goal to a critical survival requirement.

Because a low MTTR is the safety net, the system requires automated incident orchestration. The pipeline uses external agentic tools, such as incident.io or Rootly, to perform semantic log analysis and share the root-cause output directly with the PR-drafting agents. Engineers then review these remediation PRs and control the timing of their deployment.

While tokens are getting cheaper, newer models are becoming increasingly complex. Engineering leaders must track token consumption with the same rigour they apply to cloud infrastructure spend. Project budgets account for the specific model complexity required. If the token cost of generating boilerplate is higher than the engineering time saved, the workflow gets deprecated.

The new reality of pipeline bottlenecks

As prototyping and code generation get faster, the bottleneck moves downstream. Concurrency limits on the CI/CD pipeline, and the cognitive load on the human-in-the-loop merge gate become the new constraints.

Even if engineering achieves near-infinite delivery speed, the final limit is how fast customers can absorb new features and how much real-user UX research the business can do to validate them. To survive this shift and double engineering impact, leaders must stop optimising only for output volume and start building the feedback loops required to measure real-world impact.

In this environment, we prioritise engineering resources for large partnerships to secure higher ROI, but this creates a strategic blind spot: it ignores the long tail of agile, tech-savvy partners ready to integrate and scale alongside us.

The legacy approach of proprietary data silos is no longer viable. Having the source of truth and documentation in the heads of the people performing the manual mapping creates a systemic risk. Furthermore, partners often lack the incentive to maintain these integrations, so you bear the full cost of maintenance when their systems change without notice.

This is a clear opportunity cost. When a competitor automates this mapping (and this is no longer a question of if, but when), the traditional billable model becomes a liability that slows down your time to market and leads to an inevitable loss of market share.

From strict validation to semantic interpretation

Traditional schema validation based on JSON or XML is too rigid when you face the reality of hundreds of different partner formats. While this approach works for a handful of corporate partners, it doesn’t scale to the long tail. Until very recently, the only option was constant prioritisation and hoping that engineering capacity would eventually be found for smaller integrations.

But agentic AI has disrupted the integration landscape. We must move away from the false choice between perfect data and fast onboarding. Instead, we build architectures that ingest context and intent, accepting a manageable margin of error in exchange for infinite scale.

This shift requires providing context and intent directly to agents via MCP, allowing them to understand why a field exists rather than just its data type. It also requires a deliberate trade-off: sacrificing the deterministic perfection of manual mapping for the non-deterministic scale of probabilistic ingestion. By applying variable governance (rigorous manual review for high-value contracts and automated paths for the long tail) we maintain a measurable risk profile without restricting growth.

Managing risk with multi-layered validation

Many parts of an organisation, especially outside of technology, assume that testing should reduce error to zero. However, testing is only one layer in a broader strategy to reduce the risk and impact of errors. Moving to agentic consumption requires implementing additional layers of testing, specific governance for non-deterministic systems, and a new set of technical checks.

As the architecture shifts to a probabilistic model, communication and MTTR (mean time to restore) become even more critical. A clear narrative helps the wider organisation understand this new way of working by explaining the strategic reasons for the shift, the benefits of scale, and the specific resourcing plan to address inevitable issues. And since we expect to have more issues, MTTR becomes our main lever for stability. Because hallucinations will occur (similar to bugs released in traditional systems), the organisation must be ready to weigh the positive impact of moving faster against the negative impact of the occasional issues caused by an automated, non-deterministic architecture. In this environment, the speed of recovery (MTTR) often has a larger business impact than the prevention of every individual error.

Maintaining quality in a non-deterministic system requires the same domain expertise held by our current teams. We shouldn’t outsource this to a siloed AI squad, we should embed that expertise directly into the new reliability guardrails.

To move the conversation from hoping the model is right to a rigorous engineering standard, the system relies on a confidence score generated through multiple independent validation layers. We cannot trust the model’s own self-assessment, the architecture uses semantic distance to compare outputs from different models, and a dedicated critic agent to audit the results against a strict set of business constraints. These results are then passed through a final deterministic gate (a standard schema validator) to ensure the structural integrity of the output.

This multi-layered mechanism transforms non-deterministic output into a measurable risk profile. It allows the organisation to set precise thresholds: high-confidence mappings move to production with human oversight, while low-confidence results trigger a human-in-the-loop exception. This ensures human expertise is reserved for resolving complex ambiguities rather than performing repetitive, synchronous validation.

From linear costs to competitive advantage

Agentic consumption decouples headcount from partner volume, ending a cycle where small differences made code reuse impossible and created a hard growth ceiling. While a low-growth company might use these gains to reduce costs, the strategic choice is to reinvest this capacity into the reliability and tooling required to manage a non-deterministic ingestion engine. This shift moves engineering focus from delivering bespoke mappings to improving the system success rate. However, it creates a new constraint: the need for advanced observability for the reasoning integrity. The next strategic priority is building the observability stack required to audit these autonomous decisions at scale.

By removing the onboarding bottleneck, we ensure that customers pay earlier and sales efficiency increases. This shifts integration from a capacity constraint to a competitive advantage. In this new environment, engineering leadership wins not by shipping code, but by governing the systems that ship it for us.

Engineering metrics are not for monitoring engineers, they are levers for business growth. To bridge the gap between technical effort and business value, we must focus on signals like order conversion, infrastructure cost per order, and customer sentiment. Linking these metrics to specific initiatives transforms engineering from an opaque cost centre into an investment centre with a clear return on investment.

I categorise these signals into three tiers:

1. Board level: unit economics (e.g. infrastructure cost per order), order conversion, and customer feedback

2. System level: technical viability, risk, and delivery flow

3. Team level: organisational health, including retention and engagement

Focusing on the trend of these metrics, rather than isolated snapshots, allows leaders at every level to maintain a clear direction towards delivering value. While this mental model focuses on engineering, the CTO and CPO must share these metrics. This bridge requires a shared data language to operate as a single front. Alignment does not happen naturally, it requires an explicit agreement that unit economics are as important as feature delivery.

The board level signal: unit economics

Negotiating with a CFO requires moving beyond baseline expectations like uptime. While critical, uptime is a prerequisite, not a strategic lever. In contrast, discussing unit economics, such as cost per order or cost per licence, is a strategic conversation that aligns engineering investment with business profitability.

Justifying a roadmap pause to fix tech debt is a difficult sell to a board. However, framing that same effort as a way to drive efficiency by reducing the cost per order or accelerating the delivery of features driving extra revenue changes the calculation. This approach transforms a technical burden into a gross margin improvement.

These metrics are critical during budget season. Data-driven budgeting shifts the focus from departmental spend to return on investment. If the trend for cost per order is decreasing, an increase in absolute spending becomes a signal of healthy scaling rather than uncontrolled cost.

The system level signal: risk, complexity, and flow

While board metrics track financial performance, system metrics measure the viability of the technical choices. Standard frameworks like DORA or SPACE focus on efficiency and productivity. They inform how fast the organisation is moving, but they rarely signal if you’re moving in a dangerous direction. To avoid this, leaders must monitor signals that reveal accidental complexity, where architecture or tooling choices become bottlenecks rather than enablers.

For example, a project designed around an event store may look like the best technical solution initially. However, as work progresses, the choice of architecture may add a level of complexity that makes the project unviable. This risk can be identified by tracking specific system level trends: pending work growing faster than completion rate, and an increasing list of trade-offs required to deliver each phase.

When introducing new technology, I use a walking skeleton to bring risks forward, surfacing architectural bottlenecks before the cost of reversing becomes too high. The most critical red flag is if an ETA remains unchanged or is pushed back while scope or complexity increases. At this point, you must intervene to reallocate capacity or narrow the scope, rather than hoping the team will catch up.

The pivot: metrics as a decision trigger

There are moments when board and system signals collide. If an initiative has an expanding ETA (system signal) while the organisation faces a market share risk due to a missing strategic capability (board signal), the current path is no longer viable. At this point, leadership must intervene to stop the sunk cost fallacy.

We terminated our event store project because the system signal (expanding timelines) clashed with a board level threat (loss of market share). It was a hard trade-off: we sacrificed long-term efficiency to protect immediate revenue growth. While data helps justify the pivot to the board, it rarely solves the impact to morale. I had to manage the direct risk of losing senior engineers who saw the project as a career driver. We mitigated this by linking their skills to the new strategy, although we also accepted the risk that some engineers might leave for more technical challenges.

Framing this decision is key. This deliberate pivot signals investment logic rather than team failure. When communicating this to the teams, data is the most effective tool for maintaining morale. By showing that the project was cancelled due to a changing business case rather than poor engineering performance, you decouple individual professional value from project outcomes. This clarity allows engineers to transition to new priorities with their focus on the lessons learnt rather than the pain of a cancelled roadmap.

The team level signal: connecting code to value

Teams often view metrics as a top-down monitoring tool that prevents them from focusing on delivering business value. To avoid this, leaders must use metrics to provide autonomy. If a team can reduce the cost per order while maintaining quality, metrics like tickets completed become irrelevant. Then the team moves from shipping code to delivering value.

In our all-hands, I own the narrative by explicitly linking technical milestones back to strategic outcomes. We work with each lead to set quarterly objectives that map directly to these board level signals. This helps every person to understand how a single pull request impacts a board level metric like cost per order.

Beyond economics, I monitor team engagement and retention as leading indicators of delivery stability. These human signals often flag that delivery stability is at risk before the financial metrics begin to drop. By tracking these trends, I can intervene in organisational health before the system begins to fail.

Conclusion

Remember: using the right metrics is about giving teams autonomy by providing context through transparency, allowing them to make trade-off calls independently. As an engineering leader you must provide the right data for the team to reach the desired destination. This helps create a culture where every engineer understands the impact of their work on the company’s results. When an engineer sees the cost per order trend, they aren’t just writing code, they are managing the company’s gross margin.

When engineering metrics meet business signals, you are no longer simply reporting status. You are using these metrics as levers for growth to help plan the company’s budget, transforming technical performance into strategic profit.

I led this transition during Project Terry, a high-stakes integration with a major global partner (think Amazon or Netflix). We faced a non-negotiable four-month deadline for a six-month scope. Failure would have had a material impact on our annual objectives and blocked future expansion into new markets. To ensure total focus, I negotiated a six-month roadmap pause across my entire area, halting all non-critical development to meet this single commercial objective.

To maximise bandwidth, I replaced sync-heavy meetings such as all-hands meetings with lighter, async communication streams. I also delayed personal development time and the annual objective-setting cycle. These were not responses to team failure, they were strategic necessities to reduce communication overhead. While Engineering Managers initially pushed back to protect their teams, I bridged the gap between the team-level metrics and the global commercial requirements to ensure collective focus.

Operational focus

Effective wartime leadership requires a shift in organisational boundaries. This transition relies on three levers: strategic alignment, bridging the context void, and modified autonomy.

Strategic alignment

When requirements keep changing, timing is as important as transparency. I partner with Staff+ engineers to define technical red lines and identify strategic technical shortcuts before involving the wider leadership team. During Project Terry, I ring-fenced my managers, protecting their cognitive capacity for existing roadmaps until the delivery strategy was clearer. This ensured that when development started, the team was fresh and the execution path was defined.

Bridging the context void

When teams lack context regarding a high-stakes project, they fill the void with their own assumptions, often interpreting high pressure as management incompetence. To prevent this, leaders must treat teams as commercial partners. I bridged this by presenting company financial data to the entire area, translating abstract metrics into a language they understand. As the team understood the stakes, the project transformed from an arbitrary deadline into a shared mission.

Modified autonomy

Wartime delivery demands a shift from consensus to a disagree and commit model. In this mode, the cost of a delayed decision far exceeds the cost of an imperfect one. I negotiated a reduced feature set with Product and Design, stripping the scope to the minimum viable requirements for launch. This is when previous investment in building high-performing teams pays off, as the organisation relies on their ability to execute within tighter technical boundaries.

Navigating unknown unknowns: the dual-track strategy

Linear problem-solving is a luxury that fixed-date delivery cannot afford. If a late discovery threatens the launch, you must be willing to pay for redundant paths to guarantee a successful outcome.

We faced this during the Terry integration when an incompatibility between our regional architectures and the partner’s account structure was discovered late. To mitigate the risk, we followed a two-track delivery model: one group worked on a tactical “quick and dirty” solution to unblock the launch, while another built the sustainable architectural fix. We accepted the waste of duplicate effort as an investment in delivery certainty. We maintained the discipline to abandon the tactical effort the moment the sustainable solution was confirmed. In wartime, the cost of redundancy is lower than the cost of failure.

Systems thinking also requires looking beyond the codebase. If software cannot meet a requirement in time, you must find an operational bridge. For features not ready for go-live, such as customer service tools, you may need to shift from technical requirements to a manual workaround, e.g. providing raw database queries for support staff or temporarily increasing operational capacity.

Maintaining high intensity for months inevitably creates emotional debt. A leader must proactively manage this by monitoring fatigue. During the Terry project, I maintained feedback mechanisms, specifically skip-level 1:1s, to monitor sentiment, allowing space for disagreement. I prioritised well-being through actions, such as approving immediate leave and ensuring efforts were reflected in talent reviews and promotions. Leadership in this mode is about holding a hard line on delivery while being radically empathetic toward the people carrying the load.

The recovery: paying the credibility debt

Wartime leadership is a high-interest loan against your culture. If the recovery phase is not managed with rigour, the result is permanent burnout and attrition. A leader’s responsibility during the transition back to peacetime is to pay down the technical and emotional debt incurred during the project.

Defending debt repayment

Strategic shortcuts are delivery loans that must be accepted by the business. During Project Terry, I ensured aftercare as a non-negotiable milestone, equal in priority to the launch itself. A mature leader must enforce this boundary. Allowing the business to skip the repayment phase destroys the team’s trust and turns the codebase into a liability. I treated the post-launch recovery as a hard constraint on the next quarter’s capacity, ensuring the system’s health was restored before the next cycle began.

The delivery addiction trap

The most dangerous side impact of wartime success is velocity addiction, where stakeholders attempt to normalise unsustainable output. I mitigated this from day one by categorising our intensity as a delivery loan, one with high interest rates. Throughout the project, I explicitly communicated that this pace was a response to a unique commercial moment, not a new baseline. Post-launch, I accepted a temporary dip in velocity, rejecting new high-priority requests to allow the system to stabilise and prevent long-term attrition

Restoring social capital

Restoring morale requires fulfilling every promise made during the wartime pivot. I prioritised the return to peacetime rituals: reinstating personal development time, approving holiday requests, and restoring standard meeting cadences. We closed the project with an in-person gathering to celebrate the success and hear from C-level leadership explain the specific commercial impact of the work to the teams. Fulfilling these promises is how a leader restores the trust required to ask for another extraordinary effort in the future.

Conclusion

Standard methodologies are tools, not canon. Agile or scrum should serve the business goal, not the other way around. The most valuable skill for an engineering leader is contextual awareness: recognising when the environment has shifted and having the courage to switch modes.

High-stakes delivery acts as a catalyst for leadership development. During Project Terry, I used the tight deadline as a stretch opportunity for a Staff Engineer to own the technical deep-dive across multiple domains. Apart from solving a technical problem, it also accelerated our succession planning by proving they could operate at a Principal level under extreme constraints. These projects are more than delivery milestones; they are high-pressure environments that build and reveal the next generation of leadership

Your value is not found in your loyalty to a process, but in your ability to shape that process to meet the commercial moment. Wartime is not a license to abandon discipline, it is a period to be more intentional where you choose exactly which risks to carry. True seniority is the ability to recognise when the constraints of a system have become its main liability, and having the strategic clarity to adapt the rules until the objective is secured.

But the problem needs to be addressed before it becomes a crisis. Strategic re-architecture is not about cleaning code, it’s about ensuring alignment with the architecture strategy and the company’s vision

You probably have faced it before: that system that is getting increasingly difficult to maintain, slow to change and the teams keep complaining about. But when is the right time to re-architect a system? Success requires to distinguish between noise and signal. Noise is CV driven development or vague sentiment. The real signals are about the business: when the architecture no longer supports the company’s vision, when a metric supports that the system is impacting velocity, or when maintenance and incident management take most capacity for new value.

Phase 1: The strategy

With the problem defined, resist the urge to start coding immediately. Conduct discovery interviews not just with engineering consumers, but also with commercial stakeholders, to understand the gap between the system’s current capabilities and the market’s future needs.

Define the team topologies

To deliver at pace, make sure that you avoid the “design by committee” trap. Instead, structure the organisation into clear groups:

• Steering group: A cross-functional group of 3-4 leaders from Product, Engineering (you), Delivery, Commercial, Design, etc. to ensure the technical work stays aligned with the business priorities

• Builder teams (2-3 teams): The core group to define and implement the new architecture

• Consumer teams (3-30 teams): The internal customers who will migrate to the new system

The method: Strangler Fig

Big bang releases reduce trust because they are a money black hole without a visible return. I use the Strangler Fig pattern instead, to deliver incremental value. The main benefit is not the technical part, it’s how it helps with mitigating risks by releasing and validating the business case incrementally, which will help to maintain senior leadership confidence. If priorities change, we still have a working system with the value delivered so far, rather than a half-built sports car with no engine.

Staff+ leverage

Finally, rely on your Staff+ engineers to help shape the design and the scope.

• Ruthless descoping: We must define the trade-offs between feature parity and delivery speed. If a legacy feature adds 20% complexity but only 1% value, I empower Staff+ engineers to reject it or move to a Fast Followers list.

• Saying “no”: They must challenge stakeholders’ requirements (not only Product’s) that inflate the scope unnecessarily, making sure that we build only what is needed for the future state, not copying the current state or previous requirements.

Building the business case and securing buy-in

Securing buy-in isn’t about re-architecting. It’s about turning your technical plan into a compelling business case.

• Focus on your audience: Identify the budget holder, as well as anyone who might need convincing. Be empathetic, understand their concerns, and the impact of this proposal on their own strategy.

• The framing: Frame the problem using their language. Use terms like “blocking market expansion” or “opportunity cost”. Make sure that it gives them tools to support it when sharing with their colleagues, who might be impacted indirectly.

• The cost of inaction: Make the cost of inaction clear. Turn the positive impact of your proposal into the revenue the business will lose if you do nothing.

• Multiple options: Offer 2-3 options, with a clear preferred approach. This shows that you thought the problem through. Include target metrics, how you will track progress, timelines, and a list of known risks and how you plan to manage them.

Phase 2: The execution

Consumer teams have their own pressure and deadlines, so they will not voluntarily prioritise the migration unless friction is removed. To succeed, you must treat the migration as an internal product launch.

Driving adoption

We cannot rely on authority or endless road-shows to drive migration to the new system. Pushing a change will create friction, so instead I treat the new system as a product and focus on creating a “pull” mechanism through the following:

• The paved road: We invested in clear documentation and tooling. By automating 80% of the work, you lower teams’ resistance.

• Social proof: We didn’t target all teams at once, we focused on a high-influence team. We aligned the migration with their goals. We proved that the new system improved their deployment frequency and reduced their on-call noise. Once they share the positive impact, other teams will start asking to migrate.

• Senior leadership sponsorship: Bottom-up adoption is powerful, but not enough. Senior leadership sponsorship is not a one-off, they must keep reminding the organisation that the migration is a critical business objective, not optional work. We used company all-hands to share progress and celebrate the teams that have completed their migration, reinforcing the cultural message.

Resource injection

The most common failure is competition for limited resources. Teams will say that they don’t have capacity. Instead of negotiating for small bits of time, focus on solving the capacity issue.

• Be empathetic: Adjust the Builder team’s roadmap to accommodate the Consumer teams’ deadlines where possible. This is a deliberate trade-off: we sacrifice short-term output to secure long-term outcome.

• Create a migration squad: If a team is blocked, inject capacity. Either secure a temporary squad of contractors or use members from the Builder team to deliver the migration work for the Consumer teams. This will remove the resourcing argument and help stick to your timeline instead of theirs.

Handling cross-domain friction

Even with resources injected, you will face friction where a Consumer team’s leadership prioritises their own roadmap over the migration. Since these leaders are often your peers and sit outside the Steering Group, you cannot simply overrule them.

• Radical transparency: Do not let the pushback stay private. If a Domain Leader refuses to prioritise the migration, publish this in the Steering Group status report. Frame it neutrally but clearly: “Domain X is currently blocked due to conflicting roadmap priorities. Impact: Migration delayed by 4 weeks, with running costs increased by £15k”.

• The Sponsor’s role: If the deadlock persists, you must escalate the issue to the sponsor, instead of incurring an even bigger cost of delay. They will then decide: either mandate the migration (overruling the Domain Leader) or accept the delay (and the cost). This forces a business decision rather than a personal argument.

Phase 3: Governance

Safety protocols

Preparing for live traffic requires decoupling deployment (code in production) from release (traffic through the new code). To mitigate risk, you must enforce safety protocols.

Make feature toggles mandatory for instant roll-backs, use shadow traffic to test under real load, and ramp up real traffic with canary releases. For new functionality, use A/B testing to validate the added value.

Managing the long tail

The final ~5% of a migration often provides diminishing returns. Do not let this block the completion of the project unless the trade-off is in critical areas like security. Once the core value has been delivered, identify the pending low-value items and track them as technical debt to be addressed later. This allows you to close the project and have the Builder teams focus on new strategic work.

Visibility and reporting

Avoid manual spreadsheet tracking where possible. Instead, build automated dashboards (Jira, DataDog, Grafana…) to track real-time progress. However, senior leadership usually doesn’t need a high level of detail, they prefer a consolidated view. In this case, share a fortnightly summary with a cross-functional steering group, highlighting progress, risks and required actions, with links to the live data dashboards.

Key metrics to track

• Migration velocity: % of traffic migrated

• Domain KPIs: Monitoring existing business metrics to ensure there are no regressions during the switch

• System health: Number of incidents (legacy vs new)

• Business impact: The specific metrics that triggered re-architecting the system, e.g. conversion rate in a new region

Conclusion

This process is not about code, it is about making sure that the technology supports the company’s vision. By removing the friction between the legacy system and the business needs, you remove constraints and become more agile.

I applied this exact approach to migrate a core legacy system involving 20+ consumer teams. By treating the migration as an internal product launch and using the migration squad tactic to unblock teams, we achieved a 40% increase in new orders and a 70% reduction in infrastructure costs, while cutting production incidents by 90%.

Re-architecting is not only a technical task, it is a strategic decision to unlock future revenue.