👋 Hi, I’m Jos.
For over 20 years I’ve worked with teams that build smart, beautiful things, and sometimes just struggle with the process.
In this newsletter I share what I’ve learned: how to keep complex problems small, and make improvement manageable.
Each week: one theme, one tiny improvement you can use right away, and one book to go deeper.
Table of Contents
🛑 Stop fixing what you don’t understand
It’s a regular Wednesday morning.
You grab your coffee and start your morning routine.
Suddenly the dashboard turns red. Jobs fail, errors spike…
You know at once: something is wrong.
The room goes quiet.
“I see errors” someone calls. Colleagues look up. “I’m already looking,” someone else says. Two more are deep in their screens. From their posture you can tell something is up.
They’re debugging. Or so it seems. Maybe they’re guessing. I’ve done it often myself, and it rarely worked.
Everyone means well. Everyone is busy fixing…
But no one communicates.
No one says what we know for sure.
I call it the fix reflex. And I see it every week.
It’s natural behaviour. Developers in their natural habitat. We love to fix things.
And I’ve seen this pattern in every team for the past 10 to 15 years:
👉 There is urgency, so we jump into action.
👉 Sometimes that helps. Often it doesn’t.
👉 And if I’m honest: I still fall for it too.
Two big cloud outages last week made that painfully clear again.
AWS and Microsoft both had a major outage. Docker containers wouldn’t start.
Jobs failed. Tests refused to pass.
Not because of your code, but because of the environment.
Vague errors that still seem to land on your desk.
And still we dive into the code…
✅ Try this instead: Five simple steps
Pause for five minutes. Facts first. Assumptions separate.
Split the roles:
One person communicates.
One person investigates.
One person peer-reviews.
One person logs what happens.
Keep communication simple:
One thread.
Short.
Factual.
Rhythm over speed.
Schedule the next check-in right away.
Run a 15-minute mini retro within 24 hours.
Preferably the same day. One lesson. Apply it.
👉 These steps are easy to implement. No heavy process thinking needed.
📊 Metrics you can use
Once this approach is in place, you can grow it with a few simple metrics:
Time To First Update
(Minutes until the first update in the thread)Wrong-Fix Count
(Number of fixes you roll back)Assumption Ratio
(Number of assumptions divided by number of facts)Noise Minutes
(Time lost to side paths)Recurrence Rate
(How often this problem returns)
👉 Pick one, two at most. Keep it light.
🌱 Your 1% habit for this week
Like every week i have a little habit you can try. Another small step to make huge impact. So this week. again… Keep it small!
Take one case that is live right now.
Solve it using the steps above. Nothing more.
Facts first.
One change at a time.
Short update in the same thread.
Done.
🎁 Bonus habit
See a problem starting to flare up?
Pull the imaginary Andon cord (like at Toyota).
Stop briefly, bring heads together, recheck facts, confirm roles, set a new check-in.
Five minutes is enough.
📖 Book of the week
Stop Guessing — Nat Greene
This is the ultimate problem-solving book. It helps you stop guessing and look for evidence first.
What it taught me (and might help you too):
Write one sentence that states what you know for sure.
Test exactly one hypothesis at a time.
Keep facts and assumptions separate in your update.
And before you go.. Let me know what you think. Tips, idea’s or feedback… I’m ready to learn. Till next time 👋.