08 January 2022

What You Need to Know as a New Team Lead

Tyler Young
Tyler Young @TylerAYoung @tylerayoung@fosstodon.org
Work

So you’re becoming a software team lead. If this is your first foray into the management track (as it was for me), you probably have a lot of questions about what you’re, um, supposed to do. This is a brain dump of some of the stuff a new team lead might need to know—things I wish I’d known when I started.

The core of the team lead job is empowering the team to do its best work. That takes a few forms:

  1. Protecting the team’s focus, including being a communication channel from the rest of the organization to the team (or the individuals on the team who need to know something)
  2. Unblocking or reducing drag on the team, either:
    • by improving collaboration with your product & customer success teams,
    • by coordinating with the broader org (when your team needs something from outside), or
    • technically (often via “janitorial” type work or collaboration on a particularly thorny problem)
  3. Hiring, interviewing, and onboarding new devs
  4. Supporting individuals’ growth and career development

Those are listed roughly in priority order, which means that unfortunately I’ve done a rather poor job of supporting people’s professional development, because it always comes last… and I’ve also been a less than ideal onboarding buddy.¹

You’ll note that “developing new features” isn’t on that list. For awhile, it was, but my time is so fragmented with meetings and such that signing up for feature or bug tickets was super stressful. I don’t have the spare cycles to do something on any particular timeline unless it’s something I can be sure will fit entirely on my low-meetings day. For this reason, my dev time has been focused on janitorial stuff which moves the team forward, but doesn’t have a timeline on it. This has included stuff like CI improvements, dependency upgrades, refactorings, expanding documentation, etc.

On reducing drag for the team

For me, solving technical blockers is easy, and requires no explanation. (If I can’t help directly, I can at least find the person who can.) Organizational drag is a lot more complicated, and this is the bulk of where my time has gone.

One good example of this: since time immemorial, the dev team has been frustrated with the IT-issued antivirus slowing them down. Any time you did a compile (and especially an Elm compile), the antivirus would lock up the machine, sometimes for 30+ seconds. (This is a side-effect of its design: it scans every file you read or write prior to handing the data over to userland.) While this frustrated everyone, no one had ever taken the steps to work with IT to get it removed. By collaborating with IT over a period of a couple months (!), I was able to get an exclusion put into the antivirus ruleset for the devs’ code directory and thereby stop the lockups and remove some pain from the development process.

Speaking of process… medium-to-large orgs tend to have a significant amount of process built up around how teams work, and how devs collaborate with the product team. These processes are there for a reason (shout out to Chesterton’s Fence), but those reasons may or may not be applicable or even known today. There may be a lot of processes that can be improved, but a company is a big ship to turn, especially for a small rudder like a team lead. Even experimenting with small changes can produce a lot of uncertainty, anxiety, and resistance.

On improving collaboration with other disciplines

Devs tend to have a fair bit of Dunning-Kruger when it comes to other disciplines they need to collaborate with. (I’m thinking particularly of product and customer success teams here, but it applies more broadly.) Simply put, we’re biased in favor of people who write code to solve problems. This isn’t really a criticism of developers in particular, though. The truth is everyone underestimates the difficulty of jobs they’ve never done.

For our purposes, though, what this means is that devs tend to conceptualize annoyances brought on them by other parts of the org in terms of negative traits of those teams—low competence, poor planning, lack of caring, etc. This is a side effect of low trust. In many (most?) cases, this is misplaced—to the extent that devs have legitimate grievances, it’s been my experience that the product & CS teams are rarely the source of the issue; instead, they’re often under pressure themselves from outside in ways that devs can’t see—from leadership, customer demands, etc.

As you build trust with the other teams, asking “what sort of pressure are you under here?” is really valuable, and you can often come up with new solutions together that better meet the needs of both the dev team and the rest of the org.

On communication

I’ve done my best to avoid being a go-between when someone on my team needs a question answered by someone outside the team. There’s usually no value-add to them asking me something, me asking the third party, and me doing my best to relay that answer. It’s more productive for everyone if they connect directly.

That is not always the case when a third party needs something from my team, though.

  • If someone has a question about the state of the ticket, I should be able to direct them to Jira; if the Jira ticket hasn’t had sufficient status updates on it, I’ll ask the dev to do that when it’s convenient, in an attempt to not break them out of whatever they’re working on at this particular moment.
  • If someone needs some additional work on a ticket, they can add a comment to the ticket and we’ll discuss it at the next stand-up.
  • If someone needs new work, it can be prioritized by the normal processes.
  • If a high-severity incident comes up, I do my best to dig into the ticket as thoroughly as possible to decide:
    • Does this have enough context for a dev to be able to productively work on it? (What ²key information is it missing that will cause them to spin their wheels unnecessarily?)
    • Who in the dev organization has the most context on this? If it’s someone on a team other than mine, is there high-urgency work we can take off that team’s to-do list so they can take this bug instead of us?

On meetings

You will be the broader org’s interface to the team. As such, everyone will want to meet with you all the time. Many of these meetings could instead be just as productive (if not more productive²) as an email/Slack discussion/etc. My recommendation is to push for this.

On hiring

I have a post on hiring software developers. I still think that’s good advice: have people write code that exemplifies the role you’re hiring for. I also have a Twitter thread with the kinds of questions I ask candidates during the in-person portion of the interview.

There are a number of places I’ve tried to advertise our open recs for Elixir people:

On pleasing everyone

I discovered quickly that even with a team of four, there was basically no decision I could make, on any topic, that would satisfy everyone. Often it felt like half the team was telling me “we need way more of x,” while the other half was saying “we need way less”.

Then, inevitably if we did get more of x, the first half would say “…but not like that.”

I don’t want to paint that picture too negatively—nobody was mean spirited, or finicky, or whiny. But communication is hard, and everyone has different ideas for how they want to work, and the goal of running experiments is to learn from them, not to have a perfect success rate.

The point remains, though: try as you might to build consensus on a topic, you’ll never reach 100%. The best you can do in these cases is to:

  1. Make sure your decision is reversible (run experiments³, don’t set things in stone)
  2. Explain your reasoning
  3. Set some criteria for when and how you’ll evaluate how the experiment has gone

On prioritizing

I’ve been given the advice that “you only get credit for things you finish.” To that end, I’ve tried to have one or two initiatives I’m working on at a time and bring those fully to completion before starting something else. (If I have five things in flight, I don’t make enough progress on any of them to be worth the churn.)

To that end, I’ve prioritized working on things where the product of effort and impact is highest; if I can do something that requires only a small amount of work but produces a large, lasting impact (like improving tooling), that strikes me as a better thing to prioritize than something with a huge impact that will might take many months or years to accomplish.

Note, though, that this is not the tradeoff some of the other team leads I’ve worked with have made! They’ve often prioritized moving the Really Big Boulders, and were determined to make those things right first. I don’t think they’re wrong to do so, and in a lot of ways our approach here has been complementary.

On working with the other team leads

One final thought: My experience has not been the experience of the other team leads, and it may not be yours.

First, even within the same company, different teams face different challenges; they have different priorities, and different personalities/team cultures. It’s kind of amazing how different teams can be in these areas despite being so similar in other, perhaps more outwardly visible ways.

Second, your relationship with your team will be different from mine. If you come into it with more management experience, you’ll probably struggle less than I did in a lot of these areas.

Best wishes for your success. ☺️

Footnotes

¹ Team leads are inherently in what Gergely Orosz calls the “danger zone” due to the demands placed on them from so many different directions. If you haven’t already, you should expense a subscription to The Pragmatic Engineer—it’s the only Substack I’ve ever even considered paying for, and it’s 100% worth it for any software engineering leader.

² How could “lower-bandwidth” communication be more productive? Easy! It forces the person asking for your time to really think through what they’re proposing/asking/etc. up front, rather than “doing it live.” It also gives you time to digest it, rather than having to come up with feedback on the spot. Plus, if you need to, you can always have a meeting after you’ve had a chance to review the initial document.

³ The irony here is: some folks dislike running experiments on our processes at all; they feel like they’re being jerked around. I don’t know how to overcome this aside from doing your best to build consensus in advance of running an experiment, in an attempt to improve your success rate. If you can get buy-in from these folks in advance, so much the better.