Architecture is genuinely a different job from writing code line by line. “Different job” does not mean “disconnected job” — and the best architects never let it become one.

Picture a football coach who has not kicked a ball in fifteen years, never watches practice, and only sees the team on match day through a scoreboard. That coach can still talk about strategy in theory. But ask them whether a particular drill is realistic for tired legs in the eighty-ninth minute, and they will be guessing. They have lost the “feel” of the game — the part that only comes from being close to it.

A software architect who never touches code risks becoming exactly that coach. Architecture is the big-picture plan for how a software system is built — which pieces exist, how they talk to each other, what rules keep everything from turning into a tangled mess. It is genuinely a different job from writing code line by line. But “different job” does not mean “disconnected job.” The architects who make the best decisions are almost always the ones who still get their hands a little dirty — even if it is just occasionally, even if it is just a small piece of the system.

This is not a new debate. It comes up in almost every technical community, in almost every generation of engineers. Some argue that architecture is a specialised skill in its own right, deserving full attention, and that splitting time with hands-on coding just makes an architect mediocre at two things instead of excellent at one. Others argue the opposite: that architecture without regular contact with real code is not really architecture at all — it is just guessing with extra confidence. The honest answer, as usual, sits somewhere in between, and this guide walks through exactly where.

It also helps to be clear about what this guide is not saying. It is not saying architects should compete with developers to write the most code, or that an architect who writes zero code today is automatically doing a bad job. Circumstances differ — team size, company stage, personal history, health, workload. What matters is the underlying habit and mindset: does this person actively work to stay close to the reality of building software, or have they quietly let that connection fade away?

Not forty hours a week of production code. Something much smaller, and much more specific — enough to keep an honest, felt sense of the work alive.

This is worth clearing up right away, because it is easy to picture the wrong thing. Staying hands-on does not mean an architect should spend forty hours a week writing production code like a full-time developer. That is not realistic, and honestly, it is not even the architect’s job. Architects are paid to think about the shape of the whole system — the decisions that are painful to reverse later, the trade-offs between speed and safety, the way a hundred small choices add up to either a healthy codebase or a fragile one.

What “hands-on” really means is smaller and more specific:

• Writing a proof-of-concept before asking a team to commit months of effort to an idea — a rough, throwaway version built just to test whether the core assumption actually holds up.
• Reading real code in the actual codebase, not just diagrams that describe it, so the mental model of the system matches what genuinely exists rather than what was true two years ago.
• Occasionally picking up a small ticket or bug fix, especially in an unfamiliar part of the system, as a deliberate way of visiting corners of the codebase that would otherwise never get a second look.
• Reviewing pull requests closely enough to understand not just what changed, but why it was hard — asking questions instead of simply approving with a quick glance.
• Trying out a new tool, framework, or library with their own two hands before recommending it to twenty other engineers who will then have to live with that choice for years.

There is a useful test for telling the difference between genuine hands-on involvement and merely pretending to be hands-on: could the architect sit down right now, with no help, and actually make the small change they are describing? If the honest answer is “not without a lot of hand-holding from the team,” that is a signal the connection to real code has started to fade, even if the architect still talks about the system with total confidence.

It is also worth separating “coding” from “understanding code.” An architect does not necessarily need to write brand-new features to stay grounded — reading the codebase carefully, tracing how a request actually flows from the front end to the database, or debugging a real issue someone else reported, all count as staying hands-on. The goal is contact with reality, and there is more than one way to maintain it.

Nobody decides on day one to stop coding forever. It happens slowly — and it has a name: ivory tower architecture.

Nobody decides on day one to stop coding forever. It happens slowly. A meeting here, a slide deck there, a promotion that adds more people to manage and fewer hours in the day — and a year later, an architect realises they have not opened a code editor in months. This slow drift has a name among engineers: ivory tower architecture. It describes decisions made from a place so far above the actual work that they stop reflecting reality.

Here is what tends to go wrong when that drift is allowed to continue unchecked:

None of this means the architect is lazy or careless. It is simply what happens naturally when a role pulls someone further and further from the keyboard, and nobody actively resists that pull.

There is also a quieter, more personal cost that rarely gets talked about: the architect’s own sense of confidence. Someone who used to feel completely at home inside a codebase, but has not opened one in a long while, often starts to feel a strange kind of nervousness about technical conversations — worried about being asked a question they can no longer answer with certainty. That nervousness can push an architect toward vague, hedge-everything language, which developers notice immediately and interpret, correctly, as a loss of hands-on footing.

Consider a simple, imaginary example. A payments team once had an architect propose combining two services into one, arguing it would “simplify things considerably.” The plan looked reasonable in a diagram. But nobody on the architecture side had actually opened the two codebases recently, and it turned out one service had accumulated years of subtle, business-critical logic buried deep inside functions with unhelpful names. Merging them was not a two-week job — it took four months and introduced two serious bugs along the way, simply because the “simple-looking” merge hid a mountain of complexity that only direct, hands-on digging would have revealed in advance.

Seven practical advantages that show up in daily decisions, hallway conversations, and how quickly a team recovers when something goes wrong.

It helps to be specific about exactly what staying close to code buys an architect. These are not abstract virtues — they are practical advantages that show up in daily decisions, in the tone of hallway conversations, and in how quickly a team recovers when something goes wrong. Taken one at a time, none of them sounds dramatic. Taken together, they explain why some architects are trusted deeply by their teams while others, despite equally strong résumés, never quite earn that same level of confidence.

1. It keeps decisions grounded in reality

An architecture diagram is a simplification by design — that is the whole point of a diagram. But simplifications can quietly hide the very details that make a decision succeed or fail. Someone who still writes code occasionally develops an instinct for spotting when a clean-looking box on a diagram is actually going to be painful to build. They know, from recent lived experience, that “just add a cache here” often means untangling three other systems that quietly depend on data being fresh, not cached.

2. It earns real credibility with engineers

Advice lands differently depending on who is giving it. A suggestion from someone who clearly still understands the day-to-day struggle of writing and debugging code carries far more weight than the same suggestion from someone who has not touched a terminal in years. Credibility is not handed out with a job title — it is earned, and it has to be re-earned continuously. Teams remember, and they talk to each other. An architect’s reputation for being “still one of us” or “totally out of touch” spreads quickly, and it is far easier to lose that reputation than to rebuild it.

3. It sharpens judgment about trade-offs

Nearly every architectural decision is a trade-off: speed versus safety, simplicity versus flexibility, cost versus performance. Judging those trade-offs well requires a felt sense of what each option actually costs in practice — and that felt sense fades quickly without regular contact with real implementation work. Someone who recently struggled with a flaky test suite understands, viscerally, why “just add more tests” is not automatically a free win. Someone who has not struggled with it in years might say it without a second thought.

4. It keeps the architect useful in a crisis

When something breaks badly at two in the morning, the people who can actually help are the ones who can still read a stack trace, still reason about a query plan, still open a debugger. An architect who has kept a working relationship with code becomes a genuine asset during an outage rather than someone who can only ask for status updates. There is a particular kind of calm that spreads through a team when a senior technical leader jumps in and starts helping directly instead of just requesting hourly summaries.

5. It keeps their mentoring honest

Junior and mid-level engineers learn enormous amounts from watching how a more experienced person actually thinks through a problem, not just from being told the “right” answer. An architect who occasionally codes alongside the team creates far richer learning moments than one who only reviews finished work from a distance. Watching someone senior get genuinely stuck, try a few approaches, and eventually work through a tricky bug teaches a junior engineer more about real problem-solving than any polished lecture ever could.

6. It keeps technology choices honest

New frameworks, libraries, and tools appear constantly, each promising to solve yesterday’s problems. An architect who evaluates these purely by reading marketing pages and conference talks is far more likely to be swayed by hype. Someone who has actually spent an afternoon wiring up a small example with the tool tends to notice the rough edges much sooner — the missing documentation, the awkward configuration, the subtle bug in an early release — long before recommending it to dozens of engineers across an organisation.

7. It keeps empathy alive

This one is easy to underestimate. An architect who regularly feels the small frustrations of real development — a confusing error message, a slow build, a flaky pipeline — naturally designs standards and guidelines with more empathy for the people who will actually live inside them every day. An architect who has forgotten those frustrations tends to write rules that look tidy on paper but quietly make everyone else’s daily work harder.

Plenty of professions have already learned this lesson the hard way — from pilots to surgeons to city planners.

None of this is a new idea outside of software — plenty of professions have already learned this lesson the hard way.

Notice the shared pattern: in every one of these professions, staying “hands-on” does not mean doing the junior person’s job. The head surgeon is not stitching every patient in the hospital. The flight instructor is not flying every route the airline offers. It means never letting the gap between “planning the work” and “doing the work” grow so wide that judgment starts to drift.

One more analogy worth sitting with: a city planner who designs new roads without ever driving on the roads they have already built. On paper, a new intersection might look perfectly efficient — clean angles, plenty of lanes, generous turning radius. But a planner who occasionally drives through their own city at rush hour will notice things no diagram reveals: the blind corner that makes left turns dangerous, the traffic light timing that backs up an entire street, the crosswalk nobody actually uses because it is in the wrong place. Software systems have the same kind of hidden friction, and the only reliable way to find it is to occasionally travel the same roads the engineers travel every day.

Engineering teams are remarkably good at detecting who has actually “been there.” Usually it takes one or two conversations.

Here is something many new architects underestimate: engineering teams are remarkably good at detecting who has actually “been there.” It does not take long — usually one or two conversations — for a team to sense whether the person setting direction understands the terrain or is speaking from theory alone.

This matters because architecture, more than almost any other technical role, depends on influence rather than authority. An architect rarely has the power to simply order engineers to do something; they have to persuade. And persuasion works best when it is backed by lived experience. “I tried this exact pattern on a side project last month and here is what surprised me” lands very differently than “I read that this pattern is best practice.”

There is an interesting side effect of this dynamic worth mentioning: humility actually builds more credibility than false confidence does. An architect who openly says “I have not worked directly in this part of the system recently, let me look at the code before I weigh in” earns more respect than one who bluffs an opinion. Admitting the limits of current, hands-on knowledge — and then actually going to close that gap by looking at the real code — is itself a form of staying grounded, and engineers notice and appreciate it.

Picture a spectrum, not an on/off switch. The goal is not to live at the far left — it is simply to stay out of the far right.

There is no single right answer here — it depends on the size of the organisation, the seniority of the architect, and how many teams they support. But it helps to picture this as a spectrum rather than an on/off switch.

Most experienced architects settle somewhere in the middle of this spectrum: not writing production code every day, but regularly enough that the muscle never fully weakens. A common, healthy pattern is spending a modest slice of each week — sometimes as little as a few focused hours — on hands-on technical work: a proof-of-concept, a tricky bug, a new tool worth trying firsthand.

It is worth noticing that position on this spectrum is not fixed forever — architects naturally slide back and forth depending on what a given project demands. During a major, unfamiliar initiative, it makes sense to lean further left, spending more time hands-on to build real understanding before making big calls. During a calmer stretch focused mostly on governance and planning, it is fine to lean right for a while. The danger is not temporarily drifting toward the ivory-tower end — it is staying there permanently without ever consciously pulling back.

Staying hands-on is not free. It costs time that could go toward planning, documentation, and stakeholder communication.

Staying hands-on is not free — it costs time that could go toward other important architect duties like planning, documentation, and stakeholder communication. A fair look at the topic means being honest about both sides.

The goal is not to eliminate the trade-offs — it is to manage them deliberately. A little hands-on work, applied thoughtfully, tends to pay back far more time than it costs, because it prevents the kind of expensive, late-discovered mistakes that come from decisions made purely on paper. Think of it less like a tax on an architect’s schedule and more like an insurance policy: a small, regular premium paid in hours, protecting against the much larger cost of a plan that quietly falls apart the moment it meets real code.

Small, consistent habits work far better than occasional heroic effort. Six patterns that fit into an already busy calendar.

This does not require a dramatic life change. Small, consistent habits work far better than occasional heroic effort. None of the ideas below require blocking off an entire day — most fit comfortably into the cracks of an already busy calendar, as long as they are treated as genuinely important rather than optional extras to be skipped whenever something more urgent shows up.

None of these habits need to happen all at once, and nobody expects an architect to do all six every single week. Picking even two or three that fit naturally into a particular team’s rhythm — and sticking with them consistently — does far more good than an ambitious plan that quietly falls apart after the first busy sprint.

A few well-known ways the hands-on habit goes wrong — each easy to recognise, and easier to fix once named.

Becoming a bottleneck

If an architect insists on personally writing every proof-of-concept or reviewing every single line, they slow the team down instead of helping it. Staying hands-on should support the team’s pace, not compete with it.

Rewriting engineers’ work without asking

Quietly changing someone’s code after the fact, instead of discussing it with them, damages trust fast and teaches the team to stop taking risks in front of the architect.

Coding only in comfortable, familiar territory

It is tempting to only touch the parts of the system that feel easy and safe. The real value comes from occasionally stepping into unfamiliar or newer parts of the codebase, where blind spots are most likely to be hiding.

Treating hands-on time as optional the moment things get busy

It is tempting, whenever a calendar fills up with meetings, to quietly cancel the “coding hour” first, since nobody is directly waiting on it the way they are waiting on a decision or an approval. Left unchecked, this turns into a habit, and the habit turns into months, and the months turn into exactly the ivory-tower drift this guide is warning about. Protecting even a small, regular slice of hands-on time — treating it the same way an important recurring meeting would be treated — helps keep it from silently disappearing.

Yes — and that is expected, not a warning sign. The volume shrinks; the willingness to open the code should not.

Yes — and that is expected, not a warning sign. As architects grow more senior and take on responsibility for larger systems or multiple teams, the amount of code they personally write naturally shrinks. What should not shrink is their willingness to occasionally get close to real implementation work when it truly matters — a risky new initiative, an unfamiliar technology, a critical production issue.

The common thread across every stage is curiosity that never fully switches off. Architects who stay effective for decades are rarely the ones who coded the most in any single year — they are the ones who never let a year go by where they stopped being curious enough to open the code and look.

It also helps to reframe what “staying current” even means at senior levels. A chief architect overseeing dozens of teams cannot possibly be deeply hands-on in every technology those teams use — that would be an unreasonable expectation. What is reasonable, and genuinely achievable, is picking one or two areas each year to go deliberately deep on, staying just familiar enough with the rest through regular conversations, code reviews, and the occasional guided walkthrough with the engineers who live in those systems daily. This targeted approach keeps the overall instinct sharp without pretending one person can personally master everything.

Six honest questions that come up repeatedly — and honest answers to each.

Is not architecture supposed to be a step away from coding?

In terms of daily responsibilities, yes — an architect’s main job is thinking about structure, trade-offs, and the bigger picture, not shipping features every day. But “a step away” does not have to mean “completely disconnected.” The most respected architects treat the role as a shift in focus, not a permanent exit from technical work. They simply spend their remaining hands-on time more deliberately — aimed at the riskiest or least familiar parts of the system, rather than spread evenly across everything.

What if an architect genuinely does not have time to code at all?

This is a common and honest situation, especially for architects supporting many teams at once. In these cases, the goal shifts slightly: instead of writing code personally, the architect can stay grounded by spending real time in code reviews, sitting in on debugging sessions, and asking engineers detailed, curious questions about what made a piece of work hard. It is a smaller substitute for hands-on coding, but it is far better than no contact with reality at all.

Does staying hands-on mean an architect should out-code the engineers?

No — and trying to do so usually backfires. Engineers who work in a system every day will almost always be faster and more precise within that system than an architect who dips in occasionally. That is completely fine and expected. The goal of staying hands-on is not to compete with specialists; it is to maintain enough personal, felt understanding of the work to make wiser decisions and give more credible guidance.

Can too much hands-on coding actually hurt an architect’s effectiveness?

Yes, if it is not balanced carefully. An architect who spends most of their time coding may end up neglecting the very things only they can do — designing the big picture, aligning stakeholders, documenting decisions, and thinking several steps ahead. The healthiest pattern treats hands-on coding as a supporting habit that sharpens judgment, not as the main event.

How does this apply to architects who came from a non-coding background?

Some architects move into the role from adjacent paths — systems administration, quality assurance, product management — without years of hands-on development experience behind them. For these architects, deliberately building basic hands-on coding comfort is not about becoming an expert developer; it is about closing the gap enough to hold credible, grounded conversations with the engineers they work with every day. Even a modest, steady investment in this direction pays off significantly over time.

What is a realistic amount of hands-on time to aim for?

There is no universal number, but many experienced architects find that even a small, protected slice of each week — enough for a short prototype, a real code review, or pairing with an engineer — is enough to keep their instincts sharp. What matters far more than the exact number of hours is consistency: a little bit, regularly, beats a lot, rarely.

None of these ideas require becoming a full-time developer again. They just protect the one thing that makes architectural judgment reliable: honest, current, felt contact with real code.

None of the ideas in this guide require an architect to become a full-time developer again, and none of them are about proving anything to anyone. They are simply about protecting the one thing that makes architectural judgment reliable in the first place: an honest, current, hands-on sense of what building the system actually feels like.