The Fallacy of "Keeping Your Hands Dirty"
Why your hands-on coding days are now mostly for show
You know that line. “I need to keep my hands dirty.”
If you have ever said it, congrats. You have recited one of engineering leadership’s favourite comfort blankets.
Not because learning is bad. Not because writing code is beneath you. But because most of the time, that sentence is a cover story. It translates a much uglier thought into something that sounds noble.
The ugly thought is this: If I am not shipping code, am I still useful?
Meanwhile, your calendar is a flaming trash pile of planning, performance conversations, production incidents, hiring loops, and “quick syncs” that are neither quick nor a sync. You are not a senior developer with some meetings. You are a manager. Or a staff-plus leader. Which means your “hands dirty” time is often a costume change.
So let’s call it what it is. Here is the real fallacy, why it happens, how it messes with your team, and what to do instead if you actually care about technical excellence.
What people mean when they say “keep your hands dirty”
In theory, it means staying close to the codebase so decisions are informed, keeping skills current so you can mentor effectively, spotting technical risk earlier, and building credibility with the team.
Sure. Those are reasonable goals.
In practice, it means you do not trust the team yet, you are scared you will become irrelevant, you miss the dopamine of closing tickets, or you have not fully accepted what the job is now and coding is familiar.
The phrase is not the problem. The mismatch between the goal and the behaviour is.
The uncomfortable truth: your job changed, and your brain hates it
When you move from individual contributor to leader, your outputs change.
Your output used to be obvious. You shipped code, you fixed bugs, you delivered features.
Now your output is indirect. You build a team that ships. You keep a system healthy. You create a pipeline that produces capable people. You make decisions that age well.
That is harder to measure. It is slower. It is also less emotionally satisfying, because you cannot point to a pull request and say, “I did that.”
So your brain tries to drag you back to the measurable work.
This is why the “hands dirty” leader ends up doing the leadership equivalent of wearing a hard hat to look busy.
How “hands-on” leadership turns into performative coding
Here is the specific failure mode.
You block two hours, open the IDE, and try to pick up a ticket.
But you are out of context. You are missing the last three design discussions. You have not read the decision record. You do not know why that hack exists. You do not know which customer is screaming.
So you grab a “safe” task nobody cares about, or you pick a high impact task and thrash, or you rewrite something to match your taste and then vanish back into meetings.
And because you are a leader, nobody can tell you “please stop” without social risk.
If you are lucky, you waste time.
If you are unlucky, you ship something half-baked, break a workflow, and your team spends the next week cleaning up after you while politely calling it “alignment.”
The hidden costs your team pays
First, it makes code review weird. Even if you are trying to be chill, your comments land like executive orders. People optimize for “what will make this person happy” rather than “what is best for the system,” and psychological safety quietly dies in the one place you actually need it.
Second, you steal the work without meaning to. If you take the interesting problems, you take away growth. If you take the boring problems, you become a bottleneck for boring problems. Either way, someone loses.
Third, you teach the team that leadership is not real work. If you treat management as something you do between commits, the team learns that planning is optional, mentorship is optional, writing is optional, and clarifying priorities is optional. Everyone is “hands dirty,” and nobody is steering.
And finally, you trade leverage for activity. Leaders get paid for leverage. A decent coding day might produce one improvement. A decent leadership day might unblock three people, prevent a month of churn, or set a direction that reduces future complexity. If you spend your rare deep work time on coding, you are choosing lower leverage because it feels productive.
Yes, staying technical can be fine
Before anyone gets cute in the comments, yes, staying technical can be useful.
It makes sense when you are in a small team where the role genuinely includes technical leadership, when you are in a temporary crisis and need extra hands, when you are learning a domain so you can make better decisions, or when you are doing targeted work that improves team velocity without stealing ownership.
The difference is intent and design.
If you are coding, it should be planned, transparent, low drama, and tied to team outcomes.
Not just “I felt weird today so I opened the IDE.”
What to do instead (without becoming a part-time IC)
You do not need to be the person pushing commits to stay technical.
You need context, signal, pattern recognition, and enough skill to ask good questions. That comes from proximity, not ownership.
So do the unsexy stuff.
Show up to the conversations that actually matter. Be in design reviews for major changes. Pay attention in incident retrospectives. Stay in architecture discussions that affect multiple teams. Then do two things: ask clarifying questions, and help the group make a decision and write it down.
Read code like a grown-up. Read a few pull requests per week, but keep your focus on system-level patterns rather than line-level nitpicks. Ask whether the change reduces future pain. When you comment, aim for questions, trade-offs, and risk awareness. Do not turn reviews into a personal style guide.
Get a weekly technical pulse. Spend an hour reading the changelog, incident summaries, and major PRs. Spend another hour talking to an engineer about what feels hard right now. The goal is to detect drift, not to catch people doing things “wrong.”
If you absolutely need to scratch the coding itch, pick small, high-leverage contributions that improve the system without stealing the spotlight.
Good options tend to be:
Logging and observability, and pipeline improvements
Fixing a painful developer experience issue
Writing a migration helper
Write more than you code
If you lead engineers, writing is a force multiplier.
Write decision records. Write one-page strategies. Write post-incident learnings. Write clear expectations for roles.
This is not “documentation.” This is how you scale your judgement.
Teach, do not rescue
The most technical thing you can do is build technical judgement in others.
Instead of jumping into the codebase to fix something, pair on the problem definition. Review the proposed approach. Ask what could go wrong. Help design an experiment.
Then let the engineer do the work.
You keep context. They keep ownership.
If you insist on coding, set rules that protect the team
If you want to code, fine. Just stop doing it in a way that makes everyone miserable.
Code on a predictable cadence. Pick tasks that are clearly scoped and not on the critical path. Avoid taking the “interesting” feature work. Have another engineer act as the reviewer who can say no. Announce when you are going to be in the codebase and why.
This turns “hands dirty” from a theory into a practice.
The credibility myth: you do not need to prove yourself every week
A lot of leaders believe that if they are not visibly technical, the team will not respect them.
Here is the twist: respect is not earned by the occasional heroic commit.
It is earned by setting clear priorities, protecting focus time, hiring well, handling performance issues without drama, making decisions and owning them, and being honest about trade-offs.
If your team only trusts you when you are coding, the problem is not your GitHub activity.
The problem is leadership.
A simple replacement for “keep your hands dirty”
Try this instead:
“I stay close enough to the work to make good decisions, and I stay out of the way enough for the team to own it.”
That is the whole job.
Conclusion
The fallacy of “keeping your hands dirty” is not that coding is bad.
It is that leaders use coding as a comfort blanket, then wonder why the team feels unmanaged.
Stay close. Stay curious. Stay useful.
Then let your developers do the developing.