Better Practices
Published in

Better Practices

The Postman Data Team’s Hub-and-Spoke Model

Designing a team structure for scalability, efficiency, innovation, and communication

The structure of a team is crucial to its success. Structure helps us determine the various communication patterns that enable a team to contribute to the organization’s overall growth. In this blog post, we’re going to talk about the structure of Postman’s data team, which includes our data engineers and data analysts.

Before going ahead, let’s look at the two team types we have at Postman:

  • Type 1: A team that builds a user-facing product or feature
  • Type 2: A team that works behind the scenes and helps Type 1 teams reach their goals

At Postman, we call Type 2 teams “foundation teams.” Foundation teams are the heart and soul of Postman; they help cater to the overall organization by building easy-to-use and highly effective platforms and internal products. Hence, the communication mechanisms (powered by the structure) of the foundation teams have a huge impact on the value that those teams can add to the organization.

The data team is one of these foundation teams, and we’ve adopted some specific approaches to help us achieve our goals.

The Hub-and-Spoke Model

While doing research to help us choose the most potentially effective team structure, we came across the hub-and-spoke model. This model dates back to the 1950s and was often used in the transportation industry as a way to distribute goods across various consumers. (You can read more about the history of the hub-and-spoke model here.)

Relating the underlying mechanism with our own use case, we discovered that we actually have a similar problem statement. Namely, much in the way that the transportation industry needs to get passengers outward to many destinations from a central hub, we have data-infused knowledge that we would like to share more broadly — and we need a channel or mechanism to disseminate that knowledge outward to the rest of the organization.

The above realization was a breakthrough for us. In addition to this, we imposed a few constraints on the structure as a measure of system design (more on this in the next section) which helped us build something really effective that we’re excited to share.

Designing the team structure

To design our team structure, we started the way we start most projects: with a problem statement.

Problem statement

We need to create a brand-new structure for the data team that enables superior scalability, efficiency, innovation, and communication.

Constraints

Once we had our problem statement, we looked at some of the constraints we faced.

The structure of Postman’s data team should be built on the following foundations:

  • The data team should enable the organization to make decisions. (We consciously took this direction so that the data team doesn’t become a service-oriented team. More on this later.)
  • The data team should scale sub-linearly with the organization. (By this, we mean that if the company grows to, say, 10x its original size, the data team shouldn’t need to grow 10x, too.)

Why should the data team scale sub-linearly? Taking an excerpt from the book Scale, we can think of the data team as a kind of gas station that fuels success. Let’s see how the number of gas stations can scale:

“Infrastructural measures, such as numbers of gas stations and lengths of roads and electrical cables, all scale sub-linearly with city population size, manifesting economies of scale with a common exponent around 0.85.”
— Scale, by Geoffrey West

Since Postman is split into multiple teams (across domains such as business, sales, engineering, etc.), the data team’s structure should be able to incorporate every domain’s problem statements and help them get the answers without growing to an unwieldy and inefficient size.

Our Solution

Given the above constraints, we built the first iteration of our solution, which is summarized in the following three team types:

  • Central: A central team caters to the larger audience and solves analytical problems with limited context. At the same time, this team understands the pain points and builds products/platforms to make decision making self-served.
  • Embedded: An embedded team gets activated when we need to deep-dive into an analytical problem.
  • Distributed: A distributed team is fine-tuned within a contextual boundary of a domain and only caters to that domain.
How central, embedded, and distributed teams within the data team interact

In short, the central team is a “hub,” and the embedded and distributed teams are the “spokes.” This is our hub-and-spoke model.

Benefits of the hub-and-spoke model

With this model, we can now tackle problem statements at scale. As the above diagram depicts, every problem statement (e.g., “Team X has an Analytical Question”) is treated as an experiment where we can build a platform/product as an outcome. However, not every solution can be self-served in this way, hence we also continuously build a knowledge repository over time so that the net-new effort required to work on a problem statement decreases over time.

In cases where we do get to build products — like a recent product that we built for forecasting (for any time-series graph) — we ensure that the usage of that product becomes streamlined over time.

Product/Platform Mindset

Building each product/platform is not just an executional activity based on the hub-and-spoke model; we believe this activity also requires a certain mindset in addition to the model. The Postman data team made a conscious choice to use Objectives & Key Results (OKRs) as a way to standardize that mindset and measure product metrics over time, including tracking our acquired, active, and retained users across every feature that we provide. This product/platform mindset, as embodied by OKRs, along with the power of the hub-and-spoke model, ensures that the data team is moving in the right direction as we continue to democratize data for the entire Postman organization.

What has helped you successfully work with team members to exchange data across your organization? Let us know in a comment below.

--

--

--

For individual engineers to the largest teams, Better Practices is intended to distill knowledge from the Postman community. This is a place to learn about modern software practices together! Read more: https://medium.com/better-practices/introducing-better-practices-e9cf14cf0c88

Recommended from Medium

How to write a results section

Neural Network Feature Importance with fastai

LIME vs. SHAP

Instant Gratification — What if Problems Could be Identified and Solved Immediately?

Adjusted R Squared

The Adjusted R² formula

Rising or Falling? Leveraging Bivariate Glyphs to Visualize Trend Changes

Meeting… Sarah Duncan, Lead Data Engineer at The New York Times

PySpark Cheat Sheet: Big Data Analytics

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Shubham Bhargav

Shubham Bhargav

Dabbler in product, data and organization design. #learning-together

More from Medium

Performance measuring tools

Replicator Service — Copying data from Mongo to BigQuery

Applying the Micro Batching Pattern to Data Transfer

How to build your own CircleCI orb for continuous integration pipelines