Something happened recently in a team meeting. A junior developer was reporting on a performance issue they'd been wrestling with for days, and as I listened, I could see the solution. My hands were itching. 'If I just spent an hour on this, I could fix it...' But then, just as I was reaching for my mouse, I noticed the team member's expression. I saw that look—half expectation, half anxiety—and felt something strange.
'Am I doing the right thing as a leader right now?'
The reason I'm writing about this is that I wanted to organize the trial and error I've experienced while leading development teams for about 6 years. I started as a practitioner and somehow ended up in a position leading a team, but honestly, few people have clear answers for this role. I'm the same.
The Hardest Thing Is 'Letting Go'
The first challenge that people who became leaders by being recognized for their hands-on work commonly face is letting go of the 'desire to do it yourself.' It's obvious, but not obvious at all.
I once had this conversation with a fellow leader:
Colleague: "These days, delegating to team members is so frustrating. I could do it in 2 hours, but explaining and reviewing takes a whole day."
Me: "So did you do it yourself?"
Colleague: "No... I held back. But it was really hard."
This conversation fascinated me. We were trained as developers to pursue efficiency, but the moment we become leaders, we're placed in a paradoxical situation where we have to make 'choices that seem inefficient.' But looking back, this is precisely the most important role of a leader.
In my experience, it takes exactly 3 months. If you resist the urge to solve things yourself and start giving team members opportunities, after 3 months, that team member can do it on their own. After 6 months, they sometimes come back with better solutions than I would have found. Watching that process—that's the essence of management.
The Leader Who Asks Questions
There's another common mistake hands-on leaders make: only trying to give answers.
For example, when a team member came with a technical concern, I used to respond like this:
Team member: "How should I implement this part?"
Old me: "Oh, just do it this way. Use method A and library B, and it'll solve cleanly."
Now I ask:
Current me: "What approaches have you considered so far? What do you think are the pros and cons of each?"
This small difference creates enormous results. The former stops the team member's thinking, while the latter helps them find the answer themselves. Of course, it takes more time. But answers found that way last much longer than answers I give.
How do you respond to your team members' questions?
The Balance Between Distance and Trust
The most disconcerting thing when my position changed from practitioner to leader was the 'distance' with team members.
A colleague I used to code with on the same team one day became my team member. At first, I thought I could just treat them like before, but once I was in the position of doing performance reviews and distributing work, a subtle line appeared. Too close and fairness is questioned; too far and communication breaks down.
I organized this problem like this: constantly reminding ourselves that 'our roles are different, but our goal is the same.'
During one-on-ones, I share this:
Me: "My role is to create an environment where you can grow well. Your role is to do your best in that environment. We're both looking in the same direction."
Small things like these naturally build trust with colleagues. What's important is showing through actions that I genuinely want my team members to grow.
How to Maintain Technical Skills
This is another topic many hands-on leaders worry about. Meetings, scheduling, cross-department communication... As management work increases, time to write code keeps decreasing.
Colleague: "These days I can't write a single line of code—just meetings all day. I'm worried I'll fall behind as a developer."
Me: "I was the same. But my thinking has changed a bit."
I now distinguish between 'writing code directly' and 'maintaining technical competence.' Even without writing code directly, you can maintain technical sense by thoroughly reviewing team members' code, participating in architecture decisions, and learning new technology trends.
Actually, things I couldn't see when I was only doing hands-on work started becoming visible. The overall system structure, the team's technical debt, long-term technology roadmaps... It's like I was only seeing trees and now I'm seeing the forest.
Responsibility for Results
As a practitioner, I only had to be responsible for my code, my work. As a leader, the entire team's performance rests on my shoulders.
The hardest moment when I first took over a team was when an incident occurred due to a team member's mistake. While reporting to executives, the thought 'This wouldn't have happened if I'd done it myself' crossed my mind. But I realized in that moment: this wasn't the team member's mistake—it was my responsibility for not creating proper review processes.
After that, I started viewing team failures as system problems.
- Team member made a mistake → Was the review process sufficient?
- Missed deadline → Was the original timeline realistic?
- Quality dropped → Did I properly establish quality standards and testing environments?
Thinking this way made constructive improvements much more possible.
In Closing
Management for hands-on leaders is ultimately the process of expanding 'what I can do' into 'what the team can do.' At first, it looks inefficient, frustrating, and sometimes anxiety-inducing. Moments constantly arise when it seems like I could do it faster and more perfectly myself.
But that patience accumulates, team members grow, and those grown team members come together to form a strong team. And in that moment, you see a team accomplishing things that could never have been achieved alone.
Try it just once. Instead of immediately giving answers to problems team members bring, respond with questions. Resist the urge to solve it yourself and give team members the opportunity. Those small changes will accumulate and help both you and your team grow.
I support and cheer for all your choices, attempts, successes, and failures. The journey as a hands-on leader will be tough at times, but few things are as rewarding as seeing the team you've grown together at the end.
Top comments (0)