Introducing Development Team Leads

The challenge: Scaling

Our dev team has reached a quite impressive size these days! Unfortunately I just don’t scale to this size. I can’t possibly conduct 1:1s, listen to feedback, give feedback and help people grow in a flat team of 12 people. While I don’t code anymore these days, and have assigned most project management tasks to Feature Coordinators, lots of new responsibilities of a growing company are now on my plate. I just have to lean on others so that every dev team member gets the attention they deserve.

That’s why we introduced the concept of Team Lead two weeks ago.

Terminology: “Team Leads” vs “Managers”

Originally I wanted to introduce “Dev Managers”, because there’s a lot of management to be done: Conducting One-on-ones, listening to feedback, helping team members achieve their longer term goals, and so on.  Also, I’ve long struggled with the term “leader”, it had this elitist ring to me, as if the leader were a much different person than the “ordinary rest of us”.

But the keynote at HR Tech made me reconsider. Simon Sinek talked about a leader as someone whose benefits are kept in check by the added responsibilities and risks. Once danger arises, it’s the group’s expectation that the leader charges towards danger first. In “cave-man settings” the group leader faces the beast, in business the team leader fights for the team’s well-being, delivers all the uncomfortable news to CEO, and works extra hard to inspire the team and make it happy. Leading doesn’t mean “follow me because you must”, but “follow me because it’s the best for the team, and if the shit hits the fan then I’ll own the failure”.

This is of course not a new dilemma organisations face, so here’s an article on the web that offers additional insight:

What to expect from Team Leads?

Here’s what we expect from all team leads, and this applies to Linda (our director of marketing/customer success) and me just as well of course, and to any other leader we’ll hire.


  • Be responsible for the well-being of a team
  • Represent the team, inspire the team, fight for the team
  • First listen, then talk! You need to understand your team before you can represent it
  • Act upon unhappiness, either resolving issues locally or raising them with people who can help
  • Be very open for feedback about your own work and behaviour, both from team members and your lead
  • Never accept the status quo: Always try to make the team better. Scout the terrain and lead the team to an even better place.
  • Delegate work and responsibility to help people grow, but ultimately take full responsibility for everything the team does



Tools and methods can change over time, but the following would be a good start

  • Conduct 1:1 meetings every 1-2 weeks, solicit feedback from each team member, and act upon it
  • take written notes about 1:1 meetings (in SI)
  • consider the person’s trajectory, and their career goals (if they are willing to share those). Suggest stepping stones on their career advancement
  • after 360 feedback comes in, be the person who discusses the feedback, and who helps find smart solutions or goals to work out any issues that might arise
  • take a look at the team as a whole, solicit suggestions for team process improvements
  • conduct retrospectives (or at least ensure they are conducted)
  • Look after career goals. Review training budget and ensure it’s spent


No overnight miracles!

The introduction of Dev Team Leads comes early compared to other companies. When I joined Atlassian back in the days, there had been 50 developers all reporting to the director of Engineering, and I took over a team of 8 that was growing, and TLs were not introduced until we approached 16 people in my team. At Soundcloud we just learned they introduced team leads when they approached 100.

So, why should SI start this early? Because it’s not an easy flick of a switch. The transition will take time, we will run into challenges, two out of three of our newly appointed team leads don’t have previous lead experience. We’ll need to provide training and we’ll occasionally screw up.

That’s why it’s better to start earlier than wait a year until things really get tough! So, we don’t expect miracles, it’s a longer term transition.

What about the Feature Coordinator Role?

Our Feature Coordinator Role is about coordinating work for each team, and seeing features launched. It’s specifically not about looking after or leading a team. Therefore the Team Lead doesn’t have to be the FC at the same time. The FC role is a lot more about project management than about team leadership. The roles are orthogonal.

Our goal is that everyone gets a chance to be the FC over time, so the FC role will be rotating. Team Techno has already rotated the role and I expect the other teams to do the same in the next couple of months (not all at once though)

Changes to Team Members?

Not much changes really! Team members will continue to come up with their own ideas, or receive input from other sources. We don’t want to become a formalistic company where everything needs to get approved by the team lead. We’ll still work as a network of teams, not as a strict hierarchy.

Team leads are also just people and have flaws. Team members must keep giving feedback to their team leads too. If issues with the team lead can’t be resolved locally, it’s totally fine to reach out to any other person in the company who might be better suited.



Slides and Outlook

I officially introduced the new roles at our weekly dev meeting two weeks ago, here are the slides from that talk.


Next steps

Although we have assembled a very strong dev team by now, we’re still learning a lot. Team management is yet another interesting challenge, and we’ll most likely have plenty of learnings to share in 6 months or so. Stay tuned!