👁34views

Federation vs Centralisation: Stop Burying Tech Talent

There’s a question that quietly shapes the fate of technology talent in almost every organisation, and most businesses never ask it directly. Instead, they stumble into an answer through a series of incremental org design decisions, budget cycles, and leadership preferences. The question is this: is technology a support function to the business, or is it a first-class citizen within it? How you answer that, consciously or not, determines whether your best technologists thrive, stagnate, or eventually leave.

1. The Hidden Cost of Full Federation

On the surface, federating technology into business units makes intuitive sense. Put the tech close to the business, make it accountable to outcomes, and remove the ivory tower. But there is a quiet and damaging side effect that rarely makes it into the org design presentation: you bury career paths. When a technologist sits inside a business unit, the next hop up the structure is typically a generic business manager, a commercial head, or a domain leader whose frame of reference has little to do with software engineering, architecture, data, or platform thinking. That person cannot meaningfully assess whether the technologist is exceptional or merely adequate, promotion conversations become abstract, recognition becomes accidental, and the technologist, talented, ambitious and aware, starts to do the maths. They are alone and unheard, and the ceiling above them is made of the wrong material. Over time they leave, not always loudly, sometimes they just stop raising their hand.

2. The Hidden Cost of Full Centralisation

The overcorrection is equally damaging. Pull all technology into a central function and you risk creating a service desk mentality, a team that processes tickets for the real business rather than co-creating its future. Distance from business context grows, relevance erodes, and talented people who want to build things that matter find themselves in queues. Neither extreme works, and the answer lies in the intentionality of the design that sits between them.

3. The Structural Sweet Spot

The goal is federation with coherence, technology that is genuinely embedded in business domains but organised in a way that preserves identity, comparability, and career trajectory for the people doing the work. This means creating reporting lines where groups of technologists roll up into technology leadership, even when those groups are operationally close to business units. It means technologists have peers, their work can be assessed by someone who understands it, and there is scope to move, laterally, upward, across domains, within a recognisable professional structure. This is not just good for talent retention, it is good for quality. When technologists can be compared to peers, standards emerge. When career paths exist, investment in craft follows. When there is domain, there is depth.

4. Why Leaders Resist This

It is worth being honest about the dynamics that push against this model. Heads of technology groups embedded in business units will frequently advocate for full federation, and it is worth understanding why. Full federation often insulates them from comparison with other technology areas, reduces external scrutiny of their team’s output, and places them under a business head who may not know enough to challenge them. That suits certain leadership styles well. This is not a cynical observation, it is a structural one. Org design creates incentives and those incentives shape advocacy, so when you hear a strong internal argument for full federation it is worth asking who benefits most from the absence of comparison.

5. Be Intentional

The right answer for your organisation is not a universal template. The size of your technology investment, the maturity of your business units, and the strategic role of technology in your industry all shape what the right balance looks like, but the worst outcome is arriving at that balance by accident. Don’t bury your technology talent inside structures that cannot see them, and don’t centralise so completely that technology loses its connection to purpose. Build the reporting lines that allow technologists to belong to the business and belong to a professional community at the same time. Ask the question directly, because your best people are already asking it, and they are not waiting long for the answer.

6. The Self-Diagnosis Test: Are You Burying Your Talent?

Most organisations do not deliberately choose to centralise or federate. They drift. Over time, local optimisations, hiring decisions, and delivery pressure quietly reshape the structure until the damage is already visible in attrition, inconsistency, and slowing delivery.

If you want to understand where you are, you do not need a strategy deck. You need to look at how your engineers actually experience the organisation day to day.

You are over-federated if:

• Engineers cannot clearly name a senior technical leader responsible for their growth beyond their immediate team
• Promotions are decided locally with no consistent standard across teams
• There is no shared definition of what “good engineering” looks like
• Each team has its own tooling, patterns, and ways of working
• Strong engineers become invisible outside their product silo
• Career progression depends more on the product manager than on technical merit

This model feels fast and empowered in the short term, but it quietly fragments standards and buries your best people where nobody can see or grow them.

You are over-centralised if:

• Work reaches engineers primarily through tickets, queues, or intake processes
• Engineers are multiple layers removed from real customers or business outcomes
• Delivery timelines are dominated by coordination, approvals, and dependencies
• Backlogs grow faster than they are burned down
• Engineers spend more time aligning than building
• Technical decisions are made far from where the problems actually exist

This model feels controlled and efficient on paper, but it strips engineers of ownership and turns builders into processors.

You are in the danger zone if:

• You are oscillating between the two models every 12 to 36 months
• Each reorganisation promises speed, but delivers disruption
• Standards swing between chaos and over-governance
• Your strongest engineers are the first to leave after each structural change

This is the centralisation versus federation trap in motion. Not a decision, but a cycle.

The uncomfortable truth

If your engineers:

• cannot see a clear career path
• are not consistently measured against their peers
• and are not connected to strong technical leadership

then you are not scaling technology, you are scaling organisational entropy.

7. The Operating Model: Federation with Coherence

If the diagnosis tells you where you are, the operating model defines where you need to go. Federation with coherence is not a slogan. It is a deliberate structural design that separates how engineers work from how they are led, assessed, and developed.

At its core, it solves a single problem: how do you embed engineers deeply in business domains without isolating them from their craft, their peers, and their career path?

The model in practice

This is the key shift: engineers belong to the business for delivery, but to technology for identity, growth, and standards.

What actually changes

This model is not about drawing a new org chart. It is about changing a few critical control points.

• Line management sits in technology
  Engineers report into technology leaders who understand their craft and can assess their performance properly.
• Delivery sits in the domain
  Engineers work day to day with product and business teams, solving real problems, not processing tickets.
• Platforms replace governance
  Standards are enforced through shared platforms, golden paths, and tooling, not committees and documents.
• Peer groups are real, not theoretical
  Engineers are part of communities where they can be compared, coached, and developed alongside others doing similar work.
• Mobility is designed in
  Moving across domains is possible without resetting your career or identity.

The role of platform engineering

Coherence does not come from meetings. It comes from platforms. Platform teams provide:

• Shared infrastructure and services
• Opinionated tooling and patterns
• Self-service capabilities
• Built-in security and compliance

This is how you get consistency without centralising decision-making. The platform becomes the control plane, not a governance forum.

The leadership requirement

This model is harder to run. It requires:

• Strong technical leadership that can operate across domains
• Clear standards that are enforced through systems, not debate
• Willingness to accept some duplication in exchange for speed and relevance

But this is the cost of scaling both talent and delivery at the same time.

8. The Talent Lifecycle: How Good Engineers Quietly Leave

Organisational design problems rarely show up as immediate failure. They show up as slow, almost invisible drift in how your best people feel about their place in the system.

The pattern is remarkably consistent.

Stage 1: Excitement

A strong engineer joins with energy. They see opportunity, interesting problems, and a chance to make an impact. They engage deeply, take ownership, and push for better ways of working.

At this stage, the structure does not matter yet. Talent compensates for it.

Stage 2: Friction

Over time, small signals start to accumulate.

They cannot see a clear path forward.
They are not sure who is evaluating their work, or against what standard.
They notice inconsistency between teams, different bars, different expectations, different outcomes.

Nothing is broken enough to escalate. But something is off.

Stage 3: Isolation

This is where the structure begins to bite.

In a federated model, they realise there is no real technical leadership above them.
In a centralised model, they realise they are far from anything that matters.

In both cases, they lose a sense of progression and belonging to a craft.

They are working, but not growing.

Stage 4: Disengagement

The engineer does not resign immediately.

They stop pushing.
They stop challenging decisions.
They stop raising their hand.

They become reliable, but no longer exceptional.

From the outside, this often looks like stability. It is not. It is quiet disengagement.

Stage 5: Exit

Eventually, they leave.

Not always for more money.
Not always for a better title.

They leave for:

• clearer progression
• stronger leadership
• a system where their work is visible and understood

By the time they resign, the decision has already been made months earlier.

The signal most organisations miss

By the time attrition shows up in your metrics, the system has already failed.

What you are seeing is not a hiring problem.
It is a structural one.

The uncomfortable reality

Your best engineers do not leave because they are disloyal.

They leave because:

• they cannot see a future
• they cannot see how they are measured
• and they cannot see who is leading them

If your organisation cannot answer those three questions clearly, your strongest people will answer them for themselves.