

In a nutshell, foundation teams enable squads by providing anything from tooling to governance. 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.Įnter foundation teams, which come into the picture to create a balance between the extremities of centralized versus decentralized. 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. 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.
#Postman teams pricing software#
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. Here is an interesting thought: do you know how many decisions Postman would need to make if web frameworks did not exist? 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.

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.Įven 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. Just like Spotify’s own Squad model, we leverage a user-oriented team with distributed decision-making.

Postman follows a similar model called Squads. 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). 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. As mentioned in the above-mentioned blog post, the data team is one of our foundation teams. 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. In a previous blog post, we gave a sneak-peek into Postman’s data team structure. 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 today’s internet age in which companies reach audiences with incredible ease, the ability to move even faster gives an edge.
