Scaling your data team is a fairly complex topic, but we’re going to break it down into a few crucial talking points:

  • Centralized vs decentralized analytics
  • The right tools for the job
  • The right people for the job  

Before we get started with the real meat of this article, I’d like to give you some background information about myself and my company.

About me

I’m currently Senior Director of Toast BI. We aim to drive data informed decisions. Toast is an all-encompassing online platform for restaurants. We started as a point-of-sale system, and we’ve become so much more.

Now, we offer capital and have online ordering, loyalty cards, and a marketing suite. Toast was my first venture into the B2B world.

Before that, my experience was in e-commerce. I also spent some time doing economic consulting, focusing on airlines and energy. Most notably, working on the Continental United Merger for the Department of Justice.

A brief history of Toast BI

So, why are we talking about scaling the team? And why should Toast be an example for you or your organization? Well, the main takeaway is that we’ve done a lot of different things. More crucially, we haven't been afraid to try different things. Because of that, I think we can give you an excellent perspective on the types of things that work and don’t work.

I started at Toast in 2016. I was the first dedicated BI analytics resource, we were about 200 people, and the company was run on Excel docs and Salesforce reports. It was a very scary place. I was brought on to build real reporting and modernize.


Firstly, I started to build out a small, centralized team. I focused on the technology selection. We chose a tool called Incorta. We had three people, myself and a couple of others doing a little of everything. We started to have a hybrid team, and it was a bit of a balancing act in terms of who did the actual work.

In 2019, that's when we moved away from that tool and started to use a multi-stack tool. We use Stitch, Airflow, Snowflake and Looker. That was after quite a bit of research - 2019 was also when we hired our first dedicated data engineer.

In 2020, after COVID hit, we brought those decentralized teams that I mentioned together, and we actually centralized them all under one umbrella. Now we have about 2,000 employees.

The key takeaway here is, we tried a lot of different things before we got it right. I think that gives a good perspective on the types of things you should look at. Different approaches are right at different points. Don't feel locked into anything.

The spectrum

There's centralized and decentralized analytics, but almost everyone is a hybrid like we are. It's not a one-size-fits-all, and almost everyone is somewhere in the middle. It's not often that people fit squarely into one of these categories.


So, let’s dig into what centralized and decentralized actually mean: 👇

Centralized analytics

Analytics stands as its own function. Analysts and teams may be dedicated to different departments, but they will all report into a central hub. We were centralized when we started.

Pros of centralized analytics

  • Consistent standards and expectations for analysts.
  • Increased collaboration leading to more mentorship and faster growth.
  • Simpler to move around resources when necessary.
  • More likely to see the whole business in duplication.
  • Reduced work duplication.

Cons of centralized analytics

  • Velocity is generally slower.
  • Easier for things to get lost in translation.
  • Jockeying for resources can be challenging.
  • OKR alignment is more complex.

Decentralized analytics

Departments house their own analytics functions. These analysts mainly report to leaders of their own departments.

Pros of decentralized analytics  

  • Output velocity is high and can fluctuate with the business.
  • Teams can easily allocate different amounts of analytics resources.
  • Direct OKR alignment.

The right ingredients

Now, let’s talk about the right ingredients for putting together a great team. Gotta love those food puns! 🍲

Make hiring a priority

When you're growing the team, make hiring a priority. You don’t want to make the mistake of taking on too much yourself, you want to be adding great people to your team.

Focus on diversity

We’re not just talking about race, culture or background, we’re talking about neurodiversity.

People who think in different ways and have different skills. At Toast, we have people from traditional analyst paths, but we also have a bunch of people who are smart, quantitative people who made career shifts.

We have people who have gone from academia to Toast, people who were in sales and came to Toast. That kind of diversity of thought has really given us an awesome mix of people.

And of course, hiring people of different races and ethnicities is vitally important as well.

Don't hire for technical skills

Technical skills can almost always be taught. So, instead, think about the person you’re hiring.  Are they smart and quantitative minded? Our case studies are quite generic, they don't have right or wrong answers. They're designed to see how you approach a problem. I don't care if you get the right answer, I care much more about the though process.

Hire athletes

I don't mean people who have done sports, I mean people who can do a little of everything. At the beginning, we focused on hiring people who are happy to try anything.

In the early stages of a business, you don’t always know what it’s going to look like. That’s why it’s good to get people who are willing to try their hand at whatever challenge may be presented.

Don't ever mess with culture

At Toast, we have a ‘no ego’ policy. If we sense even a little ego in an interview, we cut it off there. It's just not worth the risk. I think we've been able to build a pretty strong culture in Toast because of that. As a company, it helps to establish a strong sense of shared identity, that way, everyone is on the same page.  

The right stack

When selecting tools, it’s important to be aware of the distinctions between different categories. Here, we’re going to break them down so that you can make the right choice for your business.

Full stack tools

Prominent examples of these include Domo and Siense. These are the kind of tools you might use when, for example, you’re setting up your dashboards and joining tables. These tools sound great in theory, and they look great from a budget perspective, but beware, it can get very messy.

You end up with an enormous amount of information stored in one tool, and these tools aren’t always the best at handling that. They can also be ‘sticky.’ At Toast, we found that a full stack tool simply wasn’t growing with us, that's when we switched to….

Distributed stack

We use Amazon s3, Stitch, Airflow, Snowflake and Looker. Distributed stack tools can be overwhelming, but they handle the data much more effectively. They can be complicated, so make sure you do your research before you switch, and hire appropriately to support it.

The single source of truth

As you're building out the team, and you're thinking about centralized vs decentralized, people will often tell you that you have to have a single source of truth.

I like to say, that's somewhat true, but not always true. We're trying to make the right business decisions, and there are certainly financial details to consider. Maybe you need to map out your data effectively. But overall, the most important thing is that we're making the right business decisions.

When do you need to be 100% accurate or not? That's the thing to keep in mind. Your job is to give clarity to the data and present it clearly. But the most important thing is making the right business decisions.

Don't go crazy, creating one single source of truth in spots where it’s not actually worth it. You will exhaust a ton of resources hunting for this single source of truth.

Key takeaways

The number one thing is to be flexible - try new things, embrace change and find the thing that works right for your company.

Secondly, nothing can replace great hiring. You want to hire people who can be flexible and are willing to try their hand at many things.  

Finally, be aware of overly sticky tools - you want to make sure that software grows with you. For example, if you decide to switch to a distributed stack, you need to make sure it’s because your business needs it.