I just came back from a trip to London, where I did some workshops, made some announcements and, more importantly, said bye to Plamena, my manager and our CFO.

So, her new place is a small company without a data team, and she told us she has no idea what they’ll need to do when they start hiring one and building a data stack.

One of my Data Engineers was very surprised and reacted on the spot.

What do you mean, you don’t know what tools to use? Snowflake, and everything we use here.

I told her I’d probably just use PostgreSQL and Excel.

Plamena may not be a technical person (she openly admits she knows nothing about the technicalities around data), but as an experienced finance person, she knows that a small company can’t afford to spend over a quarter of a million dollars just on the warehouses. Add a BI tool, reverse ETL, data observability, and a couple more, and we’re talking about way over half a million.

I’d start with Postgres and Excel because at a company that size, your tool budget is your hiring budget. The stack everyone uses also eats the time you need for feedback, and while you integrate it, you’re stuck in fake productivity.

You also get the six questions I ask myself before buying any tool. They’re a way of thinking about the problem, and you answer them for your own company.

Say you’re the first data person in the company, and you’re given a budget to get started. Like most strong technical people, you decide to run a platform MVP first.

So, you get Snowflake for $100k/year, Fivetran with an estimated cost of $25k/year, and Looker for $75k/year. At this point, you are already looking at $200k/year just on the critical tooling.

In a small company, that’s the budget for your first few team members, and you’ve already spent it. This immediately turns you into a team lead without a team, which means you’re responsible for:

• tool integration

• pipeline implementation

• reporting

• stakeholder management

• strategising

And you’re supposed to do everything alone. Isn’t that a setup for failure?

The stack eats your time too

But the problem is not only financial. It’s also a project management issue.

Implementing a complex amalgam of big tools requires time. Even tools that promise you can get started in hours actually need time to move from a PoC to production. Not to mention the learning curve, legalities, and locking yourself into a contract for what could be the wrong tool for the job.

With all of this, you find yourself fighting the stack far more than doing what you’re there to do.

While you integrate, the business works around you in spreadsheets anyway. That’s the obvious cost, and I won’t repeat how the business moves without you.

The less obvious one is fake productivity. You keep thinking, “just that small bit and we’re done”, instead of delivering what you already have and collecting the feedback. It’s the reason I’d rather scope a minimum viable data product that proves value fast than build a bold one.

But the thing is, you never run out of small bits. There’s always one more source to connect, one more model to clean up, one more permission to set. Then one more workaround to finish before you show it to anyone (it’s almost ready anyway). Each of them is real work, and each of them feels like progress. So you keep saying you are almost done.

Meanwhile, nobody outside the data team sees anything. Nobody has the chance to tell you that you are building the wrong solution, that what they need changes while you’re integrating, or that they don’t need it in the first place.

That’s why I call it fake productivity. You are busy every single day, and you still learn nothing about whether anyone needs what you are building. Every small bit you add pushes the feedback further away and makes “this is not what I need” more expensive when it finally comes.

I give myself five working days from the day I start building to put something ugly in front of the person who asked for it. With Postgres and Excel, that’s realistic. While you are still integrating Snowflake, Fivetran and Looker, it isn’t, and the small bits keep coming.

I’ve seen this many times, mostly with people I’ve coached who came to me after a failure like this.

It doesn’t matter what they bought, and they don’t come to me for help picking tools. They come to learn data strategy and to think like a leader who connects tech and business.

What I told Plamena

I obviously don’t know enough about Plamena’s new place (even she doesn’t know enough yet), but my answer was based on what I already knew, and it was only for the first couple of months. I mean, spreadsheets were one of the options for our own People Analytics project.

But, when do you move off PostgreSQL and Excel?

Once you have clarity about the demand in terms of ingestion and query patterns, workloads, and all sorts of technical and business requirements. You only get there through feedback, and that’s why it matters more than anything.

Read more

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.

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.

If you’ve started owning your own deadlines, the date you give is the day you’d finish if nothing got in the way. The project matters to the people asking, you want them happy with you, and you genuinely want to make it.

I gave dates like that for years, and somebody had to say it to my face before I did anything about it.

My boss doubled every estimate I gave him

10, maybe 12 years ago, I was a software engineer at a video streaming company, sitting right next to Deyan. He asked me how long a new feature would take, a live chat, and I told him it was easy and I’d be done in two weeks.

He didn’t even blink. “So, one month”.

Then he told me, “You haven’t hit any of your estimates in a while”. He’d learned that doubling whatever I said was right most of the time.

It didn’t feel good, and it wasn’t a massive surprise either, because I’d heard I wasn’t great with estimates a few times before, and I’d grown up with it. Whenever I asked my dad when something would be done, he gave me a date, it was always his best case, and we never hit it.

So I knew I had a problem, and now somebody at work had told me I suck at estimating. It took me a few years of experimenting and reading to fix it, and I even tried Six Sigma, which I knew wasn’t for me.

Part of my problem was the interruptions eating my week, and part was that my two weeks was the best case, the time the feature would take if every hour of those two weeks went on it.

Why your best case is the date you give

You give the best case because you’re trying your best. You probably don’t say the assumptions out loud, but the date you give is the one you’d hit working uninterrupted with everything going right, and you give it because you want to deliver by then.

That date assumes a perfect world, where every task is as clear as it looks, nobody needs your help or a second pair of eyes, and nothing breaks.

None of that happens, because things break all the time, and the more experienced you get, the more calls you get pulled into.

A missed date costs you trust

When you miss your own dates, the cost is trust. Once your boss says you haven’t hit any of your estimates in a while, they’ve stopped trusting you, and it doesn’t stay with the estimates. The ambitious projects, the promotion and the raise you’re chasing start slipping with it.

After enough optimistic dates my manager stopped believing me, and the math was on his side.

There’s a weird thing I keep seeing, too, where you miss a day, the next project starts a day late and ends up a week late, and then everything slides like an avalanche. I don’t know why it happens, it’s just what I’ve seen.

And it gets worse with size, because on a small project you miss by a day or a few hours, and I’ve had a month’s estimate take three months, a whole quarter.

Never estimate on perfect conditions

You must never estimate on perfect conditions, because they don’t exist, least of all once you’re chasing a senior or lead title. The question I ask is how long it’ll take given the reality of my week.

Your week has three things in it that the best case ignores, the meetings, the downtime and the unknowns.

Nobody gets 8 hours of work out of an 8-hour day. There’s the standup, the planning, the Slack thread you got pulled into, the call that was meant to be quick, and lunch, which I forgot myself when I listed these on the stream. Open your calendar and count the hours of real work you got last week, because your contract hours won’t tell you.

On my first day at my second job, my boss told me, “In an 8-hour day, if you manage to pull 6 hours of productive work, that’s amazing. That’s the best I can dream of”. These days I try to stay hands-on, and if I get 2 to 3 hours of focused work a day, that’s a great day. For most people it’s 4 to 6.

Then there are the days you won’t touch the work at all. Everybody on my team has one rota day a week, when they take the incidents and the questions so everybody else can focus on their tasks. Add holidays and planning days on top. When my team goes to our London office for 3 days of planning and team activities, those are 3 days out.

And then the unknowns, which is where most of the damage is. Access you don’t have yet, a tool nobody on the team has used, a decision somebody else has to make, and another team you’re waiting on, where you’re not their priority.

None of those show up in a best case, so each one needs a number.

How to estimate data engineering projects

Cut the work into tasks of 2 days or less and size each one. Multiply each task’s hours by an ambiguity factor, add 10%, divide by your real focus hours a day, round up and add the days you won’t work. Without the factors and the 10% you get your earliest date, and with them, the date you’d bet on.

It’s the method I’ve used for years, plus what I’ve added since. The first version ended on one single number, which is a funny way to run a method whose whole point is the gap between two numbers.

Big projects get estimated one stage at a time

The formula only works on something you can see the end of. So a big project gets split into stages, you estimate the next one, and the stages after it get their dates when they’re next.

I do it for four reasons.

• If something goes wrong or priorities switch, you miss one stage.

• Your stakeholders get something they can see, touch and play with, more often.

• In six months you might have much better ideas, and the project might look different by then.

• Nobody can plan tiny tasks across a three-month project, and with 100 of them on the list you lose sight of what the project is for.

Send both dates and promise the second

You end up with two dates, the earliest you could be done and the date you’d bet on. I always send both and say it could be done between this date and that one.

Your stakeholders will still hear the first one and hope for it, and I haven’t found a way to stop that, so I promise the second one anyway.

An estimate is a promise. Only promise the date you’d bet on.

My personal philosophy is that I want to be trustworthy, so I do what I said I’d do, and an estimate is something I said I’d do.

It goes beyond you, because if you promise the marketing team their data by a date, they plan a campaign around it, and when you miss, you’ve blocked their work as well.

I under-promise and over-deliver, so if I’m done three days before the date I promised, people are happy. If you give them the optimistic date instead, those three days of stress are yours, and you put them there yourself.

Read more

You know which model or DAG costs your team hours every week. The ticket that says so has been in the backlog for months, and you’ve started fixing it in pieces, on a Friday afternoon or inside the estimate for the next pipeline that touches it, without telling anyone.

I did the same. I cleaned up months of tech debt and got a “thank you” from the people close to the work, but outside the team I got only silence, and when reviews came up, I struggled to fill the doc. (The whole story is in No one gets hired for clean pipelines)

The story of that work never made it out of the team, and nobody outside it ever saw what the debt had been costing them. Your ticket has the same problem before you’ve written a line of the fix. It says how the pipeline makes you feel and nothing about what it costs anyone, which makes it a complaint, and complaints don’t get sprint time.

Your debt ticket says the pipeline is fragile and stops there

Open your last debt ticket and count the words like “fragile“, “flaky“ and “nobody wants to touch it“. Then count the words that say what it costs somebody, and who that somebody is.

Whoever owns the sprint ranks your ticket against new sources and models that somebody asked for and is waiting on, so each of those comes with a requester and a cost of waiting. Your ticket has neither, so it loses every ranking on arithmetic, and nobody has to be against you for that to happen.

You’ve heard that “tech debt” means nothing to the person deciding. I said it in 4 awkward stakeholder conversations you have to master, and half the internet says it with me. Swapping the word for a nicer one leaves the ticket asking for the same thing.

Chelsea Troy describes that thing from the other side:

It sounds to the business like the engineers are asking for three weeks free from the obligation to release any features

Now compare it with how Rex Morgan words a request:

We currently spend 8 hours a week on these manual tasks we neglected to automate.

His sentence tells the person deciding what they pay every week to leave things as they are, which is the one thing your ticket leaves out.

A repayment date keeps moving until the debt has a price

A lead system test engineer posted a rule on r/ExperiencedDevs after 7 years at one org. The rule is that anything logged as debt “needs a Repayment Date“.

It’s half the fix, and somebody in the same thread found the hole:

What happens when they don’t meet it? Give you another?

For a long time I ran debt tickets with cost and date as two equal fields. It didn’t work.

My read on why is that a date you set yourself costs nobody a damn thing to move, so it moves. A schema change upstream eats the sprint, the date slides, and the only thing spent is your credibility, a bit more of it with every date you give after that one.

A cost that comes back every month keeps running whatever happens to the date. Put it on the ticket as hours a month, plus compute a month when it’s on the bill, and every time the date moves the ticket records who moved it and adds another month to a running total. Moving the date stops being free, because somebody has to agree, out loud, to pay for another month.

The price changes what “not now“ means, too. Today it’s what happens by default to anything without a price, with nobody’s name on it, and with a monthly price on the ticket it becomes a choice the sprint owner makes and owns.

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.

Subscribe now

Pipeline debt charges you and everyone downstream every time it runs

Martin Fowler’s definition of the interest comes from software, where you pay it when you change the code:

The extra effort that it takes to add new features is the interest paid on the debt.

A pipeline charges you every time it runs, whether anyone touches the code or not.

The interest is the re-run when a job times out, the backfill when data goes missing, the bad load that reaches whoever reads the table first because nobody wrote the test, and the warehouse that runs bigger than it needs to because the model under it was never tuned.

Your team pays most of it as on-call or “keeping the lights on”, it disappears into the week, and that’s how a pipeline that sucks survives for years with nothing on any ticket to say what it costs.

Reema Kuvadia has the reason nobody counts it:

The debt rarely gets addressed, because it never appears as a single, dramatic incident anyone gets paged for.

The people who use the data pay as well, and they never see your ticket.

I consulted for a company where the data team ran ad-hoc queries for the marketing team, all the time. Our pipelines were timing out and we were occasionally missing data.

The queries were different every month, and nobody trusted the data, so the marketing team kept their own spreadsheets, and keeping them took 4 to 6 hours at the end of every month.

Marketing paid interest on a debt that was ours, and it didn’t get fixed while I was there.

Whenever the person paying the interest and the person who owns the pipeline are different people, nobody prices it, because you don’t feel the cost and they don’t know a ticket exists.

So count their hours as well as yours, and bring them with you when you ask. Whoever pays the interest is the one who wants the date, and the sprint owner hears it faster from them than from you.

Count people’s time in hours, because the salaries get paid anyway

I almost never put a dollar figure on people’s time. The people whose hours the debt eats are on a salary, and the salary gets paid whether the debt is fixed or not, so a dollar figure on their time promises a saving no bill will ever show. What the debt takes is hours they could spend on something else.

Count the hours from the last few weeks, and you’ll find most of them are already written down somewhere.

Give them as a range you had before anyone asked, the same rule as A confident guess is a lie, even when it’s right. It also fits Stop talking about tables, where cost means “Can we save money or time?“. Time is the half of that you can defend.

Revenue figures on debt tickets are mostly bullshit, and the first person who checks one stops trusting your next number as well.

Risk goes on the ticket only as an incident that already happened, named and dated.

Warehouse debt is the one you can price in money

Money goes on the ticket in one case, when the interest is on an invoice. Warehouse spend that exists only because the debt does is read off the bill, and nobody has to take your word for it.

I’ve carried that kind of debt on purpose. We ran bigger warehouses, our modelling wasn’t great, and we had no proper clustering, because we wanted to move fast. We knew the Snowflake cost would be high, so we budgeted for the increase in favour of releasing the projects, and once we’d delivered them, we set time aside to close the gap.

All three show up on the warehouse bill every month they stay, so the increase was a number we could budget for before we shipped. A debt like that can’t turn into a complaint, because somebody decided to pay for it with the cost already known.

Most of yours is the other kind, taken on by somebody, at some point, with no number written down anywhere, and the ticket is where you put the number back. Start with the warehouse bill, because it’s the one number on your ticket nobody can call a guess.

The fix, backfill and migration included, goes on the ticket as its own field. It’s a one-off, so it doesn’t grow while the ticket waits, and it can’t keep a date honest.

For your own case, the ready-to-use version is my digital twin, and it comes with the annual subscription.

Paying it down in secret costs you twice

When the ticket doesn’t move, you pay for the fix yourself, on a Friday or hidden in a feature estimate. It’s a crap deal, and you’re the one offering it. You pay once with your own hours and again at review, because nobody saw the price fall, so as far as anyone deciding your raise knows, the repayment never happened.

This is how I put that same silence in No one gets hired for clean pipelines:

You’re not failing because your work isn’t good enough. You’re failing because it’s silent.

That piece fixes the silence after the work is done, by asking what changed, and a priced ticket gets there before you start, because it has a before number and an after number with your name next to both.

Ron Jeffries would tell you not to ask at all, and to clean what you touch inside the feature, because

Often, that time is not granted: we’re asking for time to fix what we screwed up in the past.

He’s right about anything that fits inside work you’re already doing, like tidying a model you’re changing anyway. The ticket is for the debt that doesn’t fit, like moving a model to incremental loads, which needs a backfill and a stretch of running old and new side by side.

Priced and funded, the repayment happens in work hours, on the sprint board, with your name on it, and your Fridays go back to being yours.

Final thoughts

I’m not sure every team needs a price on every item. Alex Ewerlöf’s team won a protected debt day with no price on any item. If you already have protected debt time and nobody gatekeeps it, pricing every ticket is ceremony, and the better question is the one Ewerlöf asks: “you need to ask why the gatekeeper exists at all”.

Most of you have a gatekeeper, and the price is for them.

Some debt costs nothing to carry. A messy model that runs cheaply, breaks nobody’s week and never needs changing has a monthly price near zero, and a price near zero doesn’t need a date at all.

The case I can’t close is the one where the price is on the ticket, the person paying it is in the conversation, and the answer is still “not now”. At that point somebody has chosen to keep paying every month, knowing what it costs. Maybe that’s the right call. I still don’t know what you do next, except keep adding to the total.

Until next time,

Yordan

PS: If you want my answer to your own version of this before you have to give yours, grab the yearly subscription and ask my digital twin, which answers the way I would.

More on the topic

• No one gets hired for clean pipelines

• Stop talking about tables. Start talking about revenue, cost & risk

• A confident guess is a lie, even when it’s right

When an executive asks you a question on a call, you feel the stress in the back of your neck, especially when they ask you about things you really don’t know.

You feel the stress of all eyes looking at you. You are the expert, and you must have the answer. You are either an expert or a fraud. So, you have no other choice but to say what you know, and build your theory based on that. You guess, while trying to look confident.

I know this about you because I was doing the same.

With a CFO, with VPs, and with founders, I did it all the time, and it was worst at the start, when I’d just begun talking to executives and had no manager on the call to represent me.

If you’re doing a lead’s job without the title, those calls are already yours, with nobody more senior on them to take the hard question off you.

I covered how to give updates business people understand. This one goes after the guess, because whether to guess was never my decision to make, and it isn’t yours either.

Nobody on the call asked you to guess

The people asking would rather you paused than guessed, and I only found that out when some of them asked me to.

You believe that you, as the expert, need to have the answer on the spot, and that every second of silence counts against you. You are either good or mediocre.

I believed it too, so a pause felt like a verdict and a confident guess felt a hell of a lot cheaper than sitting through one. Then the manager I had at the time taught me to say only what I know, and that it’s fine to say this:

I don’t know yet, but I will check and come back to you with an answer.

Later, I learned that people don’t see this approach as mediocrity, but as care.

A guess is a judgement you say as a fact

Every guess I made on those calls started as a judgement, and I said it as a fact.

My philosophy is that people need to be able to trust me, always, because trust is what lets you lead people, title or no title. If I say something’s white, they know it’s white, and they don’t need to check it.

When the number turns out right, you still told them you knew it, and you didn’t.

The strongest case against me comes from Sean Goedecke, who writes that

Many engineers either feel that it’s dishonest, or lack the courage to commit to claims where they’re only 80% or 90% confident.

He’d put me in the first group, and he’d point to his own experience that “managers are very forgiving when you make a technical call and it ends up being incorrect“.

A decision is yours to make with partial information, and Democracy Is Overrated is my whole argument for making it, but a fact is never yours to invent. When the CFO asks why your revenue number doesn’t match finance’s, the answer exists somewhere, so anything you say as a fact before you’ve found it is a guess.

Guessing works until someone can check

You keep guessing because most of the time it works, and it works because nobody on the call can check your number while you’re still talking.

Kevin Goldsmith says what happens next

If you guess and you’re wrong, the next time they hear about your project from someone with the real information, they’ll wonder whether you were confused or covering something up.

When they check, your next number gets discounted, and so does whatever you’re asking for with it. Your budget request gets its figures checked before anyone listens to your argument, which is a shit trade for one confident sentence you didn’t need to say.

I ran that risk on nearly every call at the start, when I was guessing all the time.

Say only what you know, and a range counts only if you had it before they asked

My rule is “only say what you know, and if you have a range, go with it“.

Your range counts as something you know when you have it before the question. If you size the migration before the call and it comes out as a range, that range is a fact about your work, and you give it with what it rests on. A range you put together on the call while everyone waits is a guess with a wider margin, and they hear it as a number all the same.

The same goes for your team’s estimates, and I know mine, so when an executive asks for one, I give it and what it rests on, like any other fact about our work.

So you answer in three lines, in one breath:

1. What I know

2. What I don’t know yet

3. When you’ll have the rest

The third line is what buys you the pause, because the senior managers who asked me to pause also asked me to tell them later.

If they want an estimate, they’ll ask for one

When an executive insists on a rough number on a call, give one, call it an estimate, and say what it’s based on, and when nobody asks, don’t volunteer one.

That rule decides for me, since whether a rough number is useful is your executive’s call. If they need one, they’ll tell you, which frees you up to answer the question you can answer.

A guess you volunteer gets heard as a fact, because you said it as one, and an estimate they asked for gets heard as an estimate, because they asked for one. You can say the same number both times, and they weigh it differently depending on who decided it was needed.

If finance or another team owns part of it, say when you’ll have that part, and give the rough version only if they tell you rough is fine.

When you rattle off technical detail nobody asked for, you’re making the same mistake with more words, and my piece on giving updates business people understand covers how to put the decision before the detail.

For your own case, the ready-to-use version is my digital twin, and it comes with the annual subscription.

upgrade now

Read more

If you are a senior engineer on a small data team and you want to work on strategy, you have two places to learn it from, and on a team your size both of them steer you wrong. There’s your own engineering experience, where a better argument wins the design review, and there’s everything you can read about data strategy, which is written for a company with a Chief Data Officer, an executive sponsor and a budget line for every pillar of a maturity model.

You likely work somewhere where the people who sign off on your plan are the same people who send you report requests, and nobody has the job of explaining the data team to anyone.

A small team runs a real data strategy with none of the enterprise bureaucracy, and the part it can’t skip is selling it, and that’s the part engineers skip first.

On a small team, selling the plan is part of the plan

People are emotional and stupid. That includes you, me and every senior manager who signs off on a data plan. I do stupid shit all the time, and so do you.

So your senior managers decide on how a plan feels, and a plan explained in steps and numbers feels like a cost with an attached timeline.

Engineering trains the opposite reflex into you. In a code review the better argument usually wins, so you learn that being right is enough, and then you bring that habit into a planning meeting where nobody is reviewing your logic line by line.

My own version is the MongoDB story, where I gave the founder at the next desk the technical answer when he wanted the business one and lost his trust for months.

Even the biggest data organizations say people are the hard part. In the 2025 survey by Randy Bean’s Data & AI Leadership Exchange, 91.2% of executives from 125 Fortune 1000 and leading global companies named culture and change management as the principal challenge to becoming data and AI driven, against 8.8% who named technology.

In companies like those, somebody else does most of the selling. A sponsor pitches the plan upward, champions keep the other departments on side, and a comms team explains what each release was for.

Your team of five has none of that, so every one of those jobs is yours, or your manager’s, retelling your pitch from memory in a meeting you’re not in.

So the pitch is part of the strategy. You write it at the same time as the plan, and you write it yourself.

Sell where you’re going, and keep the plan honest

This is where you have to think like a marketer, which I know sounds terrible to an engineer. Your plan is a list of steps and what each one costs, and you already know how to write it. Next to it you need a picture of the company once those steps are done, the finance team that stops rebuilding the same spreadsheet every Monday, the product manager who gets an answer the same afternoon.

You need to wrap it up in a shiny package. They need to dream about the future you sell.

The picture and the plan do different jobs, and mixing them up is how this goes wrong.

The plan says what’s true today, what’s broken, what you do next and roughly how long it takes, constraints included.

The picture says where that leads. When the picture promises more than the plan delivers, the first delivery is where you lose them, because everyone compares what shipped with what they imagined, and the gap costs you the next yes.

Retell it every time you ship

Once you start shipping, nobody connects that to your plan unless you connect it for them. Something that’s step 2 of migrating Finance away from spreadsheets looks like a ticket closed on Tuesday ot others.

When nobody makes that connection, every new request starts from zero, the next step has to be argued for from scratch, and the strategy dies without anyone ever deciding to kill it.

The fix is to name the step and where it sits in the space-time continuoum. Something like “This closes step 2 of getting finance off spreadsheets, and step 3 starts on Monday“.

Train them and remind them, until your manager says it back to you in a meeting without being asked.

A Big Tech stack comes with Big Tech’s pace

Engineers are the most exposed to this one, because most of us learned what good looks like from Big Tech engineering blogs. I keep hearing some version of “If it works for META, there’s no reason why it wouldn’t work for us“, and I argued against it in the past.

Their way assumes a team with people to run each piece, and months of setup before anyone outside the team sees a result. A small team that spends those months standing up Databricks, Airflow and Alation has not a damn thing to show the CFO at the end of them, so the story you’re meant to retell every time you ship has nothing in it.

There are alternatives. A small team gets going in a day with PostgreSQL, Orchestra and a page in the Confluence wiki, or with whatever lighter option you prefer. Big tools and small tools both run a strategy fine, as long as you know what you need and where you are.

Big Tech has different problems from the ones most of us have, starting with how much data there is. Jordan Tigani wrote that “the vast majority of customers had less than a terabyte of data in total data storage“. Weigh the source, and then look at your own warehouse.

Knowing where you are comes down to three answers, before you pick the heavy option.

1. What business need does it meet, and who named it?

2. What waits while you set it up?

3. Who runs it once it’s live?

Sometimes the heavy option is right. Our ELT migration took both engineers, the whole data team at the time, for months while everything else waited, and it was still the right trade because the business needed raw data faster than our transform layer could deliver it.

What the heavy option costs to keep running is a separate bill, and I’ve already talked about this, too.

Your strategy fits on two pages, and most of it stays with you

If you’ve been reading enterprise strategy advice, or you come from academia or a big company, it’s easy to confuse strategy with compliance.

A long strategy document exists so that hundreds of people who never talk to each other work toward the same thing. Your team of five does that on one call, so a long document written for your team is written for readers who don’t exist.

Maturity models, Gantt charts and a 10-year plan circulated to the whole senior team are compliance work.

Screw all this bullshit!

Bernard Marr’s data strategy template says “a one-pager is never going to be detailed enough“, and for a company with a CDO and a strategy office he’s probably right.

The one number I have on whether long plans pay off points the other way. ClearPoint looked at 20,582 plans on its own platform and says “organizations that spend six months on SWOT analysis and stakeholder workshops have roughly the same on-track rates as those that hammer out a plan in a two-day retreat“. Those are general business plans, not data strategies, and the vendor has a stake in the answer.

What’s left fits on one or two pages of a Google doc.

• Where you’re going, in a sentence or two

• The next few steps, and why those come first

• Roughly how long each one takes

• What waits while you do them

Now, I say steps on purpose. It’s rarely a single project, and it doesn’t need to be a detailed project plan either, because how much detail goes in depends on who reads it. If you want a structure for filling the two pages, the five decisions work.

For your own case, the ready-to-use version is my digital twin, and it comes with the annual subscription.

Subscribe now

Ideally you write it and keep working on it, and it stays a document for you. Your senior managers get the story you sell them and the next steps, with as much detail as they need to say yes.

The bigger the company, the more experienced senior managers you have, and the more clarity they need. A founder at a small startup hears “finance numbers first, then the product dashboards” and has enough, while a larger company’s senior managers want the steps split out with owners and rough dates, and that’s a fair ask.

Final thoughts

Less bureaucracy on small teams is the whole idea, and I believe it. I also believe the two pages get longer as the company grows, and somewhere along the way clarity turns into the compliance I just told you to screw. I don’t know where that line is, but it isn’t anywhere near a team of five.

What I’d do this week is smaller than any of that. Write the two pages, keep the document to yourself, and tell the first person whose yes you need where the next few steps lead, in a sentence they could repeat to someone else without you there.

—

Until next time,

Yordan

PS: If you want my answer to your own version of this before you have to give yours, subscribe for the year and ask my digital twin, which answers the way I would.

PPS: Today is the last day before I raise the subscription price significantly. Upgrade while you still have the chance.

Subscribe now

More on the topic

• How to Build a Data Strategy Without Buying a Single Tool

• Your Tooling Choices Reveal More Than Your Architecture

• Persuasive Pitch Playbook: The Business Case Framework I Wish Someone Taught Me at 25

Where I work, I’m the Head of Data Engineering who signs off the 3%, which means I know how little time a case gets. Your manager has about 10 minutes, somewhere between everybody else’s cases, to present you to people who decide your pay and will never open one of your pull requests.

Somebody like me decides your promotion, in a meeting you’re not in.

Finance sizes the pool months before anybody reads a case, so when the 3% arrives looking like a verdict on your worth, that’s bullshit, and I say it as the person who signs it.

If your plan is to ask at your review, you’re preparing for the one-to-one where your manager tells you the decision, because by then the committee has already made it.

The committee checks the names on your case

We call it a promotion committee where I work, although at a smaller company it’s just your manager and whoever controls the budget. Everywhere I’ve seen it, the meeting works the same way, with one budget, everybody’s cases and a fixed amount of patience to share between them.

The committee reads your case next to the second one, the fourth and the ninth, while your manager defends lines he didn’t write. Sooner or later somebody picks one of those lines, messages the person it names and asks whether it’s true (I’ve done it myself).

Every line he says out loud puts his own credibility at risk, so he argues hardest for the cases he can explain afterwards, and so do I.

Your case is the only thing of yours in that meeting, and somebody checks the names on it.

Hamza got 2% against a 3% norm, in a year when he delivered more than most people deliver in two. His manager liked him a lot and had nothing in writing to take into that meeting, where liking somebody doesn’t count for a damn thing once the budget is fixed. Hamza has had a much bigger increase since, and he’s no better at his job than he was.

I’ve watched people on my own team rebuild 12 months of work from memory in the 3 days before a review, badly, under stress and missing half of it.

At a scale-up with no formal reviews, the conversation that sets your pay can include you, and Walt’s did. He got the promotion and 17% more in total compensation. Everything he used existed before he asked, the requirements he’d agreed with his manager 6 months earlier, a brag list and some benchmark data.

This is my course for the meeting you’re not in

I built it with one lesson for each thing that meeting needs from you, and you start every one of them months before anybody asks.

You also have to be great at your job, because anybody on the committee can message the names in your case and the first reply exposes any work you didn’t do. The course teaches you to show a good year properly, in a form your manager can repeat in that meeting without you.

Every lesson is a recorded video plus a write-up with the examples. The templates are in the Promotion OS, the same ones I use with my coaching clients.

The worked version is the Design Your Promotion course, and the recordings come with a paid subscription for as long as you keep it.

Lesson 1. Collect your wins before they go cold

Whoever signs off your raise never sees you do the work. More than 70% of data people report to somebody who can’t read their code, so the version of your year you wrote down is the only one that meeting ever gets.

“Helped with a dbt migration“ covers anything from 2 calls to the whole project, so nobody reading it can tell which. The person I coached who wrote it turned it into 2 lines anybody can check, “Migrated 40 dbt models to dbt Cloud“ and “Cut CI test time from 22 minutes to 6“.

Sometimes “helped” means you stopped another team from doing some stupid shit, which is a real win, as long as the line says what you stopped.

Write down what shipped, who saw it and what changed on the day it happens, even if it’s only a message to yourself. Once a week, spend 10 minutes turning those messages into lines.

Lesson 2. Pick your outcome and your number

Your manager has to forward your number to finance, which he can’t do with a figure he can’t attribute. Say “somewhere between 80 and 90“ and he hears 80, so research the range yourself and bring one figure.

Ask for the title and the number together, because with the title alone somebody else sets the number later, in the meeting you’re not in. A number with no title buys you a raise for the job you already have.

Kalina went from a 3% nobody asked her about to the senior title and £75,000 in 9 months, 24% up on where she started. She did it with the same work she’d been doing all along, by sourcing what her year was worth and saying so.

I ask my own team for their number 3 to 6 months before the cycle, because I can’t argue for a figure nobody gives me.

Sometimes the data says your employer already pays you right for the scope you have, which is worth knowing before you spend a cycle arguing for more.

Lesson 3. Translate your wins into business language

“Pipeline failures down 80%“ is half a line, the half you can prove alone, from the logs, in an afternoon.

The other half has to come from somebody in a different job. In my own version of that line, it’s the board report going out on time, so finance stops keeping a parallel spreadsheet just in case.

Your logs give you the left column, and only people in other jobs can give you the right one.

I failed this myself in a final-round interview, answering a head of marketing’s question about customer acquisition cost with dbt and reverse ETL, because I’d never cared about anything past loading and modelling the data.

Put this question at the top of your ledger and run every entry past it, since it’s the one that finds the wins nobody gave you a ticket for.

What would be harder right now if I hadn’t done that?

My rule is 2 weeks, so ship, wait and then ask whose week changed.

I filed one of my own wins as “clustered some tables” and only found out what it did when I heard people talking about that morning report before a call. Before the change, 4 people opened it every morning and passed the numbers on to everybody else, and now the whole team of 15 opens it themselves.

Lesson 4. Send your promotion case

I’m one of the people ranking those cases, and a strong year in a weak document loses to a decent year in a strong one. It sucks for whoever had the strong year, and I still rank them that way, because in that meeting the document is all I have to go on.

An engineer on my team wrote her own case and got nearly 18% in the same kind of cycle that gave Hamza 2%. She earns lead-level pay now without running a team, because she already does that job.

Send the case before the meeting and never present it live, because whoever decides needs time alone with it, to write in the margin and go back to the line they didn’t follow.

Your manager sends it back with notes on what his committee will ask, and the version with his notes beats yours. I’m doing the same right now with a business case for a project I’m taking to our board, which my manager has already sent back more than once.

Nobody I’ve coached or worked with has ever lost a case over the file type. Use whatever format your committee finds easiest to read.

Lesson 5. How Erfan got over 20%

A reorg can put a new manager between you and the one who promised you the next step, 3 months before your review.

In Erfan Hesami’s case the old manager raised the promotion first, then moved a level up in a reorg 3 months before the review. The company opened at 12% and Erfan finished with the lead title and 22%, after 4 meetings over 3 weeks.

I credit his written case with getting the promotion through the reorg, although his old manager’s word might have done it alone, and I wouldn’t bet a year on finding out.

Put the ask on the record at your mid-year review, 6 months out, and send a recap within 24 hours of every meeting after that.

Erfan also left the number out of his case and let the company go first, which lessons 2 and 4 both tell you not to do. He’d finished his research before their offer arrived, so he never built his number while looking at theirs. I still put the number in, even though his 22% is the strongest case against me I know of.

If a post or a search brought you here, subscribe and I’ll send you the next one. Two a week, all of them on the part of the job nobody taught you.

Take the lessons in order

Lesson 4 builds the case from the lines you write in the first 3, so if you skip the ledger you end up with a page of adjectives.

If you do one thing today, start the ledger. Every week you wait, somebody forgets a win you’ll need them to confirm.

I built the Promotion OS in the same order as the lessons.

1. Step 1 has the ledger template and both AI prompts.

2. Step 2 has the 4 salary sources, my own dated search and the Musts Card.

3. Step 3 has the three-column framework, the message that gets the answer in writing, and the 3 ways it goes wrong.

4. Step 4 has the 4 opening lines, the cut to 5 to 8 lines, and how to write up the promises you broke.

5. Step 5 has the recap template and the self-audit.

6. Erfan’s case runs all 5 steps, start to finish.

Final thoughts

I got my own 40% raise and the Head of Data Engineering title without writing a case and without asking, which still means other people decided it, in conversations I wasn’t part of.

Some of the people whose requests I kept pushing back on asked leadership to back me, because I sent my priorities out in writing every week and they could see what I was building.

I can’t tell you how much of that was the weekly updates and how much was luck. My own team writes their own cases.

—

Until next time,

Yordan from Data Gibberish

PS: You will receive one more with an announcement email today.

More on the topic

• Your Best Work Is Invisible Because You Describe It Wrong

• The Weekly Message That Got Me Promoted

• What to Do When Your Company Has No Formal Review Process

Your manager told you he sees you in a bigger role, and you’ve been working toward that conversation ever since. None of it is written anywhere. It lives in one person’s memory, and a reorg can make somebody else your manager three months before your review.

Erfan Hesami’s manager raised the promotion before Erfan did. Three months before the annual review, a reorg put another manager between them and moved the old one a level up. The company’s first offer was 12%. Erfan finished with the lead title and 22%.

A written case carried that promotion across the reorg. Maybe his old manager’s word would have been enough on its own. I wouldn’t bet a year of work on finding out.

A promise from a one-to-one belongs to whoever made it

When your manager says he sees you in a bigger role, that’s an intention. He built it out of a year of watching you work, and it’s stored in his head and nowhere else. A reorg moves the only person holding it.

The new manager inherits your team and your review date, and has never seen a day of the year your old manager watched. He’s also the one who now argues for you, in a meeting you’ll never sit in, for a promise somebody else made.

And your manager rarely decides this alone. I sit on promotion committees, and the group asks whichever manager is in front of it. After a reorg, that’s the manager who knows you least.

Then the review comes round and the new manager tells you nobody briefed him. Your old manager is a level up and busy with his half of the reorg. Everybody agrees you’re good, and nobody has a damn thing to take into the committee.

Put the ask on the record six months early

Say you want the next step at your mid-year review. Six months out is the last point where your manager can still plan around it.

That conversation is about responsibilities, the ones you already carry and the ones you’re ready to take next. Write them down and send them before the meeting as a short document. One page, because an executive won’t open ten. The title comes later, once your manager has watched you carry them.

Erfan spent most of 7 years doing the opposite. A good review, the standard increase, and a thank you for another year. A manager who hears nothing assumes you’re happy where you are, and nobody spends advocacy on somebody who looks happy.

After the mid-year conversation, give your manager things to repeat. Send updates before anybody has to chase them, short and weekly and shaped for whoever reads them. My own version is in The Weekly Message That Got Me Promoted. Take the work nobody owns, too. Erfan’s company had AI initiatives running with no governance under them. He pointed it out, volunteered to write it, came back with a plan when his manager asked for one, and was left to run it.

I ask my own team for their number 3 to 6 months before the cycle, because I can’t fight for a figure nobody has given me. A title works the same way. By the time Erfan’s case went out, his manager had raised the promotion himself, months earlier.

When your manager changes, take the case to both of them

Starting again from zero with the new manager throws away a year of evidence and the only person who watched you earn it.

Going around him to your old manager is worse. The new manager is the one who’ll argue for you, and nobody argues hard for someone who went over their head.

Keep the old manager in. In Erfan’s reorg the old manager became the new manager’s boss. He remembered the year, and he outranked the person presenting it.

Write down what’s already been said. What was agreed, roughly when, and what was meant to happen next. Send it to both of them and get the three of you agreeing on one version of the past and one plan for the months you have left.

If your old manager has left the company, that written history is all that survived the reorg, so send it to the new one anyway.

Build the case for the one who wasn’t there. You’re now writing for two readers who each know part of your year, and one of them has to carry it up to the other.

My own senior management team changed a few months ago. The business case I’m taking to the board is a document first, and my manager has already been through several revisions of it. Without that, I’d be learning what the new people want live, in front of the board.

Four things for the case the course left out

Lesson 4 has the structure. Erfan’s case carried four things none of the lessons taught.

• Three titles in the ask. Your first choice, then two you’d accept. A title has to fit the company’s ladder, so options keep it a conversation.

• Every person you worked with this year, by name. Erfan didn’t think his list would reach 15. It came to more, and a list like that is the scope argument for a lead title.

• Work outside the job. A year mentoring graduates at his old university, one of whom landed a software engineering internship, and community awards he nominated himself for and made finalist in.

• Praise you never asked for, pulled out of your inbox. Lesson 3 left the back catalogue open. Erfan’s answer for the feedback half was to have AI search his email for it, then keep every quote with the person’s name, job title and a screenshot. We check those on the committee, by going to the names on a case and asking whether it’s true.

If they name the number first

Erfan’s case asked for the title, the progression and the scope. It left the number out, so the company named it first, at 12%.

Lessons 2 and 4 both tell you to put the number in. Sometimes they go first anyway, because you left it out or because they got there before you did.

Counter with a sourced number, built the way lesson 2 describes, on the duties you’ve just agreed for the new title. Erfan’s research was finished before their offer arrived, so he wasn’t building his number while looking at theirs. Without that research you’re negotiating up from their figure with nothing in your hands, and that’s a shit place to stand.

Your manager will ask where the number came from. Send the sources, with dates on them. He needs something he can forward to finance, and a manager can’t repeat a figure he can’t attribute.

Then finance checks it. For Erfan that took about a week.

Somewhere in there, somebody asks what else would work if they can’t reach your number. Say what comes first and that you’ll hear the rest. Erfan told them salary was his priority and he was open to other options. A flat this-or-nothing ends the negotiation.

Before the last meeting, write down three outcomes. A yes. A tight budget, where you ask for a review at 3 or 6 months or when the budget resets. A no, with what has to be true by the next cycle. Erfan walked in with all three and needed the first.

One meeting becomes four, so write each one down

The first meeting can end in a reschedule. Erfan’s did. His manager hadn’t opened the case, opened it in the meeting, saw how much was in it and moved the conversation so he could read it properly. That’s a decision maker asking for time alone with your case, which is why lesson 4 tells you to send it ahead. Take the reschedule.

Erfan’s promotion took four meetings over three weeks, for a new title and a 10-point jump. Every round waits on somebody’s calendar, and at least one waits on finance.

Each of those meetings ends with something agreed out loud, and each one is another promise from a one-to-one. Send a recap within 24 hours to everyone who was there. Decisions, next steps and a checkpoint date. The template is in Step 5 of the Promotion OS, and no lesson in this course taught it.

The recaps are also what saves you when the reorg lands in the middle of the negotiation, after the case has already gone out.

Final thoughts

If your manager has told you you’re next and there’s nothing written anywhere, you have a good relationship and no promotion yet. Write it down this month, while the person who made the promise is still the person you report to.

I’ve told you twice in this course to put the number in the case. Erfan left it out and got 22%. I still think it belongs in there, and his run is the best argument against me I’ve got.

That’s the course.

—

Until next time,

Yordan

Hamza got 2% in January.

The norm is 3%. He’d delivered more in a year than most people deliver in two, and he’s the kind of engineer who wakes up at 2am to fix a pipeline and never makes it anybody else’s problem, which I don’t recommend and which he did anyway.

An engineer on my team got nearly 18% in the same kind of cycle. She’s paid at lead level now without running a team, because she was already doing that job.

Hamza did everything right technically and nothing at all strategically. He had no record of what he’d shipped, so he walked into an empty review. His manager liked him a lot and had nothing to carry upward.

He’s since secured a much bigger increase. He didn’t get better at his job in between.

Your case competes against other people’s cases

Where I work we call them promotion committees. Other companies call them something else. The shape is the same everywhere I’ve seen it. A set of documents, one budget, and a fixed amount of patience.

You already know your manager doesn’t set your number alone. What people miss is the second document in that meeting, and the fourth, and the ninth. The ones that get prioritised are the strongest documents. A strong year in a weak document loses to a decent year in a strong one, every time, and that’s a shit deal.

It’s also the real one. I’ve checked it against my own behaviour and it holds up. The case I can repeat afterwards is the case I fight for.

So I train my team to write their own. Partly that’s selfish. I’m too busy to remember everything they did, I keep a ledger, and my ledger is still worse than theirs. The other reason is that writing it teaches them more about how the business works than anything I could put in a development plan.

The order that loses it

Most first drafts come out in investigation order. I joined, I learned the stack, I found the problem, I tried three things, the third worked, and here’s what it was worth. From the inside that reads like thoroughness. From my side of the desk it’s a postmortem with the ask hidden at the bottom.

By the time your reader reaches the decision they’re bored, they’ve stopped reading, and they’re already doing something else.

So you invert it, and that’s what I mean by decision order. The ask first, the evidence underneath, and the reader picks how far down to go.

The rule underneath that has a name and I’ve been writing about it since 2023. BLUF, bottom line up front. The whole playbook is in Boost Productivity with BLUF, written about Slack messages, and it holds on any document somebody has to act on. Go and read that one instead of me teaching it twice.

What’s different on a promotion case is what goes in the four lines.

1. What you’re asking for. The title and the number, both, flat.

2. Why it matters.

3. Why it needs to happen now.

4. What happens next, and by when. Your commitment.

Then one sentence sitting over all four, naming the pattern across your wins. Across these, I have consistently unblocked the business from waiting on data. Write your own version, because that’s the line your manager repeats when somebody asks what you’re about.

Here’s the top of a real one, from an engineer on my team.

I’m asking to move to senior data engineer at £68,000. I’ve been doing that job for about a year. I own all our integrations end to end, and I took over finance reporting.

There was no comfortable way to tell her no.

Leading with the ask will feel like you haven’t earned it yet. You have. The evidence is sitting on the page, which is what it’s there for.

Then run the test, which takes 30 seconds. Read only the top.

If your manager can repeat the ask and the reason in one sentence, with none of the evidence under it, you have a case. If they can’t, the order is wrong, and more evidence won’t fix an order problem.

And when you can’t write that top confidently yourself, the document isn’t where the problem is. You don’t have the reason yet, so there’s nothing underneath to expand.

Read more

A few years ago I got to the last round for a job I wanted, and the head of marketing asked me about customer acquisition cost.

I told her how we pulled the data. How we modelled it in dbt, how we kept it consistent, how we handled quality. I talked about reverse ETL, which I still think is a good problem.

Light nodding. Then she stopped me.

I already knew. I’d worked on exactly the projects she was asking about, and I had nothing to say about them that she could use. Everything I knew about that work stopped at the point where it left my hands.

I got the head of data engineering job about a year later, and I still hold it.

You already have the three columns

If you’ve read this newsletter a while, you have the framework already, and I’m not going to teach it again.

Stop talking about tables. Start talking about revenue, cost & risk has all three columns with worked examples. Your Best Work Is Invisible Because You Describe It Wrong has them again under a different heading. Technical input. Enablement outcome. Business driver. 8 words maximum in column one, and column three lands in revenue, cost or risk or it doesn’t count.

You can learn the shape of a three-column sentence in about 4 minutes.

Then you sit down with your own year and fill column three in out of your head, because that feels like where the answer lives. Your head only holds your half of it.

The Column 2 Trap

Almost everyone who thinks they’ve translated a win has stopped at column two, and the number is what fools them.

“Pipeline failures down 80%.” Real improvement. Yours. Provable, because the logs are sitting right there. Every engineer who reads it nods.

It reads finished because it has a percentage in it.

Column two is the part you can prove on your own, in an afternoon, without talking to anybody. Column three needs a person who does a completely different job from you to tell you something, and going to get it takes effort, and it feels awkward. It felt awkward to me for years and some of it still does.

I’ve had engineers tell me they don’t have access to those people. That’s bullshit. They have access. They don’t want the conversation.

Here’s the column-three version of that same 80%. The report to the board started going out on time, so finance stopped keeping a parallel spreadsheet just in case.

Read the two out loud, one after the other. One has a percentage in it. The other has somebody changing what they do on a Tuesday morning.

Column three is somebody else’s behaviour or somebody else’s trust. Nothing else counts.

Which brings me to a correction I owe you. In the business value mapping playbook I told you to quantify the business driver in money, and I gave you examples like $300K in incremental revenue and $60K a year of analyst time. I’m reversing that here. Put a dollar figure in column three only when you have one. Estimate it and somebody asks how you got there, and the whole sentence falls over. It feels naked.

“We stopped finance submitting the wrong numbers again.” There’s no money in that sentence and no percentage, and it’s still the best line in this article.

Read more

Kalina came to me two months after her company’s promotion cycle had closed. She had a 3% increase nobody had asked her opinion about, and she’d expected a lot more than that.

Nine months later she had the senior title and £75,000. Up 24% on where she started.

None of it was new work. She took the year she’d already worked, sourced what it was worth, and said so out loud.

She didn’t enjoy all of it, and I’ll come back to that.

Where your 3% came from

I set numbers like that one. Worth saying up front, because it makes the rest of this awkward for me rather than for you.

Where I work, salaries get reviewed in January. The pool gets sized the previous autumn, against a revenue forecast, by people reading a headcount model.

By the time a percentage reaches you it has been through finance and through a manager ranking his own team, and not one person in that chain opened your pull requests.

A company will try to pay you the smallest amount that keeps you. I know, because I’m sometimes the person being asked to do it.

So your January number is accurate. It’s a fact about your employer’s budget. It reaches you as a fact about your worth, and that is bullshit.

You accepted that 3%, and then you were annoyed about it for a year.

What it costs them to replace you

Give me 10% and it costs my employer 10%.

Lose me and it costs a recruiter fee, a notice period covered twice over, and about 6 months of somebody new learning what I knew on the Friday I left. SHRM puts replacing an employee at 50% to 200% of annual salary. For senior roles the Center for American Progress puts it as high as 213%.

Your manager understands that arithmetic better than you do. He’s run a backfill. He knows what the agency charged and how long the new person took to stop asking questions.

If you leave, the company pays market rate for your replacement anyway. It pays a stranger, and you walk out with everything you know about why the ingestion job is written the way it is.

You never say you’re leaving. Say it and you have to do it, or your word is worth nothing for the rest of your time there. You only have to know it’s true while you’re sitting in the conversation.

Read more

Somebody I was coaching told me they’d helped with a dbt migration. That was the whole sentence. I asked what actually happened and they weren’t sure. A manager had signed off on something, the migration finished, and their part in it had dissolved into “helped with.”

I pushed, because “helped with” gets you nothing in a promotion case, no matter how much of the work was actually theirs.

Whoever decides your raise never saw you do the work

My own numbers put it above 70 percent. Most data professionals report to somebody who can’t read their code. That person can’t evaluate a migration or a query rewrite directly. They can weigh money, time, risk and speed, and nothing else.

So the work you’re proud of is invisible by default. The person who signs off on your raise wasn’t there when it happened, and the conversation that actually sets your pay happens somewhere else, later, without you.

Read more

This article is part of the Design Your Promotion and Get Paid at the Right Number course. Click here to explore the full course.

A free 5-session live course for data engineers, analytics engineers, and data scientists who are already the strongest person on the team and stuck at the same level. You’ll build the case for your next title and your next number out of work you’ve already delivered.

It won’t teach you to negotiate a comp band or prep for interviews. Those are separate problems, and this isn’t the place for them.

The credit keeps landing on someone else

You’re the one they Slack at 11pm when the pipeline dies. When the numbers moved last quarter and nobody could explain it, you were the one who actually knew. And the thing three people swore couldn’t be fixed, you fixed it, quietly, on some ordinary Tuesday, because that’s the job and it didn’t occur to you to make noise about it.

Then the review comes round and your manager says strong work, let’s revisit next cycle. Again.

Meanwhile someone who ships half of what you do, and talks about it twice as much, just got the title you were waiting on.

Go and look up your market rate. It takes about ten minutes, and most people reading this are a full band behind, some of you more than that. The work is there. What’s missing is a person with a budget who can see it, and you’ve never sat down and shown them. It’s a shit spot to be in, and half the time it isn’t even your fault.

What another quiet year actually costs

Say nothing changes. You stay strong, stay busy, stay underpaid. The gap compounds too, because next year’s raise is a percentage of this year’s wrong number.

And it was never only about the money. It’s whether you get to pick what you work on, whether you’re on the call when the quarter gets planned, whether the next hire reports to you or you end up reporting to them.

Another year as the most capable person on the team and the one nobody upstairs can name. That’s a hell of a way to spend twelve months.

The fix is building the case for work you already did

You don’t need another certification, a side project, or one more heroic quarter. You’ve already done the work. What’s missing is the promotion case, the one document your decision maker actually reads, built from wins you delivered and put into the language they think in.

Over 70% of data professionals report to a manager who isn’t technical. So the win that’s obvious to you, the night you got the nightly run down from 6 hours to 40 minutes and quietly went to bed, means nothing upstairs until someone puts a number on it in money, time, or risk. That translation is the thing nobody taught you, and it’s the one that moves your number.

One thing before you sign up. This is for presenting work you actually did. If you’re hoping to dress up work you didn’t, no case will save you, and the course will make that plain to you before it’s plain to anyone else. It only works if you’re already good at the job.

What you’ll build, across 5 live sessions

Every session ends with something you actually build and keep. You show up live, you leave with the asset in hand, and you’ve got 3 to 5 days to finish it off before the next one comes round.

1. The Wins, Monday, September 14. Sort a year of work into what you actually delivered versus what you can only claim, and start your Win Ledger live. You keep feeding it for the rest of the course.

2. The Number, Wednesday, September 16. Name what you’re actually asking for, title and salary, and build a market-verified range from three real sources so your number is a position you can defend, not a feeling.

3. The Translation Layer, Friday, September 18. Turn each technical win into a business outcome a non-technical manager can weigh, in money, time, risk, or speed. This is the session most people have never done, and the one that changes the answer.

4. The Promotion Case, Monday, September 21. Assemble the case your decision maker actually reads, in whatever format fits the evidence, and write the send sequence and the 24-hour recap around the conversation.

5. How Erfan Got 20%, Wednesday, September 23. A live interview with someone who ran this exact pipeline and walked out with a lead role and a 20% raise. Then you audit your own case against his, beat by beat, and mark where yours is thin.

How Erfan went from senior engineer to lead, and 12% to 20%

Erfan Hesami was a senior data engineer who was, by his own account, stuck. Here’s exactly what he did, and it’s the same pipeline you’ll build in the course.

He started collecting wins and feedback and sharing his weekly goals with his managers. He kept that up for about two months, so by the time the conversation happened, none of it was a surprise to anyone.

He built the case as an interactive dashboard, a living brag-list his manager could click through, instead of a document that gets skimmed once and closed.

He asked for the title and the scope first, before he named a number. Then he backed the number with his own market research, a $175,000 to $195,000 range he could point at.

The first offer came in around 12%. He’d done the homework, so he negotiated, and it landed near 20%. Finance signed off on the higher number in a 15-minute meeting, because by then there was nothing left to argue about. Over roughly four meetings across two to three weeks, he moved from senior engineer into a lead role. Direct reports came up as a future opportunity, not something handed over on the day.

No guarantee is attached to that. It’s one documented case, not a promise about your outcome. But it’s the whole method, run by a real person, and on the last session he walks you through it live and takes your questions.

Who this is for

• Data engineers, analytics engineers, and data scientists, roughly 3 to 10-plus years in.

• People at a scale-up or a small-to-mid company who are already the strongest on the team and stuck at their level.

• People who have actually delivered and are tired of watching it go unpaid.

Who this is not for

• Anyone in their first year or two. You don’t have the delivered work yet, and this won’t manufacture it.

• Anyone after salary-band negotiation tactics or interview prep. Different problems, not covered here.

• Anyone who wants a certificate to hang on LinkedIn. There isn’t one.

• Anyone hoping to present work they didn’t do. The course is built to catch that, and it will.

What it costs

subscribe now

Why there’s no guarantee

Questions you’re already asking

I already know most of this. I’ve read your stuff for years.

Probably true, in pieces. What you likely haven’t done is run the translation layer over your whole ledger, line by line, until every win reads in money or time or risk. Or built the case in the exact format your decision maker reads, with a send sequence and a recap around it. Knowing the ideas and having the finished case sitting in your drive are two different things. This course is the second one.

I don’t have time for a 5-part course.

It’s about 212 minutes of live teaching over 9 days, and you keep the recordings if you’re a subscriber. The work happens in the 2 to 5 day gaps, on your own wins. That’s the prep you’d have to do before any promotion conversation regardless, so this is really just it finally getting done on a schedule.

This won’t work in my org.

It works anywhere there’s real delivered work and a person who decides titles and pay. It assumes your manager probably isn’t technical, which is true for most of you. It doesn’t assume a formal promotion cycle, a big company, or spare budget lying around. What it can’t do is invent headroom that isn’t there. If there’s genuinely no path where you are, the case tells you that clearly, which is worth knowing before you burn another year.

Do I have to pay to attend?

No. All 5 live sessions are free and open to everyone. Paying gets you the recordings and the Promotion OS, and the annual subscription is under $60 through September 24.

What if I miss a session?

Come live if you can, the chat is where your questions get answered in real time. If you miss one and you’re a paid subscriber, the recording is yours. If you’re attending free, my honest advice is to take screenshots as you go.

Is this salary-negotiation training?

No. It won’t cover comp-band mechanics or interview prep, and it’s not about switching jobs. It’s about building and presenting the case for a promotion where you already are.

Start Monday

You did the work. A year from now you’ll either be paid for it or you won’t, and the difference is a case you were going to have to build anyway. Start Monday.

I spent part of the weekend thinking about a senior engineer I know. He is technically strong, prefers the technical work, and wants to become a lead. I’m not sure that is the right move for him, but that is another story.

What I know is that his technical work will not carry him into that role by itself. I watch capable engineers explain every query, dependency, implementation detail, and wrong turn, then assume the value must be obvious at the end. If the listener still has to extract your point, you force them to do the last part of your job.

But before that, I have a huge news!

Clear Communication Works Like Clear Code

You would not approve a pull request that forces the next engineer to trace six functions before they can work out what the code does. Good code has structure. It uses names, boundaries, interfaces, and familiar design patterns to make its intent clear while it keeps the hard parts available.

Your communication needs the same discipline. A pipeline update without a clear point is the spoken version of a function with twelve responsibilities. The logic may be correct, but nobody wants to touch the damn thing because the intent is buried inside it.

This is the pain point technical people prefer to dismiss. If you cannot write clear code, nobody trusts you with the hardest parts of the platform. If you cannot express your judgment clearly, nobody trusts you with the more ambitious projects that cross Finance, Product, Operations, and senior leadership. Clear communication never guarantees a promotion. Poor communication still puts a ceiling on the scope other people will risk with you.

You may call that bullshit politics because the engineering should matter more than the explanation. I disagree. On a cross-functional project, your explanation is part of the engineering. A schema migration can be technically perfect and still wreck a finance close if nobody makes the dependency, risk, and cutover decision clear.

Replace Investigation Order With Decision Order

Data engineers often report work in investigation order. You start with the first Airflow alert, move through the task error, explain the retry behaviour, trace the upstream schema change, and eventually reach the fact that the morning SLA is at risk. That sequence makes sense to you because it mirrors the investigation and proves the work is thorough.

The listener does not need to relive the investigation. They need the change, the consequence, and the next move before the technical history. Once those points are clear, lineage, logs, and query plans become evidence instead of a maze.

This does not mean you strip out technical depth. It means you rank the information. Put the decision at the top, then provide enough detail for another engineer or stakeholder to challenge it.

Put the Decision Before the Detail

Answer Four Questions

Decision order becomes useful when it survives your next Slack update or project call. Before you paste logs, map the dependency chain, or explain the dbt model, answer four questions.

1. What changed?

2. Why does it matter now?

3. What do you recommend, or what happens next?

4. Which technical evidence supports that recommendation?

The first three answers should fit into a few sentences. The evidence comes next at whatever depth the risk and audience require. Its job is to help somebody test your judgment, not hunt for it. A routine schema-change update could read like this.

The warehouse cutover moves to Tuesday because two downstream dbt models still depend on the old schema. I recommend that we keep the old tables read-only until those models move across. The lineage output and cutover checks are below.

Put the decision where people can see it, then show them the evidence.

Give Technical Evidence Its Proper Place

The update keeps the engineering work intact. It gives the listener the change, consequence, and recommendation before it asks them to inspect the evidence. If they need column-level lineage, the data-quality failure, or the validation query, give it to them.

Some engineers will push back here because this feels like a demand to dumb down technical work for non-technical people. It is the opposite. You show mastery when you know which detail affects the decision and which detail belongs in an appendix. An unranked fact dump makes the listener do the prioritization you should have done.

Failure Updates Need Fewer Logs and More Control

Separate Impact From Cause

A failure update exposes your judgment faster because the listener already wants to know whether a deadline, customer, or regulatory report is at risk. If you make them sit through a technical preamble while they wait for the impact, your accuracy starts to sound like avoidance. That is the wrong moment to make somebody excavate your point. Use the same decision order, but draw a harder line between fact and uncertainty.

1. State the impact.

2. Give the confirmed cause, or say that the cause remains unknown.

3. Explain what you have contained and what happens next.

4. Ask for the decision, owner, or support you need.

Do not turn a theory into a confirmed cause because silence feels uncomfortable. “We do not know yet” is a complete answer when you pair it with the evidence you have, the checks you still need, and the next update time. False certainty buys a few calm minutes and costs trust when the facts change. A pipeline failure update could read like this.

The overnight warehouse ingestion is down, so the finance models will not be ready before Finance starts its daily review. We have not confirmed the cause. The failure is isolated to the orchestration task, and the raw files remain intact. We will validate the last successful checkpoint before we start the backfill. I need Finance to choose whether to wait for corrected models or use yesterday’s numbers for the review.

That update stays honest about the open incident. It states the impact, separates fact from theory, describes containment, and gives Finance a decision it can make now. The task logs still matter, but they belong under the update rather than in front of it.

Put a Boundary Around Uncertainty

If you need no decision yet, name the owner and the next update time. “We will look at it” is a useless close because it gives nobody a boundary. Bad news becomes easier to trust when your uncertainty has edges.

Subscribe now

Use the Pause to Think

A Pause Is Not a Failure

Silence feels uncomfortable on a live call. Someone asks whether a backfill will breach the SLA, a few seconds pass, and you start to worry that everyone can hear you not know the answer. So you fill the gap with half-sentences, repeated words, and guesses that sound less certain with every breath.

That noise steals the attention you need for the answer. You now have to reason about the dependency, compose the next phrase, monitor your voice, and hide the silence at the same time.

I had to practise a simpler response. “Good question. I need a minute to think”. The sentence tells the other person what happens next and gives me permission to stop talking. The silence felt strange at first, but the pause got easier once I stopped treating every quiet second as a communication failure.

Name When You Will Return

Some questions need more than a minute. Then I say, “I don’t have an answer now. Let me check the lineage and come back to you by 2 p.m”. That answer is honest, but it only earns trust if I return by the time I named. If I still do not have the answer, I send an update before the boundary passes.

You may think the pause makes you look unprepared. A confident guess that turns out to be wrong makes you look worse. Senior judgment includes the ability to separate what you know from what you need to check.

The pause creates room to think. The follow-up makes the pause trustworthy.

Bigger Scope Follows Judgment Other People Can See

Technical competence is the foundation for wider scope, but it is not the only evidence people use. Ambitious data engineering projects cross systems, teams, budgets, and business deadlines. The person who assigns that work needs to see whether you can sort signal from technical noise and make a recommendation other people can act on.

Clear updates expose that judgment. They show how you assess risk around a schema change, choose a backfill plan, protect an SLA, or decide whether a quality-check failure should stop a release. The code still matters, and the quality of your work still matters. Your explanation determines whether people outside the repo can see enough of that work to trust your call.

Test your next update before you send it. Write the first four lines like this.

1. What changed?

2. Why does it matter now?

3. What do you recommend, or what happens next?

4. If something remains unknown, who owns the check and when will you update them?

Read only those four lines. Could the other person repeat the impact and next move without the logs underneath? If not, fix the order before you add another paragraph of evidence.

Final Thoughts

Your technical work needs all of its detail and an interface that lets other people use your judgment. Decision order gives you that interface. A pipeline incident or schema migration can stay technical while the change, consequence, and next move remain clear.

Start with the change, consequence, and next move. Put the logs, lineage, and validation checks underneath. When you do not know, say so and put a time boundary around the answer.

You already use structure and design patterns to make code easier to trust. Use the same discipline when you speak. Otherwise, the most ambitious work will go to the engineer whose judgment is easier to see.

And this is what my free course is aobut. Save the dates.

—

Until next time,

Yordan

PS: Now is the perfect time to upgrade and get the course and all the content in the premium content library with a massive discount. Upgrade now.

More on the Topic

• Boost Productivity with BLUF: The Communication Hack Every Data Pro Needs

• Your Best Work Is Invisible Because You Describe It Wrong

• Business value mapping playbook: How to translate data work into executive language

When you interview, the polished artifact does the talking. A dashboard shows the output. It hides the actual work:

• the trade-offs

• the rejected alternatives

• the stakeholder you talked out of a bad idea

That hidden part is what the interviewer is trying to assess, and you never articulate it because nobody ever asks you to.

You don’t hide it on purpose. You build the thing, so the decisions feel obvious to you. The interviewer sees only the result and has to reverse-engineer the reasoning from a screenshot. Most of the time they give up and ask you to walk through the code. That tests your memory. It tells them nothing about your judgment.

The Resume Is a Weak Signal

Schmidt and Hunter's 1998 meta-analysis puts the correlation between resume content and job performance at .18. That is barely above noise, and it stays true twenty-eight years later. The 2022 revision by Sackett and his co-authors pushes the numbers down further. The resume is the weakest signal. It's also the one you spend the most time polishing.

The Interview Rewards Confidence

The interview format rewards confidence. Confidence is not judgment. The candidate who says “I built this, it’s great, here are the numbers“ sounds better than the candidate who says “I built this, I rejected three approaches first, and I’m still not sure the fourth is right“. The second candidate is showing you judgment. The first is showing you a highlight reel. The format rewards the highligght reel, which is bullshit, because it’s the one thing that doesn’t predict the judgment the job actually needs.

Even the work sample, the thing everyone agrees is the strongest predictor, is weaker than we think. Roth and his co-authors revise the validity of work sample tests from .54 down to .33 in 2005. A polished portfolio project is a work sample that tests output. It never touches judgment.

Internal Promotions Are Worse

The internal promotion interview is worse. When you interview externally, the interviewer tries to figure out your judgment and mostly fails. Internally, the interviewer already knows you. The decision happens in meetings you’re never in, based on what people decided about you months ago. The interview just makes it official.

Benson, Li, and Shue find in 2018 that doubling a salesperson’s pre-promotion performance predicts a 7.5% decline in their subordinates’ performance after promotion. Companies promote on the skills that make someone good at the current job. Those are different from the skills the next job needs. For data people, that means you promote on pipeline qualityand model accuracy. Then you act surprised when the new lead can’t handle a stakeholder.

I sit on both sides of this. I hire people whose portfolios look great. Their judgment turns out to be thin. I also watch good people lose interviews because they can’t articulate the judgment that’s obvious in their work. I’ve been that person too.

You’ve Been Running on Vibes

You can’t explain why you reject three alternatives in an interview because you never write it down when you reject them. And you never write it down because, if you’re honest, you don’t reject them for reasons. The first approach feels wrong and the second feels slow, so you pick the third and call it judgment.

The decision log is a mirror. When you sit down to write “I rejected X because Y“ and you can’t fill in Y, you learn something about how you actually make decisions. You’ve been running on vibes your whole career and nobody ever made you write it down. That’s a shit realization, but it’s better than having it in an interview.

Make the Judgment Visible

Put the judgment in the artifact itself. Write the decision log. Next to every dashboard or pipeline you ship, write down:

• the three alternatives you reject and why

• the stakeholder who wants the wrong thing and what you say to them

• the trade-off you make and what it costs Five lines is all it takes. I do this all the time. This is what helped me move from data engineer to head of data engineering in less than four years.

When you interview, walk through the rejected alternatives. Leave the final output for the end. “I could do X, but I choose Y because Z“ tells the interviewer more about your judgment than the dashboard ever will. It also gives them something to probe.

Your judgment stays invisible unless you write it down. Nobody else will do it for yo.

The Decision Log Workbook

I turned the five lines into a workbook so you don’t have to figure out the format yourself. It has the template, a filled example, and ten questions that force the reasoning out when your answer is “it felt wrong“. There’s also a script for walking through the log in an interview, and a version for the promotion interview.

I turned the five lines into a workbook so you don't have to figure out the format yourself. It has the template, a filled example, and ten questions that force the reasoning out when your answer is "it felt wrong". There's also a script for walking through the log in an interview, and a version for the promotion interview.

Final Thoughts

The skills you’re proud of, writing code and architecting platforms, stopped being advantages the moment AI could do them. In 2026, leaning on them is running on fumes. AI can’t decide. Deciding is the one thing you’ve never practiced.

AI makes the resume even weaker. A Robert Half survey of more than 2,000 hiring managers in late 2025 finds that 65% say AI-generated resumes make skills harder to verify. If you write it with a robot, it reads like everyone else’s. Your judgment is the only thing that could set you apart. It’s still in your head.

I talk to tech professionals in my coaching practice, and they all make the same mistake. The ones who spent years honing their technical expertise never get promoted. You put your head down and work withot looking around. You have no idea what your impact is, and you don’t know how much your expertise costs. You leave money on the table.

I’ve helped many of them overcome this, so I’m working on something for everyone, and I’ll announce it very soon.

—

Until next time,

Yordan

PS: This applies to the promotion interview too. The people who decide already watch you build the thing. They never see why you build it that way. Write that down before you walk in.

PPS: I help tech nerds getting paid what they really deserve. Book your free discovery call today, if you are ready to earn real money.

book now

More on the Topic

• The First 90 Seconds of Your Interview Are the Most Important

• How To Stop Waiting For Permission To Lead Data Engineering

• Own it

If you wait for a calendar invite or a HR-mandated form to tell you you’re ready for the next level, you’ve already failed the test for that level. You essentially ask your manager to be your career coach, your biographer, and your cheerleader.

Most data professionals treat their career growth like a ticket in a Jira quee. They ship the code, they hit the KPIs, and then they wait for the status to change to “Promoted”. They think their manager is “too busy” or “forgetful”.

The truth is harsher. You made yourself easy to ignore because you waited for a permission slip to grow.

The First Move: Stop Asking for a Review

The biggest mistake you can make is to ask for a “performance review” when no process exists. You ask for a meeting that your manager doesn’t know how to run and doesn’t want to organize.

Shift your focus from the review to the requirements. Book a one-to-one and ask this:

What do you expect a person on my level to be able to do? What can I do more to contribute more to the org?

The framing here is everything. You aren’t a kid who asks for more toys, but a mature professional who cares about the wellbeing of the company. You identify the gap between where you are and where the company needs you to be.

During this conversation, push for specifics. If they say “be more strategic”, they’ve given you nothing. Ask for specific projects or behaviors. The more concrete the requirement, the harder it is for them to move the goalposts later.

But remember: doing a task once isn’t a skill. It’s a chore. If you’re told to “lead more meetings”, and you lead one meeting, you haven’t leveled up. You’ve just checked a box. You must show a permanent change in quality.

The difference between being overlooked and being promoted is usually just a change in who owns the growth path.

The Engine: The Brag Document

Your manager’s memory is a leaky bucket. They don’t remember that you saved the Q3 reporting cycle by fixing a legacy pipeline in your sleepm but will remember that you missed one deadline in November.

This is why you need a Brag Document.

A brag document is a live log file of your professional judgment, not a CV. If it’s not logged, it didn’t happen. Follow the gold standard here:

Track every achievement, every decision, and every win in real-time. Focus on outcomes rather than tasks.

Don’t just write “Organized the data dictionary”. Instead, write “Organized the data dictionary, which reduced onboarding time for new analysts from three weeks to one”.

Include the things that don’t show up in a GitHub commit:

• Exercised judgment by saying “no” to a low-impact request.

• Organized a cross-functional meeting that aligned three teams on a single metric.

• Spent ten hours mentoring a junior engineer who now owns the ingestion layer.

These are the markers of a senior professional. If you don’t track them, you are relying on your manager’s memory to decide your salary. That is a dangerous gamble.

How Walt Won a 17% Raise

A coaching client, Walt, worked at a scale-up with zero formal reviews. For two years, he was the “reliable guy”. He shipped everything on time, but his salary stayed flat while the market moved.

Walt stopped waiting.

He started by benchmarking his role against the external market to see exactly how underpaid he was. Then, he built a brag document that mapped his daily output to the business value he created.

Instead of going to to his manager with the phrase “I feel I deserve a raise”, Walt went with evidence. He showed the benchmarking data, the brag list, and the links to his achievements directly to the requirements he had agreed upon six months prior.

Walt, built a business case rather than an emotional plea.

In result, Walt got a promotion and a 17% increase in total compensation. The evidence made the cost of losing Walt higher than the cost of promoting him.

Closing the Gap

Once you have the requirements and the evidence, you have to close the loop.

Do not wait for the end of the year. Book the conversation 3-6 months before you expect a change. Use your existing weekly one-to-ones to keep the momentum going.

The script is simple:

Remember how I asked you what I need to deliver to start working on the next level? I believe I’ve learned what you told me. For example, I did X and Y. I can send you my full achievement list after this call. Let’s talk about my promotion.

Your manager might get defensive. They might say “not yet”.

Do not get angry. Anger is a junior response. Maturity is the only currency that matters here.

Take the “no” as a diagnostic tool. Ask for clarity:

What exactly is missing? What is the specific gap between my current output and the next level?

Exit the discussion with clear action points. Even if the action point is “we will define the exact criteria in our next call”, you have won. You have moved the conversation from “maybe” to “how”.

Final Thoughts

If you are like most engineers, you always wait for clear career path provided by the org they work for.

The reality is that you are the only owner of your career.

If you wait for a clear career path provided by your organization, you are making a bet that your manager’s agenda perfectly aligns with your financial and professional growth, but it rarely does. Your manager is focused on their own KPIs, their own stress, and the immediate fires in the pipeline. When you leave your growth in their hands, you are leaving money on the table.

This risk is higher now than it has ever been.

AI changes everything and nobody knows what our career will looks in 20 years from today. Heck, we don’t know what it would look like in 5 years. The technical skills that got you pronoted three years ago are becoming commodities, and the only hedge against this volatility is ownership.

The organization will never provide a map that is more accurate than the one you build yourself through evidence and negotiation. So, stop asking for permission to grow, and start owning the evidence, defining the requirements, and driving the conversation.

If you aren’t the one managing your career, someone else is. And they are almost certainly underpricing you.

That’s why I created this complete guide and worksheet for paid Data Gibberish subscribers to help you fast track your promotion and get paid what you really deserve.

unlock the guide now

—

Until next time,

Yordan

PS: Next time we’ll continue and I will show you how to frame your wins in a business case that gives your manager no choice, but to promote you.

PPS: Many readers prefer to get help with implementing the ideas I share here and be get better results faster. That’s when they come to me for coaching. Book your free call now.

More on the Topic

• How to Run Better 1:1 Meetings With Your Manager

• Talk Techie to Me: Translating Data Complexity for Business Leads

• 4 awkward stakeholder conversations you have to master if you want more money and respect

Subscribe now

Many years ago, I had two managers. Only one was official. My team, DataOps was engineering and I reported to the VP of Engineering. The analytics team kept changing hands until it settled under the head of data, who reported to the Chief Product Officer. We had two departments, two budgets, two sets of quarterly goals, and I answered to both of them whether anyone had written that down or not.

DataOps owned the infrastructure: ML infra, clickstream events, the data flow between systems, and the model review whenever we acquired a company.

BI owned the output: dashboards, the board pack, one shared definition of what the KPIs actually meant.

BI was my biggest stakeholder by volume. They could not ship a single number without the pipelines my team maintained. I ended up as the connection point between two senior leaders who each saw half of what I did.

This setup is comon in data orgs. Anytime engineering sits under R&D or platform and analytics reports to the business side, someone ends up standing in the middle, no mattar what the org chart shows. When that happens, you have two options.

Playing Defense Caps You At Senior

Option one is the one I see the most. Since I started coaching data engineers, I’ve talked to a handful of them stuck in exactly this setup, and most start the same way.

You get frustrated, and start wondering who this other person is to ask about their timelines, their priorities, or when you’re taking leave. You complain to your actual manager and ask them to be the proxy.

It feels justified in the moment, but it’s the wrong move.

Asking your manager to handle the comms for you tells the org that you can’t be trusted to prioritize your own work or manage a stakeholder relationship without a chaperone. Keep doing that and you cap out at senior, because the jump past senior depends on the exact skill you just outsourced.

Your stakeholders notice too, and they stop asking you directly, so they find a way around the data team entirely, but using a shadow spreadsheet or a self-service tool nobody vetted.

Treat It Like You Actually Report To Both

Option two is the one I took, mostly out of necessity. I reported my priorities, my progress, and my time off to both the VP of Engineering and the Head of BI, the same way I would have reported them to one manager. That meant a real report on what I was working on, what had shipped, what was at risk, and when I would be out.

This works because matrixed reporting lines split your visibility in half, and each manager sees a different, incomplete slice of what you do. Neither one has the full picture unless you build it yourself.

The VP of Engineering saw my roadmap, my asks, and how fast my team shipped. The BI Head saw whether the dashboards had fresh data. Neither saw the whole job, because I was the one doing it.

Everyone expected my team would work on their priorities and planned their roadmap according to this expectation. And this resulted in some overwork, a bit of context switch and a whole lot of stress.

Once I started reporting to both of them on purpose, they stopped guessing and started planning around me.

When you do that, you stop being the data team people route requests to, and you become the person both sides call before they make a decision that touches data. That’s the difference between a service provider and a strategic partner, and it doesn’t require a title change to happen.

That shift only sticks if the weekly update is simple enough to actually send.

The Weekly Habit That Makes It Work

Reporting to two managers only works if it costs you less time than avoiding it. I setup a weekly one to one with my second manager and shared my update so it would fit in 4 lines of text.

The Four-Line Format

Your report must be simple. The more time it takes you to prepare for this, the more likely you are to skip it:

• Priorities this week

• Progress since last update

• Risks or blockers

• Time off or availability

The One Rule

There is one rule keeps this from turning into two people pulling you in different directions.

Whoever owns the roadmap decides prioritization, and the other person get visibility.

In my case, when BI wanted something we didn’t have the time to do, that became a conversation between me and my actual manager, not something I negotiated ad hoc in a Slack thread.

I turned this into a one-page kit. It includes a worksheet for mapping who your other managers actually are, the exact weekly update template, and the two-sentence script for opening the arrangement.

The only way to download the worksheet is to upgrade now.

upgrade now

Final Thoughts

Org charts don’t really work for data teams we are cursed blessed with the opportunity to talk to anybody in the company, from individual contributors to the CEO.

Communication and management skills show up anywhere a stakeholder has real sway over your work without formal authority over your career, being it a vendor, a client, or a cross-functional peer who can veto your launch.

Treat the informal relationship like the formal one, and people stop wondering whether you can be trusted with the parts of the job that aren’t code. That’s really the other half of the job.

Until next time,

Yordan

PS: I started Data Gibberish to help tech experts who struggle with corporate politics and career blocks like this one. Upgrade today and get access to everything in the Premium Content Library.

upgrade here

More on the Topic

• Where Your Data Team Sits Is a Strategic Decision

• The Operating System Every Data Engineering Leader Needs

• Why Senior Data Engineers Lose Their Velocity (Even When Their Skills Improve)

I was the only data engineer responsible for all the data infra and pipelines. It was all fine in the beginning. We were just building the platform, and I never realized how the demand grew with time.

At some point, stakeholders started asking me all at once what had happened with their projects. I was replying to each one individually, and I started dropping the ball, missing some replies entirely.

My manager’s back then, Serge, plan was to let me manage stakeholders myself, learn the skill properly, and move into a lead role once I could do it good. One stakeholder at a time, I handled this fine, but that many people messaging me seperately, I dropped things I would never normally drop.

Individual Updates Don’t Scale

The dropped threads made me look unreliable. And the problem was that nobody but me could see how many people were waiting on the same person at the same time. Every conversation lived in its own private thread, so every stakeholder assumed they were my only priority and every stakeholder had a fair reason to be annoyed when I went quiet.

I could’ve tried to answer faster or set stricter response windows for myself, but neither one would have fixed anything, because the constraint was never my speed. Ten people’s worth of stakeholder management was landing on one person, and nobody outside those private threads could see it.

The Fix Serge Told Me to Try

Serge’s advice changed how the rest of this played out: stop replying to people one at a time, and post one update to the whole channel insted. We already had an official DataOps channel where I fielded requests from across the company. Every Friday, I started posting the same short message there, broken into three parts, tagging whoever was affected by each line.

It took about 4 minutes to write. I stopped writing separate private updates and started writing one public one.

What Three Bullets a Week Actually Changed

The message changed who could see my workload. Anyone in the channel could scroll up and see every stakeholder getting real updates from the same person, every week, in the same format. Nobody had to ask me how busy I was, because they could read it.

Stakeholders stopped pinging me to ask when I’d get to their request. They could see it sitting under “What’s Next Week“ and knew exactly where it stood. Serge stopped guessing what I was working on too. He was busy, and a four-minute post was the fastest way for him to see what I’d actually shipped.

It became clear to Serge and the marketing VP that one person could not keep absorbing this many stakeholders forever, and the weekly post was the reason it was clear. We hired more people onto the team, and I became a DataOps Lead.

Paid subscribers get the exact message I posted, word for word, with the real screenshot from the DataOps channel, the one rule that kept it from turning into empty promises, and the steps to build your own version.

Read more

I’ve been working remotely for nine years now, long before COVID made it mainstream. The last 6 of those years, I’ve led a team.

I’m a massive proponent of remote work, but I know most people never learn how to lead a remote team well. Actually, most managers are quite incompetent at it, and their teams pay for it in lower performance.

So today, I’m going to try to tell you how I run my remote team that ships more work, at a higher quality, than most in-office teams.

Where Most Teams Fail

Communication in the office is easy. You go to a coworker’s desk and ask them to help you, then sit together and work on the problem. You don’t need any real skill to do that.

The same applies to knowledge sharing. Since you are all in the same room, ideally sitting next to each other, knowledge gets shared naturally through diffusion.

Not to mention, how easy it is for a manager to see if their team members struggle with something, and help them on the spot.

None of this is possible in a remote working environment. Most people, never get a proper training in remote working etiquette, and fail miserably. Then they say everyone should just work from the office.

So here’s exactly how I run a remote team that works well.

Daily Stand-Ups

Most people get stand-ups wrong. They think these meetings are just a status report. You do something on the side, or scroll your phone waiting for your turn. Then, you sing your song, and get back to staring into the dark.

“This could have been an email”, everybody says.

But that’s not the point of morning stand-ups. In remote setting, they have 3 functions:

1. Team bonding

2. Status update

3. Knowledge sharing

Team bonding

We always spend the first 10 of our 30 minute stand-up in chit-chat. We talk about our days, or whatever we find interesting. 10 minutes feels like nothing, but overtime, it helps the team bond and know eachother better.

This means people stop being just random squares in Zoom, that interrupt your work every now and then.

Sharing about your interests results in building meaningful relationships at work, even if you don’t meet in person regularly. It might sound small, but it matters for mental health, especially for someone on your team who lives alone.

Last, this whole process builds trust, and people who trust each other work much better together.

Don’t trust me? Here’s my team’s eNPS score for our “Be Together” value.

Status update

Status update is of course a big reason to have a mornign stand-up. But this is not an update from a team member to a manager.

I insist everybody pays attention and stops multitasking. I want everybody present for the full 30 minutes. When you actually listen to your team members’ updates, you cut the chance of duplicate work and increase the chance of catching somebody who needs help.

I still remember introducing daily stand-ups at my previous workplace. Nobody really cared what others had to say. Once I enforced the “pay attention” policy, things started clicking. Everybody started sharing ideas about tackling blockers, and we started shipping much faster.

Knowledge sharing

When working remotely, information doesn’t pass to team members over the air. They can’t just overhear a conversation. That’s why morning stand-ups matter so much for knowledge sharing.

During your daily, you share what you did, but also what you learned and how you applied it. Maybe it’s a debugging trick that saved you an hour, a review comment that changed your approach, or a tool feature nobody else on the team knows about.

It sounds like small thing, but it adds up fast when ten people hear it every morning instead of one person stumbling onto it alone. We also often decide to dive deeper separately after the stand-up.

This issue is brought to you by Cube.

Agents do the analysis. Your team does the thinking.

A question about your own business data still means a ticket, a queue, and a week of waiting. Cube hands that workflow to AI agents: they model the data, explore it, and build the reports — your team guides and approves — so week-long analysis comes back in minutes. And because every agent works from one governed set of metric definitions, the answers come back right. 400+ companies run on Cube, including Brex, Wix, Patagonia, and Webflow.

Get started for free

Pull Requests

Just last week I ran a Show and Tell session for our DnA team (yes, that stands for Data and Analytics) last week to remind the team why use pull requests.

So let’ me ask you the same question I asked last week:

Why do we open pull requests?

Most people say “So others can spot issues we may have missed”, and while this is true, it’s only half of the story.

The other part is again knowledge sharing. A proper pull request serves as documentation when you write a clear description and commit messages that explain not just what you did, but why.

I could write an entire article on structuring a pull request that speeds up reviews and shipping. But what matters right now is to write more than three lines.

A good description needs at least three sections.

• Background. What’s the current state? What problem are you solving?

• Goal. What exactly are you trying to do, and how does your solution get you there?

• Implementation. What did you do at a high level, and why did you make the decisions you made? Answer the questions your reviewers would otherwise have to ask you directly.

Remember to list specific files that you want to get reviews for, and related pull requests, tickets, and anything that would help your reviewers go through the review quickly.

A well structured pull request description helps your reviewers understand what you’re doing, learn from it, but also review your code properly instead of just approving it blindly.

My experience shows that spending a few minutes writing a proper description, you actually saves your reviewers time now and, yourself the headaches later.

For my team, pull requests are not something you open to follow a process and then you close. We treat them as long-term documentation. When you need to know why a change was made months later, you trace it to a specific commit, and that commit ties back to a pull request.

Document your commits well, document your pull requests well, and people will actually understand the decisions behind them.

Micromanagement

This one is a bit controversial, so let me say upfront: I hate micromanagement. Micromanagers the worst as they strip their team of any sense of autonomy.

But here’s the problem in a remote working environment. When somebody struggles with their code or their project, you can’t see it. In an office, you’d notice within a day. Remotely, all you have is their status update during the daily, and that’s not always enough to tell you what’s actually going on.

So when somebody misses a deadline twice, I start nudging them. Not the first time, not even the second. But by the third or fourth miss on the same project, I start checking in daily. In the morning, during the daily, I ask directly:

• What’s your plan?

• Is it realistic?

• What’s actually blocking you?

If then need help, or I’m not clear what’s blocking them, we catch up right after the daily Sometimes this results pair coding, and some times I point them to the right person.

Later in the day, usually after lunch, I check in again.

I know this isn’t a great approach, and I don’t use it by default. I only reach for it when someone is genuinely struggling with their project.

This approach is easier in an office, where people ask their small questions a few times a day without thinking twice. Remotely, people hold back on asking for help. Someone once told me directly: “I don’t know how busy you are, so I’d rather not bother you”. So, reaching out first isn’t irritating, and it actually shows you’re there for them.

And you need that, because failing to deliver for a long stretch makes people feel guilty. It makes them feel like they’re failing. Knowing someone is there to help them hit their goals is great for their mentality.

Other Meetings

As technical people, you and I hate meetings. But the reality is that when working remotely, you do need meetings. Not all the time, and you should really avoid them when you can, yet some are unavoidable. Here are the meetings I run with my team.

One-to-One

First is the one-to-one. When you work remotely, you can’t skip this. Some people run these once a month or even once a quarter. That’s not enough. Weekly one-to-ones are a must.

I use them for whatever my team members want to talk about, whether that’s casual chat or something on their mind. Th one-to-one is also the time to talk about bigger projects, ideas, and non-urgent feedback in both directions.

Run these meetrings every single week with every single one of your team members. And here’s a pro tip: try to squeeze them all into a single day, maybe two if you have too many. I’ve dedicated Wednesdays and Thursdays to one-to-ones with my team, my manager, and a few other people I mentor across the organization.

If you want to learn how to run better one-to-one meetings, check this article I wrote earlier this year.

Retros

Every month, my team and I get on a call and go through the previous month. We talk about what went well, what we could improve, and what our action steps are.

This is a fully open discussion. My team members are free to tell me I’m an asshole, and I take it, because the point is to improve, not to defend the organization or my own decisions.

That matters even more remotely, because you don’t really have the option to pull someone aside privately and talk it out over lunch. Doing it together, as a team, works far better.

Brainstorming

We run plenty of brainstorming sessions, one-on-one, with a subgroup, or with the entire team. When somebody has a problem they need more time to explain, or wants opinions on what they’ve tried, we organize an ad-hoc session and hop on a call to work through it together.

Just today, someone from my team and I, spent half of the day in a call to run a complex migration.

This helps people understand areas they don’t normally touch, learn from eachother, and share their own experience.

It works well as a group session, but a single pair-programming session does the same job. Pair programming is one of the things my team consistently asks for.

Written Communication

As I said, meetings are great for bonding and for expressing thoughts quickly, but you should avoid them when written communication does the job. My rule of thumb is:

We work remotely, so async communication comes first. Use meetings only for recurring check-ins or when you genuinely need one. Everything else needs ink.

The thing is most people don’t know how to write. Managers are terrible at written communication themselves, and they never train their team on it either. Without that training, you usually get one of these:

• WhatsApp message: sending one word per line, like a text thread.

• Crystal ball: expecting people to somehow guess what you mean.

• Silent hill: you never send updates, and getting one out of you feels like pulling teeth.

That’s why training my team on proper written communication is a top priority for me. And I hate to admit it, but I’ve let people go because they never learned remote working communication etiquette.

BLUF

I’ve written about BLUF before. In short, it’s a framework that allows you to write structured messages that give enough context, so people know exactly what problem you have, why you have it, and what you need from them.

BLUF allows people to read just a part of your message and still get everything they need.

Overcommunication

The harsh truth is that people are way too busy with their own shit, so you should not expect them to remember what you’ve told them 3 weeks ago.

Always share the full context with the receiving end, even if you believe they should already have it. Its your job to remind them where you left things last time and what you need from them now.

When you overcommunicate, you stop people from asking what this was about. Or worse, from pretending they remember and hoping to catch up later.

Last, sharing context often helps new readers get up to speed quickly, without scrolling through the entire chat history.

Scoping docs

These documents guarantee you actually do what you and the stakeholder agreed on. They also prevent the stakeholder from adding more and more changes to the initial requirements.

Write these regardless of whether you work remotely. For now, here’s what a good scoping doc needs:

• Background

• Objective

• Stakeholder map

• Deliverables

• Risks

There’s more, to be said about that, and I strongly recommend reading my deep dive and getting my scoping doc template when you’re done with this article.

Postmortem reports

I’ve mentioned these many times before, and like scoping docs, I recommend using this tool even if you work on-site.

Postmortems are incident reports where you focus on the facts, lessons, and actions, so similar incidents don’t happen again.

The most important thing about postmortems is avoiding blame. In my experience, when an incident happens, it’s because your process allowed it to happen. Murphy’s Law is right in this case

Anything that can go wrong will go wrong.

Read this article to get my incident report guide and template

SOPs

Standard Operating Procedures are short documents where you explain exactly what you do in a given situation.

When you work remotely, you’re not always able to share your screen and walk your team through everything. That doesn’t scale. And you don’t want to be tethered to your laptop during every vacation.

So if you run a strict set of steps in a given situation, create a page on Confluence and make sure everybody knows about it. Good examples here are our pipeline debugging process and our pull request process.

AI makes writing SOPs a breeze, and I gave a complete demo how you can do it in just a few minutes. Watch the demo, and remember to copy the prompt.

Focus Time

And before we wrap it up: when working remotely, as an engineering lead, you are responsible with protecting your most precious resource, your time.

In the office, interruptions are easy. It takes someone a few seconds to walk up to your desk and break your focus. When working remotely, fighting context switching is far easier. But doing it well is more a mindset shift than anything else. So, I want you to learn this:

A relationship where you’re expected to respond within seconds is toxic. You’re an adult, and you’re paid to exercise agency. Yes, sometimes that means choosing to answer your boss after you finish writing that deduplication query.

So, here’s what I want you to do.

Stop phone notifications

Seriously, these notifications are usless. You absolutely don’t need be bothered by every status update, new TikTok video, or “Someone viewed your profile” message.

The only thing that really needs to make a sound is phone calls, because that’s how people reach out in case of emergency. Everything else stays silent.

The way I think about is this:

Stop computer notifications

Do the same with your computer. Turn off notifications from email and Slack. You don’t need to know about a new pull request immediately, or that a vendor is trying to sell you something. I’ll cover how to handle that later. For now, turn the notifications off.

On Slack, I only allow notifications for direct messages and when someone tags me. Nothing else gets through, not even a message from my boss. I’ll deal with it when I have time. Context switching is a disease, and you want to avoid it at any cost.

Block time

Now about time management itself. The principle is simple:

As I already said, you need avoid context switching at any cost. That’s why I recommend blocking chunks of your time for specific needs.

So, after grouping all your one-to-ones in a day or two (I already mentioned it earlier), I want you to block 3 more blocks:

• Your lunch break, so you don’t forget to eat. That happens more often than you’d expect.

• 30 minutes just before your lunch break for pull request reviews.

• One hour at the end of your day for another round of PR reviews and notes

Once done with these, keep adding small blocks for focused work when you can. And, check Slack and email for missed messages roughly once an hour.

Final Thoughts

Working remotely is genuinely hard. It takes real intention and self-control, and honestly, most people lack both. If you’re leading a remote engineering team and you learn to do this properly, you set yourself up to outperform most other leaders out there.

And if you learn to manage a remote team effectively, doing the same in an office would feel like child’s play.

That said, after working from home for almost a decade now, I don’t think I’ll ever go back. Come on, no organized fun with pizza beats this.

—

Until next time,

Yordan

PS: Everything in this article is one click away for paid subscribers. If you lead a remote team and want the templates instead of building them from scratch, upgrade here.

More on the Topic

• 3 Badass Productivity Hacks to Master Your Time Without Breaking a Sweat

• How I Apply The 5 SOLID Principles When Building Teams

• The 10-Minute Weekly Habit That Will Make You a Better Engineering Leader

Subscribe now

Most leaders grow their teams organically. They backfill when someone leaves, hire when a new project lands, and add an analyst when the CFO wants a dashboard. Two years later they look around and see a mess. One sub-team has six people tripping over each other, another has one person drowning, everyone is busy, yet nothing ships fast.

And you know what? You already know how to fix this.

Every engineer who made it past their first year knows SOLID principles. You apply them to your code, but nobody taught you how to use them when building team. And that’s why most engineering teams grow like spaghetti.

I have been applying SOLID to team building for years. Three years ago I wrote about using it to structure a data migration. That article still holds up. Read it here if you want the technical version.

But today, I am walking you through the people version.

I have seen this work for teams up to 15 people, which is great, because, nowadays most data teams that actually ship are even smaller.

Here is how it works and how you do it.

But before that, I’d greatly appreciate if you boost my metrics a bit by clicking the link below.

This issue is brought to you by Cube.

Agents do the analysis. Your team does the thinking.

A question about your own business data still means a ticket, a queue, and a week of waiting. Cube hands that workflow to AI agents: they model the data, explore it, and build the reports — your team guides and approves — so week-long analysis comes back in minutes. And because every agent works from one governed set of metric definitions, the answers come back right. 400+ companies run on Cube, including Brex, Wix, Patagonia, and Webflow.

Get started for free

Single Responsibility Means Splitting The Work Before You Hire

I do not love repo sprawl, but we run three separate dbt projects because the use cases, skill sets, and velocities are too different to force into one place.

The first project is for data engineers. They clean data, fix types, and enforce structure. It is the plumbing. The second project is for analysts. They build business logic, define KPIs, and model the objects that feed our BI tools. The third project is lightweight vendor modeling. Our vendors see their work, and we see what we owe them.

I split them intentionally:

• An analytics engineer should focus on their models without worrying about ingestion pipelines.

• A product person should think like a product person, and when they have to reason about data types and ingestion logic, something is wrong.

Each sub-team moves at its own speed and owns its own scope, and no one steps on another sub-team’s work.

I do not ask analysts to optimize costs or write complex macros, and I also do not want data engineers to create dashboards. Everyone knows what they own.

This is where most teams go wrong. They hire before they split the work, so they bring in five analysts and two data engineers and throw them at a monorepo, then they wonder why the analysts break pipelines and the engineers resent the noise.

How You Do It

Write down the ownership rules and post them where people see them:

• When someone asks who owns the vendor schema, the answer should be obvious.

• When someone asks who approves a change to the BI model, the answer should be obvious.

• When the answer is not obvious, people slow down, they ask around, they wait.

Clear boundaries fix that.

Open For Extension Means Your Team Grows Without Reorgs

In code, the Open/Closed Principle means you extend behavior without modifying existing code. On my team, it means you extend people without restructuring the org chart. Career growth comes from doing the work instead of watching someone else do it. When an engineer wants to try analytics engineering, give them a project.

That’s how the org chart stays the same, and they grow anyway.

I’ve had one to ones with one of our embedded analysts for years. She was more of a stakeholder than a team members. Then, she started showing interest in writing BI code, and then dbt. Our senior analytics engineer, and I helped her learn all the necessary skills. A few months later, she build one of our 3 dbt projects from scratch. After a couple more months, she fully transitioned to becoming an analyst and joined the team.

Now, this only works with strong leaders. You need to see potential in your members and give them challenging tasks that push them in the direction they want to grow. You need to foresee where your team needs to expand and support your org to reach its goals. Weak leaders give projects to people who already have experience with the area. They wait for a re-org to justify a title change, and they let people stagnate because it is easier than finding them a stretch project.

How You Do It

Map the skills on your team. Think about who writes SQL, who knows Python, who do stakeholders actually listen to, and who fixes Airflow when it breaks. Then map the gaps. What work sits unclaimed because no one has time? What projects stall because they need a skill that lives on another sub-team? Those gaps are where people grow.

Give your people a real task with stakes and support. Pair them with someone who already has the skill, and let them ship something that matters.

The key is to keep the core structure intact. The data engineering sub-team still owns ingestion, and he analytics sub-team still owns BI, but the people inside those sub-teams should move.

Remember to set a rule. Every quarter, each person should spend at least twenty percent of their time on work on the area they want to grow. Give them real work that the team needs, and track that work in your planning tool and talk about it in one-on-ones.

Liskov Substitution Means Everyone Knows What Everyone Else Does

In software, the Liskov Substitution Principle says a subtype should be replaceable with its base type. In team building, people translate this to a simple idea: if Engineer A goes on vacation, Engineer B steps in seamlessly. Every engineer must know what the others do.

Modern data teams are small and do not have the headcount for deep specialization. I like this, because every engineer knows what the others do. They learn it in dailies, show-and-tells, and pull requests where we talk out loud.

We also try to have at least two people for every role. The lead should do the job too. Managing is not the whole job.

One more note in case this gets confusing. Single Responsibility separates the roles, while Liskov Substitution makes people interchangeable within the role. The boundary sits between roles, and not inside them.

So when someone takes annual leave, the system does not break because Engineer B is a clone. Engineer B keeps the system running because they paid attention. They read the PRs and asked questions in standup. They knows which jobs fail, and which tables no one trusts.

How You Do It

Read more