I Was Right. It Did Not Matter.
The distance between a correct technical judgment and a decision somebody acts on is most of the architect’s job, and nobody teaches it.
Early in my career I thought technical disagreements were settled by being correct.
You do the analysis. You find the flaw in the plan. You explain it clearly, with the reasoning visible, and the room updates. That is how it works in code review, where the argument and the artefact are the same object, and I assumed it scaled.
It does not scale. On a large programme I have been right about something, said so, been overruled, watched it play out exactly as described, and gained nothing from it except the private satisfaction of having called it. That satisfaction is worth very little. It does not unwind the rework, and there is no version of “I told you so” that improves an engineering organisation.
The uncomfortable lesson took me a while. Being right is the cheap part. It is table stakes, it is the part I was already good at, and it was never the constraint.
The gap nobody names
There is a step between having a correct judgment and that judgment changing an outcome, and it is a real piece of work with its own skills. Most senior engineers, including me for a long time, treat it as either beneath them or as somebody else’s job.
The step is this: getting the decision to a place where it can actually be decided, in a form the person there can act on.
That sounds like politics. It is not, or it does not have to be. It is closer to interface design. You have information in a format that is native to you, which is technical, conditional, and full of caveats. The person who can act on it holds a different model, usually made of dates, money, risk, and commitments to other people. Handing them your format and calling it done is the same mistake as exposing your domain model as your public API and telling consumers to deal with it.
I used to do exactly that. I would explain the failure mode accurately, at length, to someone whose actual question was “does this move the date, and by how much.” Both of us left thinking the other had missed the point.
Why “I raised it” is not a defence
The version of this I am least proud of is the pre-emptive alibi. Say the concern once, in a meeting, get no traction, and move on with the private note that you flagged it. If it goes wrong later, you were on record.
That is not engineering. That is building a defence.
I understand the pull, especially where the same problems recur and pushing feels pointless. But an objection raised in a way that could not be acted on has not been raised in any sense that matters. It exists to protect the person who made it, and everyone can tell, which is why it usually gets treated as noise even when it is correct.
The honest test I try to apply now: if this concern is right, is it currently in a form where somebody who is not me can do something about it? If the answer is no, I have not finished, whatever I have said out loud.
What travels
A few things convert a technical judgment into something that can move. None of them are clever.
Get Stavros Theodorou’s stories in your inbox
Join Medium for free to get updates from this writer.
A number in the other person’s units. Not “this design will cause problems.” A range, in days or in risk, attached to a specific thing. Wrong-but-explicit beats right-but-vague, because a stated number can be argued with and a vague concern can only be absorbed. If somebody disputes your number you have gained a conversation about the actual trade-off, which is what you wanted.
A decision framed as a choice, not a warning. “We can do it this way and accept that the rule will be expensive to change, or spend this much now and make it cheap. Both are legitimate. Here is what each costs.” A warning invites reassurance. A choice with two priced options invites a decision, and it puts the decision where it belongs rather than leaving it with the engineer who noticed.
A written record with a date, attached to the decision and not to a person. This is the part that feels bureaucratic and is not. The point of writing it down is not so you can be proved right later. It is that the next programme inherits it. Organisations do not learn from being told; they learn from artefacts that outlive the meeting.
Reversibility, stated. Most technical arguments are treated as one-way doors when they are not, and a few are treated as details when they are. Saying which one you are looking at changes the room’s temperature more than any other single sentence I know. People will accept a bad reversible decision quickly, and they should.
The part that is genuinely not yours
There is a boundary here and I want to be precise about it, because the failure mode on the other side is real.
Some decisions are not yours and will not become yours by being better argued. Commercial relationships, delivery commitments, how much pushback a client gets. An engineer who believes that enough legibility will eventually hand them that authority is going to spend years being frustrated.
The point of doing this well is not to win. It is that when a decision is made, it is made by someone who can make it, with the actual cost visible, instead of being made by default through an engineer’s silence. Those two outcomes can look identical in the moment. They diverge over a few years, because one of them accumulates a record and the other accumulates resentment.
I have also had it go the other way, where the cost was visible, well framed, owned by the right person, and the answer was still “build it anyway, on the original date.” That is not the process failing. That is the process working and producing an answer I did not like. Those are different things and it took me longer than it should have to tell them apart.
Where this goes wrong
The obvious failure mode is becoming the person who writes documents.
If you spend your attention on making things legible and not on making things work, you have optimised for the wrong half and everyone notices. The credibility that makes any of this land comes from the engineering, not from the framing. A well-structured trade-off memo from someone whose systems do not work is worth nothing, correctly.
There is a second failure mode that is subtler. You can get good enough at this that you start pre-negotiating with yourself, sanding down a real technical objection into something comfortable before anyone else has heard it. That is worse than being blunt and losing. Some things should be said plainly and at full strength, and if that costs you the room occasionally, that is a reasonable price.
The balance I try to hold: be blunt about the technical reality, careful about the format, and completely uninterested in whether the record eventually vindicates me.
The shift
If I had to name what actually changed between senior engineer and architect for me, it is not the quality of my technical judgment. That improved slowly and unremarkably.
What changed is that I stopped treating “I was right” as the end of my responsibility and started treating it as roughly the halfway point. The second half is unglamorous, it looks like admin from the outside, and it is where most of the leverage turned out to be.
I am still not good at it. Which is why I want the counterexamples more than the agreement.
So: think of a time you were overruled on something you were later proved right about. Did having written it down beforehand change anything at all, or did it only change how it felt afterwards?
I’m Stavros Theodorou, a Senior Software Engineer & Architect. I design and run national-scale, public-sector systems. I write about enterprise architecture, clean design in production, and the senior-to-architect shift. If that’s your world, follow me here and connect on LinkedIn.
