Unwinding the Feature Factory

The Situation

The same client. A harder problem.

This engagement was a return. The same practitioner had previously spent nine months with the same client rebuilding its UK accounting product organisation — standing up three focused teams and improving delivery outcomes substantially. That engagement ended when all external engagements were suspended during the COVID-19 lockdown.

When the client decided to address deep-seated problems in its Payroll product organisation, they made a specific exception to recommission the same practitioner. The problems in Payroll were different in character from the accounting product engagement — and in some ways harder. The accounting product teams had been structurally broken but culturally ready to change. The Payroll teams had both problems simultaneously.

The Structural Problem

A feature factory with no product ownership

Two development teams were assigned features rather than product areas. PM, Engineering, and Design operated in siloed sequences — work was handed off between disciplines rather than developed together. Decisions on what to build and for how long sat entirely with Engineering Management. Each team depended on the other for parts of the product, creating a constant inter-team bottleneck that showed up as waiting time in every sprint.

The Cultural Problem

Individuals working in parallel, not a team

Engineers measured their own contribution rather than the team's output — productivity was understood as personal throughput, not collective value delivery. Daily meetings were upward status reports to management, not team planning sessions. There was artificial harmony: people avoided difficult conversations to keep the peace, which meant the most important problems were the ones least likely to surface.

Team members used phrases suggesting they did not feel trusted or empowered — they felt told what to do, not given room to use their initiative
Even experienced staff engineers were seeking direct management instructions on basic prioritisation calls — bug fixes versus tech debt — rather than making those decisions themselves
Management had identified the need for self-organisation but communicated it as an instruction, which is a contradiction: you cannot mandate autonomy into existence

One Team's Delivery Model

One of the two teams had been running a series of short waterfall projects — planning to completion, delivering at the end, with no iterative feedback loop. The other used an iterative method in name but treated each sprint as a container for individual tickets rather than a shared team commitment. Neither team was closing iterations cleanly.

The Inter-Team Dependency Problem

The two teams shared ownership of the same product area without clear boundaries. When one team needed to work on a component owned by the other, progress stopped. This inter-team dependency was the primary driver of the waiting time that consumed 6.4% of total engineering hours at baseline — one in every sixteen working hours, simply waiting.

The Approach

The same three-dimension diagnostic framework used in the previous engagement was applied — covering how the team operates, how work reaches the team, and technical practices. Changes were introduced as experiments proposed to the teams, never imposed as mandates. One-to-one coaching ran alongside team retrospectives to build the psychological safety required for honest conversation about performance.

The Commission
The recommission was made on the basis of results already observed in the same organisation. No pitch, no RFP, no competitive process. The specific exception made during a period when all external engagements had been suspended is the clearest available signal about why the client decided to act — and who they trusted to do it.

The Baseline

Where engineering time was actually going

Time allocation data was gathered approximately two months into the engagement, covering how engineers across both Payroll teams were spending their working hours. The data made the structural diagnosis precise: less than a third of total engineering time was being spent on work that directly delivered business value.

Baseline finding: 30.6% of engineering time on business value work The remaining 70% was distributed across coordination, context switching, waiting, meetings, status reporting, planning overhead, and personal development. Context switching alone — the cost of the feature-centric model — consumed 8% of total time. Waiting, driven almost entirely by inter-team dependency, consumed a further 6.4%. Together, these two structural failure modes were costing the equivalent of nearly one and a half working days per engineer per week.

What Context Switching Reveals

In a feature-centric model, engineers are assigned to whichever feature needs resource at a given moment. Each assignment switch carries a cognitive load cost — re-reading context, rebuilding mental models, re-establishing working rhythm. The Payroll teams compounded this by rotating engineers across bug and run-the-business work as well as features, pulling individuals out of their team context repeatedly throughout a sprint. At 8% of total time, context switching was the most visible symptom of the underlying model problem: teams without a defined product area cannot protect their focus.

What Waiting Reveals

Waiting time in a development team is rarely about slow individuals. It is almost always structural — teams blocked on decisions, dependencies, handoffs, or approvals they do not control. At 6.4%, the waiting time in the Payroll teams was almost entirely attributable to the inter-team dependency: work that required access to a product area owned by the other team, with no agreed mechanism for resolving the conflict.

The Intervention

Four changes, each targeting a specific failure mode

The diagnostic identified four primary structural and cultural failure modes. Each was addressed through a combination of leadership coaching, team-level experimentation, and operating model redesign — proposed as experiments to the teams, not imposed as policy. The prevailing management culture had favoured control and process over education and experimentation; the approach here was deliberately the inverse: micro-changes over time, suggested not instructed, owned by the teams that adopted them.

Operating Model

Feature teams → mission-based product teams

Each team was given a dedicated PM and XD, a defined product area to own, and a mission with specific metrics to work against. This replaced the Engineering Manager as the source of feature decisions — Product Managers took ownership of the team roadmap. Time allocation was made explicit: approximately 60% roadmap delivery, 20% defects and minor enhancements at team discretion, 20% technical debt at engineer discretion.

Team Autonomy

Self-organised product responsibility split

Rather than imposing a split of the inter-team dependency, the teams were coached to solve it themselves — given context about the problem and the space to decide. Within a month, both teams had self-organised: they held their own discussions, agreed a division of product responsibility, and implemented it as a team-owned experiment. That the solution came from the teams rather than from leadership was itself a signal that the coaching had taken hold at the level it needed to.

Accountability Model

Defect SLA ownership transferred to product teams

Production support and defect management had sat with Engineering Management as a separate function — creating a split between the people responsible for building features and the people accountable for quality. Ownership was transferred to each product team, who planned incidents and defects into their iterations. Teams now had direct accountability for the quality of their product area, which changed how they thought about the work they were shipping.

Team Operating Rhythm

Status reporting replaced with team-led planning

The daily afternoon meeting — where engineers individually reported progress upward to management — was cancelled. The morning standup was restructured into a team planning session: the team decided together how to use the day's collective capacity. Non-team members were welcomed to attend the morning session if they wanted visibility. This single change shifted the team's primary orientation from individual accountability upward toward collective accountability to each other.

On the cultural work The structural changes above were necessary but not sufficient. The teams had developed habits — artificial harmony, individual focus, conflict avoidance — that would have undermined the new operating model without deliberate intervention. One-to-one coaching with individual team members, combined with structured retrospectives designed to surface real disagreements, built the psychological safety needed for the teams to hold each other accountable. This work ran throughout the engagement alongside the structural changes, not as a separate phase.

The Results

Measured across sixteen months: where the time went

Time allocation data was captured at baseline (~2 months in) and at close of engagement (~16 months in). The comparison provides a direct measure of how the structural and cultural changes affected the distribution of engineering time.

Business Value Time

30.6% at baseline

52.6%

Percentage of total engineering time spent directly delivering business value — a 72% relative increase

Context Switching

8.0% at baseline

3.5%

More than halved. The feature-to-product team shift was the primary driver — engineers with a defined product area protect their focus naturally

Waiting Time

6.4% at baseline

0.5%

Near-eliminated. The self-organised product responsibility split removed the inter-team dependency generating almost all of this

How Engineer Time Was Spent — Before & After

% of total time · ~2 months in vs ~16 months in

Business Value

Before (30.6%)

After (52.6%)

+72%

Context Switching

Before (8.0%)

After (3.5%)

−56%

Waiting

Before (6.4%)

After (0.5%)

−92%

Slack / Email

Before (6.4%)

After (4.2%)

−34%

The Five Dysfunctions of a Team assessment, conducted near the close of engagement, showed the teams had moved substantively from their baseline position — particularly on the dimensions most directly connected to delivery: Commitment and Results.

Five Dysfunctions Assessment — Near Close of Engagement

~12 months in · one of two Payroll teams

Trust

4.17

Conflict

3.79

Commitment

3.71

Accountability

3.40

Results

4.06

Accountability remains the lowest dimension — as it typically does on teams transitioning from an individual-contribution culture. The score of 3.40 reflects a team that had moved from avoiding difficult conversations entirely to beginning to hold each other to shared standards. The journey, not just the destination, is the signal here.

What This Demonstrates

The signals a CTO or VP Engineering should take from this

Structural problems create measurable time waste

The feature-centric model wasn't a philosophical problem — it had a quantified cost. Context switching and waiting together consumed the equivalent of one and a half working days per engineer per week. The structural fix removed that cost directly.

Cultural change requires deliberate work alongside structural change

Restructuring the teams was necessary but not sufficient. Individual coaching and structured retrospectives ran throughout the engagement. Without the cultural work, the new operating model would have been inhabited with the old habits — artificial harmony, individual focus, conflict avoidance.

Teams solve their own problems best

The inter-team dependency was the single most impactful structural problem. The solution came from the teams themselves, not from the practitioner or from leadership. That the teams self-organised to resolve it is a more durable outcome than any imposed fix would have been.

Time allocation is a better diagnostic than velocity

Measuring where engineering time goes is more honest than sprint velocity. Velocity can be gamed; time allocation cannot. The data showed that 70% of engineering time was not on business value work. That number, more than any delivery metric, made the case for change.

Accountability is the hardest dimension to shift

Trust, conflict tolerance, and results-orientation all moved quickly once psychological safety improved. Accountability — teams holding each other to standards — takes longer. It requires the other four dimensions to be stable before it can take root. It should be the last thing expected, not the first thing measured.

Recommission as proof of results

An exception was made to a blanket suspension of external engagements to recommission this practitioner. The decision was made by the same leadership team who had observed the results of the first engagement. That is a different quality of endorsement from any reference or case study — it is revealed preference under constraint.

Scaling Without Breaking

Recognise the problem? Let's talk about the fix.