Ask almost any team how their service actually works, and they’ll describe a maze: exceptions, workarounds, and a process map that only makes sense to the person walking you through it. There’s a quiet temptation to read that maze as sophistication, to treat a service as complex because it’s hard to explain.
In my experience auditing services and internal tools, that’s rarely true. What looks like complexity is usually a series of reasonable decisions, made under pressure, that were never written down or joined up. The workarounds became “standard practice” long before anyone stepped back to ask why, which is exactly what I found mapping NetIX’s workflows before its rebuild, and again auditing stock and reporting data at SoPost.
None of this is a new observation. Technical debt and legibility have been written about for years. What I can add is that it holds up every single time I’ve gone looking for it.
The trap of adding without joining up
It’s easy to make a service more complicated. Anyone can add another exception, another spreadsheet, another handoff to solve a problem in front of them today. When teams are under pressure, these additions pile up without anyone owning the whole picture.
The result isn’t true complexity. It’s just noise:
- · Simple rules get buried under exceptions built for one-off cases
- · The reasoning behind a decision lives only in one person’s head
- · Every change feels risky, because no one can see how the parts connect
Making something intricate takes very little effort. Making it understandable takes real skill.
Cleverness is simplification
The best designers and engineers I’ve worked with aren’t the ones who produce the most intricate solution. They’re the ones who can take a tangle of edge cases, distil it to its core logic, and explain it to a room of stakeholders in five minutes.
Cleverness looks like:
- · Choosing the shared, boring pattern over the bespoke one, because it lowers the load on everyone else
- · Turning a process only one person understands into a map anyone on the team can follow
- · Accepting that if you can’t sketch how a service works on a napkin, you probably don’t understand it yet
Services are stories
A process tells people what to do. Documentation and structure tell people why it matters. When a service has no clear story, every new person joining has to become a detective, piecing it together from old tickets, half-remembered decisions and whoever happens to still be around.
Treat documentation and structure as storytelling, and things change:
- · Intent becomes obvious: someone new can follow a request end to end without a guided tour
- · Boundaries become clear: teams know exactly where a new piece of work belongs
- · Maintenance becomes routine: people spend less time working out how something functions, and more time making it better
Complexity is easy. Clarity takes discipline.
Give a team shared structure, and encourage them to tell the story of how their service actually works, and the “complex” system tends to disappear. What’s left is something clear and reliable, and the real cleverness of the people who made it that way.