A Behind-the-Scenes Look at How Postman’s Data Team Works
A deep dive into Postman's data team: team anatomy, levelling, onboarding, planning and prioritization, cultural rituals, and more.
When I started this Substack, one of my goals was to deep dive into tactical resources for data leaders and practitioners to answer the hard questions: how to structure data teams, what roles to hire for, how to plan and prioritize, team rituals and more.
Today, I’m super excited to deep dive into a company that I personally admire on several levels: Postman and their journey to building an amazing data team to empower the company and people building tools used by more than 17 million people from 500,000 companies globally. 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, how 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.”
My two cents: Having discussed the centralisation and decentralisation debate with several data leaders, I actually think that Postman’s solution is pretty neat: onboard analysts centrally so that they can understand the team, the data, the processes deeply and then start embedding them into business functions so that they can become business experts.
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.”
My two cents: Planning and prioritisation for data teams is always hard like Emilie spoke about. Having a clear process for the business to pass on data requests, and a person responsible for gathering context is incredibly important, and I think Postman’s “triager” concept here is fantastic. Despite that, sometimes prioritisation can become hard and that’s why I have a lot of respect for companies that structure their orgs such that the Analytics Leaders can have direct access to a key company level decision maker (in this case the role that Ankit plays for Prudhvi). In larger companies, this could be filled by ensuring the data leader has direct access to the COO/ CBO/ CRO — anyone who can ensure that prioritisation is directly aligned with business goals.
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. Read more about that journey here.
My two cents: I firmly believe that great data cultures can be built when individual people take ownership of solving the problems they face. For this, it is important to create an environment where teammates openly discuss the key challenges they are being faced with which is key to unlocking true ownership & build a sense of trust. But discussing challenges isn’t enough, it is important to give people ownership to solve key team level challenges. I am a big fan of structured ways to have teams surface problems and challenges, and then pick up initiatives to solve them in the upcoming quarter. This could be via an exercise like regular sprint retros like Postman’s team or even quarterly start, stop, continue exercises.
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.”
I’d say they’ve made some good progress in that direction. What do you think?