One question that regularly comes up in the career of developers is “Should I be a dev lead?” It’s a challenging one because the definition of a dev lead varies substantially from company to company. In a broad sense, there are three parts to being a dev lead: 1) providing deep technical insight, 2) connecting the team’s needs and the company’s needs, and 3) personnel management. There are a thousand other pieces, but these tend to be the big ones, and giving percents for each can give you a reasonably proxy for what being a dev lead means at each company.
Some Practical Examples
My first time being a dev lead was a 55:40:5 (tech insight : team/company connection : personnel management) split. The majority of my time was spent coding, helping others code, doing code reviews, and most of the things you’d generally expect from a more senior developer. The other big chunk was about conveying vision, breaking tasks down to give feedback, working with designers and backend engineers, and generally providing a voice to and from each group. The final part was very minimal with irregular one-on-one meetings. That was at a startup in the realm of 30-35 people, so there was no formal training, and I relied heavily on reading to figure out what I was supposed to be doing. For better or worse, a lot of the good things that happened on the team happened organically without me orchestrating them. That meant overall things went well but I didn’t learn a lot about where my shortcomings were.
Compare that to my experience being a dev lead at Hulu where it’s more like 30:50:30. What’s that? The numbers at up to more than 100%? Yeah, well, that’s how it feels too! With team sizes of six full time devs, two contract devs, and three QA just keeping up with one-on-one’s is a fair amount of work. Although QA doesn’t report to me, I consider them an integral part of the team and have biweekly one-on-one’s with them too. On top of that, the other Android team at Hulu was without a dev lead for a substantial amount of time, so even the irregularly scheduled meetings with those folks added more. The literal writing of code for a dev lead at Hulu is substantially different than at the startup, but providing technical insight both to the team and to other teams is still extremely important.
This post isn’t really meant to be about me, but I wanted to show contrast between just two different dev lead roles and these aren’t the only two mixes by far. So, when you ask yourself whether you want to be a dev lead, you need to first understand what that means either at the company you are working for now or at the place you want to apply. At bigger companies, a developer will often have the opportunity to take on a portion of a lead’s responsibilities to get a taste for it. See if you can be the point person for a big feature, manage an intern, or attend broader cross-team meetings. Learn which pieces you enjoy or dislike before making the full plunge.
Big Things to Consider
There are also a few specific things worth keeping in mind:
It’s easy to tell a computer what to do and it will do whatever you say (even when that’s not really what you meant). People are far more varied and some eagerly take on whatever you give them and others are reluctant to do anything outside of their own desires.
What’s best for you is not always what’s best for the team. A core part of being a leader at any level is being able to teach the people above you when they propose something bad, but a lot of people will just say yes to senior leadership because it’s a lot easier than convincing them to change their minds. It might be the best/easiest for you to just go with what the senior leadership proposes, but that’s not always best for the team (or even the larger company). On the other side of things, you also have to be able to convince the team to do something that makes sense for the business even if it isn’t what the team wants.
As a dev, you occasionally have days where you don’t make as much progress as you wanted to or you realize the approach you were taking actually won’t work, but you learn from it and move on. As a leader, you occasionally have days where you spend the entire day pushing back on asks that you disagree with. If you’re 100% successful, you could end the day exactly where you started, and that can be exhausted. For example, I’ve had meetings where people wanted the system (temporal) back navigation in Android to insert screens the user hadn’t visited during regular app use, where tech leadership wanted client devs to be paged if backends went down, where folks wanted to add paperwork to processes that were streamlined, and where some wanted to end brown bag meetings with devs. You have to keep in mind that people are well intentioned and just come with a different perspective, but you can still end up getting home and wondering why so much energy and time has to be spent on these types of things instead of focusing on what’s best for the end user.
At the end of the day, if you’re still not sure, you can always try being a dev lead and see how it goes. The challenges you face are very different but so are the rewards. The one danger you have to handle is that if you end up in a position where you’re not writing much code and you may want to shift back to being a developer again, it only takes a couple of years before that becomes really difficult. At the end of the day, you should do what you most enjoy. In the dev world, you don’t have to become a manager to keep your career alive. If you want to just write code, then do it.