Technical leadership is often described as a move away from the keyboard. In practice, the strongest engineering leaders I have seen keep enough proximity to how software is designed, built and maintained that their decisions remain grounded. That is what I mean by staying close to the craft.
What staying close to the craft means
Staying close to the craft is not about doing every pull request yourself. It is about retaining enough fluency in platforms, patterns and delivery constraints to ask useful questions, spot weak assumptions and recognise quality when you see it. In ecommerce and frontend work especially, architecture choices, performance trade-offs and operational realities change quickly. Leaders who lose touch with those realities start optimising for slides rather than systems.
It also means respecting the people who still do the detailed work. Credible technical leadership does not treat implementation as a lower tier of thinking. It treats craft as the place where strategy becomes real.
Why engineering leaders can become disconnected
Disconnection rarely arrives overnight. Calendar pressure fills the week with hiring conversations, stakeholder updates and planning cycles. Useful technical review gets squeezed into residual time. Over months, a leader can still sound fluent while losing the ability to validate detail.
Another cause is organisational distance. When reporting lines grow, feedback becomes filtered. Risks arrive late and already softened. Without deliberate habits that reconnect leaders to delivery, that filtering becomes normal.
There is also a cultural trap: treating “not coding” as a status signal. Some environments reward detachment as proof of seniority. That may produce polished process, but it weakens judgement when platforms, tooling and AI-assisted workflows are changing underneath the team.
Staying technical without becoming a delivery bottleneck
The opposite failure mode is equally real. Leaders who insist on owning every technical decision become a queue. Teams wait for approval. Context collapses into one person’s head. Delivery slows and ownership shrinks.
The balance is proximity without monopoly. Stay close enough to understand, challenge and support. Step back far enough for engineers to own outcomes. In practice that often looks like pairing on hard problems occasionally, reviewing architecture at the decision points that matter, and leaving routine implementation to the people closest to the work.
AI-assisted development makes this balance more important, not less. Tools can increase output volume quickly. Leadership still needs enough craft literacy to distinguish improved delivery from noisy activity.
Practical ways to maintain technical context
Maintain a short list of systems you personally understand well enough to discuss trade-offs without preparation theatre. Revisit them regularly. Read incident notes. Walk through critical customer journeys on the live site, not only in diagrams.
Protect time for technical conversations that are not status meetings. Architecture reviews, design critiques and post-incident learning only work when leaders are present as curious practitioners rather than distant sponsors.
Write and speak in concrete terms. Prefer “this checkout path depends on these services and fails in these ways” over abstract frameworks that could apply to any team. Concrete language is a useful self-test: if you cannot be specific, you may already be drifting.
Stay curious about the modern toolchain without pretending to master every new library. Enough understanding to evaluate risk, quality and operational cost is usually more valuable than shallow breadth.
What engineering teams need from credible technical leaders
Teams need clarity on priorities and constraints. They need someone who can translate business pressure into technical sequencing without pretending every request is equal. They also need psychological safety to raise uncertainty early.
Credibility comes from pattern recognition earned through craft, not from authority alone. When leaders can discuss why a platform decision matters, why a performance regression is expensive, or why a shortcut will return as operational load, teams listen differently.
They also need room to lead technically themselves. A leader who stays close to the craft should create more technical leadership in the organisation, not concentrate it.
Final thoughts
Staying close to the craft is a discipline, not a nostalgia for writing every line of code. It is how engineering leadership remains honest: informed enough to decide well, humble enough to keep learning, and practical enough to keep delivery connected to reality.
In ecommerce, frontend platforms and AI-enabled engineering, that discipline compounds. The work changes. The need for grounded judgement does not.
