Role
Technical lead, for a team that needs decisions made
Two engineers disagree about an approach. Both arguments are good. The team has been circling it for two weeks and the cost of the delay now exceeds the difference between the options.
How I fit
I would take this on a small team building something real, not a large organisation needing process. What I bring is the habit of writing decisions down with their reasoning and their cost, which is the difference between a team that moves and a team that revisits the same argument every quarter with no record of why it was settled.
A challenge from this role
Two engineers disagree on an approach. Both have made good arguments and neither is wrong. It has been open for two weeks, the work behind it has stalled, and the delay is now costing more than the difference between the two options possibly could.
How I approach it
Name the real disagreement first, because it is usually not the one being argued. Two good engineers arguing for a long time are almost always optimising for different things, and neither has said which. Once it is visible as a trade, say which one this team is choosing and why, then write it down with the cost of the choice included, because a decision recorded without its cost gets attacked the first time the cost is felt. Then make it reversible if it can be, and make the reversal condition explicit. Most decisions do not need to be right, they need to be made, recorded, and cheap to undo.
What proves it
Technical forks argued to a conclusion with the cost of each choice stated rather than hedged.
Every piece of work ends with a document somebody could resume from cold, which is what makes a decision durable.
Sole engineer on a platform, accountable for design, delivery and the consequences of both.
Declining to generalise a second similar build, because two clients is a coincidence and three is a pattern.
Engine design and interface craft, both current, so the direction is informed rather than remembered.
The cost of an open decision
An unresolved technical decision is not free while it is open. Work stalls behind it, people build tentatively around it, and the arguments harden as each side invests more in being right.
Past a certain point the delay costs more than the gap between the options. Recognising that moment and closing it is most of the job, and it is uncomfortable, because closing it means somebody’s argument does not win.
Two good engineers are optimising for different things
When two capable people argue for a long time without converging, they are almost never disagreeing about facts. They are weighting different values, and neither has said which.
One is optimising for speed of delivery, the other for cost of change later. Both are legitimate. Neither is a technical argument, which is why the technical argument cannot resolve it.
Naming that turns an argument into a choice, and choices are things a lead can actually make.
Record the cost, not just the decision
A decision written down without its cost gets attacked the first time somebody feels that cost, and by then nobody remembers it was accepted deliberately.
Write what was chosen, what was given up, and what would make this worth revisiting. Then the conversation in six months is about whether the condition has been met, which takes ten minutes, rather than a rerun of the original argument, which takes two weeks.
Questions people actually ask
- Do you want to stop writing code?
- No, and I would be worse at this if I did. Direction given by somebody who has not touched the system in a year is guesswork with authority attached.
- What size team?
- Small, and building something real. I am not the right person for a large organisation that mainly needs process, and pretending otherwise would waste everybody's time.