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.
