How to Structure Your Team When Building a Data Startup

How often do you get advice that is directly relevant to what you need right now? Probably never.

As a startup founder, I read a lot of articles about building and growing a business. A lot of these articles have great advice, but often try to reach a broad audience, and therefore end up glossing over the details that can really matter.

It’s possible I can make a small dent in that problem by providing some insight into the specifics of building a data startup. If you’re responsible for a data startup yourself, or any team involved in operating big data-scale technology, then this article (and others to follow) can serve as a guide for how to build and run that team. I don’t promise to have all the answers, but I can share what I’ve learned over the last few years building Datafiniti. Hopefully you’ll find the material helpful, and just a bit more relevant to your needs right now.

Our Org Chart

I’ll start by laying out our current team structure at Datafiniti. Our “org chart”, if you will:

Here’s what each of these mean:

Data Team

• Team Goals: Improving overall data quality and increasing efficiency and volume of data production
• Team Size: 4
• Team Roles: Data engineers and data scientists

Crawl Development Team

• Team Goals: Building out individual web crawls to collect data
• Team Size: 5
• Team Roles: Crawl developers and project manager

Infrastructure Team

• Team Goals: Maintaining and improving performance of our technology stack, including our web crawling components, data warehouse, and APIs
• Team Size: 3
• Team Roles: Software developers and operation engineers

Growth Team

• Team Goals: Sales and marketing
• Team Size: 4
• Team Roles: Lead-gen marketing, sales, SDR, customer success

Product Team

• Team Goals: Customer-facing web applications, including Datafiniti and 80legs products
• Team Size: 3
• Team Roles: UX designer, product developers

Customer Success Team

• Team Goals: Delivering data to customers and providing a great customer experience
• Team Size: 3
• Team Roles: Customer success, customer solutions engineer, sales

Some Observations

Two-Pizza Teams

This team layout roughly follows Jeff Bezos’ 2-Pizza Rule for team sizes. Following this principle wasn’t my intention, but I have observed better team communication and cohesiveness since we adopted this layout. As the team grows, my current plan is to split out new teams whenever an existing team gets larger than six people in size. New teams formed this way would most likely be more specialized than their predecessors. For example, the Infrastructure Team may split into an API team and a database team, or the Product Team may split into separate teams for each application we’re building.

Overlap

A few employees have responsibilities on different teams. For example, our Customer Solutions Engineer just started a project on building a monitoring tool for our data pipeline, which falls under Data Team. Conceptually, this isn’t an ideal setup, but it’s working so far. It does give some employees the opportunity to explore other parts of the company, but it requires better time management from them.

The Only Constant Is Change

We’ve gone through a lot of different team compositions. In fact, we only just started using this one since August 15th. In a previous iteration, all developers were on the same team. In the early days, the entire company met each week to discuss updates.

This composition came about as a desire to move to a more agile approach (something I’ll address in a future article), and the different team separations made sense for where we are now. I’d like to say it was a deliberate effort, but it’s really just been a result of continuous experimentation. For the time being, I feel really good about it, but it’s entirely possible we’ll find problems. In fact, I hope we do. As a wise man once said:

Unless you try to do something beyond what you have already mastered, you’ll never grow.