You may recall I started working at Atlassian in March of 2015. I’ve been a front end developer for them for about two years, but have wanted to move to a team lead position for a little while. I was offered the position, and spent three months being an “unofficial” team lead. In July all the paperwork was done and dusted and I had officially started my new role.
So, what do you do?
Yeah, that’s a good question. The team lead role at Atlassian isn’t very well defined. It grew organically as needed, and no one has put a strict definition on it. This is great because it means the role is what you make of it. This sucks because it’s sometimes hard to know what’s expected of you and how you’re tracking. From speaking with other team leads I knew this was a potential problem going into the role, so I made sure to speak with many other team leads and get a better understanding of the role. Here are some of my notes and thoughts from those conversations.
Three hats
Team leads wear three hats: process refinement (which is usually project management), people development, and programming. As a team lead you’re always trying to balance these three areas - each one comes with their own difficulties and advice.
Process (project management)
This is about defining scope, breaking features into tickets, keeping tabs, and generally getting a project from “in progress” to “done”.
A constant question is “how can we do it better?” Sometimes “it” has already happened, so I’m looking for ways to do it better next time. Sometimes “it” is still happening so we can trial process changes right then. However, one team lead I talked to wisely gave me this instruction:
Part of your job is offer the team stability - don’t change too much too quickly.
Instead, I took notes about things I thought we should trial in our next feature, and made sure to ask the team what things they were interested in changing. Changing process seems to be a slow but constant part wearing this hat.
Process is also about all the stuff that happens “around” your team - do they have a pull request that’s waiting for review from someone not in your subteam? Do we need to talk to someone from quality engineering or security about this feature? How can you find your unknown unknowns? Thankfully I got this piece of stellar advice early on:
Moving away from an individual contributor role is all about relationships: with your team, boss, triad, other decision-makers for the product, etc.
So one of my early actions was setting up one-on-ones with everyone I thought might be useful: the PM for the feature, the designer, our architect, our quality engineer, other team leads, and of course my boss and everyone on the team. I didn’t have all of these every week, but knowing there was a time and place to raise questions meant that I could dump something on a page and it would get answered in our one-on-one rather than needing to find “just 5 minutes” to ask someone something. I’ve since scaled back on some of these meetings, but building those relationships early on was incredibly beneficial.
Shipping is the most visible part of your job which means it’s also kind of a vanity metric. After all, weekly checkins are way nicer if your project is going well. It’s also easier to know how you’re performing in this area (a boolean “is your project running on time?” is a good starting point). As it happens, this is the hat your boss is the most interested in, since they look good if their features are shipping on time too.
All of this adds up to getting sucked into just this part your job and ignoring the other two. It’s easy to do, and it feels productive, but it’s not the whole of your job description. Which leads us to...
People development
There’s a bunch of official people stuff team leads do: one-on-ones, yearly reviews, promotions, approving leave etc. But these aren’t directly related to growing people. As much as pushing to get a feature across the line is how you’re evaluated day to day...
Ultimately you are measured by how well you can grow your reports.
When I thought of being a team lead this was the area I was most interested in. I’ve done a lot of tutoring and mentoring over the years and I’ve always loved it. This is not that. This is nothing like that. A key aspect I overlooked is that in tutoring and mentoring it’s assumed that you know more than the person you’re working with. Being a team lead blows that assumption right out of the water. I’m lucky enough to work with people who are much better developers than I am, so how can I possibly make them better?
I’m still very much figuring this part out. So far I think two aspects of people development are:
Giving people time and authority to invest in themselves. It’s hard to spontaneously remember to reflect on your work, so it’s part of a team lead’s job to make time for that. Having a weekly (or however often) one-on-one is official time to talk about how someone is improving. To give them tips on how they could get better faster. To talk about how awesome they already are. Maybe you set goals and track them, maybe you keep checking in and asking “what are you the most proud of this week?”, maybe it’s about giving them space to vent so they can go back to their desk feeling heard and able to move on.
Giving people work that will help them improve. When assigning tasks with the project management hat on, the question is “who can get this done the fastest?” On the flip side, when you’re wearing your people development hat the question is “who would benefit the most from doing this?” There’s a time for both of these questions in a project, but it’s important to make sure you’re asking the people development one periodically because it’s easy to get caught up in the project management side (see “vanity metric” above).
The other side of people development is gaining trust from your team. The best advice I received here is
Team members should never have surprises.
They should know what work is coming up, what the timeline is, what your expectations are. It is on you to constantly communicate all of this with them so they are never surprised. This is especially true for end of year reviews (which I haven’t done yet), so there’s an emphasis on frequent feedback in one-on-ones to be sure the both of you are on the same page before the “official” page is presented.
This is the hat your team is the most interested in. They want to be do amazing work, and it’s on you to facilitate that.
Programming
The early (and realistic) answers I got from talking with other team leads boiled down to:
You won’t do a lot of it.
It’s understandable - you’re now wearing two more hats than you were before. And both of those hats come with a lot more meetings. There’s just less time at your desk in usable chunks. A few team leads I talked to had some hacks for this - all one-on-ones on one day so the other days have more usable chunks of time; no meetings one day a week; work from home periodically; no meetings in the mornings, etc. But overall no one seems to have a solution for it. It’s up to each team lead to decide how much time they can, should, and want to dedicate to programming.
This predictably leads to an identity crisis. Programming is what you were originally hired for, you have the most professional experience here, and feel the most accomplished writing code. When things are going wrong with the other areas of your job it’s easy and tempting to come back to programming as a “safe place” where the problems are known or unknown, but never “pending”. When we were wrapping up our last feature all I wanted to do was code - our team was in a time crunch and everyone was pushing really hard to get it all done (and tested!) before we released. I desperately wanted to help them, and the way I’d done that best in the past was to crank out some bit of Javascript, close a ticket and do it again. This time things were different. I had to listen to the advice I had gotten:
Whenever you’re going to pick up a programming task as yourself “is this the best way to help my team?”
generally the answer was “no” (not least because most of the tasks were Java and I would cause more problems than solutions if I tried that...). I’ve talked to some team leads about how they stay in the loop. A few answers have been:
- Take on more pull requests than you would usually. This is a double win - you know who’s working on what and what feedback they’re getting about it, you also can read and learn from code without needing to do the “last 20%” to get the pull request merged.
- Pick up work, but never anything that’s critical path. This lets you keep your hands dirty, but means that if an urgent meeting pops up in the middle of your day you don’t need to find someone to take over your work.
- Pair program with your team. (This is my suggestion and I’m totally biased here because I love pairing.) Another double win of building relationships with your team and learning what’s happening with the code at the same time.
Overall, I think this is the hardest thing to balance. At the end of the day, no one benefits from your keeping your skills up as much as you do. If you can help your team work better “one developer” worth then you’ve already replaced yourself. It’s hard to justify why you should take time away from optimising your team further in favour of getting one ticket across the line.
Closing
I’ve now been in this role for about six months, and I’m really enjoying it. These new hats are keeping me busy and engaged. Here’s hoping I keep learning these new skills and keep up my programming skills at the same time!