Early in my time as an architect, I had a conversation with my manager that changed how I understood the role. I don’t remember the exact words, and I’d rather not reconstruct a polished speech that never happened. What stuck with me was the shape of it: he expected the job to be wider and stranger than the version I was carrying around in my head.
My version was fairly simple. An architect is basically a lead engineer with a bigger scope. Deepest technical context in the domain, set the standards, make the calls that are too big for any one team, point engineering in a direction. The title changes. The org chart shifts a little. But the shape of the work stays close to what I already knew how to do.
That model wasn’t wrong, exactly. It was incomplete. And the parts it left out have taken me a while to notice, mostly because they show up in ordinary moments instead of big ones.
I think this incomplete model gets carried by two different groups, for two different reasons. Engineers considering the move into architecture often carry it because it’s the closest role they can point to and say, “that, but more of it.” Some leaders carry a version of it too, because “the person with the deepest technical answer” is a much easier thing to staff for than whatever architecture actually is. Neither group is wrong to reach for the simpler version. It’s just not the job.
“I Just Need to Know What They Want”
One version of this shows up often. An engineer is stuck translating something ambiguous from the business side, and they come to me and say some version of, “I just need to know what they want.” Meaning: give me the technical answer so I can go build it. Skip the part where we sit in the ambiguity together.
I understand the appeal. If I hand over a clean answer, the next step is obvious, and probably the fastest path to something shipping. If I were the one implementing it, I might ask for the same thing.
But that request usually isn’t only about the technical shape of the answer. It’s about what the initiative is actually trying to produce, which constraints are real versus assumed, and whether the person closest to the implementation and the people who asked for it are picturing the same outcome. An engineer solving for “give me something clean to build” is solving a real problem. It’s just not always the same problem the business has.
Sometimes the engineer has quietly filled the gap with something reasonable but unstated: keep it consistent with the platform we already run, keep the operational load low, avoid touching a system nobody wants to own. Those are legitimate things to value. They’re just not automatically the same thing the initiative was asking for, and nobody decided that trade-off out loud.
So instead of handing over the answer, I usually redirect toward the outcome. What are we actually trying to make possible here. What has to stay true. What are we willing to trade. Which of these requirements did someone actually state, and which ones did we infer because they sounded reasonable.
That’s slower in the moment. Sometimes it’s slower than it needs to be. But a fast answer can create a false sense of progress if nobody in the room is picturing the same problem yet.
The Diagram Becomes the Argument
When that shared picture doesn’t exist, a whiteboard or a diagram usually gets us there faster than more conversation does.
Sometimes I draw it live. Sometimes I build something after the discussion and send it back for people to mark up asynchronously. The format matters less than having something everyone can react to.
The diagram surfaces things a conversation tends to hide. Someone notices a dependency actually sits with another team. An operational constraint that nobody mentioned out loud shows up. Two people realize they’ve been using the same word to mean different things. A disagreement that sounded technical turns out to be about ownership or risk.
At that point the diagram has stopped being documentation. It’s become the place where the actual decision is happening. That’s one of the parts of this job I did not expect walking in. Drawing a system is familiar work. Using the drawing to expose what people actually disagree about is a different skill, and it sits closer to the center of what architecture is than I originally gave it credit for.
Pushing Back Is Still Part of the Job
There’s a weaker version of this approach, where the architect just asks questions, nods, and lets whatever position shows up first stand. That’s not what I’m describing.
I push back. If an engineer is optimizing for something easier to build instead of the actual outcome, I’ll say so directly. If a design quietly moves risk onto a team that had no say in the decision, I want that visible before it becomes a surprise later. Sometimes my own technical opinion ends up being the recommendation.
The difference is when and how that opinion shows up. By not leading with it, I get to learn from the person who’s closer to the day-to-day reality than I am. They get room to test their own reasoning, push back on my context, and end up with a position they actually understand well enough to defend, instead of one they just inherited from me.
I don’t think engineers want to be told what to do. Most of the ones I’ve worked with want a hard problem to solve. What they need from an architect usually isn’t the answer. It’s enough context to know they’re solving the right problem in the first place.
When Lead Engineer Is Still the Right Mode
None of this means lead-engineer mode is wrong. I move into it deliberately, sometimes.
Greenfield work is the clearest example. So are proofs of concept, technology the organization hasn’t adopted yet, or a heavily cross-functional effort with no obvious technical owner. In those situations, there usually isn’t established team judgment to defer to yet. Deferring to ownership that doesn’t exist isn’t collaboration. It’s just a gap with nobody standing in it.
So I’ll build the first version, make the early calls, give a scattered group something concrete to react to. That’s useful work. It’s just a mode, not the permanent shape of the job. If the proof of concept turns into something the organization depends on, I try to make sure the judgment behind it becomes transferable, so I’m not still the default owner of every implementation decision a year later.
Recognizing What the Situation Needs
This range is probably what makes architecture hard to evaluate from the outside. An engineer moving into the role can worry that stepping back from implementation means becoming less technical. A VP watching an architect who didn’t issue a directive might wonder whether real leadership happened. In a different meeting, that same VP might watch an architect drive a design directly and wonder why engineering isn’t owning it.
Both concerns are fair. Either failure mode is real.
The thing I keep coming back to is whether the architect recognized what the situation actually needed. A team with real ownership needs something different than a group with no shared context yet. A decision stuck between two organizations is a different problem than a technology that doesn’t have a first working model yet. In each case, the useful question is whether the architect reduced uncertainty, or just added one more opinion to the pile.
Architecture is broader than lead engineering. That doesn’t make lead-engineer behavior wrong. It’s still one of the tools. It’s just not the whole job, and it’s probably not even the part that matters most.
I still respect architects who can give a strong, direct technical answer. I’m just less convinced now that being able to give one is the best way to describe what the role actually is.
If you’re an engineer weighing whether to move into architecture, that’s probably the part worth sitting with before the title changes. The technical depth doesn’t disappear. It just stops being the main thing anyone is asking of you. And if you’re the one staffing the role, it might be worth asking what you actually need someone to reduce: uncertainty, or just the number of open questions on your desk. Those aren’t quite the same request either.