When I moved from building a data platform to leading the team that builds one, I brought with me the assumption every technical person brings: that the platform is the thing. Get the architecture right, the pipelines clean, the models trustworthy, and success follows. A year and a half of leading has dismantled that assumption so thoroughly that I now believe close to the opposite, and I want to set it down properly, as the thing I'd most want to tell my past self and anyone stepping into a data leadership role: build the team before the platform. The platform was never the hard part, and it was never the point. The team is both.

This isn't a soft "people matter" platitude. It's a specific claim about where the difficulty and the value in data work actually live, arrived at the hard way, and it changes what you should spend your energy on.

The platform is the tractable part

Let me start with why the platform is so seductive as the focus, because understanding the seduction is how you resist it. The platform is a tractable problem. It has clear requirements, a definable notion of "done," and it yields to the technical skills that got you into a leadership position in the first place. When you're uncertain in a new leadership role — and you are, constantly — the platform is the thing you know how to do, and there's an enormous pull toward pouring your energy there, where you feel competent, and hoping the messier stuff sorts itself out.

And the platform genuinely matters. A bad platform undermines everything; I'm not arguing for neglecting it. But here's what a year and a half taught me: the platform, however hard it feels, is the solvable part. Given a competent team and enough time, you will build a good platform — it's an engineering problem, and engineering problems yield to engineering. The platform is difficult the way a hard puzzle is difficult: genuinely, but tractably, with a solution at the end.

The team is difficult the way people are difficult: unboundedly, unpredictably, and without a final solved state. And that's exactly why it's both the harder problem and the more important one.

Everything good flows from the team

Here's the realisation that reorganised my thinking. Every good thing I want — a great platform, a healthy data culture, work that actually changes decisions — flows from the team, and cannot be produced any other way.

  • A great platform is an output of a great team, not an input to one. You don't build a great platform and then hope for a team to run it. A capable, motivated, well-led team produces a great platform as a natural consequence of being those things. Invert your effort — build the team first — and the platform follows. Focus on the platform and neglect the team, and you get a platform that degrades the moment its overworked heroes burn out or leave.
  • The culture I've written about — the thing that determines whether the platform gets used — is a property of the team and how it engages the organisation. A team that communicates well, builds trust, and translates between the data and the business creates a data culture. No platform creates one. The culture flows from the people.
  • Resilience flows from the team. A platform built by one brilliant person who understands it all is fragile — it's one departure from crisis. A platform built by a team, where knowledge is shared and people are grown, is robust. What survives is not the cleverest architecture but the healthiest team, because the team is what adapts, maintains, and rebuilds when reality changes, as it always does.

So when I say build the team first, I don't mean "be nice to people while the real work is the platform." I mean the team is the mechanism by which every outcome you actually want gets produced, and the platform is one of its products. Get that ordering right and everything downstream gets easier. Get it wrong and you spend forever propping up a platform that a healthier team would simply have carried.

What "building the team" actually means

If the team is the priority, what does building it actually involve? Not the org-chart mechanics — the real, human work, which is mostly the communication and relationship work I keep discovering is the centre of every role I take:

  • Growing people, deliberately. The core of it. Are the people on my team becoming more capable, more autonomous, more able to do what I used to do myself? That growth is the long-term platform, because a team that's getting better builds a platform that keeps getting better. My output stopped being my work and became their development.
  • Building trust and safety. A team that trusts each other and feels safe to be honest — about mistakes, about not knowing, about disagreeing — vastly outperforms a talented team that's guarded and political. That psychological safety is something a leader builds, slowly, through how they respond when things go wrong, and it's worth more than any technical decision.
  • Translating relentlessly. Holding the why, connecting the team's work to something that matters, translating between the team and the organisation in both directions. I've written about the Scrum Master as translator and the leader as translator because it keeps being true: a huge part of building a team is the constant communication that keeps them aligned, understood, and pointed at the right thing.
  • Removing obstacles so they can do their best work. Much of leading is clearing the path — the decisions, the access, the priorities, the politics — so the team can actually build. The leader's job is often to be the platform the team runs on: the thing that removes friction so their capability converts into output.

None of that is architecture. All of it is what actually determines whether the architecture ever gets built well.

A platform is what a good team produces. Spend your leadership energy building the team, and the platform arrives as a consequence. Spend it building the platform while the team frays, and you'll have a monument that collapses the moment the people holding it up walk out. Order matters, and the order is: team first.

Two teams, one lesson

Let me make this concrete with two teams I've watched, because the abstraction earns its keep only against real cases. One was led platform-first: a brilliant, hands-on leader who owned the architecture, made the key technical decisions, and kept the hardest work for themselves because they were genuinely the best at it. The platform they built was excellent — for a while. But the team around that leader never grew, because the leader kept doing all the growth-worthy work; the team stayed junior, dependent, and quietly disengaged, because there was nothing meaningful for them to own. And when that leader eventually moved on, the excellent platform decayed within months, because it had been one person's platform all along, and that person was gone. The architecture was never the fragile part. The single point of human failure was.

The other was led team-first: a leader who was, frankly, a less dazzling engineer, but who spent their energy on growing the people — handing them the hard problems, letting them struggle and learn, building the trust that let them be honest, translating relentlessly between the team and the organisation. Their platform was, at any given moment, slightly less polished than the first team's. But it was everyone's platform, understood and owned across the team, and it got steadily better, and it survived departures and pivots that would have sunk the other. The team-first leader looked less impressive in the moment and built something far more durable. That contrast, seen enough times across enough teams, is what turned my belief from a nice idea into a conviction I'd stake a career on.

The hardest thirty seconds of the job

I want to name the specific difficulty, because the philosophy is easy to nod at and hard to live, and it lives or dies in one recurring moment. It's the thirty seconds when someone on your team is stuck on something you can see the answer to, and every instinct — every year of being the person who solves things — is screaming at you to take the keyboard and just fix it. You'd be faster. It would be done. The itch is almost physical.

And the whole job, in that moment, is to not. To sit on your hands, ask a question instead of handing over an answer, and let them find it — slower, messier, with you biting your tongue — because them finding it is how they grow, and their growth is the actual product. I have failed this test more times than I'd like: taken the keyboard, solved the thing, felt the small hit of competence-satisfaction, and watched the person deflate slightly because I'd just told them, without words, that I didn't trust them to get there. The hardest part of leading isn't a strategy or a framework. It's those thirty seconds, repeated daily, of choosing the team's growth over your own itch to be the one who solved it. Get good at those thirty seconds and you're most of the way to leading well.

How you know it's working

Because team-first leadership is slower and vaguer than platform-building, you need different signals to know you're succeeding, and learning to read them took me a while. The platform-first leader knows they're winning when the architecture is elegant. The team-first leader has to learn subtler tells:

  • People solve problems you used to be called for. The clearest signal: things that would once have escalated to you get handled without you, and you find out only afterward. Your growing irrelevance to the day-to-day firefighting isn't a threat — it's the goal, achieved.
  • People disagree with you, out loud. A team that argues with its leader openly and without fear is a team with real psychological safety, and that safety is worth more than agreement. The day someone junior tells you you're wrong, in front of others, and is right — that's a day to quietly celebrate, because you've built something healthier than deference.
  • The team gets better even when you're not looking. When you take leave and things don't merely survive but improve, you've built a team rather than a dependency. The ultimate measure of team-first leadership is how well things go in your absence — a strange and humbling thing to optimise for, because you are, in a real sense, working to make yourself unnecessary.

None of these show up in an architecture diagram, and every one of them matters more than one. Learning to take satisfaction from these signals, rather than from the elegance of something I built with my own hands, was the actual internal shift of becoming a leader.

The uncomfortable reorientation for a technical leader

I won't pretend this reordering was comfortable, because it wasn't, and I think that discomfort is worth naming for anyone facing the same transition. It meant accepting that my proudest skill — the technical craft — was no longer the headline of my job, and that my new, harder, more important work was in the domain I felt least trained for: the human one. It meant sitting on my hands while the team solved problems I could have solved faster, because them solving it was the point. It meant measuring my success not in what I built but in what they became, which is slower, vaguer, and far less immediately satisfying to a person who got here by building things.

But the evidence accumulated until I couldn't argue with it. The teams and platforms that thrived were the ones where the leader invested in the people. The ones that struggled were the ones where a technically brilliant leader treated the team as a means to the platform rather than the platform as a product of the team. Every time, the same lesson: the human investment compounds, and the platform-first investment plateaus.

Where this leaves me

So here's the philosophy I've built, and the flag I'll plant: in data work, as in most work involving humans and complexity, the team is the thing, and the platform is what a good team makes. If you're stepping into a data leadership role and every instinct is pulling you toward the architecture — because it's tractable and you're good at it and the people stuff is hard — that pull is the thing to resist. Build the team first. Grow the people, build the trust, do the translation, clear the path. The platform will follow, better and more durably than if you'd built it first, because it will be the product of something healthy rather than something propped up.

I came into data believing it was fundamentally about people communicating, took a long detour deep into the technical, and leadership has deposited me right back at that belief, now proven from the other side: that the human layer isn't the soft part around the real technical work — it's the load-bearing structure that everything else rests on. Build the team before the platform. Everything you actually want is downstream of the people. I wish someone had told me that on day one; consider yourself told.