Nobody warns you about the identity crisis. You spend years getting really good at a thing. You build your reputation on being the person who can pull insights from data, build models, write clean code, or design elegant architectures. Then you get promoted into leadership and suddenly none of those skills are your primary job anymore.
The first time I sat through a full day of meetings without opening a dataset, I felt useless. Genuinely useless. I went home thinking, “What did I actually accomplish today?” The answer, though I didn’t recognise it at the time, was that I’d unblocked three teams, aligned two stakeholders on a priority, and talked a frustrated engineer out of quitting. But none of that felt like “real work” because real work, in my mind, meant writing code or building models.
That mental model almost sank me. And I’ve watched it sink others.
The Skills That Got You Here Won’t Get You There
This is the central truth of the transition, and it’s genuinely painful to accept. The technical excellence that earned you the promotion is now maybe 15% of your job. The other 85% is stuff you were never trained for and probably aren’t naturally good at.
Communication becomes your primary tool. Not writing documentation or presenting analysis, but persuading, negotiating, and translating between groups that speak different languages. Your job is to explain technical constraints to business leaders who want things faster, and explain business priorities to engineers who want to build things properly. Both sides think the other is being unreasonable, and you’re in the middle.
At Westpac, I spent my first year as a leader preparing detailed technical presentations for executive meetings. They were thorough, accurate, and completely wrong for the audience. An executive finally pulled me aside and said, “Mal, I need you to tell me what this means for the business in two sentences. Save the technical details for your team.” That conversation changed how I communicate. Two sentences first. Details only if asked.
The Delegation Problem
The hardest thing I’ve had to learn is to stop doing the work myself. When I see a data quality issue, my instinct is to open a notebook and fix it. When a model isn’t performing well, I want to look at the features. When a dashboard is wrong, I want to dig into the SQL.
This instinct is a trap. Every hour I spend doing individual contributor work is an hour I’m not spending on the things only I can do: setting direction, removing obstacles, building relationships with other leaders, and making sure my team has what they need to succeed.
I had a mentor who put it bluntly: “If you’re the VP and you’re still writing SQL, you’re stealing work from your team and neglecting your actual job.” It stung. It was also correct.
The practical challenge is that delegation feels slower and lower quality at first. Someone on your team will take twice as long to do something you could do in an hour. They might do it differently than you would. That’s fine. That’s the point. Your job is to build a team that can operate without you, not to be the indispensable bottleneck.
What Nobody Tells You About Meetings
I used to think meetings were a waste of time. Now I understand that, for a leader, meetings are where the work happens. Decisions get made in meetings. Relationships get built in meetings. Information flows through meetings. A well-run meeting is the most efficient tool a leader has.
The key word is “well-run.” Most meetings are terrible because they have no clear purpose, no agenda, and no defined outcome. I’ve become ruthless about meeting hygiene. Every meeting I attend has a stated purpose and an expected output. If I can’t articulate why I need to be there, I decline.
This sounds obvious. In practice, most leaders accept every meeting invite because they’re afraid of missing something. I’ve learned that missing a meeting where I wasn’t needed costs me nothing, but attending one wastes an hour I can’t get back.
The Loneliness Nobody Mentions
Leadership is lonely in a way that’s hard to explain until you experience it. You can’t vent to your team about organisational politics because it would undermine their confidence. You can’t share everything you know about company direction because some of it is confidential. You carry context that nobody else has, and the weight of decisions that affect people’s careers and livelihoods.
At The Smith Family, I made a restructuring decision that eliminated two positions. It was the right business decision. I still think about those conversations. The technical work I used to do never kept me up at night. The people decisions do.
Building a peer network of other data leaders helped more than anything else. People who understand the specific challenges of leading data teams, who’ve faced similar situations, and who can offer perspective without judgment. If you’re moving into leadership and you don’t have this, start building it now.
Staying Technical Enough
There’s a trap on the other side too. Some leaders completely abandon their technical roots and become pure politicians. They lose the ability to evaluate technical proposals, spot overengineered solutions, or call out when someone is hand-waving past a hard problem.
I try to stay technical enough to be dangerous. I don’t write production code anymore, but I review architecture proposals and can tell when something doesn’t add up. I stay current on major developments in AI and data engineering, not by reading every paper, but by having regular conversations with people who do.
The specific line I try to hold: I should be able to ask a good question about any technical decision my team makes. Not make the decision myself. Ask the question that surfaces the tradeoff or risk they haven’t considered.
Advice I Wish I’d Had
If you’re an analyst or data scientist thinking about leadership, here’s what I’d tell you.
Start leading before you have the title. Volunteer for cross-functional work. Mentor someone junior. Run a project where you have to influence people who don’t report to you. These experiences will tell you whether leadership energises you or drains you.
Get comfortable with ambiguity. Technical work has right answers. Leadership rarely does. You’ll make decisions with 60% of the information you want and live with the consequences. If that sounds terrible, the individual contributor path might be a better fit, and there’s no shame in that.
Invest in communication skills now. Take a writing course. Practice presenting to non-technical audiences. Learn to tell stories with data instead of just presenting data. These skills compound over years and they separate good leaders from great ones.
Find a mentor who’s done the transition. Not a leadership coach who’s never been in a technical role. Someone who went from building things to leading teams of people who build things. They’ll understand the specific identity crisis you’re going through in a way that generic leadership advice never will.
And finally, give yourself grace. The transition takes two to three years to feel natural. You’ll have days where you miss the code. You’ll have days where you question whether you made the right choice. That’s normal. The discomfort means you’re growing.
