There is a specific moment when a growing engineering team starts to break. It is not when the codebase gets too large or when deployments start failing on Fridays. It is when the person making architectural decisions has not shipped production code in two years.
The gap between what a system should look like on a whiteboard and what it actually takes to build, deploy, and maintain in production widens every month an architect or engineering manager stops writing code. That gap does not show up in org charts. It shows up in missed estimates, brittle integrations, and design decisions that look elegant in a diagram but create misery for the people implementing them.
If you are evaluating whether to hire a software architect, bring on a technical consultant, or promote someone into a leadership role, the single most telling signal is this: do they still build?
The Player-Coach Engineering Leader Is Not a Compromise
There is a persistent assumption in tech hiring that leadership and hands-on work are opposing forces. The logic goes: once someone reaches a senior enough level, their time is better spent in meetings, reviewing pull requests from a distance, and setting direction. Writing code becomes beneath the role.
This framing misunderstands what architectural leadership actually requires. A software architect who does not code is designing in theory. They are making decisions about service boundaries, data pipelines, security controls, and deployment strategies based on how they remember those things working — not how they work today.
A player-coach engineering leader, by contrast, stays grounded. They know that the Terraform module they are recommending has a state-locking quirk that will burn half a sprint if no one accounts for it. They know that the API integration pattern they are proposing will collide with the existing authentication layer because they have recently built against that same layer. Their decisions carry the weight of current, lived experience.
Our partner Stephen McDermott has spent more than 25 years building software — .NET and Java/Spring service layers, API and integration platforms, ETL and reporting systems — across healthcare, media, financial services, and SaaS. He has led engineering teams of up to 20 people, onshore and offshore. And through all of that, he has continued to write a significant share of the code himself. Not because there was no one else to do it, but because staying in the codebase is how an architect keeps their judgment sharp.
That is not a compromise between leading and building. It is a deliberate practice that produces better architecture.
What Happens When the Architect Stops Building
The failure mode is predictable and well-documented across engineering organizations of every size. When the senior technical decision-maker drifts away from implementation, several things compound:
Designs Become Disconnected from Reality
An architect who has not wrestled with a production deployment in months will underestimate complexity. They will propose microservice boundaries that make sense on a whiteboard but create a distributed-systems headache for a team of four. They will recommend tooling they have read about but have not configured. The team inherits the gap between intention and implementation as unplanned work.
Estimates Lose Calibration
One of the most valuable things a hands-on technical leader provides is realistic estimation. Not because they are a better project manager, but because they have recently done the work. They know that integrating a third-party API is not a two-day task when that API has undocumented rate limits and inconsistent error responses. An architect who stopped coding three years ago will quote the idealized version of the effort, and the team will absorb the delta as crunch.
Code Review Becomes Performative
A leader who does not write code can still read code. But their reviews tend to drift toward style preferences and surface-level observations rather than catching the structural issues that matter — the race condition in the queue consumer, the missing index that will cause a full table scan at scale, the security control that was skipped because the deadline was tight. Staying in the code is what keeps a reviewer's pattern recognition current.
Trust Erodes
Engineers know. They can tell within weeks whether the person directing their architecture has current technical depth or is operating on reputation. When a leader's credibility is built on what they built five years ago rather than what they can build today, the team's willingness to follow their direction quietly degrades. This is not about ego. It is about the fundamental trust required for a team to move fast on hard problems.
How to Evaluate a Hands-On Technical Consultant or Architect
Whether you are hiring a full-time software architect, evaluating a technical consultant, or assessing a fractional engineering leader, here are the questions that separate a grounded builder from someone who has drifted into pure management.
Ask About Recent Production Work
Not projects they oversaw. Not teams they managed. Ask what they personally shipped in the last six months. What code did they write? What infrastructure did they configure? What broke in production and how did they diagnose it?
A hands-on architect will answer with specific, technical detail. They will name the service, describe the failure mode, walk through their debugging process. A manager who stopped coding will redirect to team accomplishments. Both are valid roles. But they are different roles, and you need to know which one you are getting.
Look for Breadth Across the Stack
The most effective player-coach engineering leaders are not specialists who happen to attend standups. They have depth in their primary domain — whether that is backend services, infrastructure, data engineering, or security — but they can also work across boundaries. They understand how the API layer connects to the deployment pipeline, how the data model affects the frontend, how the security controls interact with the CI/CD workflow.
This breadth is what makes architectural judgment reliable. A narrow specialist can design one layer well. A grounded, full-stack architect can design systems that work as one integrated organism rather than a collection of disconnected parts.
Test Their Comfort with Ambiguity
Architects who still build are comfortable saying, "I do not know yet — let me prototype it." Architects who stopped coding tend to reach for patterns they already know, because they do not have the muscle memory to quickly validate a new approach. The willingness to build a proof of concept before committing the team to a direction is one of the clearest signals of hands-on technical leadership.
Check How They Handle Incidents
Production incidents reveal whether a leader is still technically grounded. Ask about a recent incident they personally triaged. Did they jump into logs and traces, or did they delegate and wait for a summary? Did they identify the root cause themselves, or did they facilitate a meeting where someone else did?
There is nothing wrong with delegation in a large organization. But if you are hiring an architect for a team under 20, or engaging a technical consultant to design foundational systems, you need someone who can own triage and remediation directly — not someone who needs an engineer to translate the problem for them.
The Discovery Work That Makes Architecture Stick
Hands-on technical judgment matters most at the beginning of an engagement, before a single line of code is written. This is the soil work — the discovery and architecture phase where the most consequential decisions get made.
When an architect who still builds sits down to map your current stack, they see things a pure manager cannot. They notice the drift between your Terraform state and your actual infrastructure. They spot the manual deployment step that everyone has worked around but no one has automated. They identify the integration that is held together with a cron job and a prayer.
These are not theoretical observations. They are the product of current, hands-on experience with the tools, platforms, and failure modes that define real systems.
At FigTree Development, every engagement starts with this kind of grounded discovery. We map goals, current architecture, and the competitive environment before recommending a build. The point is not to produce a document that looks impressive. It is to design a foundation — scalable from day one — that the team can actually implement and maintain.
What You Are Really Hiring
When you hire a software architect or engage a technical consultant, you are not hiring a title. You are hiring judgment. And judgment in software architecture is perishable. It decays the moment someone stops doing the work that produced it.
The best technical leaders treat hands-on work not as a phase they have graduated from, but as a discipline they maintain. They lead teams and write code. They design systems and deploy them. They set direction and stay close enough to the implementation to course-correct when reality diverges from the plan.
This is not about working more hours. It is about allocating leadership time toward the work that keeps architectural decisions rooted in what is actually true about the system today.
Start with a Conversation, Not a Pitch
If you are evaluating technical leadership for your team — whether that means hiring a hands-on architect, engaging a fractional engineering leader, or figuring out whether your current architecture needs foundational work before you scale — we would be glad to think through it with you.
At FigTree Development, our approach starts with listening and mapping before building. No assumptions, no boilerplate recommendations. Just a grounded conversation about where your systems are, where they need to go, and what it will actually take to get there.
Book a free 20-minute discovery call and let us dig into what you are working with. The best architecture starts with honest assessment — and that starts with a conversation.