This post is my attempt to put together an org design for the engineering team at Quizizz.

Decentralization and autonomy are central to my proposal, maybe crypto is real. Just saying 🙂

Let’s go!

Ask any growth stage startup founder about their biggest worries as their organizations grow, more often than not it is the fear of losing the culture of:

Speed of execution, rather velocity

Staying close to customers

I strongly believe that high velocity and customer-obsessed teams have the following characteristics:

Maximum autonomy

Self-sufficiency

As few decision-makers as possible

Unlike your technical architecture, don’t design organizations for the long term. Organizations should be designed to win today, and increase the team’s capacity to win tomorrow, not next week. Good organizations evolve and are willing to adapt to get to the destination. Evolution is a sign of success.

First off, there are trade-offs → Speed vs Coordination. It is possible to carefully coordinate product development across the organization without compromising on speed. This is a typical fully connected startup in the early stages of its incarnation (<20 people). The communication overhead is generally O(n2) and sustainable in the early stages. As the team grows, the energy spent to bring people together to innovate is too high and comes at the cost of speed. In light of this, the goal is to optimize for speed at the cost of some coordination, and create self-sufficient autonomous and high-ownership teams.

The proposal is to create 2 types of teams:

• Product
• Platform
  

What is a Product Team?

Product teams are x-functional teams that are long-lived with a mission. This team can have any combination of mobile engineers, backend engineers, product managers, designers, data scientists, QA, and Ops. This team can execute on whatever is required to make progress without having to ask another team for permission or help. The team is largely autonomous, without being blocked on any other team. This team can be led by any functional team member, more often than not it ends up being a product manager or an engineer.

Sounds great, but…

Will this create situations where teams are hacking away on architecture that may not be ready?

Will this create duplication of work by multiple teams?

The first one is counterintuitive. Multiple teams hacking on the same service may start off as hacks, but will soon push for modularization and strengthening of systems/services. Duplicity is usually caused due to silos. As the team grows, rituals can be put in place to break silos (demos, tech talks, launch announcements, blogs, etc.,). Remember, it is about trade-offs.

What is a Platform Team?

Products are built on top of platforms. Platform teams build foundations and provide building blocks on top of which product teams build user facing offerings. The key difference is that a product team is focused on a business mission whereas a platform team is focused on technical mission (scale, performance, reliability, adding capabilities that serve more than one team. Most platform teams are 100% engineers.

Aren’t product teams going to be blocked on platform teams?

No, they are not. Rather, the setup is a form of Open Source model, where any engineer can directly work on the platforms with the right checks and balances. If the Platform team is able to work on the platform, that is preferable. The goal is for the Product team to not be blocked on the Platform team.

What about functional teams?

Functional teams (Eng, Product, Design) are still intact. Everyone should think of themselves as being part of 2 teams. The Product / Platform team is where the day-day activities happen. Functional teams are important for best practices and consistency. Take designers for example, they can be sprinkled in different teams and can lead to fragmented designs. Designers come together in their functional teams to review, challenge and learn from each other. A manager continues to have functional teams reporting to them.

What about team size and composition?

Each team should be responsible for a product or platform and should be expected to have a couple of work streams at the same time. An ideal span for a first-line engineering leader is 7–8 engineers. This gives her sufficient time to be in touch with technology, have context about every person on the team, and focus on their career growth. Each team has a couple of senior engineers (not level) and 5–6 junior to mid-level engineers. This creates a healthy balance where engineers can learn and teach each other. The next layer should ideally have 4–6 teams under the same umbrella in related areas. The goal is to minimize cross-group collaboration and have a reasonably short path for escalations.

Conclusion

Sizing and organizing an engineering team, any team for that matter needs a structured and deliberate approach. There is no one size fits all. Context is everything. Bias for action and willingness to evolve is key.

That’s it.

PS: I’ve traded off the length of this article to be comprehensive and left a few questions unanswered. My goal was to seed the proposal and have a healthy discussion around it.