Why Team Leaders Give Up
80% of the team leaders I talked to considered going back to developer roles at some point. Some actually did that.
In today’s article, I’m going to share how I keep my sanity and enjoy the role (spoiler - delegating important things). As usual, based on personal stories and mistakes :)
Why is it so hard?
The responsibility and scope of work are overwhelming. You need to:
Interview and hire
Train new employees
Perform code reviews
Deal with the day-to-day
Have 1:1s with your developers
Work with the PM on the roadmap
Create a long-term vision for the team
Handle alerts and production incidents
Write technical designs and lead new epics
And somehow still find time to write quality code!
The first few months are ALWAYS a complete mess. You are stressed out in the best-case scenario, or burned out in the worst.
This is what worked for me:
Delegating the work on these 2 things - dealing with the day-to-day and leading new projects.
Dealing with the day-to-day
What wasn’t working
Before being promoted, I was a senior developer on the team. I loved knowing everything that was going on, jumping on every Pagerduty alert or Sentry error.
This habit moved with me to my new role. In the first year, the support team talked only to me. I handled 50% of the production issues (the rest I passed to the team only after understanding the problem) and I still investigated all the alerts.
It made so much sense to me:
✅ I kept the team from being distracted
✅ Important things got done fast, as I saw the whole picture and could prioritize
✅ Nothing fell between the chairs, there was no confusion about who is responsible
But in reality…
⛔ I kept the team from valuable experiences (and knowledge)
⛔ There was a huge bottleneck. Me. The response rate was slow.
⛔ When I was away - everything fell between the chairs
“But how can you delegate the day-to-day?”.
Turns out you can.
What did I change
After a year, we implemented ‘The Team Rep’ (short of representative). It’s a concept I took from being a DevOps team lead, which at first I didn’t find relevant to a Fullstack team.
It works like this:
Every day, there is a team member who is the Rep*
The Rep is responsible for:
Monitoring all alert channels
Helping the support team in anything they need
Debugging new issues
The Rep is NOT responsible for fixing everything! If developers release a bug, they will be the ones fixing it (mostly). But the Rep will Coordinate it, and learn something new along the way.
* Tip - make sure it’s on the calendar. I created a recurring meeting, with guidelines. It’s very useful for the first couple of weeks.
I expected some resistance from the developers, but there was ZERO. Good developers enjoy knowing what’s going on, and having more responsibility. And in practice, it doesn’t take more than an hour each week (except in rare cases, with big production incidents).
Note: Don’t leave yourself out of the cycle. It’s important to share the load, and understand how the day of the rep looks like.
Benefits:
No single point of failure (passing the ‘bus factor’)
Increased ownership and debugging skills for the developers
A feeling of ‘we are in the same boat’. Much healthier in the long term.
Do you have any questions about the process? Ask in the comments, I’ll reply to each one.
Leading new projects
What wasn’t working
I had an assumption this was the MAIN thing I should do as a team leader:
Prepare a high-quality technical design.
Verify that the decisions the PM makes are sensible.
Break down the Epic into chunks, so it’ll be easier for your team to start working.
It took tons of time from me and isolated the developers from the rest of the organization. It took me 3 years of management (and 1 in the current role) to understand I can share that work.
What did I change
Each Epic/effort now has a team member assigned to it.
They are responsible for:
Meeting with the PM
Doing the technical design
Breaking it down into small tasks
Deciding on the work distribution among team members
At each step of the way - I’m involved. I share my thoughts and suggestions, without withholding anything on purpose. My involvement changes, based on the scope of work, and the experience of the developer. But they make the decisions.
Benefits:
Valuable experience for your developers - no matter the career path, the skills learned are super useful!
Increased quality of technical design(!) - As each developer leads only one project at a time, they can be 100% dedicated to the work, without skipping steps
More time for you to focus on other important areas
Summary
It’s worth revisiting once in a while what takes you time (and energy), and whether you can delegate it. Some things you definitely can’t (like 1:1s), but they are rare.
4 tips to remember:
Delegation is not about throwing off responsibility to others. It’s about sharing it.
Never delegate 100% of a specific area. Do it yourself once in a while.
You can share at least 50% of your current work.
It helps the whole team when you do it.
Indeed I have seen developers promoted to lead positions going back to non-leading positions. The "Rep" idea is a great one. Do you think the step back from lead positions is because some people lack the required people skills, on a position previously heavy on technical skills only ?
This is so relatable!