Last Monday, I was happy to finally get the opportunity to contribute to a blog I’ve been a reader of for a long time: Simple Programmer. I talked a bit about my journey as a developer and how others can learn from it. Looking for a guest contributor to your own blog? Don’t hesitate to reach out. Now, let’s get to the post:
When I began working as a developer, I was deeply focused on the little things: how an algorithm works, the exact syntax for the language I was writing in, why an answer on Stack Overflow broke my code, and all the other roadblocks along the way.
As I advanced in my career and those roadblocks stopped getting in my way as often, I became more focused on what my code was actually doing. I transitioned into my first full-time developer role, where I was assigned tasks by my project manager and completed them one at a time, taking on bigger pieces of the project as I grew more confident and capable.
Then, all of a sudden, I found myself working on a project that was a little different.
There were two developers with less experience than me on the project team, I was working directly with the client’s technology team, and there was no senior developer specifically assigned to my project.
I had accidentally become the lead developer.
How Is Being a Lead Developer Different From Working as a Typical Developer?
Being a lead developer isn’t easy, and it comes with many challenges. You’ll have to adapt to changes in your workflow, receive more interruptions from others expecting you to weigh in on issues broader than what you were used to in an individual contributor role, and juggle the tasks of both a creator and a coordinator.
One of the first things I found when I assumed this new role is that my daily workflow changed quite quickly. I was used to coming into the office in the morning, sitting down, and cranking out a couple hours of code with my headphones in, all before heading to lunch and being more social and collaborative for the rest of the afternoon. I was accustomed to being a “creator.”
As the lead developer, it seemed like I was coming into the office with a bunch of emails to answer from other people in the company checking in on a project, and questions from the other developers on my team. I’d have open pull requests waiting for my review, and I would already have meetings on my schedule. I had been forced to become a “coordinator.”
This can happen quickly or you might find that your coordinator tasks creep in more slowly. In either situation, it’s important to recognize when you’re working on creator tasks or coordinator tasks and adapt your work accordingly.
Creator vs Coordinator
These new responsibilities would have been fine if I was able to recognize them as my new focus and shift from creator mode to coordinator mode. But I wasn’t. I still convinced myself that I could fit in a full day’s worth of writing code in between meetings, phone calls, and desk visits from other developers.
Looking back on it now, that was a recipe for disaster.
Convinced the only time I could get “real work” done was after everyone else had gone home, I started staying at the office later to get coding done after a whole day of coordinating the project. Spoiler alert: This isn’t sustainable.
Managing a team, coordinating development work, consulting on architecture, and helping with things like debugging and deployment are all real work, even if you’re not directly writing code. As an individual contributor, you’re used to measuring your work by how many commits you pushed that day or how many lines of code you wrote on a particular project.
The work you do as a lead developer is much less tangible, but potentially even more important. You’re affecting your entire team’s ability to be productive and this impact ripples out to be even larger than what you could have contributed to the project as an individual.
As someone used to being a developer full time, this concept can be difficult to grasp, but taking a step back from purely writing code allows you to better manage your team. Although the creator role is the one you’re more familiar with, you can’t neglect or avoid the coordinator role just because it’s unfamiliar or scary.
As a lead, you’ll code much less. You won’t give it up completely, as there are still optimizations and refactoring you can contribute to the project because you’re able to see the bigger picture. However, as a coordinator, you’ll help others write their code in the most efficient way possible rather than write it yourself. You’ll use your coding skills to save others on your team time and frustration rather than ship everything yourself.
Your Team’s Success = Your Success
As a lead developer or tech lead, your number one priority is keeping your team on track and helping them thrive. As a creator, your success was based on how efficiently you were able to complete the tasks you were assigned. Now, as a lead, your success is when your team achieves their goals and ships what they’ve been tasked with. Sometimes, this might derail whatever you’re currently working on. As the lead, though, it’s important to be able to put your work aside to help your team.
As a lead developer, you’ll find that on every project, there’s work that more junior team members will not have the skills to tackle, such as deployment, integration with outside systems, and anything that’s a bit more ambiguous than the clearly defined features they’re used to. These are exactly the kinds of messy tasks that you should take on as a lead. Figuring out these sorts of processes will help your team be more productive without taking the project’s less seasoned developers away from contributing directly to the project.
Another important part of being a lead is helping your team develop the skills necessary for them to succeed. When assigning a task to a developer, try to feel out if they believe they have the knowledge to complete it. If not, it’s often helpful to sit down and walk through some scaffolding code together. Even just writing out in code comments the general flow of how the feature should be implemented can help kickstart development and take the burden of staring at a “blank page” off the less experienced members of your team.
You’re the Leader, Not the Dictator
As the lead developer, it’s now your job to make high-level technical decisions and arbitrate technical disputes between your team. However, this doesn’t mean you should make unilateral decisions without consulting your team.
When it comes to a decision such as what approach to take when developing a certain feature, members of your team are likely to have their own ideas about the way to proceed. It’s important to take these opinions into account and evaluate them.
There will be times when a member of your team offers a better approach and it’s important to allow this discussion to take place. You may be the lead, but you will be wrong at times, which is why you need to hear out all ideas and approaches before moving forward. You’re on a team, so you don’t have to make all the decisions on your own, and it’s important to use all your resources.
However, over the course of having these important discussions, some disagreements will arise. There will be times when two different members of your team disagree on the technical approach and you will have to arbitrate this dispute.
Developers can be strong-willed, especially when it comes to defending their code and ideas. This is great, but it’s also important as the mediator to not let these discussions get personal. The focus should be on the technical merits of each approach being suggested. These mediation skills can be tough to learn, but as you participate in more of these conversations, you’ll learn how to lead developers with different views and get them to rally behind a common solution.
You Have a Whole New Set of Skills to Learn
Early on in your career as a developer, you probably focused mostly on learning technical skills such as new programming languages, new editors, and new build tools. However, now that you’re in a lead role, you need to learn some soft skills as well. These are skills such as breaking down a larger project into its component tasks, dealing with budget issues, and hiring and training other developers.
There is a whole set of management skills that most developers dismiss as not important. Now that you’re a lead developer, you can no longer have this attitude. Two great resources to get started are Peopleware and The Mythical Man-Month. Each of these books looks at the lifecycle of a development project from the point of view of a manager and provides a perspective on how to manage a team when you’re not the one writing all the code.
The most important skill to learn in your new lead developer role is the ability to keep track of multiple tasks in your head without getting overwhelmed. Previously, as an individual contributor, you had more leeway to focus on one task until it was completed, removing dependencies yourself with that singular focus of getting it completed.
In your new role, there will be tasks where you will decide on a course of action, but not be able to move forward until some other dependency gets completed. It’s important to move on to other tasks and have the presence of mind to come back to your original task when you can actually move forward on it.
In addition, it’s important to learn from others who have been here before you. One of the best ways you can transition into the lead developer role is to learn from developers who have become managers in the past. Patrick Kua has a great talk on what he has seen while leading and being part of various development teams.
As you continue into your new role, it’s important to focus on learning all the skills that you’ll need to be successful and not just on the technical skills, because those already come more naturally to you. You might find yourself reading business and leadership books that you once thought had nothing to offer you. And that’s great! Developing these skills can take you past a lead developer position into a role as a project manager or an even larger management position.
Moving Forward as a Lead Developer
Lead developer is a role that some developers try to achieve throughout their entire careers. If managing technical people is something you enjoy and you’re lucky enough to move up into this role, you can find more satisfaction in your work and your career.
One of the greatest rewards of becoming a lead developer is when all your hard work pays off and you see your team succeed. It’s an incredible feeling to watch junior developers take the new skills you’ve taught them and apply them to your team’s work. Or to see the approach you decided on as a team work out and have the project ship on time. This satisfaction is one of the best parts of being a lead developer and something not many developers think about when accepting this role.
It’s important to remember that you now have to balance the two roles of creator and coordinator, and not lean too far to either side. Keeping that in mind will help you transition into this new role seamlessly and propel your team forward.
This post originally appeared on SimpleProgrammer.com and all images are courtesy of SimpleProgrammer.com