Update:
Curious on how to do feedback sessions between you and your engineering team? Click here for the FREE downloadable Notion template!
Part 1: The necessary teammate archetype
💡 “What’s the best engineering team structure to facilitate moving fast while building?”
Before we discuss structure, first, think people.
In my opinion, the structure of the team matters significantly less than the people who make up the team.
The most important factor is that every person on the team should be someone who takes extreme ownership and moves autonomously. With this setup, it matters less if you’re ultra-flat with no titles (like Spotify was in the early days), or more hierarchical.
What does extreme ownership and moving autonomously mean? Extreme ownership means you:
- Know what your responsibilities in a project are. Whether you own the project overall, or you contribute to a larger project, you always have some portion where you are the directly responsible individual. Managers should make clear what each person’s responsibilities are, so there’s never any confusion or politicking for projects that are shinier/look more appealing.
- Spread celebrations around and take criticism directly on yourself. If your actions led you to a win, you had others who contributed to the success. Give that credit where it is due and openly praise those who helped you. If your actions led you to a loss, avoid spreading blame. Instead, focus on the parts where you had shortcomings, and sunshine your mistakes. Below is an excerpt from CEO of Netflix Reed Hastings’ No Rules Rules to explain more about sunshining:
“When you sunshine your failed bets, everyone wins. You win because people learn they can trust you to tell the truth and to take responsibility for your actions. The team wins because it learns from the lessons that came out of the project. And the company wins because everyone sees clearly that failed bets are an inherent part of an innovative success wheel.”
Similarly, moving autonomously means:
- Acting as the owner of your responsibilities. My friend Jeff said, “Whoever said curiosity killed the cat set society back a notch. Get curious!” In other words, don’t wait for someone to tell you what to do. Instead, problem-solve what needs to be done and declare it to the immediate team you’re working with. If you’re working on a one-person project, note down your steps in your weekly update to the larger team. This bias towards action is what causes people to move fast and build stuff. Without it, if there’s a ton of red tape to cut through, it doesn’t matter if the org is flat or hierarchical; everyone will ship slowly because they are afraid of moving without permission. Be wary that you are not creating red tape for yourself - think outside of the box. If you’re asked to screw something in and there’s no hole— well, drill a hole! See how you can problem solve on your own.
With this archetype of a person, you will be able to move quickly and build stuff. Without this type of person, there is no setup or structure that will cause your team to build fast.
(And of course, it’s worth mentioning that as a manager, you are also expected to follow these traits, not just your direct teammates!)
Part 2: Ideal team structures
Now, let's talk structure.
Structures I’ve seen will vary depending on size and stage of a company. See below for more information.
💡 Note: below, I’ve listed examples of smaller engineering orgs (<20 people) and larger engineering orgs (100+ people). Assume that mid-sized orgs fall somewhere in between both practices. Because this isn’t rocket science, you might disagree with some of the examples - that is okay. Again, it matters less how things are structured, and what matters more is the company culture as a whole, as noted above.
Smaller engineering orgs (<20 people)
🚢 Shipping: Handled individually.
- Each person is responsible for their own project and works independently, or in pairs if it’s a bigger feature.
- If a feature or project is more fully fledged, there should be a clear roadmap on what has to be built, in what order, and by when.
- This makes shipping a large product with a team of 1-2 much more efficient, versus shipping a project with 3+ people (where there is suddenly added lag time to coordinate efforts, divvy up responsibilities, and added meetings to the calendar to sync and stay on the same page.)
- Also, this limits the need for daily standups that take up synchronous time. Because there are only teams of 1-2, there is likely no need for 15-minute standups that cut into deep work time.
🪲 Bugs and tech debt: Handled individually.
- There is no real reason for engineers to have to bug bash all at the same time, nor should there be a reason for engineers to only bug bash features they themselves worked on. In the ideal setup, all of your engineers are good at their jobs to fix any bug or make any improvement in the codebase.
- Of course, if the engineer who worked on the feature happens to be available to fix their own work, that’s more ideal. My point here is that engineers should be willing to fix any bug they encounter and shouldn’t have ego tied up in their work.
👀 Pull request reviews: Handled collaboratively with the whole engineering org.
Use PR review time collaboratively to help your engineers level up by:
- Giving and receiving feedback on their code
- Learning about general changes made to your repository
- Adding an extra pair of eyes to the code to make sure the code won’t break anything obvious
- Using this time to check the code for bugs and issues (e.g.: end-to-end testing, unit testing, code formatting, etc.)
Larger engineering orgs (100+ people)
🚢 Shipping: Handle collaboratively.
- Larger orgs typically organize in teams of 4-8 engineers help to ship large features together, by a given deadline.
- Product Managers and Engineering Managers are there to oversee these engineering teams; usually one manager per 1-2 engineering teams. They should be responsible for communicating the timeline, what needs to be built, and collaborate with engineers to make sure everyone knows what their responsibilities are.
🪲 Bugs and tech debt: Outsourced.
Majority of bug fixing and tech debt is outsourced at this stage. Save your best engineers for feature building.
- Infrastructure tech debt can be handled by another team
- Bugs can either be handled by the team or a QA org
👀 Pull request reviews: Handled by the closest team responsible.
- Either the immediate team does PR reviews, or…
- Have another team review if you were collaborating/contributing to someone else’s app, feature, or service.
Applicable to all orgs regardless of size
In general, if you can limit recurring syncs in order to spare deep work time, your engineers will thank you profusely.
All syncs should happen ideally on the same day, so engineers can have the rest of their week to go into deep work mode (this includes scheduling 1-1s and All Hands on the same day too, if possible.)
See below for a list of syncs that should take place on the same day, and how to use them efficiently. For more on how to run the syncs well, read: Run efficient meetings that don’t suck
- Engineering syncs (30 min): larger dev-related issues that are feature-agnostic can be discussed during this time. Additionally, if someone is blocked on a feature they’re working on and want to mastermind it with other engineers, they can surface the issue during this time.
- Eng-Product-Design (EPD) syncs (50 min): this time is used as a cross-functional collaboration effort. This time should be mainly used for PMs to communicate what the product roadmap/feature prioritization is and why, Designers and Engineers to surface any issues that pertain to the larger EPD org, and to come to a collective agreement on any actions that have to be taken
🚫 Incident management: this isn’t a sync, but once a product is developed enough, there should be an incident management system put in place to avoid outages. Use a system like PagerDuty to manage the rotational schedule amongst your engineers so that it can be done in a collaborative spirit.
- For smaller teams, incident management is usually done on a rotational basis.
- For larger teams, there is usually a dedicated team for incident management.
Part 3: More thoughts from technical friends
Because it didn’t feel right for me to write this post without consulting with my closest engineering friends, here are some further thoughts that don’t fit neatly anywhere above:
From Case Sandberg (companyOS)
Regarding bugs and tech debt:
I think the best thing to do is to have a dedicated QA Engineer. Senior and staff level engineers are able to go 50% faster at shipping features if they don’t have to worry about writing tests. Bugs coming in could get a test case written by a QA engineer, and there is still confidence that any fix by an engineer solves the problem.
From Lucas Gerbeaux (Carbon)
I agree that the individuals themselves and the traits you look for when building an eng team are arguably more important than the structure itself. (It follows the concept of talent density.)
How do you figure out what kind of team you want to build? I would approach it this way:
1. Define the kind of working style you want your team to have, based on your company’s operating style and size. Depending on whether you desire more reporting or less, that will change the kind of team that thrives under your supervision.
- For example, if you want highly-productive managers of one that own a large portion of work and can deliver autonomously, don’t hinder them by blocking their work behind endless design committees and sync meetings. Hire people who fit this archetype.
- On the other hand, if you want a highly distributed org where no one person is the single point of failure and everyone has general knowledge about everything going on in the company, then it’s much more important to distribute crucial information to your team as it is getting designed and implemented - even if it costs you speed and efficiency. Look for people who have experience working this way when hiring.
2. Regarding the structure itself, I think this is more appropriately determined on a case-by-case basis depending on the needs of your company. The best thing you can do is follow the advice above regarding grouping and limiting meetings, specifying every meeting’s desired outcome, and leaving with action items + a clear understanding of what was done and why it was effective. I’d also avoid doing things for the sake of doing them: for example, don’t run SCRUM for the sake of calling your team agile; take what makes sense for you and your team.
From Xinran Xiao (AngelList)
I don't think there's "one reason" that contributes overwhelming to our ability to ship quickly, but rather a combination of things that happen to work well together:
- Hiring. We hire fast (take risks), but also fire fast when things are not working well. Maintaining an extremely high talent density is a pre-requisite for anything else.
- Small teams with high ownership (and stakes). If you have ambitious people, you have to give them extremely ambitious goals that stretch them. We still have 1-2 people max working on any particular feature or product at a time. Dharmesh has a nice sound-bite about this: https://youtube.com/watch?v=MiIUSARRmHg…
- Culture. Can't hack this one, and it starts from the top.
Below are some notes I wrote a while back on our operating principles. The manager ones are directly influenced from this great blog post by Daniel: https://dcgross.com/the-human-performance-lab
Special thanks go to Lucas Gerbeaux (Carbon), Case Sandberg (companyOS), Xianran Xiao (AngelList), and Jeff Bargmann for contributing their thoughts and software engineering POVs to this write-up. I am grateful for your wisdom and knowledge! Also, thank you Sydney Liu (Commaful) for encouraging me to do the research and write this up. I appreciate you always!
Update:
Curious on how to do feedback sessions between you and your engineering team? Click here for the FREE downloadable Notion template!
