Moving from functional silos to product-aligned squads.

In a previous product and technology leadership role, I helped move an around 60-person B2B fintech/regtech company from functional engineering silos into cross-functional, product-aligned squads.

The organisation had around 37 engineers, four product people, two designers, and five squads. The first problem was structural. The second was behavioural.

The company initially had functional teams: QA, DevOps, frontend, backend, and other specialist groups. Work moved between those groups through handoffs, negotiation, and escalation. Over time, this had created slow decision-making, unclear ownership, quality issues, and too much firefighting.

The first change was moving from functional silos into cross-functional, product-aligned squads. That put ownership closer to the work and gave teams more ability to make decisions, improve quality, and respond to incidents.

Once that structure was in place, the next constraint became clearer. The squads were moving faster, but too much of the work was still framed as feature delivery rather than progress against customer and business outcomes.

The work became a two-stage change: first redesign the teams around ownership, then mature the operating model around product value.

What was getting in the way

The original structure made ownership difficult.

Because work was split across functional teams, no single team owned a product area end to end. Decisions made in one area often had consequences elsewhere. Engineers spent too much time coordinating across silos, arguing over approach, or dealing with issues that emerged later because quality and operability were not owned close enough to the work.

This also affected reliability. When incidents happened, the response often depended on pulling several people together from different parts of the organisation. It was too easy for responsibility to sit with a function, rather than with the team closest to the product area and customer impact.

After the move to cross-functional product-aligned squads, some of those problems improved. Teams had clearer ownership, faster local decision-making, and better ability to improve quality and reliability. But the next constraint became more visible: the organisation was still too focused on output.

Squads were busy, but not all of that work was creating enough customer or business value. There were too many competing priorities, too many feature requests, and not enough discipline around feasibility, customer need, commercial impact, and product direction.

What I changed

The first stage was a team design change, led in partnership with the CTO.

We moved from functional silos into predominantly value-aligned squads. Each squad had the skills needed to design, deliver, operate, and maintain a product area or value stream.

The aim was to put ownership closer to the work.

To support that, I introduced decision guardrails based on what I called blast radius thinking. If a decision only affected the squad, the squad could make it. If it affected nearby squads, those squads needed to be involved. If it affected the wider organisation, it needed broader agreement.

This helped teams move faster without creating unnecessary chaos.

We also gave squads room to choose the way of working that suited their context, whether that was Scrum, Kanban, or something closer to continuous flow. At the same time, we introduced engineering efficiency metrics so we could see whether the new model was actually improving flow and reliability.

A big part of the change was cultural. We had to build trust inside the squads and across leadership. Blameless postmortems became important here. The point was not to find someone to blame when something went wrong, but to understand what the system had allowed to happen and what we could improve next.

The second stage was a product operating model change.

Once the squads were in place, the focus shifted from "how do we ship more?" to "how do we make sure the work we ship is worth doing?"

This meant clarifying the role of product managers and putting them closer to the centre of business decision-making. Feature requests no longer moved straight to engineers. They went through product, where they could be assessed against customer need, feasibility, profitability, product direction, and the goals set through the quarterly operating rhythm.

Product managers became more visible in company-wide conversations. They owned progress updates, product KPIs, and the trade-offs around what should and should not be built.

Engineers also moved closer to the problem space. They were involved earlier in customer conversations, feasibility discussions, and solution design. That changed the quality of the solutions. Instead of simply writing good code for a predefined feature, engineers could help find simpler ways to solve the underlying problem.

In some cases, that meant writing less code. In others, it meant spotting one solution that could address several related problems.

What changed

After the first stage of the change had settled, the engineering efficiency metrics improved significantly.

Cycle time, pickup time, and deployment time improved by around 5x. Mean time to recover improved dramatically, with incidents that previously took days to resolve being recovered from in minutes.

The reason was not just that teams were working harder. The system had changed.

Squads owned their product areas more clearly. They were responsible for quality, operability, maintenance, and recovery. When incidents happened, the team learned from them, added better checks, improved alerts, introduced automation, and made the next recovery easier.

That created a self-improving operating model. Problems became inputs into improvement, rather than recurring interruptions.

The second stage changed how the organisation decided what was worth building.

The company started shipping less code, but saw better movement in the business outcomes it cared about. Work became more focused on the quarterly goals. Product and engineering worked more closely together on the problem, not just the implementation. Product managers had clearer authority over prioritisation, and engineers had better context for the value they were helping to create.

Qualitatively, the organisation saw clearer ownership, faster decisions, fewer handoffs, better product and engineering alignment, more reliable work, and much faster incident response.

Leadership also had more confidence because progress was easier to see. The conversation moved away from how busy the teams were and toward whether the work was moving the right measures.

Why it mattered

This was not just a restructure.

The useful change was that ownership, decision-making, quality, product judgement, and business goals became more closely connected.

The first stage helped teams move faster and recover faster. The second helped make sure that speed was pointed in the right direction.

It did not fix every problem. Different squads had different levels of maturity, and this kind of operating model needs continual improvement. But that was part of the point. The system became better at surfacing what was working, what was stuck, and where leadership needed to pay attention.

For me, this is the work behind a lot of product and engineering performance. The issue is rarely that teams are not busy enough. More often, the system around them makes it too hard to turn effort into meaningful business progress.

Start with a clearer view of what is getting in the way.

If your product, technology, or AI work feels harder than it should, HRVN can help you talk through the situation, make sense of the problem, and decide what kind of support would be most useful.

Talk through what's getting in the way [email protected]