I have seen many organisations restructure their technology teams over and over, but whichever model they opt for – they never seem to be able to get the desired results with respect to speed, resilience and quality. For this reason organisations will tend to oscillate from centralised teams, which are organised around skills and reuse, to federated teams that are organised around products and time to market. This article exams the failure modes for both centralised and federated teams and then questions whether there are better alternatives?

Day 1: Centralisation

Centralised technology teams tend to create frustrated product teams, long backlogs and lots of prioritisation escalations. Quality is normally fairly consistent (it can be consistently bad or consistently good), but speed is generally considered problematic.

These central teams will often institute some kind of ticketing system to coordinate their activities. They will even use tickets to coordinate activities between their own, narrowly focused central teams. These teams will create reports that demonstrate “millions” of tickets have been closed each month. This will be sold as some form of success / progress. Dependent product teams, on the other hand, will still struggle to get their work loads into production and frequently escalate the bottlenecks created using a centralised approach.

Central teams tend to focus on reusability, creating large consolidated central services and cost compression. Their architecture will tend to create massive “risk concentrators”, whereby they reuse the same infrastructure for the entire organisation. Any upgrades to these central services tend to be a life threatening event, making things like minor version changes and even patching extremely challenging. These central services will have poorly designed logical boundaries. This means that “bad” consumers of these shared services, can create saturation outages which affect the entire enterprise. These teams will be comfortable with mainframes, large physical datacenters and have a poor culture of learning. The technology stack will be at least 20 years old and you will often hear the term, “tried and tested”. They will view change as a bad thing and will create reports showing that change is causing outages. They will periodically suggest a slow down, or freezes to combat the great evil of “change”. There will be no attempt made to get better at delivering change and everything will be described as a “journey”. It will take years to get anything done in this world and the technology stack will be a legacy, expensive, immutable blob of tightly coupled vendor products.

Day 2: Lets Federate!

Eventually delivery pressure builds and the organisation capitulates into the chaotic world of federation. This is quickly followed by an explosion in headcount, as each product team attempts to utopian state of “end to end autonomy”. End to end autonomy, is the equivalent of absolute freedom – it simple does not and cannot exist. Why can’t you have an absolute state of full autonomy? It turns out that unless you’re a one product startup, you will have to share certain services and channels with other products. This means that any single products “autonomy” expressed in any shared channel/framework, ends up becoming another products “constraint”.

A great example of this is a client facing channel, like an app or a web site. Imagine if you carved up a channel into little product size pieces. Imagine how hard it would be to support your clients, where do you route support queries? Even something basic, like trying to keep the channel available would be difficult, as there is no single team stopping other teams from injecting failure planes and vendor SDKs into critical shared areas. In this world, each product does what it wants, when it wants, how it wants and the channel ends up yielding an inconsistent, frustrating and unstable customer experience. No product team will ever get around to dealing with complex issues, like fraud, cyber security or even basics like observability. Instead they will naturally chase PnL. In the end, you will have to resort to using social media to field complaints and resolve issues. Game theory depicts this as something called the “Tragedy of the Commons” – it’s these common assets that die in the federated world.

In the federated world, the lack of scope for staff results in ballooning your headcount and aggregating roles across multiple disciplines for the staff you have managed to hire. Highly skilled staff tend to get very bored with their “golden cages” and search out more challenging roles at other companies.

You will see lots of key man risk in this world. Because product teams can never fully fund their end to end autonomy – you will commonly see individuals that looks after networking, DBA and storage and cyber. When this person eventually resigns, the risks from their undocumented “tactile fixes” quickly start to materialise as the flow of outages starts to takes a grip. You will struggle to hire highly skilled resources into this model, as the scope of the roles you advertise are restrictively narrow, eg a DBA to look after a single database, a senior UX person to look after 3 screens. Obviously, if you manage to hire a senior UX person, you can then show them the 2 databases you also want them to manage 😂

If not this, then what?

Is the issue that we didn’t try hard enough? Maybe we should have given the model more time to bear fruit? Maybe we didn’t get the teams buy in? So what I am saying? I am saying BOTH federated and centralised models will eventually fail, because they are extremes. These are not the only choices on the table, there are a vast number of states in between, depending on your architecture, the size of your organization and the pools of skills you have.

Before you start tinkering with your organisations structure it’s key that you agree on what is the purpose of your organisation structure? Specifically – what are you trying to do and how are you trying to do it? Centralists will argue that economies of scale, better quality are key. But the federation proponents will point to time to market and speed. So how do you design your organisation?

There are two main parameters that you should try to optimise for:

1. Domain Optimisation: Design your structure around people and skills (from the centralised model). Give your staff enough domain / scope to be able to solve complex problems and add value across multiple products in your enterprise. The benefit of teams with wide domains, is that you can put your best resources on your biggest problems. But watch out, because as the domain of each team increases, so will the dependencies on this team.
2. Dependency Optimisation: Design your structure around flow/output by removing dependencies and enabling self service (from the federated model). Put simply, try to pay down dependencies by changing your architecture to enable self service such that product teams can execute quickly, whilst benefiting from high quality, reusable building blocks.

These two parameters are antagonistic, with your underlying architecture being the lever to change the gradient of the yield.

Domain Optimisation

Your company cannot be successful, if you narrow the scope of your roles down to a single product. Senior, skilled engineers need domain and companies need to make sure that complicated problems flow to those who can best solve these problems. Having myopically scoped roles, not only balloons your headcount, it also means that your best staff might be sat on your easiest problems. More than this, how do you practically hire the various disciplines you need, if you’re scope is restricted to a single product that might only occasionally use a fraction of your skills.

You need to give staff from a skill / discipline enough scope to make sure they are stretched and that you’re getting value from them. If this domain creates a bottleneck, then you should look to fracture these pools of skills by creating multiple layers. Keeping one team close to operational workloads (to reduce dependencies) and a second team looking a more strategic problems. For example, you can have a UX team look after a single channel, but also have a strategic UX team look after more long dated / complex UX challenges (like peer analysis, telemetry insights, redesigns etc).

Dependency Optimisation

As we already discussed, end to end autonomy is a bogus construct. But teams should absolutely look to shed as many dependencies as possible, so that they can yield flow without begging other teams to do their jobs. There are two ways of reducing dependency:

1. Reduce the scope of a role and look at creating multiple pools of skills with different scopes.
2. Change your technology architecture.

Typically only item 1) is considered, and this is the crux of this article. Performing periodic org structure rewrites simply gives you a new poison to swallow. This is great, maybe you like strawberry flavoured arsenic! But my question is, why not stop taking poison altogether?

If you look at the anecdotal graph below you can see the relationship between domain / scope and dependency. This graph shows you that as you reduce domain you reduce dependency. Put simply, the lower your dependancies them more “federated” your organisation and the more domain your staff have the more “centralised” your organisation is.

What you will also observe that poorly architectured systems exhibit a “dependency cliff”. What this means is that even as you reduce the scope of your roles – your will not see any dependency benefit. This is because your systems are so tightly coupled that any amount of org structure gymnastics will not give you lower dependencies. If you attempt to carve up any shared systems that are exhibiting a dependency cliff, you have to hire more staff, you will have more outages, less output and more escalations.

To resolve any dependency cliffs, you have a few choices:

1. De-aggregate/re-architect workloads. If all your products sit in a single core banking platform, then do NOT buy a new core banking platform. Instead, rather rearchitect these products, to separate the shared services (eg ledger) from the product services (eg home loans). This is a complex topic and needs a detailed debate.
2. Optimise workloads. Acknowledge that a channel or platform can be a product in its own right and ensure that most of the changes product teams want to make on a channel / platform can be automated. Create product specific pipelines, create product enclaves (eg PWA), allow the product teams the ability to store and update state on the channel without having to go through testing release cycles.
3. Ensure any central services are opensourced. This will enable product teams to contribute changes and not feel “captive” to the cadence of central teams.
4. Deliver all services with REST APIs to ensure all shared services can be self-service.

The Conclusion

There is no easy win when it comes to org structure, because its typically your architecture that drives all your issues. So shuffling people around from one line manager to another will achieve very little. If you want to be successful you will need to look at each service and product in detail and try and remove dependencies by making architectural changes such that product teams can self service wherever possible. When you remove architectural constraints, you will steepen the gradient of the line and give your staff broad domains, without adding dependencies and bottlenecks.

Am done with this article. I really thought I was going to be quick to write and I have run out of energy. I will probably do another push on this in a few weeks. Please DM with spelling mistakes or something that doesn’t make sense.

I think you’re a genius! You found this blog and your reading it – what more evidence do I need?! So why do you keep asking others to think for you?

There is a harmful bias built into most technology projects that assumes “the customer knows best” and this is simply a lie. The customer will know what works and what doesn’t when you give them a product; but thats not the same as being able to give specification/requirements. Sadly, somehow technologists have been relegated to order takers that are unable to make decisions or move forwards without detailed requirements. I disagree.

In general, everyone (including technologists) should fixate on understanding your customers, collaborating across all disciplines, testing ideas with customers, making decisions and executing. If you get it wrong, learn, get feedback, fix issues, then rinse and repeat. If you are going through a one way door or making a big call; then by all means validate. But don’t forget that your a genius and you work with other geniuses. So stop asking for requirements, switch your brain on and show off your unfiltered genius. You may even meet requirements that your customers haven’t even dreamt of! 

Many corporate technology teams are unable to operate without an analyst to gather, collate and serve up pages of requirements. This learnt helplessness is problematic. There are definitely times, especially on complex projects where analysts working together with technologists can create more focus and speed up product development. But there is also a balance to be found in that a technology teams should feel confident to ideate solutions themselves.

Finally, one of the biggest causes for large delays on technology workstreams is the lack of challenge around requirements. If your customer wants an edge case feature that’s extremely difficult to do; then you should consider delaying it or even not doing it. Try to find a way around complex requirements, develop other features or evolve the feature to something that is deliverable. Never get bogged down on a requirement that will sink your project. You should always have way more features than you can ever deliver, so if you deliver everything your customer wanted there is an argument to say this is wasteful and indulgent. You will also be constantly disappointed when your customer changes their minds!

bonuscide

noun

Definition of bonuscide:

Bonuscide is a term used to describe incentive schemes that progressively poisons an organisation by ensuring the flow of discretionary pay is non does not serve the organisations goals. These schemes can be observed in two main ways, the loss of key staff or the reduction in client/customer base.

Bonuscide becomes more observable during a major crisis (for example covid 19). Companies that practise this will create self harm by amplifying the fiscal impact of the crisis on a specific population of staff that are key to the companies success. For example, legacy organisations will tend to target skills that the board or exco don’t understand and disproportionately target its technology teams, whilst protect their many layers of management.

The kinds of symptoms that will be visible are listed below:

1. Rolling downside metrics: A metric will be used to reduce the discretionary pay pool, but this metric was never previously used to as an upside metric. If at some future stage the metric becomes favourable
2. Pivot Upside Metrics: If the financial measure that was chosen in 1) improves in the future; a new/alternative unfavourable financial measure will be substituted.
3. Status Quo: Discretionary pay will always favour the preservation of the management of status quo. Incentives will never flow to those involved in execution or change, because these companies are governed Pournelle’s Iron Law of Bureaucracy.
4. Panic Pay: Companies that practice bonuside are periodically forced to carry out poorly thought through emergency incentives to their residual staff. This will create a negative selection process (whereby they lockin the tail performers after loosing their top talent).
5. Trust Vacuum: Leaders involved in managing this pay process will feel compromised, as they know that the trusted relationship with their team will be indefinitely tainted.
6. Business Case: The savings generated by the reduced discretionary compensation will be a small fraction of the additional costs and revenue impact that that the saving in compensation will have. This phenomenon is well covered in my previous post on Constraint Theory.

Put simply, if a business case was created for this exercise, it wouldn’t see the light of day. The end result of bonuscide is the creation of a corporate trust / talent vacuum that leads to significant long term harm and brand damage.

Introduction

In most large corporates technology will typically report into either finance or operations. This means that it will tend to be subject to cultural inheritance, which is not always a good thing. One example of where the cultural default should be challenged is when managing IP duplication. In finance or operations duplication rarely yields any benefits and will often result in unnecessary costs and/or inconsistent customer experiences. Because of this, technology teams will tend to be asked to centrally analyse all incoming workstreams for convergence opportunities. If any seemingly overlapping effort is discovered, this would then typically be extracted into a central, “do it once” team. Experienced technologists will likely remark that it generally turns out that the analysis process is very slow, overlaps are small, the cost of extracting them are high, additional complexity is introduced, backlogs become unmanageable, testing the consolidated “swiss army knife” product is problematic and critically, the teams are typically reduced to crawling speed as they try to transport context and requirements to the central delivery team. I have called the above process “Triplication”, simply because is creates more waste and costs more than duplication ever could (and also because my finance colleagues seem to connect with this term).

The article below attempts to explain why we fear duplication and why slavishly trying to remove all duplication is a mistake. Having said this, a purely federated model or abundant resource model with no collaboration leads to similarly chronic issues (I will write an article about “Federated Strangulation” shortly).

The Three Big Corporate Fears

1. The fear of doing something badly.
2. The fear of doing something twice (duplication).
3. The fear of doing nothing at all.

In my experience, most corporates focus on fear 1) and 2). They will typically focus on layers of governance, contractual bindings, interlocks and magic metric tracking (SLA, OLA, KPI etc etc). The governance is typically multi-layered, with each forum meeting infrequently and ingesting the data in a unique format (no sense in not duplicating the governance overhead, right?!). As a result these large corporates typically achieve fear 3) – they will do nothing at all.

Most start-ups/tech companies worry almost exclusively about 3) – as a result they achieve a bit of 1) and 2). Control is highly federated, decision trees are short, and teams are self empowered and self organising. Dead ends are found quickly, bad ideas are cancelled or remediated as the work progresses. Given my rather bias narrative about – it won’t be a surprise to learn that I believe 3) is the greatest of all evils. To allow yourself to be overtaken is the greatest of all evils, to watch a race that you should be running is the most extreme form a failure.

For me, managed duplication can be a positive thing. But the key is that you have to manage it properly. You will often see divergence and consolidation in equal measure as the various work streams mature. The key to managing duplication is to enforce scarcity of resources and collaboration. Additionally, you may find that a decentralised team could become conflicted when it is asked to manage multiple business units interests. This is actually success! This means this team has created something that has been virally absorbed by other parts of the business – it means you have created something thats actually good! When this happens look at your contribution options, and sometimes it may make sense to split the product team up into a several business facing teams and a core platform engineering team. If however, there is no collaboration and an abundance of resources are thrown at all problems, you end up with material and avoidable waste. Additionally, observe exactly what your duplicating – never duplicate a commodity and never federate data. You also need to avoid a snowflake culture and make sure that were it makes sense you are trying to share.

Triplication happens when a two or more products are misunderstood to be “similar” and then attempted to be fused together. The over aggregation of your product development streams will yield most of the below:

1) Cripplingly slow and expensive to develop.

2) Risk concentration/instability. Every release will cause trauma to multiple customer bases.

3) Unsupportable. It will take you days to work out what went wrong and how on earth you can fix the issue as you will suffer from Quantum Entanglement.

4) Untestable. The complexity of the product will guarantee each release causes distress.

5) Low grade client experience.

Initially these problems will be described as “teething problems”. After a while it becomes clearer that the problem is not fixing itself. Next you will likely start the “stability” projects. A year or so later after the next pile of cash is burnt there will be a realisation that this is as good as it gets. At this point, senior managers start to see the writing on the wall and will quickly distance themselves from the product. Luckily for them, nobody will likely remember exactly whom in the many approval forums thought this was a good idea in the first place. Next the product starts to get linked to the term “legacy”. The final chapter for this violation of common sense, is the multi-year decommissioning process. BUT – its highly likely that the strategic replacement contains the exact same flaws as the legacy product…

The Conclusion

To conclude, I created the term “Triplication” as I needed a way to succinctly explain that things can get worse when you lump them together without a good understanding of why your doing this.  I needed a way to help challenge statements like, “you have to be able to extract efficiencies if you just lump all your teams together”. This thinking is equivalent to saying; “hey I have a great idea…! We ALL like music, right?? So lets save money – lets go buy a single CD for all of us!”

The reality for those that have played out the triplication scenario in real life, is that you will see costs balloon, progress grind to a halt, revenues fall of a cliff and the final step in the debacle is usually a loss of trust – followed by the inevitable outsourcing pill. On the other hand collaboration, scarcity, lean, quick MVPs, shared learning, cloud, open source, common rails and internal mobility are the friends of fast deliverables, customer satisfaction and yes – low costs!

There are two fundamentally different ways technology is run inside large organisations.
Engineers feel the difference immediately usually within their first week.

One model treats engineers as risk to be controlled.
The other treats engineers as the system designers they actually are.

Everything else morale, velocity, quality, resilience is a downstream effect.

Model A — Technology Run By Generic Management

This is the dominant corporate model. It survives not because it works, but because it looks controllable.
1. Decisions are made by non engineers.
Architecture is dictated by people who don’t ship code, debug prod, or carry pagers.
2. Design authority is replaced by committees.
If enough people sign off, the design must be safe — even if it’s incoherent.
3. Requirements are frozen early.
Learning is treated as failure. Discovery is treated as scope creep.
4. Central teams own everything and nothing.
Platforms, tooling, security, release management — all abstracted away from delivery and accountability.
5. Engineers are throughput units.
Work arrives as tickets. Context is stripped out. Ownership is temporary.
6. Documentation is valued over correctness.
A wrong design with a diagram is preferable to a correct one discovered late.
7. Metrics reward appearances, not outcomes.
Green dashboards coexist peacefully with outages, rollbacks and customer pain.
8. Failure is investigated, not absorbed.
Post-mortems focus on who missed a process, not what the system made inevitable.
9. Scaling means adding layers.
When things slow down, coordination is added instead of removing constraints.
10. Release is an event.
Change is risky, infrequent, and stressful — therefore avoided.
11. Tooling lags years behind reality.
Engineers compensate with scripts, side systems and quiet heroics.
12. Abstraction is accidental.
Complexity leaks everywhere, but no one owns simplifying it.
13. Engineers stop caring.
Not because they’re lazy — because the system punishes initiative.
14. Talent retention becomes a mystery.
Leadership blames “the market” instead of the environment they created.
15. Technology becomes brittle.

The system works, until it doesn’t, and no one knows how it actually works anymore.

This is not a skills problem.
This is a system design failure.

Model B — Technology Run By Engineers

This model looks chaotic to outsiders.
To engineers, it feels calm, rational, and fast.
1. Engineers make engineering decisions.
Authority is tied to competence, not org charts.
2. Architecture emerges through use.
Designs evolve based on real constraints, not imaginary futures.
3. Requirements are negotiable.
Learning early is success, not failure.
4. Teams own systems end to end.
Build it, run it, improve it, or simplify it away.
5. Context is preserved.
Engineers understand why something exists, not just what to build.
6. Documentation follows reality.
It’s generated from code, pipelines and contracts — not PowerPoint.
7. Metrics are operationally honest.
Latency, error rates, deploy frequency, recovery time — not vanity KPIs.
8. Failure is expected and designed for.
Systems degrade gracefully. Humans don’t have to improvise heroics.
9. Scaling means removing friction.
Fewer handoffs. Fewer gates. Smaller interfaces.
10. Release is continuous.
Change is small, reversible and routine.
11. Tooling matches how engineers actually work.
CI, observability, infra and security are accelerators, not obstacles.
12. Abstraction is intentional.
Complexity is isolated, owned and constantly questioned.
13. Engineers optimise for long term health.
Because they’ll still be on call for it next year.
14. Talent stays because the work is meaningful.
Engineers grow systems, and themselves.
15. Technology compounds.
Each improvement makes the next one easier.

This model does not require “rockstar engineers”.
It requires trust in engineering judgement.

The Part No One Likes Hearing

Most corporate technology teams are dysfunctional, through fear of engineers making mistakes. So organisations replace judgement with process. They replace ownership with governance. They replace learning with compliance.

And then they wonder why:
• Systems are fragile
• Delivery is slow
• Engineers disengage
• Innovation comes from outside

If you don’t let engineers design systems, they’ll eventually stop understanding them. If they stop understanding them, no amount of process will save you.