Sit down, let us talk about building a data science team. Not the conference talk version. The real one, from inside a large, heavily regulated enterprise, over two years, with a small team, a tight budget, and no map. I am going to tell you what I was given, what I did about it, what it cost me, and what I would tell you to do if you were starting tomorrow.
What I was given#
Picture your first week. You ask for the handover and there is none. Not a thin one. None. Models are running in production, real customers are depending on them every day, and there is no record anywhere of how they were built, what data feeds them, who uses their outputs, or how accurate they are. The products exist. The knowledge about them lives in nobody's hands.
The team is small and talented, but it has been running without structure, reporting into a business function rather than an engineering one. Everything is done on the fly because there has never been anyone whose job it was to decide how things should be done. The infrastructure is a legacy engineering stack built for hosting applications, solid for what it was designed for, and completely wrong for distributed data work. And the budget is tight. Not tight as in negotiate harder. Tight as in there is no line item for any of what you are about to need.
Here is the first thing I want you to understand, because everything else follows from it. In that situation, the temptation is to start fixing the loudest thing. Do not. The loudest thing is almost never the load bearing thing. What follows is the order that worked, and more importantly, the reasoning behind the order.
First, make the work visible#
You cannot lead what you cannot see. When I arrived, work started, stalled and finished invisibly. People were busy, genuinely busy, but the team could not answer the simplest question about itself: what are we working on, and how is it going?
So before touching any technology, I introduced structure: agile working through Jira. Two week sprints. A standup every two days rather than daily, because a small team fighting production fires does not need another meeting, it needs a rhythm. At the end of each sprint we sat together and asked the honest questions. What got done? What did not? Why? Who is blocked, and on what?
If you have read The Phoenix Project, you know the idea: invisible work is unmanageable work, and the first act of any turnaround is making the work visible. What visibility bought me was not speed. It was knowledge. Within a few sprints I could see who knew what, which skills we had and which we lacked, and exactly where work went to die. You are not building velocity in this phase. You are building sight.
Write everything down, like you might leave tomorrow#
Once I could see the work, the next problem introduced itself: every important thing lived inside someone's head. In a small team that is not a culture quirk, it is an existential risk. One resignation and a production system becomes an orphan.
So I introduced Confluence and seeded it myself, starting with the onboarding guide I wished I had received: every tool we use, where to find it, how to get access, which entitlements to request, which regulations you must complete before you can do this work in a regulated environment. Then the harder job: we went into the backyard and reverse engineered our own production models. Every product the business relies on got documented. What it does. How it works. What feeds it. Who uses it. Nobody handed us that knowledge, so we dug it out ourselves, because the alternative was operating systems we did not understand.
Richard Feynman, when a historian described his notebooks as a record of his thinking, corrected him: the notes were not a record of the thinking, they were the thinking. That is what documentation is for a team. It is not admin after the real work. It is the team thinking in a form that survives.
And here is the part I did not fully predict. The documentation outgrew us. Our Confluence space now serves governance and audit purposes, and teams outside our own area use it to understand our models for their own work. Knowledge we wrote down to protect a small team became an asset the broader organisation draws on. When people later joined the team, they onboarded from a documented path, not from word of mouth. There is an old proverb that says the palest ink is better than the best memory. Believe it before your first resignation, not after.
The cost of this phase was my own evenings, and I will not pretend otherwise. Nobody asks for documentation. You do it because you are building something that must not depend on you.
The long game against the short game#
Now I must tell you about the hardest challenge of the whole two years, because it was not technical.
Management, quite reasonably, wanted immediate results. Things they could count this quarter. And almost everything I have described so far produces nothing you can count this quarter. Sprints, documentation, governance processes: these are investments whose returns arrive later and compound quietly. My strategy was long term, sustainability over spectacle, and that meant living inside a permanent tension between what the business wanted to see now and what the team needed to become.
I will be honest with you: sometimes holding that line means going against what management is asking of you in the moment, because you can see what a scalable data science capability requires before it is visible to anyone else. That can end well or badly, and you should know that before you choose it. It is ownership in its purest form. If the long game pays off, you were a builder. If it does not, you were difficult. Warren Buffett put the principle better than I can: someone is sitting in the shade today because someone planted a tree a long time ago. I decided early that I was there to plant trees, and I accepted the cost of explaining, over and over, why I was digging when everyone wanted fruit.
My belief, and by the end of this post I hope it becomes yours: a good data science team is one whose systems outlive the people who built them. If I leave, if anyone leaves, if the whole team leaves, the documentation, the pipelines, the patterns and the governance must keep working. There is a moment in One Piece where Dr. Hiluluk asks when a man truly dies, and answers: not when he is shot, but when he is forgotten. Systems are how a team remembers. Build so that nothing important dies with a resignation letter, including yours.
When the infrastructure bill arrives#
Then reality did what reality does: it presented the bill for infrastructure choices made long before I arrived.
During a platform migration, things broke, and one of our products began accumulating a backlog of unprocessed records that the legacy stack could never catch up on. It was never going to catch up, because the stack was built for hosting applications, not for distributed data processing. No amount of team discipline fixes a platform mismatch. The workload and the infrastructure simply did not share a shape.
I had seen this coming, and I had prepared for it, and this is the most transferable lesson I own: you do not get budget for infrastructure, you get budget for pain. There is an old line, often credited to Churchill, about never letting a good crisis go to waste. When the backlog crisis arrived, I did not bring management a complaint. I brought a costed proposal for Databricks that was already prepared, and I carried it end to end: the contract, the environment stood up with the platform and networking teams, and a migration framework off the legacy stack. A repeatable path, not a heroic once off.
The risk was mine and I knew it. If the platform failed, there would be no confusion about whose idea it was. That is the ownership I keep talking about: putting your name on an outcome before you know how it ends.
Processing that used to take months finished in a day. The backlog died. And something subtler happened: the team's default assumption shifted to cloud first, and moving our data storage fully to the cloud is now one of the team's biggest running initiatives. Nobody argued about strategy after that. Results ended the argument, which is the only way arguments like that ever end.
Teach the team you have#
Here is a constraint nobody warns you about: you will mostly not be allowed to hire your way out. The team you have is the team you build with, and my team had been hired for a different technical world. Models lived on laptops and personal virtual machines where nobody else could reach them. PySpark and Databricks were new to almost everyone. And the training budget was, you already know, tight.
So the training programme was us. I taught, over and over: sessions on Databricks, on PySpark, on Jira, on Confluence, always showing value rather than announcing policy, because people adopt tools when they watch their own problem get smaller, never because an email told them to.
Then I made teaching an institution: show and tells, every Friday, with rules that are loose on purpose. Share the model you are building. Share something you learned about the business. Share the course you are studying, a better way to do something, a piece of technology news. Everyone becomes able to do a bit of everyone's job, which is the only real insurance a small team has. And this institution outgrew us exactly like the documentation did: people from across the business now attend and give feedback, which quietly turned a team ritual into a standing relationship with our stakeholders. Alongside it I pushed everyone toward the studies the company sponsors, because in a small specialised team, personal development is not a perk, it is the growth strategy. The proverb holds: if you want to go fast, go alone; if you want to go far, go together.
Patterns, not heroics#
By now the team could see its work, find its knowledge, and stand on real infrastructure. The remaining gap was discipline. Deployments happened by hand, jobs run directly on the platform by whoever built them. It worked, and in a regulated environment it was quietly dangerous: not reproducible, not governed, not accessible to anyone but the author.
So we built the engineering layer: this is how we deploy here. Ingestion patterns, model development patterns, dashboarding patterns, and full CI/CD through GitHub workflows, with governance, reproducibility and access control designed in rather than bolted on. The mathematician Alfred North Whitehead wrote that civilisation advances by extending the number of important operations we can perform without thinking about them. That is exactly what a pattern is: one person's hard won competence, converted into the team's default.
And here I must tell the engine story properly, because the order matters. During my PhD research on distributed systems I had built an open source engine that lets you describe a data or machine learning pipeline once, as a small folder of configuration and Python, and run that same folder anywhere. It existed to serve my research. But standing in front of this team's engineering gap, I realised the thing I had already built was the stabiliser we needed. That engine is Ubunye Engine, its whole story is written from why convention is the real deliverable through how to use it with real examples, and it became the backbone of how the team does data engineering. Research met reality, and they strengthened each other.
Rolling patterns out is not an email. It was onboarding, practical sessions, hands on hours every Friday, working through real pipelines together until the patterns stopped being mine and became the team's.
Learn to let go#
Eventually I hit the ceiling every builder hits, and the ceiling was me.
I was running the process and leading the engineering at the same time, and doing both badly on alternate days. Worse, every structure I personally held together was a structure that would fail the week I went on leave, which would have betrayed the entire philosophy of this build. So I went to management and made the case for help. We grew the team. We brought in a project manager and scrum masters to run the process. And we began handing engineering capabilities we had built over to the platform teams, whose job that properly is, so they support us instead of us carrying everything. If you want the theory underneath that move, Team Topologies is the book: platform teams exist so that stream teams can flow.
Lao Tzu said a leader is best when people barely know he exists, and that when the work is done, the people say: we did it ourselves. I used to read that as poetry. I now read it as an engineering requirement. The cost of this phase is ego, and it is the cheapest price on this whole page once you understand what it buys.
What two years bought#
So what does all of this add up to? Told plainly, the way I would tell you across a table:
A new model used to take an unbounded amount of time to reach production. Nobody could tell you how long, because nobody could see the path. Now it ships in days. When backlogs build up, they clear in a day, where they once took months and sometimes broke things entirely. New people onboard from a documented path instead of an oral tradition. Every production model is understood, documented, and governed, and other teams use that documentation for their own work. The research in Accelerate found that delivery speed and stability rise together or not at all, and that matched our experience exactly: we got faster because we got safer.
And the change that matters more than every number: the team stopped being reactive. We were once a team that chased whatever was on fire that day. We are now proactive for most of what we do, which means we choose our work instead of our work choosing us.
The systems run whether I am in the room or not. That was the goal the whole time.
The key takeaways#
If you are about to build a data science team from scratch, this is what I would say to you before anything else.
- Decide what you believe, because everything else follows from it. Mine was: build systems that outlive the people who build them. Every move on this page is that belief wearing different clothes.
- Make the work visible before you touch technology. You cannot fix a team you cannot see, and no platform purchase repairs invisible work.
- Documentation is leadership, not admin. Write the guide you wish you had received. It will outgrow your team and become the organisation's memory.
- Play the long game, and know its price. Management will want countable results now, and your most important work will not be countable for months. Sometimes you will hold your line against what is being asked, because you can see what a scalable capability requires. Understand clearly: that can end as vision or as insubordination, and which one it becomes depends on what you deliver. Take that ownership with open eyes.
- You get budget for pain, not for infrastructure. Prepare the proposal before the crisis, because the crisis is coming. When it arrives, bring a costed plan, not a complaint, and put your name on the outcome.
- Teach the team you have. A weekly show and tell is a training programme with a budget of zero, and a small team where everyone can do a bit of everything is more resilient than a large team of silos.
- Patterns beat heroics. Convert individual competence into team defaults, and automate the important operations until nobody has to think about them.
- Let go on purpose. Hand the process to process people and the platforms to platform people. If the team only works when you are watching, you have built a performance, not a capability.
- Expect sacrifices, and choose them consciously. This build cost evenings, patience, political capital, and ego. Ownership means some of what you own may fail with your name on it. I would pay all of it again, because the alternative is a team that dies a little every time someone resigns.
None of this required genius. It required knowing why I was doing each thing, doing the unglamorous ones in the right order, and refusing to skip the boring ones. That is what building a capability from scratch actually is: planting trees, in the right sequence, whose shade you may never personally sit in.