👷 How I Apply The 5 SOLID Principles When Building Teams
You already know how to build software, and here’s you you use these skills to build teams.
This article is part of the Build & Lead Data Teams playlist. Click here to explore the full series.
Most leaders grow their teams organically. They backfill when someone leaves, hire when a new project lands, and add an analyst when the CFO wants a dashboard. Two years later they look around and see a mess. One sub-team has six people tripping over each other, another has one person drowning, everyone is busy, yet nothing ships fast.
And you know what? You already know how to fix this.
Every engineer who made it past their first year knows SOLID principles. You apply them to your code, but nobody taught you how to use them when building team. And that’s why most engineering teams grow like spaghetti.
I have been applying SOLID to team building for years. Three years ago I wrote about using it to structure a data migration. That article still holds up. Read it here if you want the technical version.
But today, I am walking you through the people version.
I have seen this work for teams up to 15 people, which is great, because, nowadays most data teams that actually ship are even smaller.
Here is how it works and how you do it.
But before that, I’d greatly appreciate if you boost my metrics a bit by clicking the link below.
This issue is brought to you by Cube.
Agents do the analysis. Your team does the thinking.
A question about your own business data still means a ticket, a queue, and a week of waiting. Cube hands that workflow to AI agents: they model the data, explore it, and build the reports — your team guides and approves — so week-long analysis comes back in minutes. And because every agent works from one governed set of metric definitions, the answers come back right. 400+ companies run on Cube, including Brex, Wix, Patagonia, and Webflow.
Single Responsibility Means Splitting The Work Before You Hire
I do not love repo sprawl, but we run three separate dbt projects because the use cases, skill sets, and velocities are too different to force into one place.
The first project is for data engineers. They clean data, fix types, and enforce structure. It is the plumbing. The second project is for analysts. They build business logic, define KPIs, and model the objects that feed our BI tools. The third project is lightweight vendor modeling. Our vendors see their work, and we see what we owe them.
I split them intentionally:
An analytics engineer should focus on their models without worrying about ingestion pipelines.
A product person should think like a product person, and when they have to reason about data types and ingestion logic, something is wrong.
Each sub-team moves at its own speed and owns its own scope, and no one steps on another sub-team’s work.
I do not ask analysts to optimize costs or write complex macros, and I also do not want data engineers to create dashboards. Everyone knows what they own.
This is where most teams go wrong. They hire before they split the work, so they bring in five analysts and two data engineers and throw them at a monorepo, then they wonder why the analysts break pipelines and the engineers resent the noise.
How You Do It
Write down the ownership rules and post them where people see them:
When someone asks who owns the vendor schema, the answer should be obvious.
When someone asks who approves a change to the BI model, the answer should be obvious.
When the answer is not obvious, people slow down, they ask around, they wait.
Clear boundaries fix that.
Open For Extension Means Your Team Grows Without Reorgs
In code, the Open/Closed Principle means you extend behavior without modifying existing code. On my team, it means you extend people without restructuring the org chart. Career growth comes from doing the work instead of watching someone else do it. When an engineer wants to try analytics engineering, give them a project.
That’s how the org chart stays the same, and they grow anyway.
I’ve had one to ones with one of our embedded analysts for years. She was more of a stakeholder than a team members. Then, she started showing interest in writing BI code, and then dbt. Our senior analytics engineer, and I helped her learn all the necessary skills. A few months later, she build one of our 3 dbt projects from scratch. After a couple more months, she fully transitioned to becoming an analyst and joined the team.
Now, this only works with strong leaders. You need to see potential in your members and give them challenging tasks that push them in the direction they want to grow. You need to foresee where your team needs to expand and support your org to reach its goals. Weak leaders give projects to people who already have experience with the area. They wait for a re-org to justify a title change, and they let people stagnate because it is easier than finding them a stretch project.
How You Do It
Map the skills on your team. Think about who writes SQL, who knows Python, who do stakeholders actually listen to, and who fixes Airflow when it breaks. Then map the gaps. What work sits unclaimed because no one has time? What projects stall because they need a skill that lives on another sub-team? Those gaps are where people grow.
Give your people a real task with stakes and support. Pair them with someone who already has the skill, and let them ship something that matters.
The key is to keep the core structure intact. The data engineering sub-team still owns ingestion, and he analytics sub-team still owns BI, but the people inside those sub-teams should move.
Remember to set a rule. Every quarter, each person should spend at least twenty percent of their time on work on the area they want to grow. Give them real work that the team needs, and track that work in your planning tool and talk about it in one-on-ones.
Liskov Substitution Means Everyone Knows What Everyone Else Does
In software, the Liskov Substitution Principle says a subtype should be replaceable with its base type. In team building, people translate this to a simple idea: if Engineer A goes on vacation, Engineer B steps in seamlessly. Every engineer must know what the others do.
Modern data teams are small and do not have the headcount for deep specialization. I like this, because every engineer knows what the others do. They learn it in dailies, show-and-tells, and pull requests where we talk out loud.
We also try to have at least two people for every role. The lead should do the job too. Managing is not the whole job.
One more note in case this gets confusing. Single Responsibility separates the roles, while Liskov Substitution makes people interchangeable within the role. The boundary sits between roles, and not inside them.
So when someone takes annual leave, the system does not break because Engineer B is a clone. Engineer B keeps the system running because they paid attention. They read the PRs and asked questions in standup. They knows which jobs fail, and which tables no one trusts.
