Management: Small Team vs. Large Team

An unexpected difference building a startup from the ground up was going from managing multiple engineering teams back to just one single small team. Because I think the skills involved are really quite different.

Large: Managing Managers

Once you have more than a dozen or so people, you tend to have some sort of structure in place. Typically you'll have a team lead looking after each individual team, then for larger structures a number of leads-of-leads or engineering managers each looking after a group of team leads whose teams work in a related area.

This means that as a head of, or a lead-of-leads, you're mostly managing managers:

• Your direct reports will be talking about the help they need with managing their teams, discussing technical approaches and handling inter-team dependencies.
• Your skip-level meetings will tend to focus on wider context issues, as you'll be seen as the person who can unblock things which travel beyond just one team.

The less obvious difference here is you're spending most of your time working with people who are some way along the career journey. Someone at lead level has already had to get the senior promotion and then the lead promotion; they know what they need and tend to be open to discussing their challenges (or at least amenable to coaching in that direction).

Small: Managing Personal Growth

With a small team, you don't have that intermediate layer; you're managing software engineers directly and often doing a chunk of the hands-on work yourself. Most likely you have a mix of skills and attitudes, from obvious candidates for team lead once you grow, to juniors in their first software development job.

Going back to this was a bit of a culture shock, because I'd forgotten how much of "well, that's just how a team operates, you get a good team lead and they look after it" is driven by those team leads endlessly pushing best practice:

• Getting people to keep boards up-to-date
• Getting people to raise blockers and impediments, not struggle alone
• Getting people to follow coding standards
• Making sure processes (e.g. peer review, tests) are done

With a large team, my discussion around a developer not being great at coding might be five minutes of, "_ is struggling to keep up", "do you think training would help?", "that's a good shout", "find a good course and I'll get it paid for".

With a small team, I'm doing this same thing but then I'm also making sure that developer takes time to do the course, I'm checking in on every 1:1 with them to see that they're learning, I'm looking at their merge requests and when the improvement stops picking up with the, "hey, how are things going with that training?" I need to manage their personal growth so one day they're also that "I don't need to tell them what to do, they just tell me what they need" senior or lead.

It's made me really appreciate what my team leads do when I'm managing a larger team.

Repetition

I think what struck me most is how much these tasks repeat. When I bring in a junior developer, I'm going through the same things: how the process works, what to do to get code deployed, when to ask for help, and in these post-COVID days even basics like expectations for remote working. Everything to avoid the classic, "I didn't realise I was supposed to merge my code, I've just been running it locally in my development environment whenever we needed to synchronise tracking information"

Which is great, because I can bring in mechanisms; good onboarding docs, correct-is-least-friction tooling, pairing approaches, all the good stuff where we can go, "these things repeat, let's make them more efficient".

When you're managing managers, it's much harder to go "here's a mechanism for that, let's implement it". Usually what you're trying to solve together is the thing blocking you from putting a mechanism in place.

Problems in this world are complex, bespoke and often relate to interpersonal dynamics - whether it's the team lead going, "these young developers are killing me, they keep pulling in four different directions" or every engineer in the department threatening to quit because the senior architect won't deviate a single box from their perfect vision, you're having to think on your feet as there won't be a textbook answer out there. You're providing skill and experience to help people solve these problems within the unique constraints of your particular environment.

Going through that startup journey, from "there's just me" all the way to having a trusted lead again has really helped me understand how different these styles are, and the different skills required for each.