I’ve watched a lot of developers make the move into architecture. The ones who struggled the longest weren’t the ones who didn’t understand distributed systems or couldn’t draw a useful architecture diagram. Most of them had plenty of technical depth.
What they struggled with was something harder to name.
It usually came out in small ways at first. An architect who kept rewriting code during a code review instead of asking questions. A senior architect who volunteered to take on a critical bug fix personally because “it would be faster.” A new principal engineer who stopped going to team planning sessions because “that’s not what I should be doing anymore,” and then six months later admitted they felt disconnected and useless.
All of these are versions of the same problem. The identity they had built their career on, “I am the person who builds things,” was no longer the job description. And nobody had helped them build a new one.
The competence trap
Developers become good developers by being the person who knows things and builds things. That’s the loop: learn, apply, get better, get recognized, get more opportunity, repeat. The reward system in software development is tightly coupled to personal technical output.
That loop creates a specific kind of identity. You are competent because you can do things other people can’t. You add value by doing those things. Your standing in the room is based on your technical credibility, which is demonstrated by doing.
Now move that person into an architecture role. Their technical credibility is real. They absolutely know things. But the way that competence is supposed to be expressed has fundamentally changed. You no longer add value by building. You add value by enabling others to build better than they would have on their own.
That’s a different answer to the question “what do I actually do here?” And for someone whose identity has been built on the previous answer, the new one can feel hollow for a long time before it starts to feel true.
The moment it usually comes to a head
There’s almost always a specific moment in a new architect’s first year where this identity tension gets acute.
The honeymoon period of the new role is over. They’ve been in meetings, drawn diagrams, reviewed designs. And someone asks some version of the question: “What have you been working on lately?”
And the honest answer is uncomfortable. “I’ve been in a lot of conversations. I’ve been thinking about how we should restructure the data layer. I’ve been trying to get the platform team and the product team aligned on the API contract. I’ve been reviewing and providing feedback on a lot of designs.”
None of that sounds like working to someone whose definition of work is “producing tangible output.” Including, often, the architect themselves.
This is the moment where a lot of people start drifting back toward implementation. Not because the architectural work isn’t important, but because the psychological feedback loop is much weaker. Building something gives you immediate evidence that you did something. Shaping a conversation that eventually leads to a better system decision gives you evidence three months later, indirectly, and it’s hard to draw a clear line from your contribution to the outcome.
What the new identity actually looks like
The identity shift that works involves moving from “I am the person who builds the best things” to “I am the person who creates the conditions for the best things to get built.”
That sounds like a small reframe, but it isn’t. It changes almost everything about how you think about your day, your value, and your success criteria.
When your identity is the first version, a week where you didn’t write code is a bad week. When your identity is the second version, a week where you unblocked three teams, shaped two major technical decisions, and built alignment between two groups that were heading for a costly collision is an excellent week. Even though your GitHub activity is empty.
The practical work of building this new identity involves a few things. First, getting explicit about what architectural output actually looks like. It’s documented decisions, design reviews, shared frameworks, improved team processes. Second, finding ways to make that work visible, both to yourself and to the people you work with. Third, getting comfortable with a longer feedback loop. The work of architecture compounds over months and years, not days and weeks.
The thing nobody tells you
What I wish someone had told me earlier, the discomfort you feel in the first year of an architecture role isn’t a signal that you’re in the wrong job. Rather, it’s a signal that you’re doing it right.
If you’re comfortable, you’re probably still doing developer work in an architect costume. If you’re a little disoriented, a little unsure whether you’re adding value, a little frustrated by the ambiguity of the role, that’s the transition actually happening.
The identity shift takes time. It takes practice. And it takes a willingness to sit with the discomfort long enough for the new answer to start feeling true.
The developers who make it through that transition tend to find something they didn’t expect on the other side. The work starts to feel bigger. The impact becomes harder to measure but easier to see. And the orchestra starts to sound like something you could never have produced with just one instrument.
Thanks for reading The Software Conductor! Subscribe for free to receive new posts and support my work.
