How Postman’s data team set up better onboarding, infrastructure, and processes while growing 4–5x in one year
Postman is no stranger to scale. What started out as a side project six years ago is now one of India’s latest unicorns with a $5.6 billion valuation.
APIs can be complicated, but Postman aims to make them easier and faster. Its API collaboration platform is being used by more than 17 million people from 500,000 companies globally.
It would be easy to think that as Postman’s company and valuation exploded, each of their teams grew in suit. But in April 2020, just months before Postman closed their $150 million Series C round, its data team only had six or seven people.
Since then, however, it has been a different story. A little over a year later, Postman’s data team has grown by 4–5x to 25 people. In the second half of 2020, they added one new hire per month, followed by two four-person batches in 2021.
Last June, we couldn’t have imagined recruiting and onboarding 4 new hires in a month.
Prudhvi Vasa, Analytics Leader, Postman
But after a lot of effort to build better infrastructure and processes, Postman’s data team is now more comfortable with onboarding new hires, handling requests from the rest of the company, and planning their work.
As the co-founder of Atlan, the unified data workspace that Postman added to their data stack, I got an inside look at their small but efficient data team. Setting up better team processes while a team is growing fast can be difficult, so I thought it would be valuable to share a snapshot of how the team works, both together and with the rest of the organization.
Through a series of conversations with Prudhvi Vasa, Postman’s Analytics Leader, I’ve written this article to dive into a behind-the-scenes view of Postman’s data team — how it’s structured, who they hire for different roles, how they plan and prioritize their work democratically, and how they use sprints to constantly identify problems and make improvements.
The basics on Postman’s data team
Postman has a 400-member team with people spread across two Bangalore offices, one San Francisco office, and distributed remotely across 4 continents. However, its 25-member data team works together in Bangalore.
We have a data team centrally located. Basically, we sit together and we work for everyone in the organization. Our vision is to enable all functions with the power of data and insights, allowing us to take high-impact decisions quickly with confidence.
Prudhvi Vasa, Postman
Postman’s data team is made up of two sub-teams — the Data Engineering Team (8 people) and the Data Science Team (17 people). Data Engineering brings raw data (e.g. internal or external, crawled or enriched) into Redshift, while Data Science turns that data into metrics, reports, and dashboards in Looker. Nearly one quarter of the company is active on Looker every week, using this data.
The Data Science team, led by Prudhvi, is further broken down into three types of data analysts: central, embedded, and distributed.
Central data analysts are the most common type — they account for 13 or 14 of the 17 total data scientists. These analysts work centrally as part of the data team to maintain company-wide metrics in Looker, such as the number of users for Postman or the top-to-bottom funnel. They also solve problems and questions that come in from other teams, such as “Why was there a 10% increase in users from the US yesterday?”
Embedded data analysts are central data analysts who sit with a specific team for a fixed time period. For example, the Product Team may ask for a dedicated analyst for three months. A data analyst from the central Data Science team will then embed themselves into the Product Team (thus temporarily becoming an embedded analyst), work closely with the team to solve their data problem, and then return to the central team when they’re done.
Distributed data analysts are like embedded data analysts, but they work permanently with another team rather than returning to the central Data Team after completing a project. Embedded analysts work across different domains and data (e.g. marketing, product, sales) and report to the Data Team, whereas distributed analysts are experts in their team’s specialty and report to that team’s lead.
Debating a centralized vs. decentralized team structure
This team structure sounds set in stone, but it’s something that had to quickly evolve as Postman hired a ton of new data analysts.
In fact, Postman first tried to make the Data Science Team more decentralized, where they hired analysts directly into other teams (e.g. marketing, sales, etc). These distributed analysts were never meant to be part of a central data team. For some teams, like the Product Team, this worked fairly well. However, for other teams like Marketing and Customer Success, it failed.
The decentralized analysts started building their own data systems and reporting metrics to their team manager. Meanwhile, Prudhvi and his pre-existing, three-person data team had their own data systems and metrics. The founders quickly realized that they were getting two different numbers for the same things.
“The problem was that they were not centrally onboarded,” said Prudhvi.
If people sit together, work together for some time, and learn everything about the data, then they can go and work with other teams. That’s the right workflow.
Prudhvi Vasa, Postman
After experimenting with decentralization, Postman has moved towards a more centralized data team. They hire analysts into the Data Science Team and train them centrally. After a several month onboarding process, some new hires move to the more data-mature teams (like the Product Team) as embedded or decentralized analysts.
As Prudhvi explained, analysts who are hired to a central data team have the common context and knowledge that’s critical for collaborating on data across teams. “They have a good rapport with the central team. They know what we are developing, and they also tell us what they are developing. So we have a synergy, and they use what we build. It has worked really well.”
Creating levels and hierarchy
When Postman started to create its data team, it started with a flat structure.
Since we only started growing the team last year, we called everyone ‘data analysts’. We didn’t distinguish between designations for a fresher or a person with five years of experience.
Prudhvi Vasa, Postman
This was also something that had to change. As the team scaled and quickly added a lot of new hires, it became important to distinguish between different levels of data analysts.
Now the Data Analytics Team has a fairly simple three-part hierarchy — Data Analyst 1, Data Analyst 2, and Technical Analyst.
- Data Analyst: Young analysts who are very new to the data industry. They usually have just started working, and mostly spend their time learning new things.
- Senior Data Analyst: The subject matter experts who have worked for two to three years across different domains. They don’t need as much supervision on projects.
- Technical Lead: People who can innovate and improve the team’s performance. They are often good at documentation, identifying patterns, and growing the team’s ability and skills.
Planning and prioritizing data work
Every data team has experienced the challenge of prioritization. Everyone in the organization needs your time, and they need it now. Divvying up limited time across competing priorities is never easy, especially with centralized analysts who aren’t beholden to a single team.
As Postman grew, Prudhvi had to develop a system to efficiently deal with data to-dos. “It’s not verbal,” he emphasized. “When someone comes and just asks us for help, we don’t take it.” That’s because his team has a clear system for scoping and breaking down data requests.
It starts with a ticketing system on Jira. They have a “Data Public” board that’s open to everyone in the organization, and anyone can go on the board and create a ticket.
Most importantly, the tickets are designed to help other teams clearly articulate their data requests. Anyone who creates a ticket has to explain the problem they’re facing, what questions they’re trying to answer, and what impact their project will have on Postman.
Only if there is a ticket, we’re going to work on it. Only if they fill all of this information, we’re going to have a discussion. It makes it clear for us, which is the most impactful thing.
Prudhvi Vasa, Postman
Next, the team follows up on each ticket, each person taking turns to act as a Triager for the sprint. The Triager starts on Jira, looks at all the incoming tickets, and tries to gather more information. If needed, they delve into unclear tickets with questions like “Can you give more clarity on this?” or “This wasn’t said. Can you explain it?” Once the Triager is satisfied with all the responses, they assign each ticket to a sprint, depending on its priority and impact.
For some requests, they may also do an in-person brainstorming session to further scope out the request. This includes someone from the data team, the person who created the request, and other relevant people who can add value to the topic. After lots of questions to help everyone zero in on the problem at hand, the analyst can explain how to clarify and improve the ticket.
Meanwhile, Prudhvi keeps an open line of communication with other company leaders about balancing their data requests. “If I have a doubt, I talk to Ankit (the CTO and Co-founder) about what has the most impact,” he said. “Then I go and convince the other managers that we’ll take up their requests next month or next sprint. Most of the people understand that we are prioritising other high-impact work.”
Democratizing project allocation through weekly Issue Grooming sessions
Another constant problem that Postman’s data team faced was allocating projects. Sometimes people would complain about their work — e.g. “I’m not getting to work on customer projects” or “I want to work on the founders’ projects”.
Rather than trying to allocate tasks more “fairly”, which is just a path to more controversy, the team took a different path. The solution was to distribute planning and hand control over to the team’s analysts.
We democratized it. Then people couldn’t complain, ‘Vasa, you’re being biased’. I’m like, it’s up to you guys. You guys decide what you want to work on.
Prudhvi Vasa, Postman
Now the data team has a weekly Issue Grooming session, where they assess and assign new tasks.
One challenge with assigning tasks is that some people don’t have as much context as others. Newer team members can be apprehensive about working on a project they feel they don’t understand as well as others, even if it would end up being a great project for them. That’s why Issue Grooming sessions start by bringing everyone to the same level of understanding.
“We want to come to a common platform, where all of us know what each project is about,” said Prudhvi. “We explain to everyone what the project is about, then everyone can express interest in working on it.”
Before the session, each new ticket is assigned to a separate analyst. That analyst drives their ticket — first by going through it in advance to make sure they fully understand it, then by explaining it to everyone during the call.
After the ticket explanations, the group takes up each ticket during the Issue Grooming session. Tickets with a broader scope get broken down into smaller tickets to promote continuous delivery, rather than trying to deliver a major project all at once. “We discuss what needs to be done,” said Prudhvi. “If needed, we convert one ticket into three tickets, then we assign the first ticket to someone and the next tickets to further sprints.”
After breaking each ticket down into smaller tasks, the team bids to allocate tasks. “We first ask who is interested in working on a task. If there are multiple people, we have a bidding system, based on how interested they are to work on or learn about the ticket. Whoever bids the highest, we give it to them,” said Prudhvi.
Adopting the sprint methodology
As the Issue Grooming Session hinted at, Postman’s data team works in two-week sprints. Prudhvi finds them helpful for two main reasons.
First, sprints encourage the team to break down projects and create continuous output.
Say that the team needs to forecast customer churn. That takes a month. Leaving an analyst to work on the task and only learning the results after weeks of effort can be a problem. What if they get stuck, or what if they fall behind? It can take too long to realize these types of problems with long projects.
However, the sprint methodology encourages teams to break down big projects into smaller ones. “Some projects take time. You can’t deliver everything in one week or two weeks,” said Prudhvi. “Even if someone raises a ticket with a big scope, we break it down into smaller tasks, and we assign them to sprints. We say, for this sprint, this is the objective.”
We don’t just wait for the final output. We break down tasks in sprints to make sure that output is continuous.
Prudhvi Vasa, Postman
Second, the sprint retrospectives help Postman’s data team continuously find issues with how they work and improve their processes.
Every two weeks, after a sprint finishes, there’s a sprint retrospective. These sessions encourage the team to look back on the sprint, check in on what they actually accomplished, and assess what went well and what didn’t. When the same problem crops up in multiple retrospectives, the team can add fixing that problem as a goal for the next sprint.
For example, Postman’s data team found that they had a repetitive issue with questions like “Where is this data?” or “What data should I use?” Slack was overflowing, and senior people were spending a lot of time answering questions every week.
To make matters worse, the same questions kept appearing over and over again. “I asked the same question, someone else asked the same question…” said Prudhvi. “But they don’t know what to search for in Slack, because they don’t know the table name. It was very repetitive.”
It’s easy to ignore small but repetitive issues until they reach a breaking point, but the sprint retrospectives help bring them to the team’s attention. As a result, the data team embarked on a project to solve data discoverability, broke it down into smaller tasks, and added them to upcoming sprints.
There were lots of twists and turns along the way, but this is actually how they discovered and ended up implementing Atlan. Read more about that journey here.
Looking ahead for Postman’s data team
If you ask Prudhvi where the data team stands, he’d say it’s still early. “We haven’t solved for data being a product to everyone yet. That’s what we want to solve.”
Just like every data team, they’re still working to improve data quality issues, legacy infrastructure, and unexpected bugs every day. But it’s hard to deny the progress they’ve made.
A year ago, Postman’s data team would have imploded with the weight of four new hires. Now they’ve experimented with and implemented clear processes — like centralized onboarding, internal hierarchy, better prioritization, and Issue Grooming sessions — to help everyone collaborate on big data challenges amidst massive internal growth and change.
Big thanks to Postman and Prudhvi Vasa for giving their time and support to this article! ❤️
This article was originally published on Entrepreneur’s Handbook.
