Different Team Sizes And Their PM Overhead
Are you an experienced PM? Then I’d love to chat with you about:
- What factors should be taken into account when determining the size of a developer team?
- At what point does a developer team typically need a manager, in terms of team size?this
- How does the role of a manager change as a team grows in size?
- Can a team be too small to need a manager, or does every team benefit from having one?
- How does the management structure of a small development team differ from that of a larger team?
- What are some common challenges that arise when a team outgrows its current management structure?
Last year I had call with a potential client of my dev service company. He wanted to get a team to maintain and improve the backend of his app-based business.
He had strong opinions on how this team should operate:
I won’t ever accept a manager who is not technical. We don’t have time for someone just moving tickets.
I wanted to object. I wanted to tell him about the many teams I worked with where a non-technical manager added huge benefits.
He did have a point though:
⚠️ At the small size of his development team, an additional manager who cannot code, would not add value. In fact, more communication might even reduce performance, if the team is small.
Can “agile” improve this?
I called up a friend of mine with many years of tech lead experience. His insight came short and sweet:
In an agile team, you ideally don’t even need a PM at all. Let’s say there’s a good PO from the customer side, and you have a solid dev team. Then you can maybe have one tech lead. But a PM is not even necessary unless you need them as an account manager.
His emphasis was “agile teams”. Looking at the agile manifesto gives some pointers:
Business people and developers must work together daily throughout the project.
and
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
No plan survives contact with the enemy
In reality, it’s always good to have someone planning deadlines. It’d good to have someone being held accountable.
But does this need to be a manager, as in: this person does nothing else than “manage”?
In my career I’ve seen a couple of teams from 1 to 4 people that totally worked without a manager but made good use of tech lead roles. After 5 developers most teams added a part-time or even a full-time PM with huge benefits.
These are the patterns I’ve found. Note that I assume here that there’s some entity giving the specifications. That could be a very well-written document, a very complete functional spec or a person giving the input.
1. One Single Developer 👩🏻💻
This construct only works for small projects, or with a strong PO. The Product Owner (PO), or any specifying person for that matter, has to constantly test the work and keep the developer aligned with the desired outcome.
Without a strong person giving directions and keeping the developer accountable, a major problem can occur:
Incentivization problems
Great developers are always in demand. If a project should work with a single dev, that person is required to be full-stack - and really good. The problem with really good people is that they usually have a backlog of work.
If the incentivization is non-existent, for example with hourly work, then the developer might work on things they find interesting. Most of the times, these interesting features are not he exact business goal.
Tips how to get away with minimal PM time
Break the project down in milestones. Specify each milestone well and make a functional spec. If the project is new, the developer may agree to a fixed price based on milestones.
2. A Pair 👩🏻💻👨💻
Pairs work well for a lot of reasons, and are usually way more effective than one individual. Those teams work really well when one developer is the radical who is not afraid to change code and build big structures quick.
If the other is more grounded and sticks to best practices and code quality, then great things can evolve.
I’ve personally seen this when I was the tech lead of a critical project that needed to get done in 6 weeks. Not only did we ship in time, thanks to the more grounded developer we also had good test coverage and acceptable code quality.
Tips how to get away with minimal PM time
- Make sure the devs are somewhat on one level so they respect each other’s opinion
- One dev is the lead. They are doing more architecture work.
- The PO should talk to both, but go deep into spec questions with both individually, depending on the features.
3-4. Small Squad 👩🏻💻👨💻👩🏻💻👨💻
Personally, this is when things are most fun, and also most effective. Cost for such teams are high, but with a strong tech lead they can move mountains.
It all depends on a strong tech lead. One person usually builds architecture and gives direction on where the codebase is going.
Tips how to get away with minimal PM time
As my friend stated above: teams of this size don’t necessarily need a PM. The teach lead can technically do it - with one caveat: the PO side needs to be spot on, and smart. Politics needs to get cut to a minimum.
Once politics are involved and/or the team gets challenged internally to hand out time/expertise/help to other teams frequently it does make sense to add a PM to shield them from the product owners.
I’ve seen very effective squads of this size with and without a manager. It really depends on how well the customer’s side is kept in check.
5-7. Big Squad 👩🏻💻👨💻 👩🏻💻👨💻 👩🏻💻👨💻
When I coded Java back in 2007, I worked with a great consultant who taught our somewhat junior time a lot. One day he said this:
I like to keep teams so small that you can sit together at a kitchen table, have lunch, and discuss problems.
Once the team outgrows a kitchen table, break it up into two teams. He might have stolen that idea from the more popular Two-Pizza Teams from Jeff Bezos, but it’s still valid.
These teams most likely need a dedicated PM who helps to organize meetings and always has one eye on the tickets.
7-10. Time to split? 💔
I’ve only worked in teams of that size for short stretches of time. Usually those were broken up quickly into two smaller parts.
Once, an expert from the customer side told me off the records:
With our current structure running a SCRUM process with that many people, I’ve calculated that the net-work time is just at 50%.
Isn’t that crazy?
I bet you have a similar experience (if you have, let me know please).
How to break up teams? Some approaches:
- Feature/Fixes: One team codes forward while the other makes sure that code is stable.
- Frontend/Backend: That might be a given anyway, but I’ve heard full-stack devs often outperform a separation like this.
- Feature-based: This makes a lot of sense if there are two categories that can be worked on mostly independently.
- Platform/Implementation: In case you want to extract a generic layer into an own codebase/module, that might be it.
I listed these just as inspiration. If you are in a big project team you will already know what’s best. If you know more methods, I’d like to add them here as well.
Supplementing research
I had a look at some studies about this topic. The data here does not show exactly how the teams are split up in smallest units. I guess these show the whole head count for a software project, regardless of the actual granular teams:
Development team size increasingly at around 6-10. Source: the state of code 2020.
Others argue that there’s no strict rule for the team size. See this medium Blog, which says it’s entirely on the discretion of the owner of the organization/startup.
I do believe we can learn from the opinions of other people.
Much more important is, for me at least, to be pragmatic. If something works, don’t change it. If a team figures out how to work effectively without a manager, let them keep going.
And in any case: if something doesn’t work: switch it around. Maybe remove a struggling developer. Have 1on1s to figure out if there are inefficiencies. Give people the tools, freedom, and mission. Mostly good things come out of them - regardless of the team size.
Did you read all the way to the end? Amazing! What do you think of this? If you have thoughts to share, I’d love to talk to you! [Reach out to me] (https://tillcarlos.com/about/) please.
