A month ago I led a data platform for the first time — not built one, led the team that builds one. It's the kind of move that looks, from the outside, like a natural next step: you're good at the work, so now you're in charge of the work. And a month in, I can report that it's a far stranger and more disorienting transition than that framing suggests, because the thing that got me here — being genuinely good at the technical craft — turns out to be substantially not the job anymore. These are my honest notes from month one, written while it still feels new enough to see clearly.

The uncomfortable demotion of your best skill

Here's the disorientation, stated plainly. For years I built my professional identity on getting good at the hands-on work — the architecture, the pipelines, the streams, the hard technical problems solved. That competence was the thing I was proud of and the thing that got me promoted. And leadership quietly informs you that this competence, while nice to have, is no longer the point of your day.

Because now the work isn't me solving the hard problem. It's the team solving it, and my job is to make that possible — which mostly means not solving it myself, even when I could, even when I'd be faster, even when my hands are itching to just take the keyboard. The hardest thing about month one has been sitting on those hands. Every instinct I've built says "I can see the answer, let me just do it." And every one of those instincts is now, mostly, wrong — because a leader who solves the team's problems for them builds a team that can't solve its own.

That's a genuinely uncomfortable reframing of your own value. The skill you're proudest of becomes the thing you have to restrain, and your new value is measured in something much less tangible: whether the people around you are getting better, unblocked, and able to do without you.

What the job actually turned out to be

So if it's not solving the technical problems, what is it? A month in, my rough answer is that leading the platform is three jobs, none of which is the one I trained for:

  • Removing obstacles. A surprising amount of leading is just clearing the path — getting the decision made, the access granted, the priority sorted, the blocker unblocked — so the people doing the actual work can keep doing it. It's unglamorous and it's most of the value. The team's velocity is often gated not by their skill but by things only I'm positioned to move.
  • Holding the "why" and the direction. Individual contributors can head-down into the what and the how. Somebody has to keep hold of the why — where we're going, what matters, how today's work connects to something larger — and translate that so the team's effort points the same way. That translation, it turns out, is a lot of the job, which quietly delights the communication person in me.
  • Growing people. The single biggest shift: my output is no longer my output. It's the team's, and specifically the team's growth. Am I making these people better? More capable, more autonomous, more able to do the thing I used to do? That's the actual product now, and it's slow, human work that no amount of technical skill prepares you for.

None of these is what I was good at a month ago. All of them are what I need to get good at now.

The communication thread, again

I keep noticing — and I shouldn't be surprised anymore — that the parts of this new role that feel most central are the ones that are fundamentally about communication. Translating direction. Making the why legible. Understanding what each person actually needs to grow. Mediating between what the team can do and what the organisation wants. I came into data from communication, and every rung up the ladder seems to lead me back toward it, as though the technical years were a long detour that's depositing me exactly where I started, with better context.

That's oddly reassuring, actually. The thing I feared about leadership — that I'd be leaving behind the craft I love — is real, but what I'm moving toward isn't foreign. It's the human, communicative work that I've always suspected was my actual centre of gravity. The technical depth wasn't wasted; it's what lets me lead this particular team credibly. But the leading itself is a communication job wearing a technical hat.

The skill that earns you the leadership role is the one you mostly have to stop using once you're in it. Your new job isn't to be the best engineer in the room. It's to make the room full of better engineers than you had to be alone.

What I'm holding onto from month one

I don't have this figured out — a month is nothing, and I'm sure I'll read this back in a year and wince at how much I didn't yet know. But two things already feel like anchors. First, that sitting on my hands — resisting the urge to solve it myself — is not passivity but the actual discipline of the job, and the sooner I make peace with my technical skill being a supporting act rather than the headline, the better I'll lead. Second, that the role is far more me than I feared, because underneath the management-speak it's a communication and people job, and that's home ground I'd half-forgotten I had.

The keyboard is harder to give up than I expected. But the thing on the other side of giving it up — a team that's better because I led it well, rather than a problem that's solved because I did it myself — is a bigger and better thing to be good at. Month one has mostly been learning to want the right prize. I'll let you know how month twelve goes.