Why Technical Leaders Must Code: The Case for Hands-On Leadership

I used to think that once you became a leader, coding was someone else's job. That leadership meant sitting in meetings, talking strategy, managing people, and making architectural decisions from 30,000 feet.

I was wrong.

The best technical leaders I know — the ones who build teams that ship impossible things — are all hands-on. They don't just review code, they write it. They don't just discuss architecture, they prototype it. They don't just delegate debugging, they dive in when it matters.

Here's why I believe technical leadership requires staying in the code.

1. Credibility Is Earned, Not Inherited

The first time I told a senior engineer their time estimate was wrong, they pushed back hard. "How would you know? You haven't written code in months."

They were right to challenge me. I had been too focused on management theater — endless meetings, PowerPoints, roadmap planning — and I'd lost touch with what it actually took to build the systems we were discussing.

That moment changed how I thought about leadership. If I couldn't defend my technical decisions with more than authority, I wasn't leading — I was just managing from a distance.

Engineering Teams Follow Leaders Who Can

Technical credibility isn't about your title or your years of experience. It's demonstrated in real-time through your ability to:

• Debug the unfixable - When production is down at 2 AM and everyone's stuck, can you help find the root cause?
• Reason about systems - When discussing architecture tradeoffs, do you understand the implications at the implementation level?
• Design elegant solutions - When complexity is spiraling, can you see the simple path through?
• Simplify the complex - Can you take a hairy technical problem and break it down into digestible pieces?
• Spot bullshit - When someone says "that's impossible" or "that'll take 6 months" can you tell if they're right?
• Solve what they can't - When your team hits a wall, can you be the person who figures it out?

When you're trying to mentor a team member who reports to you, why would they listen? How do they know that following your advice will lead to good things in their career?

They have to see something credible in you.

When you tell them their estimation is wrong, you have to back it up — not with authority, but with technical reasoning they can verify. When you suggest a different approach, they need to trust that you've thought through the implications because you've built similar systems before.

In order for any of that to work, you have to prove to the team you know your stuff.

The Leadership Multiplier Effect

Leaders Who Don't Code	Leaders Who Code
One layer removed from respect	Direct credibility through action
Can coordinate and inspire	Can elevate and teach
Team respects the position	Team learns from the work
Authority-based decisions	Engineering-based decisions
Distance from the work	Close to the reality

A leader who still codes becomes a multiplier. When you can jump in and pair program on a gnarly bug, when you can prototype a solution to prove it's feasible, when you can review a pull request and suggest a better solution — you're not just managing the team, you're elevating them.

Your team doesn't just respect your decisions, they learn from your code. They see how you think, how you structure problems, how you make tradeoffs. That's how you build engineers who think like architects.

2. You Can't Set Engineering Standards From the Outside

Early in my career at SportsBookReview, I inherited a codebase that was... rough. Fifteen years of technical debt, multiple architectural paradigms fighting each other, abstractions on top of abstractions that obscured what the code actually did.

I could have mandated "clean code" from above. I could have written standards documents and hired code quality consultants. But how could I define what "clean" meant if I wasn't writing code myself?

Technical Taste Only Stays Sharp Through Use

If you don't write code, you can't:

• Define what "clean" means - Is it about function length? Abstraction levels? Naming conventions? You can't articulate this without feeling the pain of messy code.
• Spot sloppy patterns - When you review a design, can you see the shortcuts that will cause problems six months from now?
• Judge architectural debt - How do you decide when to refactor versus when to ship? That requires understanding the lived experience of working in that codebase.
• Assess the seniority of candidates - In interviews, can you tell the difference between someone who's memorized patterns and someone who deeply understands tradeoffs?

You shape engineering culture with your technical taste. And technical taste only stays sharp if you keep using it.

The Ruby on Rails Lesson

When I rebuilt the Odds Importer at SportsBookReview, I made a controversial decision — I rewrote the entire system in Ruby on Rails when the rest of the company was deeply invested in C# and .NET.

The team pushed back hard. "Ruby doesn't scale." "Rails is too magical." "You're going to create a technology island."

But here's the thing — I wasn't making that decision from a conference room. I had prototyped the solution. I had built a working proof-of-concept that showed we could process millions of updates per day with a fraction of the complexity of the C# version.

When they challenged me, I didn't have to defend with theory. I showed them working code that handled their worst-case scenarios. I walked them through the architecture and explained every tradeoff. I demonstrated that I understood their concerns because I had coded through them.

They still disagreed with the decision, but they respected it because it was grounded in engineering reality, not management fantasy.

3. Coding Is How I Think

I don't think in slides or narratives or frameworks. I think in systems. And for me, that means expressing ideas through code, running experiments, building pipelines, sketching architectures.

When someone describes a problem, my brain immediately starts modeling it — what are the entities, what are the relationships, where are the bottlenecks, what are the failure modes? The fastest way for me to validate those mental models is to write code.

Coding Isn't "Doing IC Work" — It's My Native Language

Some leaders think touching code means they're "doing IC work" or "not trusting their team." That's a fundamental misunderstanding of what hands-on leadership looks like.

When I write code as a leader, I'm not taking work from my team. I'm:

• Exploring ideas - Building a proof-of-concept to see if an approach is viable before committing the team
• Unblocking problems - Diving into a hairy integration issue that's been blocking progress for days
• Setting examples - Showing what good looks like through pull requests that demonstrate patterns I want the team to adopt
• Reasoning through complexity - Writing out the system design in code to expose edge cases that weren't obvious in diagrams
• Prototyping architecture - Building the scaffolding for a new service so the team has a clear starting point

This isn't about not trusting them to do the work. It's about staying close enough to the problem space that I can make informed decisions and provide meaningful guidance.

The OddsTrader Chatbot Architecture Decision

When we were building the AI-powered sports betting assistant for OddsTrader, I had to make a critical architectural decision: how do we handle conversational context without rewriting every query from scratch?

The "obvious" approach was to treat each question independently — take the user's question, extract entities, fetch data, generate a response. Simple, stateless, predictable.

But here's the problem: real conversations don't work like that.

A user asks: "What are the current point spreads for tonight's Lakers vs Warriors game?"

Then they follow up with: "How has he performed against them this season?"

Who is "he"? Which teams are "them"? A stateless system has no idea.

The team wanted to solve this by forcing users to ask complete questions every time. "Just tell them they need to specify the player and teams again." That might work technically, but it creates a terrible user experience.

I couldn't make that architectural decision sitting in a conference room. I had to prototype both approaches.

I built a simple version of the stateless system first — clean, easy to reason about, but conversationally broken. Then I prototyped a context-aware system that maintained conversation history and resolved ambiguous references using the previous turns.

The context-aware approach added complexity: we needed conversation memory, entity resolution logic, and context window management. But when I tested both versions with actual betting questions, the difference was obvious. The stateless version felt like talking to a database. The context-aware version felt like talking to someone who understood sports.

If I hadn't coded both approaches myself, I would have gone with the "safer" stateless design and shipped a chatbot that technically worked but felt broken in real conversations. Instead, we built a system that could handle natural follow-up questions and maintained context across an entire betting session.

That architectural decision — born from hands-on prototyping, not theoretical discussion — became the foundation for how thousands of users interact with our AI assistant every day.

4. You Become the Person Who Fixes the Impossible

My career was built on being the person who fixes the unsolvable. The person who never says "it's not possible." The guy who can get something done now instead of in three months.

That reputation only exists because I stayed in the code.

When You Ask Devs to Do the Impossible

Here's what happens when you're hands-on:

When you ask developers to do something they think is impossible, they'll continue to think it's impossible — until you prove them wrong.

When you need devs to stay an extra hour to fix a broken system affecting production, and you can help them fix it faster — they see you're in the trenches with them.

When you're there solving problems alongside the team, they start believing everything is possible too.

The SportsBookReview Production Incident

One Friday night, our odds ingestion system started failing. Odds from bookmakers were coming in, but they weren't updating properly in the database. Production traffic was fine, but our competitive advantage — real-time odds updates — was broken.

The on-call engineer investigated for an hour, couldn't find the issue, and escalated. The senior engineers on Slack were throwing out theories but nobody could reproduce it. The conversation was turning toward "we'll investigate Monday" because it wasn't a complete outage.

I jumped in. Reviewed production logs, set up a local environment with a sample of the problem data, and started debugging. Within 30 minutes I found the issue — a race condition in how we were handling concurrent odds updates for the same event. The bug only manifested under specific timing conditions that were rare in development but common in production with the volume we were processing.

I wrote the fix, tested it locally, pushed to staging, confirmed it resolved the issue, and deployed to production. Total time from "I'll look into it" to "it's fixed": 90 minutes.

The team watched this happen in real-time in Slack. They saw me debug, reason through the problem, identify the root cause, and ship a fix — all while they were still trying to reproduce the issue.

That's how you build a team that believes in solving problems fast.

Not because I'm smarter than them (I'm not), but because I was willing to get hands-on when it mattered. After that night, when I told the team "this is urgent, we need to fix it now," nobody questioned whether it was actually possible.

Teaching Through Doing

The other side of this is mentorship. You can't teach someone to be a great engineer by delegating their work and reviewing it later. You teach them by pairing on hard problems, showing them how you think, and letting them see the messy reality of problem-solving.

Some of my best mentorship moments happened when junior engineers watched me struggle with a problem for an hour, try three different approaches that didn't work, and then finally figure it out. They learned:

• Debugging is about systematic elimination - You don't need to know the answer immediately, you need a process for finding it
• Most problems have simple solutions - When you strip away complexity, most bugs are simple logic errors or incorrect assumptions
• Speed comes from pattern recognition - After you've fixed 100 production incidents, the 101st one feels familiar
• Being stuck is normal - Even experienced engineers hit walls; the difference is they don't panic

You can't teach those lessons from a conference room.

What Hands-On Leadership Actually Looks Like

Let me be clear: staying hands-on doesn't mean you're writing 8 hours of code every day. It means you're close enough to the codebase that you can:

• Review a critical pull request and suggest a better abstraction
• Prototype a solution to prove something is feasible
• Dive in and debug when the team hits a blocker
• Write the scaffolding for a new service so the team has a clear starting point
• Pair program with a junior engineer to show them how to think through a complex problem

It means your technical skills stay sharp enough that when you make architectural decisions, they're grounded in engineering reality, not management fantasy.

The Pushback: "Leaders Should Delegate"

Every time I advocate for hands-on technical leadership, someone inevitably says: "If you're writing code, you're not doing your job as a leader. You should be delegating."

Here's the thing they miss: hands-on leadership and effective delegation aren't opposites.

I delegate all the time. I delegate entire features, services, and architectural decisions. But I can only delegate effectively because I understand the work deeply enough to:

• Know what's reasonable to expect
• Identify when someone is stuck versus when they're learning
• Provide specific guidance when they hit a wall
• Review their work with technical depth

Delegation without technical context is just abdication. You're not empowering your team, you're just hoping they figure it out.

The leaders who say "I don't code anymore, I delegate" often fall into a trap: they can't tell the difference between someone doing great work and someone producing plausible-sounding bullshit. They can't assess whether a project is on track or quietly spiraling. They can't identify when a three-month estimate should actually be three days.

The Path Forward: Finding Your Hands-On Balance

If you're a technical leader who's drifted away from the code, here's how to get back:

1. Block Time for Technical Work

I keep Friday afternoons for "focus time" — no meetings, no interruptions, just me and code. Sometimes I'm building prototypes, sometimes I'm reviewing architecture, sometimes I'm pair programming with a team member.

2. Own Something Small but Critical

Pick one system that you own end-to-end. For me, it's the AI content generation pipeline at Advision. It's quick to iterate on, sits at the intersection of multiple teams (SEO, content, development, AI, executive), and my work has massive productivity impacts across the organization.

When I can prototype a new feature in the pipeline in a few hours and show the content team how it saves them days of work, that's hands-on leadership. When the SEO team needs a new data integration and I can build it that afternoon instead of putting it on the backlog for next quarter, that's staying connected to the work.

The key is choosing something where your technical involvement multiplies others' effectiveness. You're not doing their work — you're removing the bottlenecks that slow them down.

3. Be the Prototype Person

When the team is discussing whether something is feasible, offer to build a proof-of-concept. This keeps you close to the technical reality while demonstrating leadership through action.

4. Dive In When It Matters

Don't touch every bug or feature, but when there's a critical incident or an "impossible" problem, be willing to roll up your sleeves and help solve it.

5. Teach Through Code Reviews

Treat pull requests as mentorship opportunities. Don't just approve or reject — explain your thinking, suggest alternatives, and help engineers see the patterns you see.

Conclusion: Leadership Is Technical Judgment

At the end of the day, technical leadership is about judgment — knowing which architectural decisions will scale, which technical debt to pay down, which optimizations matter, and which problems are actually solvable.

That judgment doesn't come from meetings or strategy documents. It comes from staying close enough to the code that you can feel the difference between a system that's well-designed and one that's held together with duct tape.

Your team needs you to be technically credible, not technically absent.

They need a leader who can jump in and help when it matters.

They need someone who understands their challenges because you're living them too.

That's what hands-on technical leadership looks like.

And it's why the best technical leaders never really stop coding.