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.