Startup Team Design

1. Introduction

I have always been interested in building and designing teams that achieve ambitious outcomes. And I truly believe that small teams can achieve big outcomes. I have also been a fan of Jeff Bezos’ two-pizza teams concept. But this wasn’t enough to help me understand how to organise product development teams without creating many problems that come with small teams. As Razorpay grew, I have experimented with different ways of setting up teams. Over time, with these experiments, I have distilled a framework on how to organise product development teams that can work in a decentralised, autonomous, bottom-up manner of execution without significant management overhead and yet are best positioned to make significant progress towards achieving ambitious goals.

2. Razorpay’s History

Razorpay like any growing startup has been constantly evolving. In the very early days, the teams were organised along functional lines. We had teams called backend, frontend, infra, etc. And in fact this design worked well till we were 30 people. That was the first time that our backend team itself was large enough to not sustain as one team. Hence we divided the function further into different backend teams with awesome sounding names - Gladiator and Transformer. Gladiator was responsible for the core payments and Transformer was responsible for leading the effort on Payments No Code apps. In a way, they did succeed in their objective of that time. In 2018, we restructured again. This time, we delineated the lifecycle of payments and different products that the company was building towards. We designed the team along the lines of prepayments, post-payments, merchant-experience, payments apps, etc. This was in reality a more thought through exercise. And even today, few teams may exist with the same names and charter as we created back then. Since then, we have gone through multiple restructuring exercises where we created new pods and deprecated old ones. These changes are far reaching and have implications not just from the end customer perspective but also have impact on the organization of technical infrastructure.

Everytime we have been through these exercises, there is a lot of learning and lessons. We have accumulated rich data points on what has worked and what hasn’t. We have evolved our philosophy in this process and distilled out a set of best practices on what works best for the product development teams. This essay lists out the lessons and philosophies of POD design at Razorpay which are generally applicable to any software development team in a high growth startup. It should serve as a template for any manager or leader who is considering org redesign. And make no mistake, change is inevitable. Anything affecting people should be thought through. This is not the place to experiment and do breaking changes frequently. or to tweak the design every month. However, be assured that in a high growth startup, you will see team structure changes at frequent pace throughout the org and within the same teams almost every year. This is especially true in the phase where the org is growing fast.

3. Goal

The goal of putting people in a team or a squad or a pod is to accomplish big hairy audacious goal than what would be possible for an individual working alone or even the simple sum of several individuals’ working independently. Teams can, but do not always, provide improved performance. The aim and purpose of a team is to perform, get results, and achieve victory in the workplace. The best leaders are those who can put together a group of individuals and mould them into an effective, ambitious and a high-output team.

4. Why is Team Design Important

Team Design is a subset of Org Design. The latter is a larger topic and out of scope of current discussion. A team can be designed in various ways. However, the design we seek is singularly important because we want it to help in achieving the org’s objectives. How we design our teams and people materially affect how efficient we are in achieving the objectives of the organization. Org design is a powerful Lever and should be used to the extent of maximum efficiency. A bad design will lead to losing a lot of time and causing many issues around cross team collaboration. While org design looks at the macro picture, team design is looking at the micro.

A collection of people is a group. But it’s not necessarily a team. A team is a group of individuals, where the whole is greater than the sum of individuals. A team has much more cohesion and synergy in working together to achieve mutual goals.

A product development team can be set up in multiple ways. After trying many things, we zeroed down in most cases to set up product oriented delivery teams aka POD. For the rest of this essay, we will focus on the POD oriented team set up.

5. What is a POD?

A Pod is a group of highly skilled individuals focused on a singular north star. It’s usually set up intentionally by the leadership. A pod has the majority of the ingredients within itself to achieve the aforementioned north star. A POD can be short-lived or long lived. However, it has to have a substantial time period to go through the whole lifecycle of moving towards the goal. If you are going for a pod creation, then it will be at the very least for 6 months. Anything lesser is instead creating a short-term goal-focused SWAT team rather than a POD. A pod must operate autonomously and independently for the most part with clear ownership of a specific domain. A pod exists to achieve its north star and most of the product delivery is towards reaching this goal.

That’s a big definition. Let’s break it down into finer points and go through each piece in detail.

5.1. Aspirational North Star

The most important factor to keep in mind when designing a pod is that it should have one true North Star. It’s the cornerstone on top of which the whole POD is built. Not only should the POD have a north star, it should also be very simple to understand, well articulated and aspirational. This is the mission and vision of a POD, something they intend to achieve during its lifetime. Most teams fail because they don’t have a mission.

5.1.1. What’s a North Star?

For any pod or team, a north star is having a defined and clear mission and vision towards helping the customer. There is nothing like having a long term goal driven purpose to highly motivate the team and keep them going through the ups and downs. It’s better if the purpose is number driven but not fully necessary. For example, consider this north star - Build a world class refund experience for customers. Building a world class refund experience cannot always be driven numerically. In these kinds of cases, we will look at a few input metrics that we are looking to move heavily to influence the north star. For this example, those metrics could be “time to refund”, “refund success rate”, “number of attempts to refund”, etc. However, very often there can be mission statements which can very easily be quantified. Like, having the best sign-up experience to drive sign-upwards - sign-up conversion is going to be the key metric here. Anyone can come up with the north star, the team should agree to it together and should get behind it.

5.1.2. Faulty Cornerstones

Many teams make the mistake of creating a pod based on either technological or skill factors. But those things are really secondary. A group of front-end engineers is not a pod but a function helping with frontend aspects of any product. Similarly, organising a pod around logical technical system components also is short sighted. Because technology will evolve with time. And your end goal is to optimise for a customer problem and not really just build cool technology. People will end up doing endless technological iterations without creating real world customer impact. In cases of platform teams, often they end up becoming a service team instead of a product team.

Why do many managers make the mistake of having a pod around technological domain? Simply because that is logical and easier to understand especially from a technology perspective. And defining a goal based pod is more uncomfortable due to unknown factors or areas over which you don’t have expertise. It holds managers accountable and makes things more objective. But it also gives a feeling of unease and gets people scared.

5.1.3. Is North Star Really A Better Idea?

Why is a north star based pod a better idea? Because, over quarters or years, technology can change, skills required can change, what you know may also change significantly but the north star remains the same because it’s hard to fully crack and can easily take a year or few to solve for. Based on the north star, the pod will work autonomously to come up with projects, ideas and experiments every sprint/month/quarter and also measure the results of every such activity. Sometimes these experiments will succeed in impacting the north star and sometimes it won’t. However, it’s easier for a pod to re-align and re-prioritise based on the results. There is also a decent amount of pressure on the pod to show quarter over quarter results if the company works on a quarterly cadence. Quarter is a good enough time in most scenarios to plan and execute projects and then measure results.

5.2. Autonomy

Having a right north star is of course not enough. Another key quality of a high performing team is having the right amount of autonomy. If you hire high quality and high agency people then you do not want to micromanage them. Having the autonomy to execute things on a day to day basis is absolutely essential. Before the quarter starts, the pod leader should lay out the quarterly OKRs which must be aspirational and the associated set of projects to be done. While the OKRs should be slightly research backed and logical, the project list can be fluid. And it’s on the pod on how they go about prioritisation of the projects. The list of tasks can change across the quarter as more information comes in. The manager of the pod leads should review the OKRs and sign off on those but they should not force the pod to do something which they themselves do not align well to.

5.3. Domain Ownership

With the right north star in place, the POD should always have an area of Domain carved out for itself. This area is where the team will build expertise over time. And the group of people will build and accumulate more knowledge in this area than anyone else in the company. The ownership is not limited to technical knowhow or product understanding. The pod must strive to understand how it impacts the end customer and the levers that will help in inching towards the north star over time. To give a few examples, if Refund Experience is your north star, then you will need to own the R&D of the Refunds domain to move towards this goal. You may need to collaborate with the Operations team or Banking team or talk to customers (both businesses and end consumers) to build expertise. Another possibility could be that Cross-Sell is your north star. Now it’s possible that it’s too large a goal to carry for one pod in a large organisation. However, a relevant domain that a pod can own is the cross-sell infrastructure and intelligence that other teams can leverage.

5.4. Independence

The pods should have clear ownership and execution independence over their domain. One of the ways having a clear north star and domain ownership manifests is in having the independence to execute projects across a patchwork of technical/product areas which may or may not be clearly defined or owned. This is a tricky concept to explain but let me make an attempt. There is definitely a clear area of operation which the POD will manage from a day-to-day perspective. However, over time, towards the achievement of their goals, there will be projects or areas where they will be dependent or reliant on the other teams to do some work. Ideally this is not a problem. If a pod is dependent on some other team or pod, then during goal setting exercises, they can ensure that the other pod also has that particular task or project as one of their quarterly goals or deliverables. But in case that’s not feasible due to any reason, then they should have the independence to go ahead and execute a project outside of their domain in service of achieving their own goals.

5.5. Size - Two Pizza Team

If you have been around in the startup world long enough, then you would have heard of the Two Pizza Team philosophy of Jeff Bezos that has been a key driver for success in Amazon. No matter how large the organization gets, individual teams shouldn’t be larger than what two pizzas can feed. There has been a lot of rationalisation and discussion on this in the internet which is worth reading. A good starting point - http://blog.idonethis.com/two-pizza-team/. Gist of it is that the ideal pod size should be between 5 to 10. Anything beyond 10 and you will start running into communication issues. For example, a stand-up will stretch beyond half an hour if you have 15 people!

The intent of the pod is that each person has context on what others are working in the pod. People are able to build good expertise and ownership of the area the pod is working on. This results in rapid execution towards the north star. A person can keep track of the work of 5-7 people but the threads will break beyond that.

Note that Pod is at the node or leaf level in the org structure. Anything larger is no longer a pod. It can be a group/business-unit/org or anything else but definitely not a pod. If you see a pod becoming larger, then it’s ideal to split it into two instead of bloating it and reducing efficiency.

The ideal mix of skill sets is not something that can be defined here and depends a lot on the context. Some pods can be completely backend engineers while others may have a combination of front-end, design and testing. It also depends a lot on the domain and goal of the organization.

A pod also should have a minimum size such that it can operate fairly well without burning out folks. 1 person leaving the team or going on holiday must not necessarily cause the execution to suffer or the OKRs to be re-adjusted.

Sidenote: In Razorpay context, collection of Pods is a Group and Collection of Groups is a Business Unit.

5.6. Performance Management

There are different philosophies around this. Companies like Google take OKRs to the team and individuals but do not tie performance to it. On the other hand, Amazon and others have heavy dependence on the team’s goals during appraisal. At Razorpay, the Engineering and Product lead performance management is partially tied to POD’s impact in a direct consequential manner. There are some who may worry that this will cause the leaders to sandbag their OKRs and become more conservative. But goals usually flow top down and it’s a leader’s job to motivate the team to instil the importance of taking aspirational and stretch goals for a team. This is easy to do in a high growth environment. The key takeaway point is that the impact a POD creates should be linkedin in a structural fashion to the POD’s performance review for them to be successful.This is because it causes brutal prioritisation of projects and tasks which help move the needle on these goals and you would cut down on projects which are good to have but don’t yield results. It also forces leaders to understand and measure the impact of their projects regularly.But performance management should be empathetic, taking the context of the impact delivered or the lack of it into account rather than being pure numbers based.

6. When to start a POD?

Certain conditions that call for starting a POD are - You have a new and important goal which isn’t being tackled today A POD is becoming too large and unwieldy and hence should be split

While any lead or manager can write and put forth a proposal to start a pod, it must require senior leadership approval. Having a pod means investing time, money and bandwidth towards a goal which is worthwhile and relevant to the org. Decision making of commissioning a pod in that sense should be fully centralised to the leadership. And to make that happen, you should at bare minimum have a document covering the vision and mission (north-star) of the pod, with an initial idea of the skills needed. If you can talk about initial few projects that can sustain the pod for next 1-2 quarters then it’s a bonus but the roadmap may not be clear for new products or areas where heavy research is needed first.

7. POD Hierarchy ==> Org Design

All the above characteristics of a pod are important to be kept in mind and have to be thought about when designing the PODs. However, in a large software development group (say 100 people), there are various ways PODs can be put together. Organising a group of 100 people into different PODs will need a separate discussion.

8. POD Design Template

To get you started quickly, here is a sample template that you can reference and use - Template Link.

It’s good to periodically review currently running pods and their status and staffing. This helps us review the execution health of different pods periodically though it doesn’t talk about their impact status. You can grab a copy here.

In this, you will notice columns for vision doc link and okr doc link. Having a clearly laid out Vision statement and OKRs goes a long way in solidifying the pod’s charter and creating a sense of implicit purpose. The status and staffing columns talk about the up-to-date state of currently running pods.

In the end, having a simple way of creating small teams that can make significant impact repeatedly, predictably and scalably can help the startup scale its execution 10x to 100x through its hyper growth journey.