The Gift & Curse of Small Data Teams

A small or one person data team is a gift because there is less red tape and you can move fast. It is a curse because with less oversight it is easy to cut corners, and those shortcuts compound over time. The fix is not more data or a big tech style system. It is adopting the workflow and conventions a bigger, more mature team would use: separate environments, tight database roles, consistent project design, and a real Git workflow. None of that is complicated, and a small team can put it in place faster than a large one because there is nobody to ask for permission.

What building like a bigger team actually means

To be clear up front, I am not talking about adding more data or building the kind of overly complex system you see at a big tech company. I am talking about workflow, conventions, and how you go about building.

The easiest way to show the difference is through examples. Below are four I see repeatedly, each comparing how a smaller team tends to operate with how a more structured team would handle the same thing.

Example 1: Environments

When one person is running the show, there is often no clear separation between production and development. It lives in their head. It's just them, or maybe two people, so going straight to production doesn't feel like a big deal.

What a bigger team does instead

A more mature team has clear environments: development, maybe a pre-production environment, and production. Nobody goes straight to production. There are workflows and testing in between.

None of this has to be complicated. You don't need elaborate integrations. Some baseline tests and a simple set of environments to move data through is enough.

That alone is the difference between catching bugs up front and having your stakeholders catch them for you.

Example 2: Users and roles

This one usually shows up in the database. On smaller teams I often see admin roles used for nearly every process: ingestion, transformation, reporting, all of it.

It is easier to get started that way. You never have to wonder whether something has permission. It just works, and there is nothing to manage.

Where it falls apart

• Scaling. When you bring on another team member and try to explain the process to them, there isn't one. It's all running as admin.
• Security. An admin credential exposes your data to whoever gets a copy of it. That is a problem whether you have two users or two hundred.

Clear roles with tight permissions

A bigger team groups users by purpose and gives each group only what it needs: a developer role, a role for ingestion tools, a role for reporting users. Admin isn't used for anything routine.

As an individual developer, you should not be able to update production. That is a quick permission change, and it gets overlooked and pushed aside all the time.

The hard part is adherence. With roles, and really with every example here, the challenge is sticking to the rules you set for yourself. You have to be diligent about them and not bypass them just because bypassing is easy.

Example 3: Project and query design

This one is honestly a problem on both sides of the coin. But thinking small, the pattern is wild inconsistency. Every query you open looks different: different aliasing, different structure, different style.

So every time you touch something, you start with a deep investigation to figure out what is actually happening. That cost compounds with every query you add.

Conventions and tribal knowledge

The same goes for conventions. If things are named differently and live in different folders, you spend your time figuring out where things are before you can get to the work.

That is how tribal knowledge starts. Only the one or two people who built it understand it, and anyone else would struggle to follow along.

The aspirational version

A more mature team has clear conventions that are expected to be followed: a style guide, naming conventions, and overall consistency across the project.

I've also worked on big teams where that wasn't the case, so this is not black and white. It is an aspirational goal. The real question is: how would a larger, more mature company handle this, and why aren't you doing it just because you are small?

Example 4: Git workflow

This was a real learning curve for me earlier in my career. I had no idea what a Git workflow was about. But any company of meaningful size has one, and you should have one too, even if it's just you.

Most of the small teams I work with do have version control. They just aren't using it to its fullest. Two patterns come up a lot:

• One big shared dev branch. Every change goes there, followed by one large commit and push to main.
• Straight to main. No dev branches at all, because the only developer sees no reason to put themselves through a pull request review.

What a bigger team does instead

• An individual feature branch for each unit of work. One project, one branch. No shared dev branch.
• Frequent, smaller commits instead of one giant commit with everything in it.
• A pull request for every change, even when you are the only person on the team.

Why it is worth the extra steps

This isn't about adding work to your plate. Individual changes become easy to track, so you can go back and see exactly what changed instead of losing it inside a big commit message.

And when someone else needs to look at your work, say you are out of the office and they need to understand why a piece of logic changed, a clean history is the difference between a quick answer and a long dig.

Environments, roles, design, Git workflow. None of these require a bigger company or more data. They are workflow and process, and they just need the right attention.

Why you should care

The goal here isn't to judge anyone. I've been guilty of every one of these, and so have many teams I've worked with.

It's about awareness. Maybe one of these is something you can fix this week. Maybe it is something you've been putting off and this is the reminder. Or maybe you never realized it was a problem.

Your team is a business inside the company

I think about a data team as a little business within a company. We have customers, which are our stakeholders. We have a product: the reports, the data feeds, the analytics we deliver. And we have our own way of doing things, like any business.

If you were building a business, you would want it to be a good, well structured one. That mindset is what gets you to care about the small nuances: conventions, workflow, permissions.

Individually none of them seems like a big deal. Together they are the difference between a business that runs seamlessly and one that is a mess.

The handoff you haven't planned for

At some point you may leave the company. A new opportunity comes along, or things don't work out. Or the team grows, you bring on help, and you have to hand off responsibility.

In those moments you want the transition to be easy, so the next person isn't digging through messy notes and inconsistent processes to deliver what they are expected to deliver.

If you set up the foundations now, it is much easier for someone to help you. And if you want to step back from the day to day, the standard is already set. You are just passing it off and guiding them.

It might not be a person

You might be asked to bring on an AI coding tool or an agent and train it on your project. That is a lot harder when there is no consistency to train it on.

At some point you may not have the time to not think about this. I know the response: too much on my plate, too stressed, can't possibly consider it right now. You have to figure out when that point is for you.

Your future self will thank you. Or if it isn't you, someone else will be very glad you did it for them. And as a small team you can make these changes faster than anyone, because there is far less red tape in your way.

Related reading

• Don't Overlook Workflow (as a Small Data Team)
• The Art of Data Team Workflows
• The Risks of Lazy Database Roles
• What Every Data Team Lead Should Know

Final takeaway

Nearly every small team I work with has at least one of these four running on the honor system, and it is usually the first thing we fix together. Build as if you were already the bigger team you might become, because the shortcuts you take alone are the ones someone else inherits.