Technical leaders should still write code.

Not because it looks good. Not because it makes for a nice founder story. Because architecture degrades when the person setting direction is no longer close enough to implementation to catch drift.

I learned that while managing a 25-person engineering team across three timezones.

I spent about 80% of my time in meetings and stopped participating inactive development almost entirely. At the time, that felt like the responsible leadership move. It was not.

When a technical leader stops coding completely, architecture turns into suggestion instead of direction. These days, you can use your time more effectively with AI as a scaffolding partner.

The bottom line

There is a version of leadership advice that says your job is to get out of the way and let the team implement.

But “getting out of the way” is also how you end up with a system that technically matches the ticket while violating the design constraints you thought were obvious.

If you are the person carrying system-wide context, you need a direct path into the codebase. Otherwise, you and your engineers are playing a game of telephone. Writing code in C# and proving it works is different than writing instructions in English and hoping someone else lands in the same place.

That path does not require you to be a full-time IC. But, it does require you to stay hands-on enough to prove patterns, lay foundations, and inspect the parts of the system where the shape matters.

How I learned

When I was heading up that 25-person team, I was leading architecture, stakeholder communication, and day-to-day management all at once.

The workload was high enough that I kept telling myself I would step back into the code once things settled down. They never did.

So, I kept giving architectural direction verbally, in Slack, or in tickets. I assumed that was enough because the team was senior enough to fill in the gaps.

That assumption cost me.

What broke

The first thing I lost was the ability to speak authoritatively about the real shape of the codebase.

I could still describe what I wanted. I could not guarantee that was what got built.

One case stuck with me because it was so avoidable.

I asked the team to build a simple audit trail for async events so we could trace what happened across the system. I expected an explicit event log with known payload contracts and a clean write path.

A few weeks later, I looked at the implementation and found a reflection-heavy C# mess doing runtime object introspection across multiple message types. Behavior was hidden behind generic helpers. Event records were inconsistent. Nobody trusted it.

We fought with that design for roughly a year before I finally tore it out and rewrote it by hand over a weekend.

That was not a team failure. That was a leadership failure.

I had pushed architecture through explanation instead of implementation. Then, I acted surprised when people interpreted the explanation differently than I would have built it myself.

When technical leaders should code

This does not mean you should grab random feature tickets to prove you still can.

Your coding time should happen when system shape is still fluid.

Foundations

Lay down the skeleton yourself when the architecture is still taking shape: service boundaries, deployment patterns, data flow, auth structure, analytics hooks, and the first pass at testing strategy.

Those are not just implementation details. They are decisions the rest of the team will build on top of for months.

Before AI existed, this meant diagrams, docs, and a lot of syntax grinding. Now leaders can use AI to research patterns, distill documentation, and scaffold the boring parts in minutes.

Architecture spikes

If the team is stuck on a risky question, build the proof of concept.

I usually start by using AI to see the common patterns. Then I interrogate the AI through its decision making, making it back itself up with real data before I move on to prototyping.

Then I write a short plan for the structure and data flow and hand that to an agent for the first pass. The agent gets me 90% of the way there. I execute the last tests by hand to make it’s up to my high standard.

A small harness in code is usually more valuable than another architecture meeting. It gives the team something concrete to react to, and it forces your ideas to survive contact with reality early.

Critical-path interfaces

When two major parts of the system need to fit together, that boundary is often worth touching directly.

On the audit trail rewrite, I defined the API shape, the base models, and cursor-based paging because I knew those logs could get huge. Then I added a thin adapter to a couple of POST routes and ran the whole thing through Swagger to make sure data went in and came back out cleanly.

I did not implement every endpoint or edge case. I just gave the team a working path that was close enough to build on.

That took me one long weekend at the time. With AI scaffolding the models, DTOs, and CRUD boilerplate, it would have taken hours instead of days.

What not to spend your time on

Routine features, bug fixes, instrumentation tweaks, and polish work are not usually the best use of a technical leader’s hands-on time.

Those matter. But they are not where your system-wide context has the highest value.

The point is not to out-code your team. The point is to reduce architectural ambiguity before it multiplies.

What I got wrong

I treated implementation as something I could fully delegate while still expecting the architecture to come out the way I pictured it.

That was wrong.

If you are the one setting direction, you need to touch the system enough to make key decisions concrete. Otherwise you are not really defining architecture. You are describing it and hoping the description survives translation.

That hope gets expensive fast.

When to do something different

If you are leading several large teams, your hands-on time may be narrower than mine was.

Fine. Narrow is not the same thing as nonexistent.

In a larger org, your direct contribution may look like architecture spikes, targeted reviews on risky changes, or building a reference implementation the team can copy. The principle stays the same: keep one foot in the real system.

What’s next

Architecture drift was the first cost of stepping away from code. The second was more personal: I started losing credibility with my own team.

That next post is about what happens when engineers stop seeing you in the work, and why technical authority gets weaker long before your title does.

If you want that when it goes live, sign up below for alerts.