Approach
The method, in the order I do it
If the system scares you to touch, you want to know two things: what I'll do, and in what order. Here it is. I read first, find the load, then implement, and I leave a map behind.
-
Read the real system
I start with the system as it runs, not as it's documented. I watch it under load, I reproduce the failures you've been describing, and I trace where the data actually goes. The gap between the docs and the behavior is usually where the problem is hiding, so I treat that gap as the map I'm building.
-
Find the load
Every tangled system has a piece carrying the real weight. I identify it and I look at what was built around it, because the layers are almost always there to protect that piece or to compensate for a weakness in it. Once I know what's load-bearing, I know what's not allowed to be touched.
-
Cut back to the signal
I make the load-bearing part do one clean job, and I remove the layers that don't earn their cost. I work in small, reversible steps so you can see each change and roll it back. The goal is a design your team could redraw on a whiteboard, because if it can't be drawn, it can't be trusted.
-
Leave the map behind
The work isn't done when it's made simple. It's done when the person on call can explain it. I write the account up for them: what the system does, why the simple design holds, what to watch, and where it's allowed to fail.
The quick check
Is this you?
-
You can't say what the system does
The docs describe a system you had years ago.
-
One person is the only safety net
Their resignation would be a risk event.
-
Change has become expensive
The idea takes a week. The fear takes the quarter.
-
You've stopped trying to fix the root
Workarounds are the budget line now.
Three or four of these is the point where the tangle is costing more than the fix would. That's what the first call is for.
Depth is selective on purpose. I go deep where the system is hard and stay out of the parts that are fine.
What counts as a fit
Bring the problem that needs one unifying voice to see it through
The system is real and it's yours
You can give me access to the actual system, not a slide about it. I need to touch the box to understand what's inside.
There's a cost to the tangle
The complexity is costing you something you can name: failed deploys, on-call pain, a feature you can't ship because you don't trust the part underneath it.
You'll act on the finding
I can map a system and name the simple design, but the cut has to be a decision you're willing to make. There's no point to the work if the answer will sit in a drawer.
You want simple, not just new
The end goal is fewer moving parts you have to think about, not a modernized stack that's just as complicated with a newer name on it.
What is not a fit
- A greenfield build where nothing exists yet to untangle. That's a different job and I'll say so.
- A system that's complicated because the problem is genuinely complicated and you're avoiding the decision. Simplicity can't remove a requirement you haven't accepted.
- A project where you need a team to run it day to day. I'm one person on the hard part, not a staff.
Not sure it's a fit? That's what the first call is for.
Send the shape of the problem. I'll tell you honestly whether this is the right way to solve it.
Contact