A long list of platforms, tools and architectural layers can look like proof of a well-run engineering function. More often it is a sign that nobody has owned the job of deciding what to take away.
The real test of maturity has little to do with how the system looks from the outside. It is whether the team can make confident changes to it, keep it running without drama, and explain why each part still earns its place.
Does a complicated stack mean a stronger team?
Reading a sophisticated stack as proof of a strong team means measuring the wrong thing. It shapes who gets hired and how teams get built around them.
Complexity usually builds up one decision at a time: a platform added here, a tool adopted for a single project there, an extra layer bolted on to solve a problem that no longer exists. None of those decisions looked wrong by itself.
The organisation with the most moving parts has not necessarily grown the most capable. Often it has been the least disciplined about removing what no longer earns its keep.
This changes who you should be hiring, and what you brief a recruiter to look for. A candidate who has spent a career adding tools to an already crowded environment has a different skill set to one who has spent time consolidating and standardising.
Both experiences can read as “worked in a complex environment” on a CV. They are not the same experience, and they are not interchangeable if you are trying to fix a stack the team can no longer reason about.
How do you start cutting unnecessary complexity out of your stack?
Beyond asking one team to explain one layer, there is a broader set of habits worth building into how a team reviews its own architecture:
- Run an inventory, not a redesign. List every platform, service and tool currently in production, and against each one, note who can confidently explain why it exists. Gaps in that list are where complexity has outpaced understanding.
- Set a standing test before adopting anything new. Ask whether it genuinely needs to differ from what the team already runs. Reserve differentiation for the parts of the stack that genuinely set the business apart, and standardise everything else.
- Treat removal as scheduled work, not a side project. If a tool or service has not been actively maintained, cannot be explained with confidence, or exists because of a decision nobody remembers making, put decommissioning it on the same roadmap as new feature work.
- Ask new hires, during onboarding, what looks unnecessarily complicated to them. A fresh set of eyes, before they have absorbed the team’s habits and blind spots, often catches complexity that insiders have stopped noticing.
- Revisit this on a cadence, not as a one-off. Complexity accumulates gradually, so the review that catches it has to happen regularly too, rather than as a clean-up after things have already become unwieldy.
What should you look for in a candidate who can manage complexity well?
On a CV, look for language about simplification, consolidation and standardisation alongside the usual language of adoption and scale. Someone who led a migration onto fewer platforms is showing a different skill to someone who has only ever added to a stack.
The same goes for someone who standardised a team onto a shared pattern instead of letting each project choose its own. That is a deliberate, harder-won capability, worth naming specifically when you compare candidates.
In the interview, these questions test for that judgement directly:
- Describe a system you inherited that was more complicated than it needed to be, and what you did about it, if anything. Listen for whether they made a case for removing something, or learned to work around it instead.
- How do you decide whether a new tool is worth introducing to a team? A strong answer talks about what gets removed or avoided as a result, as much as what the new tool enables.
- Describe one part of a system you have worked on that you genuinely could not explain with confidence. Candidates who can name this honestly tend to have a more realistic relationship with complexity than ones who claim to understand everything they have touched.
- If you inherited a team’s architecture and found three layers nobody could explain, what would you do in your first ninety days? The answer shows whether they default towards addition or towards investigation first.
Is simpler always the better call?
None of this is an argument for simplicity as an end in itself. Some complexity is earned.
A business with real scale, regulatory obligations or multiple products sometimes needs more moving parts than a smaller one. Stripping those back for a tidier diagram can create new risk rather than remove it.
It is also worth being fair to teams that inherited complexity rather than created it. A team working through decisions made years before anyone currently on it arrived deserves a different conversation to one that has been adding tools without reason for years running.
Standardising too aggressively has its own cost too. Force every team onto identical tooling regardless of what their specific problem needs, and you trade one kind of inefficiency for another, less visible one that shows up later as friction rather than as a line item.
Ready to talk about your next engineering hire? Get in touch.
Liam
Technology & Software Engineering Recruitment
Last updated: October 2026
