should architects code?

Table of Contents

Key Takeaways

• There’s no simple answer to whether architects should code; it depends on context and personal strengths.
• Staying hands-on helps architects stay connected with technology and maintain empathy with engineers.
• Architects must balance coding with big-picture thinking to avoid losing sight of strategic goals.
• The true value of an architect is in enabling teams and translating vision into practical solutions.
• Whether coding or not, clarity on your role and impact is what matters most.

I was asked this question recently and it made me stop and think. I don’t think there is a yes/no answer.

To me, it’s never been about whether you could code; it’s about knowing when and why you should.

The Hands On Dilemma

Early in my career, when I first transitioned from developer to architect, it was difficult for me to separate myself from the codebase. Writing software was how I defined my value ; it was tangible proof of my contribution.

I know from experience now that this is a very common issue for those on that path from engineer to architect.

As my responsibilities expanded, coding began to feel like a distraction. Meetings piled up, designs needed refining, and teams looked to me for answers beyond syntax or structure.

I struggled with the balance. Coding was familiar, comforting even, but the impact of my decisions as an architect extended far beyond a single pull request.

Eventually, I came to realize that my role had shifted - it now wasn’t about delivering features but enabling teams to deliver them effectively. That shift in perspective was liberating but also bittersweet.

Staying Hands-On?

Yet, there’s a danger in stepping too far away from the code. As architects, we rely on engineers to bring design to life, but how can we guide them if we lose touch with the challenges they face? Technologies evolve rapidly, and patterns that seemed cutting-edge a few years ago might now feel clunky or outdated.

Staying hands-on doesn’t mean coding every day. It’s about staying close enough to the process to understand it; whether that’s by contributing to smaller, non-critical tasks, pairing with developers on challenging problems, or simply reviewing code to keep a finger on the pulse.

For me, occasional coding has been a way to maintain empathy. It reminds me of the frustrations of debugging, the joy of solving a tricky problem, and the complexity of implementing designs that, on paper, seemed so straightforward.

Can you see the wood for the trees?

There’s nothing quite like a quote from the 1500’s.

Architects who spend too much time hands on may miss the bigger picture; the cross-team dependencies, the long-term scalability concerns, or the business priorities driving technical decisions. There is a risk in becoming too immersed in the weeds.

I’ve seen architects who couldn’t resist diving into the details, only to find themselves overwhelmed. Their strategic influence waned because they were too busy chasing the next bug fix or feature implementation.

Architecture is a balancing act.

The value of an architect lies in their ability to translate high-level goals into actionable designs and empower others to implement them. Sometimes, that means letting go of the keyboard and trusting your teams to execute.

As always - it depends. on the context, the team, and the individual architect’s strengths. Some thrive as hands-on leaders, blending design with delivery. Others excel by focusing entirely on strategy and communication, leaving implementation to the experts.

What’s essential is clarity; both about your role and your impact. If coding enhances your ability to lead, guide, or inspire, then it’s a tool worth using. But if it becomes a crutch or a distraction, it might be time to step back.

A Personal Reflection

Today, my relationship with coding is a pragmatic one. I dip in when it helps me connect with my teams or validate a design, but I no longer feel the need to prove my technical chops.

My value as an architect isn’t measured by the lines of code ; it’s measured by the systems I help shape and the teams I help grow.

At its core, any debate over whether architects should be hands-on or not isn’t about skills; it’s about priorities. Architects who can/do code aren’t better or worse than those who can’t/won’t/don’t.

What matters is how effectively you can bridge the gap between strategy and execution, ensuring that your decisions drive outcomes, not just output.

So where do you stand?

Whether you’re someone who thrives on hands-on work or who prefers to guide from a higher level - the question is whether you’re doing what’s necessary to make your systems, and strategy and people succeed.