Essay
Technical depth still matters for engineering managers. The goal is leverage — better platforms, better engineers, and better judgment — not remaining the person who ships the hardest work.
People still ask whether an engineering manager should code.
I understand the question. I also think it is the wrong one.
I stay close to architecture and code. That is true. It is also no longer the most useful way to describe the job. The useful question is whether the organization gets more capable because of how you spend that closeness — or whether it still needs you in the loop for every hard decision.
I lead Integrations and Platform at SpotDraft. The work spans platform architecture, developer experience, reliability, AI-assisted development, and people growth. I can still sit in a design review and argue about contracts, retries, and object mappings. I should not be the person those reviews cannot proceed without.
Some managers code because they do not trust the team. Some code because they cannot let go of being the strongest individual contributor in the room. Some code until they become a hidden bottleneck: every important pull request waits, every architecture decision routes through one person, every incident needs the same voice.
That is not technical leadership. That is a dependency with a title.
When I stay close to a system, I am trying to keep my judgment honest. Distance is expensive. You start learning about engineering only through summaries. Architecture looks cleaner than it is. Delivery problems get misread as people problems. Developer-experience pain becomes a slide instead of a concrete tax that engineers pay every week.
Staying close helps me see:
The point is not to prove I can still implement the hardest problem myself. The point is to turn that context into better architecture, better engineers, and systems that keep working when I am not in the room.
Salesforce reverse sync could have been a customer-specific job: map these objects, ship the fastest Salesforce version, move on.
That would have been a reasonable IC move under deadline pressure. It would have been a poor platform move.
We treated it as a reusable automation model — triggers, conditions, object mappings — rather than a one-off CRM chore. That decision only holds if you are close enough to the system to feel the difference between “this customer ships” and “the next five customers inherit a primitive.”
I still wanted to understand the edges: what should be generic, what should stay product-specific, what would become unmaintainable if we hardcoded Salesforce into the middle of the design. Then the work needed owners who were not me.
If I had kept the implementation because I enjoyed the problem, the organization would have gained a manager who can still code and lost a reusable surface.
Legal Intake started as a hackathon idea in 2024 and became a shipped product. The technical work mattered. The larger lesson for me was that execution itself can be engineered.
I introduced spec-first planning, phased milestones, explicit ownership, visible risk tracking, and reusable planning templates. That is not “still coding.” That is building a delivery system so a product can move without depending on one person’s memory of what is blocked.
If your only proof of technical depth is that you wrote the feature, you will eventually run out of hours. If your proof is that the team can run a planning and review system without you holding every thread, you have created leverage.
AI is changing the engineering loop: requirements, specifications, implementation, tests, pull-request review, documentation, project workflows, even parts of engineering management.
I am helping lead how that loop evolves at SpotDraft. The interesting problem is not whether engineers use coding agents. It is whether the organization gets a repeatable system — adoption, evaluation, workflow design — or a pile of individual tools.
Leaders who cannot operate as engineers will struggle to design that system. You cannot evaluate agent infrastructure or Model Context Protocol abstractions from a dashboard of “AI usage.” You have to understand where a tool is the right interface, where a deterministic workflow is better, and what an evaluation gate should look like.
That is why I stay close. It is not nostalgia for writing production code. It is because AI pulls leaders back into the engineering loop, and the job is to design the loop rather than become the permanent reviewer inside it.
I try to move engineers through a progression: task ownership, then project ownership, then technical judgment, then organizational ownership. That only works if I give people a larger decision space instead of a harder ticket with the same decision-maker behind it.
Three engineers I worked with progressed from SDE1 to SDE2. The useful part of that story is not a promotion count. It is the mechanism: explicit growth paths, stretch ownership, continuous feedback, and evidence against next-level expectations.
If I stay in the code as the person who still makes the architecture call, those engineers do not get a decision space. They get a manager who is technically impressive and a team that cannot operate without that manager.
I would rather spend review time on contracts, risks, and high-context decisions, and let peer and technical-lead review carry more of the implementation quality. That is still technical work. It is technical work aimed at multiplying judgment rather than concentrating it.
When I am tempted to jump into implementation, I ask a few questions:
Sometimes the honest answer is that I should write the spike, because the architecture is still unclear and a document will lie. Sometimes the honest answer is that I should sit in the review, not the diff.
The bar is not “does the manager still code?”
The bar is whether technical depth is converting into platforms, engineers, and operating systems that scale — or whether it is still sitting in one person’s hands.
Krishna Dey