DEV Community

loading...
Cover image for Avoiding burnout as a new tech lead

Avoiding burnout as a new tech lead

Danny Perez
DevOps Engineer & Engineering Manager at an ed-tech company helping our teams ship software quickly and reliably.
Originally published at intricatecloud.io ・4 min read

Does this sound familiar? The best dev on the team is promoted to being a tech lead, despite not having any management experience. That dev then all of a sudden has to deal with:

  • Angela, the senior dev who broke up with her partner and is emotionally devastated and needs to take a few days
  • Oscar, the new dev, saying he needs a few more days to refactor a logging module that needs a "cleaner" interface.
  • Kevin the PM who keeps making these damn status meetings
  • Michael, the sales guy who keeps promising features that don't exist yet

You spend all your time drowning in problems, trying to keep everyone happy. You found out that multiple teams were depending on your work only after it all fell behind. People start looking to you for answers, and you don't have any. You stopped caring. You're burnt out. I've been there myself. 👋 hi.

Almost as if the presence of programming skills also indicated that the person can manage a project with many other people. There are, at least, a good chunk of people (developers included) who honestly believe this. It sounds wrong, doesn't it?

How I started as a lead

First time I became a lead, I had no prep other than being a teammate and so my only goal for my first few months was to do everything the last person did - like I imagine the person before them did, and the person before them... I also started reading everything I could about being a tech lead - check out my list here

I also decided to keep taking on the same amount of work I usually did, in addition to my tech lead responsibilities. Sound familiar? :raises_hand: I

They were in a lot of meetings, so I felt I had to be in a lot of meetings. That blew apart my schedule for the week because I couldn't work on some relatively important things, and so schedules fell behind quickly after that. I would stay late at the office (seemed to be common among tech leads or maybe just consultants), and spend long evenings catching up on extra work after people started leaving for the day. In my bachelor days, this was fine - I had no other responsibilities and coding was fun - thats the excuse anyway.

All this meant that my days were filled with meetings and other "administrivia", my evening/nights were filled with coding, and I started burning myself out over time.

Anyway, long story short.

Here's a couple tips to help you avoid burnout as a new lead

1. Plan your time carefully

Block out time on your calendar to manage your week, set hard boundaries between when you start/end the day (especially if you work remotely) and stick to it.

You probably don't need to attend every meeting thats on your calendar. But if for some reason, you are required, depending on the meeting, I'll multi-task and be a "fly on the wall" and just listen, other times I'll have to be an active participant.

If you need to set aside a day to do some hands-on dev work, put it in the calendar and decline everything else. Unless you're working on life/death scenarios, it could probably wait until later. Some people have No Meeting Thursdays, Code Review Afternoons... Call it whatever you want.

When performance review season rolls around, its even more helpful to block out time to prepare everyone's review. I've tried to write all my reviews the night before in one week for my team, and it wound up taking me HOURS for each person as I tried to remember everything they did.

2. Stay out of the critical path

The critical path in a project is the set of tasks that NEED to be accomplished in order for something to work. For example - if you're building a feature that adds a button to your site, adding a linter or a CSS theme to your project is not required for that button to work. The button itself is obviously the important work.

As a tech lead, you gotta stop picking up any of that important work. If its a time sensitive thing, and you aren't able to get it done in time, it'll have some downstream consequences, and start blocking other projects from getting done. Thats what your team is for - they can go heads down on the work.

But what if some of your team doesn't know how to make changes to your CI/CD pipeline, or the front-end dev hasn't worked on backend SQL queries? Its on you as the lead to support the team to do the work - like that time we hired a junior dev who knew python and just a little javascript to do front-end work in an Angular app. He had never worked with a full-blown framework with all the bells and whistles before, but we had bugs to fix and no time to kill, and sure enough, with some training and mentoring, he got up to speed and started cranking through bugs.

Now, its important you stay technically involved at some level, but your focus will be on the big picture, like making sure that important features are getting shipped, and less on the small details, like why is [1,2,3].flatMap throwing an error.

Want to make your week easier? Try these to start.

  • start with blocking out a 4 hour chunk one day a week for heads-down coding time and decline everything. See how it goes and you can adjust depending on your workload.
  • Take a look at upcoming work that you would usually do like adding a new API endpoint to a backend, and offer to pair with another dev so that they can learn how to do that work.

If you're a new tech lead, definitely check out some of the 9 books that helped me navigate my first time being a tech lead.

I'd like to hear from you - what were some of the things that frustrated you when you first became a tech lead?

Discussion (2)

Collapse
griffinator76 profile image
Nathan Griffiths

Oh some of those situations sound awfully familiar! I've had a couple of lead roles now and while there were many rewarding aspects to those roles, particularly helping people in my team grow their skills and confidence, I also fell into a few of the traps mentioned in the article.

Things I wish I'd done, or done sooner or better:

  • Learned to delegate
  • Focus on creating an environment where people can succeed, because they have the right skills and the confidence to use them
  • Managed my time better by blocking out periods for team admin, meetings, project work
  • Restructure the team where it's not working effectively
  • Reached out to another experienced people lead to mentor me

Things I wish I hadn't done:

  • Felt compelled to attend every meeting I was invited to
  • Worked every hour of the day and night - in the long run a burned out team leader benefits no-one
  • Allowed the loudest voices to monopolise my time
Collapse
intricatecloud profile image
Danny Perez Author

Even after being a lead a few times, its still easy to make the same mistakes - like just now I realized that I need to block out time to prep my team's performance reviews, I keep putting it off as not urgent, but it's important and into the calendar it goes.

Thanks for reading!