Putting the “trade” in “trade-off”.
I think museums are best enjoyed as a solo activity. Every time I go with a group, I feel tension from an invisible rubber band that keeps us from getting too far apart. Either I’m at my limit for ancient artifacts and pushing us all forward, or I’m stubbornly reading every detail about Napoleon the Third’s love of trains while everyone else is pleading with me to leave the French History wing. We all end up a little disappointed.
There is a trade-off of depth and breadth that comes with every visit to a museum. Do you want to explore every room of the Louvre? Would you rather spend all day appreciating the Tree of Crows? Neither is better, but knowing which you prefer will help you manage your time.
Problematic Systems
In software engineering, teams face a similar challenge with project structure. Over time, projects can become large, integrated systems called “monoliths” where all of the code is put into the same project. While this setup is convenient, it collapses under its own size. I’ve seen countless teams struggle to update older code or deliver small fixes because a tiny change requires retesting the entire system.
Inevitably, someone suggests switching to a “multi-entity” architecture, where code is divided into independent projects that communicate with each other instead of being fully integrated.
Multi-Entity seems like the obvious solution. But the moment you try to make a small change, data incompatibilities between services can bring the entire system crashing down. While individual updates are easier, ensuring that all services work together requires extensive testing. The new problem we’re facing is the complexity of having these services integrate correctly. So what do you do?
You’ll never believe what happens next. Someone in the room actually suggests moving back to a monolithic architecture. I’ve watched this happen with my own eyes and ears.
Although it’s true that the problems we identified were solved by changing our architecture, it was foolish to think that there wouldn’t be new, different problems that would arise from the switch.
We can change the system to change the problems, but the real issue is that problems are always outcomes of systems. We have to find ways to address them.
Problem Decomposition
In software testing, Root Cause Analysis (RCA) is used to identify the true source of a problem. It borrows from Socratic Questioning to dig as deeply as possible to identify foundational problems, rather than addressing surface level symptoms. It’s like weeding a garden – if you only remove the plants at the surface, their roots will keep growing new weeds.
Let’s say that your team supposed to deliver a report, but it was a week late. Why did you miss that deadline?
At first glance, the delay was caused by inaccurate information in the final draft, which required fact-checking and rewrites. The report was also edited by hand, and copies were printed and passed around in person. There was a huge productivity loss due to gaps in ownership. Miscommunication with the customer led to entire sections being scrapped. Take a look:
Lets try decomposing those problems into their smallest forms. We can resolve fact-checking by incorporating it into our process earlier. Hand-editing needs to stop too – if the team shifts to online tools, edits can be incorporated instantly. Ownership can be passed without waiting overnight to deliver notes in-person. Finally, we can stop miscommunicating with customer feedback loops to stop the team from getting off-track. How does it look now?
Do each of these feel fully decomposed? Since fact-checking is a skill that no one on the team has, we need to hire a new person. Online tools are easy to implement, but who’s responsible for ownership? Is there someone who is taking on new responsibilities? Setting up feedback loops involves someone to handle coordination, and you’ll need more time to account for client feedback.
Once the team has settled on fully decomposed solutions, they can begin to incorporate them and actually solve the root problems. If the team had stopped at the first step, then they wouldn’t have known what was needed to meet the deadline.
The Root of All…
Once you’ve done this kind of analysis for long enough, you’ll start to see three main issues emerge:
- Insufficient Knowledge – training, communication, and experience.
- Insufficient Tools – missing or obsolete tools harm productivity.
- Insufficient Staffing – not enough workers to finish sustainably.
You might notice a common theme with each of these root causes – they all cost money!
I frequently see businesses stop at that first level of solution exploration and expect the team to magically conjure up more time or resources. Sometimes there are ways to improve efficiency, but usually if a business wants something faster than it takes to produce, then they need to invest more money. Businesses never like to hear that answer. They love their bottom line.
The value of mapping out these problems is that you’re able to start a negotiation with management around how you can solve it. “In order to deliver within this timeline… we need these resources.” Because you are armed with knowledge, this is a statement of fact rather than opinion.
Employing this kind of problem alchemy turns complexity problems into money problems. This presents businesses with investment opportunities. Perhaps growing headcount is part of its long-term goals. It could decide to not invest any money, but will have to accept slower timelines.
Just like alchemists turn metal into gold, you transform confusion into clarity. It enables smarter decisions, better planning, and enables real progress, rather than coping with chaos.
Once you’ve turned all of the complicated problems on your plate into matters of strategy and investment, you’re free to move into a new role with new challenges to alchemize.
Leave a Reply