doing less
12th march 2022
my new year's resolution for 2022 is simple: do less.
2021 was the year I switched jobs (again). and with this I had a boat load of new things to learn and I was very keen to do all the things.
we all know burnout is a thing. and i became increasingly aware over the course of the year that I seemed to be rollercoastering between highs and lows of productivity. i think there are two core reasons for this: how to measure my impact and knowing where to focus my efforts.
i think i was really struggling to see my impact as a team lead on a day-to-day level, especially when coming from my previous role as an individual contributor. i found that i was no longer finishing a day of coding with a final passing test and commit. no longer was i closing a ticket or shutting my laptop after adding the final touches to a design diagram i'd been working on.
instead, i bounced from meeting to meeting, context switching my way through lunch and beyond. from document to code review, zoom call to hr system, the outlook calendar became my master. i'm not saying there is anything wrong with this. i just think for me it meant the peaks and troughs of productivity i mentioned previously, became more exaggerated. this lack of clarity often led to more burnout.
you can see the change in where i was spending my time clearly on my github contributions graphs from before and after i took the team lead role.
and secondly, whenever a new team lead joins a team, it can take a bit of time to figure out where they can add the most value. the team lead role can be very flexible. they are expected to not only work out how to have the biggest impact for the team, but to also then just do it.
i am very lucky in my current team in that i work with some fantastic people. this means that where in other organisations the team lead would be expected to pick up parts of the product and project management role, in my current team i already have all that covered. it didn't help that in 2021 the team welcomed myself alongside a new delivery manager and product manager. meaning we all spent a large portion of the year stepping on each others toes and figuring out our roles and responsibilities.
so this year i want to take a step back. say no to some meetings/commitments and be a bit more selfish with my time. i want to get back to some technical hands-on work. i want to be able to mix the measurable with the immeasurable. i want to bring back a bit of that buzz that comes with solving technical problems and spend more time with the engineers helping them grow at the same time as continuing to exercise my own technical muscles.
lots of blog posts, podcasts and articles talk about the move from ic to manager. and some go even further and talk about the engineer/manager pendulum. A lot of them mention that when becoming a manager, you should put down the coding. and if you want to pick it back up, you should swing the pendulum back to being an individual contributor. i've found this tricky. not the putting down the coding part. i think i've been pretty successful at that. but the question i ask is: at what cost? i personally think that a team lead's role is so hard to measure and keep consistent, that having some time apportioned to the more measurable and consistent task of coding can help level off those peaks and troughs of productivity. have a full day of zoom calls? spend the next day on a technical ticket to balance it out. spent a few hours writing up a lengthy document on ways or working? pick off a tech debt ticket from the backlog to bring you back to earth.
i'm very lucky that i work somewhere where i can be the master of my own career and journey. where i can craft the role to what i want it to be and how i think it will be the most valuable to the rest of the team.
i guess we'll see how i get on...
-dom