Writing
Why I Still Write Code After More Than 20 Years in Software Engineering
After CTO and VP roles, I still build software. Here is where the hours went when I moved into leadership, what staying technical buys a leader, and the line I try never to cross.
By Ka Lun Chan · Still Building After 20 Years · Leadership / Learning / Founder story
I started by doing almost everything
This is the second story in Still Building After 20 Years. The first was about the infrastructure path. This one is about a question I get from recruiters, engineers and occasionally my own family: after CTO and VP roles, why am I still writing code?
The honest answer starts with how I learned the job. My early career was network engineering and Linux administration. Then I co-founded a company, and for a long time I was most of its engineering department. In a given week I racked servers, configured routers, administered Linux, wrote the backend, built the front end, kept the billing system honest, wrote C++ for the Nokia app, carried the pager and made product calls with customers on the phone. I have told that story in being every department at once.
What that period gave me was a sense of the whole system, physically. I know what a slow query feels like from the database side, the application side and the customer side, because at one point all three were me. That turned out to be the most useful thing I ever learned for leading engineers, and I did not know it at the time.
Leadership changes where the hours go
As the company grew, my hours moved. Hiring and mentoring. Architecture decisions, written down so they outlived the meeting. Planning, and saying no to good ideas so the team could finish the important ones. Delivery, which mostly means noticing early that something is slipping. Talking to the board and to customers. Operational responsibility for a platform people depended on. Business decisions where the technically correct answer was the wrong one. Later, as a VP of Operations and as CTO of a media publisher, the share of my week spent in an editor shrank further.
That is correct. A leader who is still the best individual contributor on the team and spends the week proving it is a very expensive engineer and an absent manager. The work that only the leader can do, setting direction, growing people and connecting engineering to the business, does not get done by anyone else.
So when I say I still write code, I do not mean I write it instead of leading. I mean I never stopped building things, and I made sure the building happened somewhere it did not sit in my team’s way.
What I still build
Most of what I build now is my own. FedPath helps small businesses find and evaluate federal contracts. Useful Little Tools is a set of free calculators that doubles as my playground for new techniques. I rebuilt the Berkeley Omnium site for the race weekend I help organize. This site is mine too, and I am in the middle of building a job-search agent on Hermes that I am writing up as I go. Yippify is the consulting work, where I am hands-on wherever it takes risk out of the build and stay out of the way where the client’s engineers own it.
Building my own things is the cleanest arrangement I have found. Nobody waits on my pull request. If I get it wrong, the only person inconvenienced is me. And I get to learn a new framework or a new way of deploying on something real, which is how I learn anything.
What staying technical buys a leader
It makes me a better judge of estimates. When an engineer says a change will take three weeks, I can usually see where the hidden work is: the migration, the edge case in the old data, the test that has to be rewritten. That lets me ask a useful question instead of a skeptical one.
It makes technical debt concrete. Debt is a financing decision, and I am a better lender when I have felt the interest myself, in my own codebases, at eleven at night.
It keeps architecture tradeoffs honest. I have written about what every extra service costs, and I believe it more because I have to run the services I build.
It keeps me humble about debugging. Every time I lose an evening to a problem that turns out to be one character in a config file, I remember what my engineers deal with, and I stop asking why something is taking so long.
It keeps developer productivity real. When I set up a pipeline for my own project and the build takes nine minutes, I understand in my body why a team’s velocity is limited by its slowest feedback loop. And it keeps me close to infrastructure costs and security, because on my own projects the bill and the breach would both be mine.
What it must not turn into
There is a failure mode for technical leaders, and I have seen it from both sides. The leader who reviews every line, overrides the team’s design because they would have done it differently, and becomes the single point of failure for every decision. The team learns to wait for approval instead of thinking. Velocity drops, the best engineers leave, and the leader concludes the team needs more supervision.
| What it lets me do | What it must not become |
|---|---|
| Read the code well enough to ask the right question in a design review | Review every pull request before it can merge |
| Estimate with the team, knowing where the hidden work usually is | Overrule the team’s estimate because I could do it faster |
| Prototype the riskiest part to learn whether it is possible | Keep the prototype and make the team maintain it |
| Debug alongside someone when they are stuck | Take the keyboard and fix it myself |
| Know what the infrastructure costs and why | Make every architecture decision personally |
The point of staying technical is to understand the work well enough to support it, not to do it for people. Good leaders build an environment where engineers make decisions without them, and step in only where the decision is theirs to make. I think of it the way I think about mentoring: if the team cannot run without me, I have built a dependency, not a team.
AI made building fun in a new way
The last few years changed how I build, and I have enjoyed it more than I expected. Claude Code and OpenAI’s Codex sit in my terminal, and I describe what I want, read what they propose, and decide. The typing got cheaper. The judgment did not, and that suits a leader with limited hours very well, because judgment is the part I have the most of.
It also brought back an old feeling. Working at a prompt, typing instructions and watching text come back, is how I started on DOS and on router consoles, which I wrote about in talking to AI in a terminal. The difference is that now I speak my own language and the assistant speaks the machine’s.
The next story in the series is about the part that is not fun: what it takes to make an AI agent reliable once nobody is watching it.
Short answers
Should engineering leaders still write code?
Not as their main job, and not where the team has to wait on them. Writing code on side projects or prototypes keeps a leader close enough to judge estimates, technical debt, architecture tradeoffs, debugging and infrastructure cost, while the team owns the production codebase.
How do technical leaders avoid becoming a bottleneck?
By using their technical depth to ask better questions rather than to make every decision: no mandatory review of every pull request, no overriding estimates, no taking the keyboard. If the team cannot run without the leader, the leader has built a dependency rather than a team.
Not to prove anything. Because I like building.
I do not write code to prove I am still an engineer. I write it because I enjoy building things, learning new tools and understanding the problems my teams solve.
Stay close enough to the work to support it. Stay far enough from it that the team never has to wait for you.
That balance is most of what I believe about technical leadership.