This post is featured in our ebook, "Hello World! A new grad's guide to coding as a team"– a collection of essays designed to help new programmers succeed in a team setting.
Grab it for yourself, your team, or the new computer science graduate in your life. Even seasoned coders might learn a thing or two.
Click here to download for your Kindle
It's not quite what I had in mind when growing up, but right now my role title tells me I am a team lead. In the course of my time in this role, I've learned that being a team lead is something my fellow developers are interested in doing someday, so I want to share about my experience. This is what I've learned in discovering what it means to be a team lead.
People management
I'll start with the obvious. A team lead is supposed to manage the people on their team. For me, these people are usually developers. Of course, everyone is different and situations arise in a variety of ways, some that I can prepare for or help with and some that I cannot. Over the years I have learned a lot about how to manage people and how to deal with common problems, but the one common denominator is that I don't always know what to do in 100% of the situations. This is certainly a never-ending learning exercise. It's an interesting aspect of the role that managing no one person is ever the same. Getting a team of different people to work together, keeping them challenged and motivated, ensuring they are performing, improving, and growing, is all quite interesting and challenging. Seeing teams form to reach their potential and watching individuals progress in their career is what I find most rewarding about my job.
Project management
Generally as team lead, I'm also the one managing the projects and making sure they get delivered on time (← why is that bit so hard?!). Delivering the right features, a good user experience, and high quality software on time is damn hard. There are so many equally important projects going on that should have been delivered yesterday. There is never enough time, so you have to constantly prioritise, which often means just saying no.
This picture best describes the situation I often find myself in. Just picture me in the middle of this four way tug-of-war. In front of me is a product manager, who tells me all the lovely, but never-ending list of things we must do. To the left I have a designer showing me designs for the best user experience we could possibly build. To my right is the quality engineer who always seems to be scolding me about our test coverage and quality of code. And of course, behind me are the developers who tell me things are going to take longer than estimated, complain about the amount of code debt we have, and explain how we need to build things better.
Now, I may be slightly exaggerating here, but the truth is, everyone is rightfully doing their job and pulling me in the direction they are supposed to. I just happen to be the person in the middle. The trick is finding the right balance and not falling over, which is quite hard to do. I sometimes worry if I'll even make anyone happy in this constant game of give and take.
"As a development lead, it's my job to be pulled in different directions without losing my balance."
When I'm not embroiled in a game of tug-of-war, some other things I do associated with project management include sprint planning, roadmap planning, people planning, risk mitigation planning, deployment planning and planning for planning (yes, it's a thing).
Having a bird's eye view
This overlaps with project management a bit, but I tend to think about it separately since it's on my mind a lot. As someone not on the ground coding everyday, I am able to take a step back and look at what my team is building more holistically. There is always a constant stream of questions to be asked and decisions to be made, ranging from technical concepts like implementation to other concepts like if the user experience makes sense. A final aspect of this perspective is considering the project dependencies, or how my team is depending on a different team, and how other teams are depending on us.
Wearing different hats
You don't necessarily have to be a team lead to wear different hats, but it's absolutely required of me when the Product Manager, Designer, or QA Engineer isn't available. I don't claim to do any of these roles particularly well, but I have to learn to think like these people. It is quite common for questions to arise once development has already started, and it's usually quicker for me to make these small decisions on the spot, which is where putting myself in someone else's shoes comes in handy.
Conversations and coding
As a team lead, my calendar is full of meetings, which I prefer to call conversations, because that is what they are. Besides my 1-on-1s with the people I manage, my mentors, and my managers, my calendar is usually full with conversations about the software we're going to build. There is planning to be done, design reviews to go over, technical discussions to be had, and more.
To be honest, I hardly code any more. I code 1-2 hours a week if I'm lucky organised. Most of the team leads I know don't code much either. Letting go of coding is probably the first thing most devs-who-become-team-leads struggle with. I learned that as team lead it is not my priority to be writing code. In fact, when I do have to code, I'm not as efficient as another developer because I haven't been following the issue entirely through the workflow. In an attempt to keep up, I try to do random code reviews, set up a dev environment, do a bug fix, or simply pair with whoever is available.
Well, this is my experience being a team lead. Even after a few years, I still find my job stressful, challenging and hard, but for the most part, it is highly rewarding and enjoyable. If one day you find yourself in my position, I hope hearing about my experience will have served you well in the challenges and opportunities you will face.
This post is featured in our ebook, "Hello World! A new grad's guide to coding as a team"– a collection of essays designed to help new programmers succeed in a team setting.
Grab it for yourself, your team, or the new computer science graduate in your life. Even seasoned coders might learn a thing or two.
