I’ve been a part of my fair share of engineering teams now and I have to say that one of the hardest parts about working with any number of people is trying to figure out how many people it really takes.
There is this idea that the smaller the team the easier it is to communicate. Smaller means more agile or that by removing people from the decision making you get to decisions quicker. There are no roles so everyone just steps in and gets shit done. I’d say generally those things are true. But it doesn’t always work out that way.
There are many things you can complain about with larger teams. Decisions are dragged over days, roles and responsibilities are unclear because often it’s duplicative, meetings take hours and workflows extend to handful of people rather than just a few. However if the product you’re developing is feature rich or massive in scale sometimes you truly need an army to manage it all.
It’s not the size of the …
There are books written on software project management. It’s my observation they all are written with a certain kind of project in mind, and that isn’t the project you’re working on. Obviously you can glean best practices for managing feature intake, defect tracking and scope estimation, but there are certainly no silver bullets. And if your answer to all of this is “agile”, well I think there is a saying … if I have to explain it, you wouldn’t understand it anyways.
It’s funny because on all the teams I’ve been a part of there always seemed to be roles. Everyone has a title and a job description. But sometimes it’s just not clear what each member is supposed to do exactly. If I’m an engineer should I be involved in project roadmap discussions? If I’m an architect should I be involved in estimating the work effort? Inevitably you wind up with people confused about what to do, how to do it and then the mistake is made of believing there just aren’t enough people (or more rarely, believing there are too many people).
There is something else to consider along with team size that I think helps make things run just a bit smoother. That is clearly defined roles. It’s my opinion there are four essential roles. Planners, Designers, Doers and Verifiers.
Planners are what we typically call project managers or scrum managers. This role is responsible for and takes control of the plan. Define the plan, document it, communicate to the organization and then follow up on it to make sure it’s happening. It’s my opinion you only need one of these. Any more and you get plan heavy. There should only be one plan so why would you have more than one planner?
Designers are often called architect. Sometimes there could be a few of these people. I’d promote the idea that you want specialists in these designer roles and not generalists. I want experts with deep knowledge of their specialty. Their job is to make sure there is a design for others to follow. Software can get real messy. These folks are responsible for making sure it doesn’t. But there is a rule for the Designer: if you don’t like how it’s getting done become a Doer.
Doers are the engineers. Get shit done people. Yes you might have a large number of these people but their responsibility is very straight forward: write software according to the plan using the design. Be on time, be accurate and be nice. If you don’t like the plan, become a Planner. If you don’t like the design, become a Designer. Otherwise sit there and kick ass at getting shit done. This is another role that can be specialized. Scratch that, this role must be specialized. Experts in their fields. Don’t have back-end engineers doing front-end work or vice-versa.
Verifiers are obviously the people who make sure that the software matches the design and fits in the plan. Our beloved QA folks. This job is hard. You have to be involved in everything. You need to know the plan. You have to understand the design. You have to validate. There could be a lot of these kinds of people on your team. The more the better. But they also have to be conscious not to be too dictatorial. It’s not within their role to make decisions. Just as it goes for the Doer: If you don’t like the plan or the design or how it’s being done … then become that.
I can imagine all of this sounds overly simplistic. But I’m pretty sure that if this were the guide to building the most correctly sized team you would end up getting really close to perfect. When trying to determine the number of people it will take to get the job done I think you can simply ask “how many planners, designers, doers and verifiers will it take?”