How (and Why) Postman Engineering Uses Foundation Teams

In today’s internet age in which companies reach audiences with incredible ease, the ability to move even faster gives an edge. Organizational structure is one of the many levers that can be used to attain the speed that we all crave, and so it plays a critical role in a company’s success.

In a previous blog post, we gave a sneak-peek into Postman’s data team structure. Now, we’ll walk through a journey of Postman’s product and engineering org structure with a major focus on one of the core tenets of this structure: foundation teams. As mentioned in the above-mentioned blog post, the data team is one of our foundation teams. Let’s take a look at Postman’s engineering org structure and its use of foundation teams: why these teams exist and how we are envisioning their future.

Finding inspiration for a Squad model

Looking at Amazon’s two-pizza rule, we can see the power of establishing an org structure built on small teams, which was a principle that successfully led to the creation of AWS (Amazon Web Services). Postman follows a similar model called Squads. Just like Spotify’s own Squad model, we leverage a user-oriented team with distributed decision-making.

The immediate question arises: which squads should I create for my organization? At Postman, we create a domain-driven boundary per squad using the very popular (and very complex) principles of domain-driven design.

Even though individual squads are supposedly independent of each other, they still have a system-level dependency because their systems/microservices call each other for information exchange.

If you’d like to learn more about our journey establishing squads, check out what Postman Co-founder and CTO Ankit Sobti shares in this video.

Where do foundation teams come in?

Here is an interesting thought: do you know how many decisions Postman would need to make if web frameworks did not exist?

The number of decisions any organization has to make—about everything from scripting to software design—can be overwhelming each time it wants to build something. It can be a nightmare.

This means there is a need to centralize decisions to enable squads to do what they do best, which is ultimately to build something that is helpful and easily adoptable for users.

The underlying problem is that when building an org structure, going for either extremes—entirely decentralized (squads-centric) or entirely centralized (central-governance-centric)—does not work. In addition to the above example, you can refer to the previous article about the two-pizza rule to see certain downsides, including (but not limited to) increased stress because of too many responsibilities, dependency on key individuals due to lack of shared knowledge, inconsistency in decision-making, and more.

Enter foundation teams, which come into the picture to create a balance between the extremities of centralized versus decentralized. In a nutshell, foundation teams enable squads by providing anything from tooling to governance.

Designing a foundation team

Now that we’ve gone over the idea of a centralized foundation team, let’s see what mental models we can leverage.

A service-based approach, in which every incoming request gets queued and executed with a service-level agreement (SLA), seems logical. Taking an example of an infrastructure team, the following types of incoming requests can be accommodated with this approach:

• Database administration work
• Infrastructure changes
• Access control management
• Tooling for development, packaging, testing, etc.

While the approach seems like an easy answer, a few challenges can come up, including when scaling the team (i.e., when scaling, more requests lead to more hiring, more training, and more overhead). We’ve discussed other downsides of this approach in our previous blog post about the Postman data team’s hub-and-spoke model.

We found a solution. Why not build a product for these dependent activities?

Postman’s infrastructure journey

While the foundation-as-a-product approach is logical and helpful, it can be challenging to implement. We have been facing the challenge to make it a reality, and though the setup that we have today is nowhere near close to what we aspire to be, it is a work in progress that we are excitedly building upon.

For example, the team owning infrastructure and reliability currently uses a Jira project as an interface to meet consumers’ needs. This Jira project is bound by certain SLAs that power up our manual-process-performance metrics, giving us signals to avoid breaching the SLAs. It is quite similar to how we drive focused hiring via data.

Even though the current setup has helped us get to where we are today, we have strong apprehensions about using it in the future.

Why not envision infrastructure as a product?

Considering the scale of Postman’s infrastructure needs, we can only cater to generics, not specifics. The interesting thing is that the generic use cases account for more than 80% of our consumer base. Hence, this model will work for a majority of our use cases.

For the remaining 20%, we are planning to keep the existing interface open, and the biggest challenge will be to move this 20% to a generic-use cases bucket as well. Just like any other product, this will be an ongoing challenge.

Investing in technical infrastructure is a hot topic in the industry. It’s just a matter of time until certain organizations’ internal thought processes around infrastructure become future products.

Do we really need foundation teams?

When all is said and done, foundation teams don’t look entirely different from our typical user-facing squads. If you take a closer look, both a squad and a foundation team have to do the following:

• Provide value to their users by building a product(s)
• Cater to their dependencies within the organization

The latter point is not generally understood because squads are considered to be independent units. So why do they need to cater to their organizational dependencies at all? It’s simple: the boundaries are created to cater to user domains (like payments, shipping, etc.) but these domains are connected internally, especially at a system level. For squads, those dependencies could be APIs (application programming interfaces) that they need to maintain and improve upon for other squads. Ultimately, a foundation team is another team that interfaces with other internal squads of the organization.

Did you find this blog post interesting? If so, you might also be interested in working at Postman. Learn about joining the Postman team here.