Making the decision is not enough
Why a well-documented decision can still fizzle out and what I would set up differently today.
By Daniel Schmeiß3 min read- Decisions
I am looking at a service and come across Python code. Newly written, a few months ago.
More than two years ago we decided to use only TypeScript and Java in the backend. No more Python. When I ask about it, I almost always hear one of these answers:
"This one is a special case." "We didn't have time to rebuild it." "It works, doesn't it?"
From the team's point of view, each of them makes sense. That is how exceptions like this come about.
The decision wasn't the problem
The decision is clear. We worked it out in a public document, with the situation, goals, constraints and options. Everyone affected could read along and join in from the start. My colleagues know it.
They just don't think it is urgent. The Python service works for their team. Rebuilding it takes time they would rather spend on features.
The effort lands in the team right away, the benefit across the whole organisation later. Code moves between teams. People leave the company. At some point someone who doesn't know Python will have to look after that service.
"People move, tech stays."
That is why we agreed on the standard.
My part
Looking back, I treated the decision as done once it was documented. I should have followed up more.
Above all, I should have encouraged the engineers and managers more to stand behind the decision in their own teams. If it only arrives there as a rule from outside, nobody is there to ask at the next exception whether it is really necessary.
So two years later, I am the one standing in front of new Python code, asking questions.
What I would do differently today
For a bigger decision, I would show from the start how far along we are with the implementation.
No big reporting setup. A simple monthly overview, visible to everyone, is enough: Where do we meet the goal, where not yet, and which exceptions are there?
That way everyone sees the same picture. Exceptions become visible before they settle in. And we can talk concretely about why a team hasn't switched yet and what it would need.
Before the next bigger decision, I would ask myself four questions:
- How will we know the decision has been implemented?
- Who regularly sees where we stand?
- Who stands behind the decision in the teams when I'm not in the room?
- How do we decide on exceptions before they quietly become the rule?
Staying with it
I still think the decision we made back then was right. My mistake was paying too little attention to the implementation afterwards.
Making and documenting a decision is the shorter part. After that, everyone needs to see for months whether anything is actually changing.
If you are facing a decision like this yourself, for example during annual planning, plan for the longer part too. And build the way you measure whether you reach the goal right at the start.