You did the thing. You learned SQL, you built the portfolio, you taught yourself enough Python to be dangerous, and somewhere along the way a company decided to pay you to do data work. That was three years ago. Or five. Or ten.
So last week, feeling a bit stuck, you searched for how to grow as a data analyst, and the results were uncanny in their familiarity. Learn SQL. Build a portfolio. Contribute to open source. Get comfortable with the command line. The exact advice you followed to get in, served back to you as the path forward, as if the only direction a career moves is the first ten metres of it.
The advice isn't wrong. It's just answering a different question than the one you're asking, and it doesn't seem to know the difference.
Two different problems wearing the same words
"How do I succeed in data" is not one question. It's at least two, and they barely overlap.
The first is the entry problem: how do I go from outside the industry to inside it. This problem is wonderfully legible. It has a clear finish line, getting hired, and a clear set of gates between you and it, namely the skills a screening process can check for. You can list the steps. You can put them in a numbered post. You can measure your progress in commits, certificates, and projects shipped. The whole thing is shaped like a checklist because the problem genuinely is one.
The second is the growth problem: I'm already in the role, doing real work in a real organisation, and I want to get better and go further. This problem is the opposite of legible. There's no finish line, no universal set of gates, and the things that actually move you forward are maddeningly specific to your company, your team, your manager, and the particular tangle of systems and politics you happen to be sitting inside.
Almost all the advice that exists is built for the first problem. And it's built for the first problem for reasons that have nothing to do with which problem matters more.
Why the useful advice doesn't get written
Start with audience size. There are vastly more people trying to break into data than there are people five years deep trying to level up, and there always will be, because every senior analyst was once an aspiring one but not vice versa. Anyone optimising content for reach writes for the larger group. The incentives of the entire advice ecosystem point at beginners.
Then there's how teachable the two problems are. The entry problem generalises beautifully. "Learn SQL" is true for essentially everyone, everywhere, regardless of industry or company. That's what makes it writable. The growth problem refuses to generalise. The single most useful thing for your career this year might be learning to say no to a particular stakeholder, or understanding why finance distrusts your numbers, or realising the dashboard nobody opens is political cover rather than a tool. None of that compresses into a blog post, because the moment you make it general enough to publish, you've stripped out the specifics that made it useful.
There's also a survivorship problem in who's doing the writing. The people most visible giving data career advice are disproportionately the ones who found the entry phase notable enough to document it, which is to say people relatively close to it. The person fifteen years in, who's forgotten what it felt like not to know, mostly isn't writing listicles. They're just doing the work, and the work is the kind that doesn't photograph well.
So the genuinely useful mid-career knowledge stays where it's always been: trapped inside individuals, transmitted in hallway conversations and one-on-ones and the occasional good manager, and almost never written down in a form you can search for at 11pm when you feel stuck.
What the growth problem actually rewards
If the checklist doesn't apply, what does. Not another tool, mostly. The mid-career constraint is rarely "I don't know enough functions." It's some combination of judgment, scope, and translation.
Judgment is knowing which problem is worth solving, which is a completely different muscle from being able to solve it. Early on, someone hands you the problem and you're graded on execution. Later, the value is in picking the right problem from a dozen plausible ones, and that skill is invisible to every certificate program because it can only be learned against real stakes.
Scope is the difference between answering the question you were asked and understanding the decision underneath it. The analyst who delivers the requested number is useful. The one who works out what the requester is actually trying to decide, and reshapes the deliverable around that, is the one whose work changes outcomes. That's not a SQL skill. It lives in asking the right question before you start, which is where this month's Blunt Bianca arc (5 June) picks it up.
Translation is making your work legible to people who will never read your query. The most technically correct analysis that nobody acts on is worth less than a rougher one that changes a decision, and the gap between them is entirely communication. This compounds harder than any technical skill, and it's the one beginners are told least about, because at the entry stage nobody's asking you to translate anything.
None of these have a course. All of them are what the second half of a data career is actually made of.
The way to think about it
Here's the reframe worth keeping. The legibility of a piece of advice is a signal about who it's for. If it comes as a clean checklist with a clear finish line, it's almost certainly aimed at the entry problem, no matter what the title promises about "levelling up" or "senior skills." Genuinely mid-career advice tends to be uncomfortable, contingent, and annoyingly hard to act on directly, because the real answer is usually "it depends on your situation, and here's how to think about your situation" rather than "do these five things."
So stop looking for the next course to fix the stuck feeling. The stuck feeling is not a skills gap you can close by learning one more tool, and treating it like one is how people end up with six certificates and the same job. The thing you're missing isn't on a syllabus. It's judgment, scope, and the ability to make your work matter to people who don't share your vocabulary, and those are built by paying deliberate attention to the specifics of where you actually work, which no blog post can do for you. Including this one.
For more on what good actually looks like at small scale, where every one of these pressures is concentrated, see data work on a small team (31 May). And for why the entry-level advice keeps getting recycled even when it stops applying, the case against "just learn SQL" (3 May) is the companion piece to this one.
Frequently Asked Questions
So is the beginner advice actually bad?
No, it's good advice aimed at a real problem. Learning SQL, building a portfolio, and shipping projects is exactly right when the question is how to get hired. The failure is the relabelling: serving entry advice under a "how to grow" headline, so people who finished the entry phase years ago keep being pointed back at the start line. The advice is fine. The targeting is broken.
What should I actually do if I feel stuck mid-career?
Look at your specific situation rather than the generic web. Which decisions at your company would be better if the data work were better, and are you working on those or on whatever lands in your inbox? Who acts on your analysis and who ignores it, and why? The useful next move is almost always context-specific, which is exactly why no article can hand it to you. Find a senior person who knows your environment and ask them, because that knowledge mostly travels by conversation.
Doesn't more technical skill always help?
It helps until it doesn't, then it plateaus hard. Past a certain point, another framework or a deeper grasp of window functions adds very little, because your constraint stopped being technical a while ago. People who keep grinding technical skill into a non-technical bottleneck stay stuck and get frustrated, because they're getting demonstrably better at the thing that isn't the problem.
Is this just an argument for becoming a manager?
No. Judgment, scope, and translation are individual-contributor skills, and the senior IC track rewards them just as much as management does, often more. You can grow enormously without ever managing a person. The point isn't "go manage people," it's that the growth axis stops being technical and starts being about impact, whichever track you take.
Why is mid-career data advice so rare when there's so much content?
Because it doesn't generalise and it doesn't scale. The useful version is specific to a company and a situation, so it can't be written for a wide audience without losing the specificity that made it useful. And the people who hold that knowledge are usually too deep in the work to be writing for beginners. The economics of content point at the largest, earliest-stage audience, so that's what gets made.
