Yordan Ivanov

I'd worry about a lead who wins every argument. Nobody tells you when your team stops arguing, and the mistakes reach production with your name on them. When did your team last change your mind?

I lose arguments to my team all the time. When someone wins, I commend them, because they know something I don't, and I'd rather find that out in an argument than in production. PS: I write about getting from senior data engineer to lead. Follow if you want that job.

I make my team earn every argument they win. My rule is objective decisions over personal preferences, mine included, so to change my mind you must know your shit. Internal processes, tooling and infra, and why you use what you use.

2 places I'd put people over code this week. On your projects, pick what stakeholders need, and with anyone you mentor, lean on their strengths, which I didn't. PS: I write about getting from senior data engineer to lead. Follow if you want that job.

I watched the weaker programmer get the team. Kamil was better than Nick at prioritisation, still not great. Nobody outside the data team gives a shit how beautiful the code is. What's your case for lead besides the code?

I was criticising him, showing him "the right way". He was experienced in another career and new to engineering, and I didn't lean on his strengths. He didn't say why he left, but we all knew.

State of big AI today.

Your debt ticket has no requester and no price, so it loses to every new model on arithmetic. https://open.substack.com/pub/datagibberish/p/data-tech-debt-ticket-without-a-price?utm_source=bluesky&utm_medium=social&utm_campaign=data-tech-debt-ticket-without-a-price

Paying down tech debt in secret is a crap deal. You pay in your own hours and again at review. https://open.substack.com/pub/datagibberish/p/data-tech-debt-ticket-without-a-price?utm_source=bluesky&utm_medium=social&utm_campaign=data-tech-debt-ticket-without-a-price

I checked my market rate this month. A quote can say you're already paid right for the job you have. That's worth knowing too, and cheaper to find out in October than in February.

Two managers need one rule. Whoever owns the roadmap decides priorities, and the other one gets visibility. Which one owns yours?

Whoever uses the number decides if the data is usable. Your job is to say what's wrong with it in the first line, then let them choose between waiting for the fix and using what you have. PS: I write about getting from senior data engineer to lead. Follow if you want that job.

Look at last week's calendar if you lead the team. If most of it happened inside a codebase and not inside a conversation, you're still operating like an engineer with a bigger title.

Your explanation is part of the engineering. On a cross-functional project, a schema migration can be technically perfect and still wreck a finance close if nobody makes the cutover decision clear. Who explains the cutover to Finance on your team?

Most exec questions are curiosities. A Data Wise post makes that case, and building for them anyway is how you end up explaining the ROI of data to the CFO. PS: I write about getting from senior data engineer to lead. Follow if you want that job.

"I could do X, but I chose Y because Z". That line tells an interviewer more about your judgment than the dashboard ever will, so lead with the rejected alternatives. PS: I write about getting from senior data engineer to lead. Follow if you want that job.

A range barely matters for work you've done many times. The two dates nearly touch and nobody argues about a day. It earns its keep when there's something you don't know yet, which on a data team is most of the time.

Doubling an estimate is a crap way to plan. When the plan slips, nobody can tell whether the work ran late or the multiplier was wrong. Who doubles your numbers, and by how much?

The fastest debugger on a team slows everyone else down. A lead I coached was first on every incident her team had. Each one got fixed, and it's one of the reasons nobody else on her team got faster. When did someone else last get to an alert before you?

I only promise the slice in front of me. If you promise a date months out, you find out how wrong it was near the end, when the only thing left is the apology. On a migration that means dates for the first slice, and the rest gets dates when I can see it.

Padding is a margin you hide inside one number. They know there's some bullshit in there, so they cut, and you know they cut, so next time you pad more. PS: The full guide is on my newsletter.

Done is an agreement with your stakeholder. Before I hand anything over, I ask if there's anything critical missing. If the answer is no, it ships, and two weeks later I check the query history to see whether anyone uses it. What do you check after you ship?

Each date you miss without warning cheapens the next. Miss a few and you get what I got from a founder about ten years ago, every number doubled before it reached anyone's plan. PS: I write about getting from senior data engineer to lead. Follow if you want that job.

An estimate is a promise. Only promise the date you'd bet on. The best case is still the first date I think of, ten years after a founder doubled every number I gave him, so I send it as the near end of a range and promise the far end.

"Most of what we call prioritization is forging agreeable narratives". That's John Cutler, and he says nobody leaves a retro blaming the scoring model. They blame not having the conviction to stop something. What does your team keep not stopping?

Your work happens in investigation order. Your explanation needs to happen in decision order. The SLA at risk goes first, and the Airflow alert and the schema change go underneath. PS: I write about getting from senior data engineer to lead. Follow if you want that job.

"Good question. I need a minute to think". I had to practise that line for live calls, because a confident guess costs you trust the moment the facts change, and a pause costs nothing as long as you come back when you said you would.

Modern organisations are becoming flat. That's good news if you like doing the work yourself, and it means nobody retells your work in the exec meeting you're not in. Your update reaches them exactly as you wrote it.

I once spent a week on key bindings nobody used. It was my first real job, a client's job board, and I thought that was what good work looked like. PS: I write about getting from senior data engineer to lead. Follow if you want that job.

A lead who only codes is a bottleneck. In January I wrote that staying 100% focused on the code was the biggest mistake I made as a new lead, and in a flat org the lead who only manages is the overhead getting cut. Which way does your week lean?

A fortnight before your review, the person who'd confirm your best line has forgotten what changed, and the case is a draft nobody has time to mark up. Everything your case needs has to exist months before anybody asks. The full guide is on my newsletter.

"I'm pretty sure they did great work". That's a promotion case built on memory. Memory doesnt hold the outage somebody headed off in a design review, or the process un-fucked. The near miss is the strongest work you have. It lives nowhere. PS: ask what nearly broke this month.

My engineers keep brag lists. But I do it for them, too. Every dat I write down what shipped, what broke, and what almost broke. Their memory fades. Mine is written down. When I defend them in rooms they never see, I bring my list and the dates do the talking.

Review season started. My strongest engineer cant remember what he shipped in March. He shipped plenty. The memory moved on with the work. His self-assessment has three bullets in it. Write it down when it happens, or you will undersell it later. What can you name from March?

No matter what you've been told, salary season doesn't start in December. If you need a promotion or a salary increase, you need to start pusing for that in September.

"Great question, let me take that away" is corporate for "I have no idea and I hope you forget".

"We're all one team here" is corporate for "you're about to do someone else's job for free".

"Let's circle back on that" is corporate for "I will never think about this again".

Owning the outcome means owning the failure too. That trade is the whole job of leading.

Stop asking for a review. Start owning the requirements. Ask what the next level looks like, then deliver it.

Waiting for a title before you lead is how you stay invisible. Name the problem and make it yours.

Your manager's memory is a leaky bucket. If your wins aren't written down, they didn't happen. Keep a brag document.