Common patterns for organizing PED teams

As product+engineering+design (PED) teams grow from 2 to 15+ people, they tend to face similar challenges and adopt similar structures and processes to support their growth. By outlining some of the best practices I’ve seen for teams of different sizes, I hope this post helps others stay ahead of challenges and identify strategies for dealing with growth.

Team size matters a lot! When a team gets bigger, processes that used to work well can suddenly stop working. On the other hand, when a small new team starts out, they often chafe against the processes that larger teams swear by. While every situation is different, most teams of a certain size will face similar challenges and end up adopting certain structures to address those challenges. This post is designed as a reference to help teams identify new techniques for addressing some of their current challenges, predicting some of their upcoming challenges, and normalizing the fact that almost every team struggles with the same things as they grow.

“Partnership”: 1-2 engineers, a product person, maybe a designer

At this very early stage, structures are highly informal and designed to support rapid shifts in direction.

Typical structures:

• The team’s planning usually looks like a semi-structured “What do we want to do this week?”. There’s little to no backlog. People may create to-do lists for themselves, but detailed task-based sprint planning is probably unnecessary.
• What people are working on may change day-to-day; daily standups are used for both sharing status and deciding if priorities should change based on yesterday’s events.
• The “product person” - a PM, a founder, or other team lead - is likely to be deeply involved in the details of each task. The “product spec,” if it exists at all, is mainly an outline or reference for the PM.
• Decisions are made in real-time as the product is built, rather than codified in a spec.
• The team may set goals as to when features will be done, but detailed estimates and timelines are usually overkill because of the frequency of changes to scope & functionality.
• The team sets and updates goals on a week-to-week basis.

Challenges:

• With a small team, there are a lot of people who are the only one of their skillset on the team. People may long for more opportunities to interact with others of their skillset to learn or commiserate.
• On-call load is usually non-existent for these teams, but if there is, people will burn out from constantly being on-call.
• If the team experiences too much change, isn’t seeing progress, or doesn’t have a clear goal, people can feel like they are spinning their wheels but not getting anywhere.

“Minimum viable team”: 3 engineers, a PM, ½ to 1 designer

With 3 engineers, coordination becomes necessary, and so structures start getting formalized to avoid stepping on toes. The group starts feeling like a “team” with consistent processes and rituals, rather than just a group of individuals working towards a goal.

Structure:

• The team usually has a backlog and does lightweight “sprint planning” every week to assign tasks to engineers. With 3 people and week-long sprints, tasks are not typically given point estimates, and it’s easy to ensure that the team is taking on a “reasonable” amount of work.
• There are fewer day-to-day changes of direction; the direction & tasks decided on at the weekly sprint planning are usually followed through, but mid-sprint pivots do still happen.
• At this stage, if there’s no manager, the role of “Tech Lead” will likely be formalized to break down work into tasks, run sprint planning, and coordinate across engineers.
• The PM is still involved in each task that is done, but will create lightweight specs to help engineers estimate and break up work. Engineers may write tech specs for more complex projects.
• With a backlog and sprint planning in place, the team can start articulating goals for what they want to accomplish over the next few weeks, but is unlikely to commit to hard dates.
• The team can start setting goals on a month-to-month basis.

Challenges:

• With only 3 engineers, an illness or PTO will significantly impact the team’s velocity.
• It’s tough to introduce new processes to people who have gotten used to informal structures. The team will go from having almost no meetings to having 1-3 hours of meetings/week - while still very little overhead, the relative change can cause grumbling.
• The creation of a tech lead creates the first instance of hierarchy, which can cause strain.
• With a backlog in place and likely some sort of product out in the wild, there will be far more work to do than can be accomplished. The team has to start making hard tradeoffs on what to prioritize.
• The need to make tradeoffs and the creation of formal processes will push the team to make explicit the team mission and culture.The team will start getting pressure to set quarterly goals but will likely not have good visibility into where they’ll be 2 months out.
• After the initial product build-out, most of the work at this stage is incremental product improvements. Engineers can tire of shipping lots of small things, and may long for bigger, meatier projects.

“Projects”: 4-6 engineers, a PM, a designer, and an Eng Manager

As the team fills out, they’ll gain the ability to take on a bigger project alongside building small new features and capabilities. This is a bit of a hybrid stage, and will introduce new structures that will become more important as the team grows.

Structure:

• Sprint planning is now essential for coordinating the team’s work. There is too much scope to fit in any one person’s head, so tasks need to be broken down into manageable chunks and given rough estimates to ensure the right amount of work is allocated. Teams may shift to biweekly sprints.
• Knowledge sharing becomes important, as people will have different familiarity or tenure with different parts of the product. The team will start documenting common questions or pitfalls.
• In order to manage the work on bigger projects, the team will start needing more formal planning documents. At this stage, PMs are writing full product specs and launch plans, engineers are writing detailed technical specs, etc.
• With bigger projects and more things in flight, the need for project management grows. The PM may do this themselves, or may lean on tech leads so that the PM can focus more on other or spec’ing work. The PM will probably still have a hand in everything the team works on.
• The team can plan out their work for the next quarter at least, and can meaningfully set quarterly goals, but may struggle with having visibility for where they’ll be in a year.
• There is sufficient management overhead - people management, process management, and project management - that there is a full time engineering manager instead of or in addition to tech leads.

Challenges:

• For the first time, each member of the team won’t intimately understand what each other member is working on. The team may need to create “shepherds” for different parts of the code base to maintain consistency, or start doing end-of-week demos to share out progress.
• People can start specializing on one part of the product/code base, which is either something to lean into or explicitly work against by rotating people around.
• The team will need to build expertise in how to do project management, how to estimate complex tasks, and how to set long-term goals.
• With 4-5 people working in parallel on a bigger code base, it’s likely that people will accidentally collide or break something unexpectedly. Teams start seeking more infrastructure for automated testing.
• With more people on the team, there’s increased likelihood of problematic intra-group dynamics: two people not getting along, someone who’s underperforming, arguments over the team’s direction, culture, or right approach to a project, etc.
• With a bigger team and more variety of work, people may have less visibility into how their individual work ladders up to the team goals and mission. Team leaders will have to put in intentional work to remind people why their work matters.
• The creation of a full-time manager role on the team has a lot of potential pitfalls, particularly if the manager was promoted from within the team and is now managing their former peers.

“Pods”: 7-12 engineers, a PM, 1-2 designers, an Eng Manager

With more people, the team shifts from organizing around “tasks” to organizing around “projects,” bigger initiatives with a consistent team of people working on it for 4+ weeks. This significantly impacts the team’s structure and processes, as many of the old ways stop working and new challenges crop up.

Structure:

• The team assembles into “pods” of people who maintain long-term effort on a particular project. As projects complete, pods typically disband and people form new pods to take on the next project.
• Tech leads for each project take a major role in writing tech specs, breaking down projects into tasks, and project managing.
• The PM & Eng Manager are less involved in the prioritization of specific tasks, and instead focus more on how to prioritize and allocate resources across projects. Teams start making gantt charts and multi-quarter roadmaps.
• The PM or Eng Manager may get more involved on particularly critical projects, but mostly stay out of the details unless a pod gets stuck.
• Because the work revolves around independently-run projects, the team may get rid of sprint planning entirely, or use it to review the tasks for each individual project. Engineers on different pods may find it a waste of time.
• Each pod will likely have a weekly project status/check-in meeting to ensure things are progressing smoothly.
• The team starts having a backlog of projects - rather than tasks - with some specs ready to go once the current projects finish.
• At the larger end of the spectrum, the engineering capacity to work on projects exceeds the PMs ability to spec out meaningful work - “product leads” (designers, SCS people, associate PMs) are brought in to own & spec specific projects, supervised by the PM.

Challenges

• With multiple distinct pods, the team may start feeling increasingly disconnected from one another’s work.
• The PM and Eng Manager need good mechanisms for catching and addressing issues with projects as they arise, or projects will start going off the rails.
• The PM will no longer be able to be in the details for all the projects, and needs to figure out how to write effective specs and empower pods with the context they need to make good decisions.
• At the larger end, the PM will need to learn how to effectively delegate projects to APMs and supervise their work while still owning projects of their own.
• With a lot of work up in the air, things start “slipping through the cracks”. Upper management will ask for explanations on decisions or issues that the PM or Eng Manager wasn't directly involved in.
• The team has less agility to jump on new tasks or projects as they come up. The team will need to make explicit space between or around projects to slot in quick wins, polish, and tech debt.
• If multiple projects all kick off at the same time, it can overwhelm a PM who doesn’t have time to research & spec them all at the same time. Ideally, the PM has staggered projects so that there is always one launching, one kicking off, and a few in-flight. This is particularly common at the start of a quarter or year.
• With more engineering capacity, the PM end up trying to “feed the beast” rather than focusing on how to provide the most value. This is also the stage where teams can start feeling like “feature factories”.
• Engineers can get tired of big project work and miss the variety and rapid velocity that comes with shipping a lot of small things.
• Oncall load & tech debt can slowly creep up until it’s consuming a significant percent of the team’s overall capacity.

“Team of Teams” - 12+ engineers, 2+ PMs, 2+ designers

At a certain point, the team splits into 2+ smaller teams. To start, they may roll up into a “Group PM” that manages a few PMs and is also directly PMing a team themselves. At this point, the process resets, and teams go back to a different point on the ladder.

This brings with it a whole host of new challenges in how to organize teams-of-teams, which is a topic for future posts.

Team size matters a lot! I hope this post helps others stay ahead of challenges and identify strategies for dealing with changing team size.