If you’re the strongest engineer on your data team, you believe that’s your case for the next level. You keep clearing the technical bar, and you’re still senior.
I believed the same thing. Getting better at the tech is what gets you to the next level, and that’s bullshit I held on to for half my career.
Somebody decides who gets the next level, and I’ve been close enough to one of those decisions to ask why it went the way it did.
Here’s a quick story: I was working for a company, where one of the teams left without a lead, so the promotion committee, which I was part of, got together and started discussing who should lead it, and the CTO voted for Kamil over Nick.
They weren’t even the same level as programmers. Nick is significantly better, one of the smartest (and nerdiest) people I know, and Kamil is good in general, but average compared to him.
So, I asked the CTO, “Why Kamil instead of Nick?“, and his response was “Nick codes a lot“.
I knew what he meant. Nick was focused on coding, and if you asked him, he’d say “good design“ was the point of his work. He’d prioritise beautiful code over stakeholder needs any time.
Kamil got the team, with Nick on it, and the job came with direct reports and more pay than Nick’s.
If your case for the next level is that you’re the strongest engineer on the team, you’re making Nick’s case, and Nick’s case lost to the weaker programmer.
Why you’re stuck at senior when you’re the stronger data engineer
Kamil wasn’t great at the half of the job that isn’t code either. He was much better than Nick at prioritisation, still not great, and that was enough to get him the team.
The call he was better at is the one Nick kept making the other way, beautiful code or what the stakeholder needs. If you lead, you make that call all week, so whoever picks a lead is picking the person who’ll make it the stakeholder’s way more often, and Kamil only had to beat Nick at it.
Scope and ownership move you further than another tool, and your work has to tie to what the business needs, which you already know.
You lose the lead job on what you believe your work is for, and the bar you’re failing is lower than the technical one you keep clearing.
Getting better at the tech has a ceiling
Getting better at the tech does pay sometimes, but not a lot. It has a ceiling, especially in the age of AI and flat organisations.
Most of the advice ranking for “how to get paid more without becoming a manager“ tells you to go deeper and become the expert, and I don’t buy it past a point. Today, it doesn’t matter what your title is. You are required to work closely with business stakeholders, so having tech skills only is limiting you.
This is a strong belief I hold, and I don’t want to offend anyone, but I think it’s why a lot of people find it hard to find a job. They trained themselves to be code monkeys, and AI is a code monkey too, and it’s much cheaper than a person who says “You are right” all the time.
By “code monkey“ I mean the engineer who only codes. Choosing to stay senior and keep your focus on the stack is a fair choice, and I’m not talking about you if you’ve made it. If all you do is code, you have no value added compared to Claude Code.
Subscribe if you want your team out of constant urgent fixes and your work seen by the people who fund it, and I’ll send you the two pieces a week I write on how to do both.
Do the lead’s job without being asked
I was driving initiatives, communicating downtime, starting 1:1s with my team, and mentoring them. Essentially everything a lead does, but without being asked to do so. All four came before the team moved under me.
These days I’m Head of Data Engineering.
You don’t have to be great at any of the four to start, any more than Kamil had to be great at prioritising.
When something breaks, tell your stakeholders it affects immediately, without waiting for anyone to ask you to. Nobody gives you a title for that, and it’s still a lead’s job.
Start 1:1s with the people on your team too, which I did without anyone asking me to.
Drive a migration or a tool change
For me, driving initiatives meant migrations, tools, and stuff. I’ve done it many times, and I drove ETL to ELT and Redshift to Snowflake before getting the lead role.
When you drive the work, you’re the one making the priority call, the same call Nick made the other way. At some point in a migration, the beautiful version and what a stakeholder needs pull apart, and if you’re driving, you decide which one wins.
Pick what the stakeholder needs, before anyone tells you to. Nobody outside the data team gives a shit how beautiful the code is, and that call is the one Kamil got the team for.
From my chair, the engineer who drives a project takes work off my plate.
Mentor by leaning on their strengths
Mentoring is where I made Nick’s mistake, and I made it with a person.
I had someone who transitioned from a different career. He was experienced in his other job, and that was his first engineering job. Instead of leaning on his strengths and understanding he needed time to get experience, instead of encouraging him, I was criticising him and showing him how to do things “the right way“. I prioritised code over people.
He didn’t say why he left, but we all knew.
That was a shitty way to mentor anyone, and it’s the same belief Nick had, that the code is the point, aimed at a person who was experienced in another job and new to this one.
So do the opposite of what I did, and lean on their strengths, give them time to get experience, and encourage them while they get it.
Take the scope first, then ask for the money
This is the order it came in for me: First, scope, then the pay, and shortly after the increase, I got the title, too.
The pay was a 40% raise, and I asked for it, kind of, because I had a benchmark, an offer at that level, which is my standard pay advice.
If you copy one thing, copy the order. I asked after the scope was already mine, so the benchmark priced a job I was already doing. Ask before you have the scope, and the same offer prices a job you’re only promising to do.
I wouldn’t stop at the raise, though, because the title came shortly after mine, and the title is what moves you into a different band.
For your own case, the ready-to-use version is my digital twin, and it comes with the annual subscription.
Final Thoughts
My belief is that you don’t need the title to lead. Mine was the last thing to arrive, after the scope and after the money.
If you’re stuck at senior, it’s on you. The CTO explained his vote in four words, and they were about a choice Nick made every time the code and the stakeholder pulled apart, which he could have made the other way.
You make the same choice this week, on whatever you’re driving, and you can make it the stakeholder’s way before anyone gives you a team.
And this is all Data Gibberish is about.
—
Until next time,
Yordan
PS: If you want to make the next decision that’s yours without waiting for anyone’s permission, subscribe for the year and ask my digital twin what I’d do before you make it. It’s an AI assistant that answers the way I would.
PPS: Your yearly subscription also comes with my course Design Your Promotion and Get Paid at the Right Number.