From Legacy Bottleneck to Modern Platform

Context

This is an anonymized story from a Nerd/Noir engagement with a client in the e-commerce sector. Our work centered on one portfolio: the software services most other teams in the company depended on — a central dependency. Executive leadership decided to restructure development processes and practices to address coordination complexity between teams and competitive pressure in the market.

Two companion case studies zoom in on parts of this story: Re-aligning Teams to Value Streams on the team re-cut, and 30x ROI on New Products on what the platform investment returned in dollars.

The change vision: what and why

A change vision establishes a shared understanding of the opportunity, the obstacles, and the proposed countermeasures. Treat it as a hypothesis to validate or invalidate by doing. It starts by naming the most significant challenge the group faces.

The diagnosis, in the organization’s own words:

Our product portfolio relies on a collection of services developed over many years. Building new features on top of them requires excessive coordination and effort. These services have become a bottleneck for the entire organization.

Common core system capabilities are at the heart of our ability to grow revenue and compete in the marketplace, and much of the system is legacy code in tools and languages our development teams no longer have the skills to maintain or extend. Improving their usability is business-critical.

The vision then describes what the future looks like and what has to change to get there:

Going forward, we will unify these services into a cohesive platform: reusable functionality that stream-aligned teams incorporate into their own services and applications, reducing dependency overhead across the organization.

This change is a joint effort between the product and engineering organizations. It demands collaboration, alignment, and compromise from leadership on both sides of the house, with many tradeoffs negotiated over a long period.

Strategies: how in principle

Strategies are principles for resolving conflicting priorities — enabling constraints that form a basis for decisions across product and engineering. Anyone can ask, “Does what I’m doing align with our strategy?” When the answer is no, either the action is misaligned or the strategy needs tuning.

• Modernize the platform to accelerate stream-aligned teams. Reduce the cognitive load on stream-aligned teams. Develop the system as a platform of discoverable APIs, front ends, and components that teams assemble to solve their own domain-specific use cases. Deprecate capabilities that no longer deliver value to the business.

• Align platform evolution with new product opportunities. The platform exists to enable product capabilities that unlock business value, developed just in time for high-impact product initiatives. This shifts how product and engineering prioritize together: decisions balance product ambition against platform investment.

• Redistribute responsibility to local creators. Stream-aligned teams fully own the orchestrations and use cases specific to them. Platform teams treat those teams as customers and serve them reusable components. System-level contracts such as APIs replace expensive human-driven coordination.

• Evolve collaboration patterns as the platform matures. Joint development first, with new platform teams building system functionality alongside principal engineers and stream-aligned teams, moving toward a self-service platform that dramatically reduces coordination overhead and dependency management.

Execution: how in action

A change vision sets goals; it doesn’t dictate the details. Leaders and teams use the guiding principles to make coherent plans of their own.

The changes grouped into three stages: an initial rollout of foundational moves by executive leadership, staff+ engineers, product managers, and team managers that would be hard to reverse later; early changes aligning team workflows to new processes at every level of the organization; and ongoing steps — behaviors and processes that need longer adoption and feedback cycles before they compound into improved flow.

Initial rollout

Conway’s Law observes that product topology mimics team communication structures. If the vision differs significantly from the current state, the existing org structure is an impediment. But sweeping personnel moves create a fog of uncertainty that puts sustained progress at risk.

Team organization: Leadership weighed how much to restructure the teams around the new core-systems concept. There was an early push to shuffle personnel between teams; instead, team coherence won out over redistributing domain expertise, producing a smaller, more tactical first wave of moves to balance skill sets and team sizes. The teams stayed stable enough to take on the harder demands of the transformation with minimal disruption and attrition.

The organization’s current outcomes result from its current processes. Changing the outcomes means changing the processes — and you can’t change a process you haven’t seen.

Product development life cycle: Teams mapped their existing discovery and delivery workflow and found buildups of work in progress driving long latencies, stale work, and delivery of non-value-added features. Using the map and historical delivery data, they made the first changes to their pipeline to align product and engineering.

Momentum requires communicating the strategy relentlessly. Teams writing their own action plans generate enrollment, agency, and empowerment at every level; the strategy’s governing constraints keep those plans aligned.

Socializing the change: Leadership presented plans as they were developed — broad strokes at all-hands meetings, more detail in smaller forums with presentations and discussion. Feedback was actively solicited from teams to build enrollment and surface obstacles to the first process changes.

Early changes

Collaboration and negotiation only work when all parties have enough information to make informed trade-offs. Information radiators, standard metrics, and working agreements around value decisions let teams act locally on a global strategy.

Value prioritization: Product managers had each worked their own initiatives with a single engineering team, routinely needing skills or domain knowledge from other teams. There was no portfolio-level capability to prioritize the most valuable features, so teams followed their PM’s lead — straight into scheduling conflicts.

The organization introduced a single common backlog spanning all teams. PMs collaborated on one global priority for the shared feature-level backlog while senior engineers fed in design input for the platform architecture, mapping risk and effort onto priority decisions. A single point of truth for work exposed long-lead items, enabled early product discovery, surfaced scheduling issues, and gave conflicting efforts a table to be negotiated at. Cycle time for delivering features dropped, and so did switching between initiatives.

Reducing delivery size: Features had grown to the point where some became “projects” lasting months or quarters, so teams couldn’t safely or quickly pivot when new priorities arose. Teams constrained story size and limited work in progress, adopting techniques to split work into small, manageable chunks. Product management began evaluating promised versus delivered value in financial terms. Lead time for stories dropped significantly, along with rollover of work between sprints. Priorities became cheap to change — literal agility.

Continuous experimentation: Constant feature requests had crowded out deliberate investment in practices, cohesion, and architecture. Smaller delivery increments created room. Senior engineers ran experiments targeting specific gaps in platform capability and ways to add architectural rigor while developing features already on the backlog. Most notably, they created new APIs that let dependent teams self-serve needs once fulfilled through toilsome, manual requests. A platform takes shape.

Ongoing steps

Only the broad strokes of a process change are visible at the outset. As organizational behavior shifts, secondary effects surface — old habits operating inside new processes, or root causes that nearer problems had hidden. Iterating the strategy means probing these with empirical data and acting on what you find.

Just-in-time focus: The common backlog made all work in progress visible — and revealed PMs refining work with teams that had no capacity to start the resulting stories, an issue spotted in the backlog’s cumulative flow metrics. PMs continued cutting the number of features in focus to shrink inventories of planned work, and the development teams carry retrospective items to improve delivery.

Process evolution: The core management team held retrospectives at sprint boundaries to evaluate the process and run small countermeasure experiments against it. The early meetings yielded so many changes that experiments blurred into the plan of record; documenting the metrics behind each change, and putting a WIP limit on change itself, made changes both impactful and visible. The process stabilized considerably as teams settled into new ways of working.

As proficiency grows, things once deemed unwieldy or impossible become tractable, and structured experiments can test the boundary of the feasible.

Team coordination: For stories requiring cross-domain expertise, teams experimented with ways to share knowledge and avoid siloed impediments: whole-team pairings, “guest star” experts from other teams, story splitting across well-defined boundaries. Coordinating with teams outside the core platform remains harder — they arrive without the shared process vocabulary and need to be brought up to speed.

The outcomes of a change vision manifest as the emergent behavior of the whole system passes a threshold. Slowly, then all at once.

Legacy architecture: Senior engineers continue retiring the older, impossible-to-maintain codebases. Stories to stand up new services or place facades in front of old ones are on the backlog and actively refined by teams.

The results

The actions aligned with these strategies yielded measurable results.

• 500+ new products created in 60 days through the new APIs, replacing a laborious, ticket-driven process — and validating key architectural patterns of the nascent platform. 30x ROI on New Products walks through the dollars on this one.
• A 48% increase in value delivered sprint over sprint, from breaking months-long project deliveries into weeks-long value deployments that could be reprioritized to support innovation experiments.
• Work rollover between sprints effectively eliminated. Teams stopped starting and started finishing inside their two-week iterations, which is what makes dynamically reprioritizing major initiatives safe.

Evolution: how strategy changes with learning

Realizing a change vision means pushing past the desire to set a plan and simply execute its steps. Educated bets and small, rigorous experiments aligned to strategic principles demand constant involvement and a willingness to learn from failure.

Our approach to strategy is heavily inspired by the Observe-Orient-Decide-Act loop created by United States Air Force Colonel John Boyd — specifically Simon Wardley’s strategy-focused adaptation of it, which also underpins the Wardley Mapping practice we use in strategy work:

Simon Wardley’s strategy cycle, from wardleymaps.com (CC BY-SA 4.0).

Some actions achieve the goals of the change vision. Others reveal new obstacles. Measuring results tells you whether the strategically aligned actions are advancing toward the vision or whether the approach itself needs another turn of the loop.

The plan did not survive contact with the organization intact. It was never supposed to.