Lately I’m seeing the same thing with several clients: people leading a team struggle to make technical decisions. That’s actually why I’ve been working so closely with several of them lately, almost as a sparring partner for the decision rather than the one making it for them — and, without exaggerating, it’s one of the parts of the work I enjoy most.
What I generally find when I sit down with a team is a process problem, not a judgment problem: they usually know the specific topic better than anyone, but they never learned an orderly way to decide. That’s where I come in — not to decide for them, but to put structure around something that, until then, ran purely on instinct.
The first mistake I find almost every time is that the decision had been made alone, or in a very small group, without writing anything down: not the context, not why that option was chosen over another, not why now instead of later. So the first thing we do together is simply write: what problem you’re actually trying to solve, what context this specific decision is being weighed in, and what non-negotiable outcome you expect from it — something measurable. A percentage improvement in performance, a concrete quality bar, whatever it is, but measurable.
After that, we pick a decision framework together that fits the size of the problem — a SWOT, a side-by-side comparison with a vote among the options on the table — and, what can’t be skipped, we expose that decision to be challenged by someone else before closing it. Not to ask permission: to bring in a perspective different from the one already inside the problem. Watching a team go from “we just decided this between the two of us in a hurry” to defending the same decision with context and other people in the room is, for me, the most rewarding part of the work.
The other mistake I see often is almost the opposite: freezing while looking for the ideal tool, the one that “solves everything.” Trying to predict whether a company will still be maintaining some framework three years from now, for instance — something nobody can know, not even the company itself. There, my job is more about conversation than method: I tell them, over and over, to stay in their circle of influence, not their circle of concern. They’re going to decide with the information they have today, not with the certainty they wish they had about the future of a technology they don’t control.
When they decide as a group, with a clear process and in good conscience, there’s no reprimand waiting on the other side — no decision is free of consequences, but having weighed the alternatives leaves them with a mitigation plan for each scenario. And watching that calm settle into a team that used to decide out of fear is the reason I keep choosing this kind of work over just handing them the answer myself.