Uncategorized
1 Comment

Avoiding burnout as a new tech lead

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. :wave: 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?

You might also like

More Similar Posts

Menu