I was in my early twenties, still in university university, and responsible for a handful of client projects at my first real job. I had been coding since high school and I thought I knew what good work looked like.

I added key bindings to a jov board website. The client ran a small recruitment agency. Nobody on their team had asked for it, and nobody ever used it but I spent a week on it.

Projects ran late, budgets inflated, and our clients got angry. My boss, instead of firing me, handed me a small stack of books. In one of these books, The Pragmatic Programmer, I read about a concept I had never considered: shipping code that is good enough.

That idea rewired how I work. It changed how I ship, how I grow, and how I think about what it means to be a good engineer. I have spent years since then watching talented senior engineers repeat the same pattern I had at 21, and lose the same things I lost: time, trust, and the opportunity to work on harder problems.

Perfectionism Is Not About Bugs

You should never deliver buggy work intentionally. That is not the argument here, and I want to be clear about it before going further.

Most of the work engineers do past the point of “done“ falls into one of two buckets.

The first is rough edges. All sorts of imperfections that exist in the product but that no real user will ever notice or care about fall in this bucket. Think about a column name that is slightly inconsistent with the naming convention elsewhere, or query that runs in 800ms when it could run in 200ms, on a report that gets opened twice a week.

The second bucket is design preferences. These are things you want differently that your stakeholder never asked for, like a cleaner folder structure in the repo, a more elegant solution to a problem the current solution already solves.

The Distinction That Changes Everything

Rough edges and design preferences get presented as quality standards. That is the trap. An engineer tells themselves they are maintaining high standards when they are spending an entile afternoon on a naming convention nobody will audit.

Intentional restraint is a design decision. Choosing not to smooth a rough edge because no user will ever hit it is not laziness, and choosing not to build the abstraction because the requirement does not exist yet is not cutting corners. These are scoping decisions, and good engineers make them on purpose.

The engineers who struggle to stop are not the ones with low standards. They are the ones who have never separated “complete in my head“ from “complete for the purpose it serves“.

Perfectionism Costs More Than You Think

Shipping on time builds something you do not think about in the moment: a track record of reliability.

Your stakeholder remembers two things about you:

• whether your work was good

• whether you delivered when you said you would.

The second one compounds faster than the first.

When you ship clean, scoped work on time, you get the next project. And, you get pulled into the room where the decision is being made, because someone already knows you can be trusted to close things out.

That is the return on shipping. It is not glamorous, but it is how careers actually move.

The Week You Think You’re Investing

When you spend an extra week polishing past the agreed scope you lose:

• the relationship capital that week would have built with a different project

• the harder problem waiting on the other side of this one closing

• the visibility that comes from being someone who finishes

The cost disappears into the background noise of a slow quarter, and you never connect it to the week you spent on a naming convention nobody audited.

What You Actually Buy With That Extra Week

Polish on a finished product does not teach you anything new. It does not stretch your judgment or expose you to problems you have not solved before. It has the texture of diligence without the substance of it.

Perfectionism Is an Identity Problem

Here is what I have never heard a perfectionist engineer say: “I know this is done, I just cannot stop“.

They do not say it because they do not believe it. Every rough edge they are smoothing feels critical, and every design preference they are implementing feels like a quality standard.

The rationalization runs underneath the decision, and it sounds like judgment.

Where the Identity Comes From

At some point early in your career, you built an equation: good engineer equals engineer who finishes everything.

You saw thoroughness rewarded. You also got praised for catching edge cases, for going deeper than required, for the extra mile. The identity formed around completion.

That equation made sense then. In the early stages of a career, thoroughness is how you signal competence. You do not have a track record yet, so you demonstrate care through the detail of your work.

The problem is that the equation does not update. Ten years later, you are still running the same calculation, in a context where finishing the right things matters more than finishing everything.

What the Research Says

Psychologists separate perfectionism into two types.

Adaptive perfectionism: high standards, strong execution, healthy relationship with finishing.

Maladaptive perfectionism: the same high standards, but fused with avoidance, procrastination, and an inability to call something done.

The difference is what happens in your head when the work is good enough but not perfect.

A 2021 meta-analysis found that adaptive perfectionism is associated with better performance and wellbeing, while maladaptive perfec tionism is associated with worse wellbeing, more procrastination, and avoidant coping.

Most engineers I know with this pattern are maladaptive perfectionists. I was one, too.

The Gap Between Knowing and Shipping

There is a moment every over-polishing engineer knows but rarely names. The product works. The stakeholder is happy with what they have seen. The agreed scope is complete. And you are still in the code.

You know you are done. You stay anyway.

What fills that gap is the discomfort of letting something exist in the world that is not complete in your head. Shipping means accepting that the version in production will always be slightly less than the version you imagined.

For an engineer whose identity is built around completeness, that feels like becoming a lesser version of yourself.

That is the thing a productivity tip cannot fix. You need a different answer to the question of what a good engineer actually is.

The Stakeholder Already Told You It’s Done

Most engineers treat “done“ as a technical state. The data product reaches some internal threshold of completeness and then it ships. The problem with that definition is that you set the threshold, and you will keep moving it.

Done is an agreement.

You and your stakeholder defined the scope before the work started. They tell you what they need, and you build it. At some point in the review process, the nature of their feedback changes.

Early feedback sounds like “can we change how this filter works“ or “the numbers on this chart do not match what I expected“. That is active problem-solving.

Then the feedback shifts:

• “This looks great, when can we roll it out?“

• “When I can get access to this?”

• “Can the we also give access to my team?”

This shows you that your stakeholder has stopped looking for gaps and started thinking about using the product. The agreement has been reached.

The Closing Question

Questions like “is there anything you’d like to improve“ or “are there any other features you’d find useful invite scope expansion and put you back at the beginning of the loop. Stop asking them.

Before you hand anything over, ask one question: is there anything critical missing?

The word critical does the work. It filters out preferences and surfaces only the things that would prevent the product from serving its purpose.

If the answer is no, you are done. Write it down, send it in a message, create a paper trail. That record is for you as much as for them.

When You Talk Yourself Out of the Signal

• “They said it looks great, but they have not stress-tested it yet.“

• “The feedback was positive, but that was on the easy use case.“

• “I should add one more thing before it goes live, so the first impression is better.“

Each of these sounds reasonable. None of them are about the product. They are about the discomfort of letting go, but the stakeholder told you it is done.

Bugs, Rough Edges, and Design Preferences Are Not the Same Thing

The “one more thing“ feeling always presents itself as necessary. That is what makes it hard to dismiss, and that is exactly why you need a framework for categorising what you are looking at before you act on it.

Bugs

A bug prevents the product from doing what it was agreed to do:

• A pipeline that drops rows under certain conditions

• A report that breaks when the date range crosses a month boundary

• A metric that calculates correctly in the dev environment and incorrectly in production.

Defects are non-negotiable. Fix them before you ship, and if you find them after you ship, fix them immediately. This is the category that justifies stopping the clock.

Rough Edges

A rough edge is an imperfection that exists outside any real user’s path:

• A column name that deviates from the naming convention in a table nobody joins to directly

• A query that runs in 900ms when it could run in 150ms, on a dashboard opened twice a week by one analyst

• A tooltip with slightly imprecise wording on a filter that experienced users skip entirely.

Rough edges are invisible in practice. Leaving them is a scoping decision made on purpose, based on actual usage.

“Ugly by design“ is a legitimate engineering position. It means you looked at the imperfection, assessed its real-world impact, and decided the cost of fixing it outweighs the value.

Design Preferences

Design preferences are the expensive category, because they are the hardest to recognise in the moment.

A design preference is something you want differently that your stakeholder never asked for:

• A cleaner abstraction that would make future changes easier, for a future with no confirmed date

• A folder structure that better reflects your mental model of the system

• A more elegant solution to a problem the current solution already solves.

The test is one question: did anyone ask for this, or does it exist because it is incomplete in your head?

If the answer is the second one, you are looking at a design preference.

The Post-Launch Contract

Shipping is not abandonment. Your stakeholder needs to know what happens after the product goes live, and that conversation is your responsibility to initiate.

Most engineers skip it. The product ships, the Slack message goes out, and everyone moves on with an implicit assumption that the engineer is available for whatever comes next. That assumption becomes a maintenance burden with no defined edges, and it will pull you back into the product indefinitely.

Define the edges before you ship.

What You Commit To

Two things:

First, if something breaks in a way that prevents the product from doing its job, you fix it. A bug that surfaces post-launch is still a bug.

Second, you will check in proactively after two weeks to ask whether the product is working for them and whether anything critical is missing.

That check-in matters more than most engineers realise. It signals that you care about the outcome, keeps the relationship warm, and gives your stakeholder a defined moment to surface real issues. It also gives you closure.

What You Do Not Commit To

Everything outside those two things goes into a backlog. Feature requests, aesthetic preferences, and optimisations that would be nice to have are legitimate inputs for a future iteration, and you should capture them.

They are worth doing if the product sees real usage and the stakeholder comes back with them after living with the tool for a while.

A short message after launch that outlines what you are monitoring, when you will check in, and how to flag something urgent. Two paragraphs are enough.

The goal is a shared understanding, not a formal document, slides or any other corporate bullshit.

Why This Protects the Relationship

A stakeholder who knows what to expect from you after launch trusts you more. The engineer who disappears after shipping and the engineer who commits to everything indefinitely both damage the relationship in different ways.

Defining the post-launch contract is what makes you someone worth working with on the next hard problem.

You Will Know If It Works

Two weeks after launch, you have access to something more reliable than your own anxiety: data.

Data products leave traces:

• Every query run against your pipeline shows up in query history

• Every dashboard opened appears in your BI tool’s usage logs

• Every tab viewed in a shared Google Sheet is recorded in the Activity Dashboard

You do not need your stakeholder to tell you whether the product is being used, because you can look.

This matters because the fear that drives post-launch anxiety is usually vague:

• “What if something is wrong?“

• “What if they are not using it?“

• “What if I missed something?“

These are discomfort dressed up as diligence. The data answers them directly, and the answer is almost always that the product is running, people are using it, and nothing is on fire.

What to Look For

Query history tells you whether the pipeline is being hit and at what frequency. A product that was supposed to run daily and shows seven consecutive days of successful runs is a product that works

If the usage logs show nothing, that is information too. A product nobody uses is a product worth a conversation with your stakeholder, and that conversation is more useful than another week of polish would have been.

The Check-In

At the two-week mark, send a short message. Ask two things: is the product working for them, and is there anything critical missing.

The same question you asked before launch, asked again with two weeks of real usage behind it.

Most of the time the answer is positive. Occasionally something surfaces that genuinely needed addressing, and you address it. Either way, you now have a closed loop.

The product is no longer an open question sitting in the back of your head. You can move on to the next problem without carrying it with you.

Final Thoughts

The way you write code has changed. AI writes a significant portion of it now, which means the craft argument for over-polishing has collapsed.

Spending an extra week perfecting namming conventions and folder structures in a codebase where most of the code was generated is a poor use of the one thing AI cannot replicate: your judgment about what to build and whether it worked.

Your value as an engineer was always moving in this direction, but AI accelerated it. The engineer who ships, checks whether the outcome landed, and moves on to the next hard problem is worth more than the engineer who produces immaculate code that took three weeks longer than agreed.

Stop asking whether the code is beautiful. Start asking whether the outcome is what you and your stakeholder agreed on. That is the question that maps to real value, and it is the question that will matter more with every year that passes.

Ship it. Check if it works. Move on.

—

Yordan

More on the Topic

• Stop Starting Data Projects

• The Customer Service Mindset Is The Fastest Way To Destroy Your Data Team

• How ruthless prioritization got me a 40% raise and a head of data title I didn’t even want

As a hiring manager and coach, I have interviewed hundreds of candidates over the years. The pattern is almost identical every time.

The interviewer asks “Tell me about yourself“. You take a breath and start at the beginning.

You walk through your education, then your first role, then every move after that, including the reorg nobody asked about and the project you are clearly proud of. 5 minutes into your monologue, the interviewer is nodding, but their eyes have gone somewhere else.

I get it, you have a lot to say. The problem is that you are answering a different question than the one being asked.

“Tell me about yourself” is not an invitation to walk through your resume. It is the one moment in the entire interview where you hold the controls. You decide what they ask you next. Most candidates hand that back immediately and spend the next five or even ten minutes reading from a document the interviewer already read.

You will not do that.

They Already Read Your CV

The interviewer already read your resume. That’s why they called you for an interview.

They did not call you to hear it again. They called you because something on that one-pager was interesting enough to warrant a conversation. The resume did its job. Your job now is different.

Walking through it line by line does not add information. It repeats it, slower, with more words, to someone who is already familiar with the content. Worse, it signals that you do not know the difference between a document and a conversation.

You have not idea how to be effective communicator. And you don’t know what matters the most.

The candidates who impress in the first two minutes are not the ones with the longest history. Hiring managers remember candidates who show up knowing exactly what is relevant for this role and lead with that. Everything else can come out later, in the questions, where it lands with context.

You Only Have 90 Seconds

Spend no more than 90 seconds introducing yourself.

That limit is the difference between giving the interviewer something to grab onto and overwhelming them with everything at once. A short intro forces you to choose what matters. That choice is what signals seniority.

There is another reason to keep it tight: Interviewers follow up on what they heard last. Whatever you end your intro with is where the conversation goes next.

That means your 90 seconds are a steering mechanism. You are deciding, right now, which parts of your experience get explored in depth and which ones stay in the background.

Most candidates never realize this.

They treat the opener as a formality to get through. It is the opposite. It is the most leverage you have in the entire conversation.

How to Build Your 90-Second Intro

Read more

I started applying the same processes I use at work to my own career and life. Logging decisions and why I made them. Running retros on myself, tracking where I wanted to go and whether I was actually moving in that direction.

At some point I noticed I was getting better faster. Writing forced me to actually process the information around me.

That’s the discipline most engineers never apply to themselves. They track everything at work and nothing about their own career. Years of decisions, hard lessons, pivots all live in memory, which means most of it is already gone.

We are going to fix that today.

Your Brain Is a Terrible Data Store

You carry an enormous amount in your head at any given moment:

• Technical tradeoffs you’ve made

• Political context that shaped a decision

• Conversation that changed how you thought about a problem

• A pattern you noticed but never wrote down

All of it evaporates.

This is the thing nobody talks about at the senior level. You get better at your job, build better systems, and make faster decisions. But you have no record of any of it. No way to know whether you are actually growing or just staying busy.

The Feeling of Falling Behind Is a Data Problem

By not recording your own progress, you consistently underestimate how far you have come. The wins feel smaller in hindsight and the mistakes loom larger. Your brain rewrites the timeline to fit whatever story feels true in the moment.

You would never run a data platform with no observability or let a production system generate events you never capture.

Your career is generating signal every single day. So why you won’t capture it?

What Writing Actually Does

Most people treat writing as output, a way to communicate something they already know. That framing misses the point entirely.

Writing is how you think. The act of putting something into words forces your brain to resolve ambiguity it was happy to leave floating. You jsut can’t write too vague vague thoughts.

Subscribe now

The Pennebaker Experiment

In 1986, psychologists James Pennebaker and Sandra Beall ran one of the most replicated experiments in psychological research at Southern Methodist University. They split healthy undergraduate students into three groups and had each group write for 15 minutes a day across four consecutive days.

The first group wrote about boring topics like describing their dorm room, their shoes, or a tree outside the window. Pure surface-level observation with no emotional content whatsoever.

The second group wrote about a traumatic or stressful event from their lives, but with strict instructions: facts only, with no mention of how it felt or what it meant.

The third group wrote about both the facts and their deepest thoughts and feelings about the experience, the reasoning behind what happened, the emotional weight of it, and what it meant to them.

What the Data Showed

The differences in long-term physical and mental health outcomes across the three groups were significant. The first two groups showed minimal lasting benefit. The third group showed measurably better health outcomes months later.

You already know this distinction at work. A log entry that says “pipeline failed” is useless, but a post-mortem that captures what failed, why it failed, what assumptions were wrong, and what you would change is what actually improves the system.

The same principle applies to you.

At the senior level, the events worth processing are rarely technical. Instead, they are the messy, ambiguous, political moments that shape how you lead.

Writing about what happened is the easy part. But writing about why you made the call you made, what you were afraid of, and what you would do differently is where the actual learning happens.

How to Write

The blank page is where most people quit. The habit dies before it starts because writing “whatever comes to mind“ produces nothing useful and feels like a waste of time.

Proper structure fixes this. A small set of questions you return to consistently is all you need.

The Weekly Review

Once a week, write about three things:

• A decision you made and the reasoning behind it

• Something that frustrated you and what you think is underneath it

• Where you are relative to where you want to be

You need fifteen minutes at most. The goal is to get your thinking out of your head and into a place where you can actually look at it.

This is the layer that catches the things you would otherwise carry forward unresolved. Most engineers have three to five open loops in their head at any given time, a conversation that did not land, a call they second-guess, a relationship they are unsure about.

The weekly review is where those loops get closed, or at least named. Named problems are manageable, while unnamed ones accumulate.

The question that does the most work is the second one. Frustration points at something you care about, something that conflicts with how you think things should work, or something you have been avoiding. Writing about what is underneath it is where the actual insight lives.

The Event Log

Whenever something significant happens, write about it the same day. A hard conversation, a project that went sideways, a moment where you handled something better than you expected.

The detail fades faster than you think, and the reasoning fades even faster.

Two weeks after a difficult stakeholder conversation, you will remember the outcome but lose the texture of what you were thinking, what you were afraid of, and what you chose to say versus what you held back. That texture makes the entry useful when you read it six months later.

The event log is also where you catch your own patterns before they become problems. The same frustration appearing three times in four weeks is information. The same type of conversation going badly repeatedly is a skill gap worth addressing. It’s very hard to see any of that without a record.

The Career Retro

Once a quarter, zoom out. What did you ship, what did you avoid, where did you grow, where did you stall. This is the layer that makes the weekly entries useful because patterns only become visible when you read across time.

The career retro is the closest thing to running a proper retrospective on yourself. Most engineers run retros on their projects and never on their own trajectory. A quarterly review of your own writing surfaces the things your brain was too close to see in the moment.

Read back through the last three months of entries before you write the retro. Look for recurring themes, recurring frustrations, recurring avoidance. The goal is to walk away with one or two things you want to do differently in the next quarter, leaving the long list of resolutions behind.

Subscribe now

Write Like You Talk

Specificity beats polish every time. What happened, what you decided, why you made that call, what you would do differently. You are creating a record your future self can actually use, and that record is only useful if it is honest.

The trap most people fall into is writing for an imaginary audience. They tidy up their reasoning, smooth out the contradictions, and produce something that reads well but captures nothing real.

The entry that says “I approved the hire because I was under pressure and did not do the reference check properly“ is worth ten times more than one that says “we moved quickly on this one“.

Dictation changed how I write entirely. I dictate most of my entries now (the same way do with this article). Speaking removes the friction of the blank page and keeps the tone honest. You do not perform for a voice memo the way you perform for a text editor. The words come out closer to how you actually think.

Start Slow

Write when you have something to write about. The weekly review, the event log, the quarterly retro are all things you build toward, not things you set up on day one. Pick one thing that happened this week and write about it for ten minutes. That is the whole system for now.

The mistake most people make is treating the habit like a project. You design the perfect framework, pick the perfect tool, and quit two weeks later because the system is too heavy to maintain.

And here’s one more principle to mention: Consistency over completeness. A messy entry you actually wrote beats a perfect template you opened and closed. The value builds through repetition, and repetition only happens when the bar to start is low enough that you do it even on the days you do not feel like it.

With time, when you start enjoying it (because you will), set a system. I wrote about that on the Dear Self blog.

Why Email and AI Changed Everything

Paper journals have a beautiful aesthetic and a fatal flaw. You cannot search what you wrote. The insight you wrote down eighteen months ago stays buried unless you happen to find the right book and flip to the right page.

Most apps solve the search problem but introduce a different one. They add friction by locking your data into a format you do not control, and they tend to disappear or pivot into something you never asked for. You have probably abandoned at least one app and lost everything inside it.

Why Bullet Journaling Eventually Breaks Down

Bullet journaling worked well for me for years. The structure kept the habit alive and the format was fast enough to not feel like a chore.

However, Bullet journaling is optimised for capture, and capture alone produces the same result as the second group in Pennebaker’s experiment. You get the facts and skip the reflection. The entries become a log of events rather than a record of your thinking, and a log of events without reasoning is not much more useful than a calendar.

Why Email Works

Email is the one tool you will never abandon and never lose access to. There is no new interface to learn, no blank page anxiety, and no proprietary format trapping your entries. You open a compose window, write, and send it to yourself. The archive is searchable from day one.

Writing to yourself by email also changes the tone in a useful way. You are writing a message to your future self, and that framing naturally produces the kind of specificity and honesty that makes entries worth reading later.

It is close enough to a conversation that the words come out more naturally than they do in a dedicated journaling app.

Where AI Changes the Game

Search is the foundation, but AI is what turns a collection of entries into a system that actively works for you.

The difference is between a graveyard of notes and something that talks back:

• Proactive prompts surface the questions worth asking based on what you have already written.

• Reflections get surfaced back to you at the right moment, connecting something you wrote six months ago to something you are dealing with today.

• Patterns you would never spot manually become visible across hundreds of entries.

This is the layer that makes the whole practice qualitatively different from anything that existed five years ago. The ability to query valuable writing, reflect on it, and have it reflected back to you is what makes it a system.

That is why I built Dear Self.

I actually built it for myself, and after a few months I can say it is the best journaling experience I have ever had. I want to share that with you. It is free and if you are a paid Data Gibberish subscriber, DM me and I will get you your first year of premium features on me.

Final Thoughts

The best engineers I know learn faster than everyone else, because they are better at extracting signal from their own experience.

You have been generating that signal for years. Every hard decision, every difficult conversation, every project that went sideways and every one that worked better than expected, contains information about how you think, where you are strong, and where you have room to grow.

Writing is how you stop letting that information evaporate.

The engineers who compound fastest are the ones who treat their own career with the same rigour they bring to their systems. They log, they retro, they reflect. They build a record of their own reasoning and they actually use it.

You already know how to do this work. You do it every day for your team, your stakeholders, your infrastructure. The only thing left is to point the same discipline at yourself.

Start this week with one entry in less than ten minutes. Write about something that is still sitting in your head from the past few days and what you actually think about it.

That is the whole system for now.

—

Yordan

PS: The medium doesn’t matter and you don’t need to use my service. But if you do, I’d love to hear your constructive feedback. Start by writing an email to me@dearself.ai.

More on the Topic

• How to Plan a Year of Content as a Data Engineering Leader

• This Engineer Teaches Their Audience How To Think The Right Way

• Stop Feeling Behind: How Journaling Heals Productivity Shame

There is a moment you hit as a senior engineer and almost nobody warns you about. The learning that used to feel automatic starts to slow down. The gaps between “I learned something real today“ get longer. Weeks, sometimes months.

Most people read this as a personal failure. You assume you have gotten lazy, or comfortable, or that the hunger that made you good is fading. You start chasing certifications or side projects to feel the velocity again.

The velocity does not come back. And chasing it is the wrong move.

What actually happened is that your horizon changed. When you were building things, feedback arrived fast. You wrote the code, the tests ran, the pipeline moved. The learning was continuous because the signals were continuous.

When you operate, you make a decision in January and find out in August whether it was right. A different kind of learning, with a different rhythm, and almost nothing prepares you for it.

This piece is about how to keep growing when the old mechanisms stop working, because you outgrew them.

The Horizon Shifted

As an engineer, your feedback loop is tight. A PR merges, a pipeline runs, a test passes. You know within hours whether you did the right thing. That tightness is what makes learning feel fast. You get a signal, adjust, and move.

When your role grow, the signals take months:

• You change a hiring process and find out a year later whether you hired well.

• You restructure how your team runs projects and see the results two quarters down the line.

• You invest in a stakeholder relationship and the payoff arrives slowly and quietly, instead of in a notification or a merge.

This is the job now.

If you still measure yourself by what you personally shipped this week, you will always feel behind. Not because you are behind, but because you are using the wrong ruler.

The New Ruler

So what do you measure yourself by instead?

Three things:

• The team ships.

• Stakeholders are happy.

• The people on your team feel like they grow from working with you.

That is it. Those three are your new ruler. If all three are true, you are doing your job well. If any of them are consistently off, something needs your attention, regardless of how much you personally produce.

This feels uncomfortable at first, especially if you are used to clearing a todo list and knowing exactly where you stand.

These three things are slower to read and harder to fake. A stakeholder who tells you everything is fine in the meeting and escalates to your manager the next day is a signal you missed something. A team member who looks busy but stops bringing you hard problems is a signal too.

You learn to read these, but it takes time.

It also feels, like you are doing less at first. You are not shipping the pipelines, not writing the models, and not closing the tickets. The work is less visible and the feedback is slower. You are running a system instead of building a component. That is harder, and the leverage is orders of magnitude larger.

Own it as seriously as you owned every PR you ever merged. Even more.

Block the Time

All of this happens by design.

If you do not protect time for learning, the week fills up and learning is always the thing that moves to next week. Next week becomes next month. A year passes and you realise you have been reacting to the job rather than growing inside it.

Block two to three hours a week.

That’s non-negotiable. Put it in your calendar as a recurring block and treat it with the same respect you give your most important meetings. Because that is a meeting with your future.

You don’t need to do it in a single block. Thirty minutes at the end of each day works just as well. What matters is that it is regular and protected. The moment you start treating it as optional, it disappears.

What you do with the time doesn’t matter that much. Take a course, read a book, build something small, or even talk with a peer at another company. The medium is less important than the habit. The point is to keep a part of your attention pointed outward, at something that is not your current backlog, your current team, your current problems.

Subscribe now

One thing worth noting:

Learning at this level is not mostly about new tools or frameworks.

A new tool is learnable in a day when you have enough context. What takes real time is developing judgment:

• How to read an organisation.

• How to run a hard conversation.

• How to make a call with sixty percent of the information you want.

You build that slowly, through exposure and reflection. Tutorials won’t help you here.

The two to three hours a week is where that reflection happens.

The Learning Workspace

Learning without a strong manager who can really teach you the skills you need is hard. So, I packed some of my best tools to share them with you so you can design your career growth and become the professional you want to.

Read more

Presenting Peter Mukherjee

Peter built a London business from scratch in 1992, grew it into an international franchise network with a public listing, and lost most of it to the 2008 crash. He reinvented himself as a professional architectural photographer and worked at it for fifteen years before retiring in 2023 to write full-time.

Subscribe to Peter's Publication

I’ve known for about an year now, and he’s one of the wisest people I’ve ever talked to.

The whole time he was talking during our conversation, I kept hearing the same diagnosis for why most senior engineers hit a ceiling.

You are managing your career like an employee.

The people who break through manage it like a business. They use a different vocabulary, run a different operating system, and make different decisions. None of it requires another certification, and all of it requires a mindset shift most senior engineers never make.

Forced Pivots Surface The Rest Of You

The default for a generation was 30-40 years at one employer, a stable pension, and a CV that looked sensible. The world does not work that way anymore. Multiple careers across one working life is now the norm.

The hardest version is the forced pivot. Income stops, status stops, and everything you built is on hold while you scramble to establish something new.

Getting through it requires confidence in your own abilities, because most people are more capable than they give themselves credit for, and the work is digging deep, finding the talents you have, and pulling yourself through.

Resilience is built mostly through failure. There is no shortcut. You learn the most during the times you fail, because failure forces you to dig in and recover. The worst response is going negative, looking backwards, sliding into “what have I done“. That posture stops the recovery before it starts.

The deeper insight is that most people never find out what their real talents are. They pick the first thing they think they are good at and develop only that.

There might be tens of thousands of people with that level of athletic talent who never find out they run, because they never explored their full range. When things go wrong, you are forced to ask “what else am I good at?“ That question, under pressure, surfaces the talents the comfortable version of you never bothered to look for.

The Old Leadership Model Is Finished

The safe pair of hands is done. Steady the ship, grow dividends 5-8% a year, stay around for ten years. That mindset takes the business backwards now, because the world moves too fast for it. Standing still is moving backwards.

The replacement is the transformational leader. Transformation involves risk-taking, which only works if the culture supports it, which means giving your people permission to take risks too, without making them fear for their jobs when they get something wrong.

Apple and Google run open plans where managers sit among their people. Senior managers might have an office, but it is glass-sided so people see them and they see their people. Any transformational leader has to be able to carry their people through change, and you only carry them properly if you are visibly involved with them.

A successful US business leader who talked about being vulnerable in front of her people in the 90s was told “that’s because you’re a woman“. Now every leadership conversation centres on empathy and vulnerability. COVID accelerated it and AI will accelerate it further.

Where Leaders Lose People

The biggest source of failure is arrogance and ego, and the biggest organisational consequence is losing the people you invested time and money into developing. You will always be outbid on salary. There is always someone offering more money.

But the one thing people put ahead of the bigger paycheque is enjoying where they work. The manager who is arrogant, ego-driven, and disconnected from their team creates an environment people are eager to leave, and that manager loses good people on a clock.

Humility Is The Hardest Lesson

The kind of humility forced on you by having to let go of people who built the business with you. Telling someone who has been with you for 15 years that the business is closing is one of the hardest things a leader does.

There are two ways to handle it. The first is matter-of-fact, because that is what organisations do. The second is to treat the moment with the weight it carries for the person on the other side of the desk, with empathy and active care for what happens to them next, including helping them frame what they learned.

The relationships survive the second version.

The same principle runs through every other team interaction. Make people feel included, valued, recognised.

A specific mechanic that works: team-level bonuses where the team itself decides who the top contributors are. Everyone shares in the reward, but the team picks the largest pieces. It does not have to be financial. A day out, a big dinner, share options. The point is structuring recognition so it incentivises working together instead of competing.

The 51/100 Rule

The mythology of the successful CEO making lots of right decisions is wrong. Every CEO is making decisions every day, and some they get wrong, sometimes catastrophically.

The batting average, from Ursula Burns (former CEO of Xerox, started as an intern): out of every 100 decisions, you make 51 good ones and 49 bad ones. The job is making sure the 49 bad ones are not too bad.

You afford one or two howlers, but the rest need to be recoverable. If you have an immaculate record of getting everything right, you are not taking enough risk, and your career is moving backwards while you congratulate yourself for being right.

The mechanic underneath is reversibility. Good risk-taking is calculated, not suicidal. Sort every decision into reversible and irreversible. The reversible ones get volume. The irreversible ones get contingency planning.

The downside in the reversible bucket is embarrassment and a week of recovery. The downside in the irreversible bucket is structural and measured in years.

Most senior engineers treat every decision as if it were in the irreversible bucket. They spend two weeks deciding whether to submit a conference talk. They draft a LinkedIn post and never publish it. They workshop an internal proposal until the moment to make it has passed. The cost is invisible because nothing went wrong. Nothing happened at all.

Curiosity Is The Response To Uncertainty

For individuals, the best response to uncertainty is curiosity. Nobody becomes successful without it. Learning does not stop when you finish university. Curious people are the ones who do something big.

Invest in emotional skills. Degrees matter less. The capability to communicate, manage people, be visionary, be inspirational, and bring creativity is what employers will look for. Those are the skills that differentiate you in three years’ time, and they are the ones currently at risk from the AI-as-co-pilot trap.

The AI Entropy Warning

Entropy is a real thing. Systems decay toward their lowest energy state when nothing pushes back. Brains are a system. The muscle you stop using is the one that atrophies. People who used their brains for the work are now using AI for the work. The output looks fine. The brain underneath is going to sleep.

The fix is using the tools while keeping the thinking. Let AI draft, then edit by hand, let it summarise, then read the source or let it suggest options, then make the decision yourself and write down why.

The skills that cannot be outsourced are the ones the technical job market will pay for in three years, and right now the industry is volunteering for neglect.

Load The Dice Yourself

Every successful person credits luck. A specific phone call, a meeting, a door that opened at the right moment. A single phone call was the pivot for a multi-billion-dollar career, where the answer was 50-50 right up until it was given. The mistake is to hear that and conclude luck is random.

Luck is a numbers game with a rigged distribution. Go to one networking event a year and talk to three people you already know, you have three lottery tickets. Go to five events and talk to ten new people each, you have fifty. Same person, same skills, sixteen times the surface area for a lucky break.

For data engineers, the equivalent is volume of visible work. Internal documents that travel. Brown bags and lightning talks. External writing. Conference submissions. Every one of them is in the reversible bucket. The hit rate on any individual piece does not matter. The volume across all of them does.

The wider pattern shows up in every successful career: luck plus passion. Everyone talks about their passion for what they do, and there is a direct correlation between success and finding it. “Follow your passion” only works if you have one. If you have not found one, the work is exploration. Keep looking until you find the thing you love. Until then, every step is a stepping stone.

The cost of getting this wrong is what makes the rest of it urgent. The greatest risk is that you never find success and fulfilment because you stuck with something you did not love.

Sir Clive Woodward, the England rugby head coach who won the 2003 World Cup, put it this way:

The worst thing that happens in life is getting older and looking back thinking “I wish I’d taken a chance on that“

Treat Yourself As A Business Inside The Organisation

Change your perception of your role. You are no longer “the programming manager.” Look at yourself like a one-person business inside the organisation you work for. Promote yourself. Acquire the skills. Develop yourself the way a business develops.

The language change shows it:

Saying “I am an admin manager, I have been doing this for seven years“ tells the listener nothing.

Saying “in the last seven years I have organised X, I have done Y, these are the successes, these are my strengths, this is where I add value, these are the things I will carry forward to help your organisation“ is a different conversation.

That is how you communicate inside the organisation. That is how you describe yourself outside it.

Life is like snakes and ladders. You roll the dice, you move forward. Lucky, you climb a ladder. Unlucky, you slide down a snake. The mistake is to think your future is dependent on the roll of the dice. Most people are more in control of their destiny than they think.

Too many expect someone else to design their career. The alternative is to go out, meet people, decide your own projects, decide your own career.

Final Thoughts

The senior engineer ceiling is not built out of skill gaps. It is built out of an operating model imported from the codebase: optimise for being right, ration the decisions, stay invisible until you are sure. That model breaks the moment the job stops being primarily technical, which is the moment the ceiling appears.

The people on the other side run a different model. They aim for 51 out of 100, sort decisions before they spend time on them, and surround themselves with people better than they are.

They take humility seriously and ego personally. They keep their brains on while the industry switches theirs off. They describe themselves like a business that knows what it sells.

None of it requires a certification. All of it requires the mindset shift most senior engineers never make.

Where To Find Peter

Peter writes on Substack. The book is available in hardback, paperback, Kindle, and audiobook, the audiobook read with 12 different voices, one per contributor.

—

Yordan

Subscribe now

A colleague of mine was one of the most talented engineers I have ever worked with. Sharp, fast, technically thorough. When a stakeholder came to him with a project, he would disappear for six weeks and come back with something impressive.

The stakeholder would look at it, go quiet, and say something like “This is not quite what I had in mind“.

And every single time, his response was the same. “They are stupid. I know what they need. They should use it“.

The project would either get quietly cancelled, or the stakeholder would ask someone else to redo it. I watched this happen twice. Same engineer, same pattern, different projects.

The thing is, he was not wrong about the technical side. The code was clean, the logic was sound, and the solution was, in his view, objectively correct.

He just never learned the business process. He never asked the stakeholder to show him how they actually worked. He heard the request, translated it into a technical problem, and solved that problem in isolation. Then he was genuinely confused why nobody wanted what he built.

The truth is that nobody gets fired for writing good code. They just stop getting the interesting projects. The stakeholder quietly routes around them. And they never quite understand why.

It is a process problem. And process can be fixed.

Here is the exact process I use, from the moment a vague Slack message lands to the moment I close a project out.

The Scripts That Keep Projects on Track

Know exactly what to type at every stage, from the first vague request to closing the project out.

Download Now

Reply to the Slack Message Before You Touch a Keyboard

The vague request is not a problem at all. It is the starting point.

Most engineers read a message like “Hey, can we get a dashboard for the sales team?“ and immediately start thinking about the data model. That is the mistake.

Instead of a spec, the request is an opening. Your job at this moment is to open a conversation without making it feel like a process.

Do not schedule a meeting. Do not send a list of questions. Send one message back.

Here is what I type:

This kind of a message signals you are taking it seriously without turning it into a project before you know what the project is.

When the call happens, most engineers ask “what do you want the dashboard to show?“

But that is the wrong question. It gets you a list of metrics that may have nothing to do with how the stakeholder actually works. Instead, ask them to show you their current process.

Here are the three questions I ask on every first call:

• Can you walk me through how you’re doing this currently?

• What does a good week look like for you, in terms of this data?

• If this was done and working perfectly, what would you do differently?

The third question is the important one. It forces them to think about behaviour, not features. The answer tells you what the project is actually for.

The Definition of Done Is a Contract

Before you leave that call, you need one sentence that both of you agree on.

Here is how I get it:

Let me make sure I’ve got this right. What we’re building is X, and we’ll know it’s done when Y. Does that sound right to you?

If they say yes, you have your definition of done. If they hesitate, you have just saved yourself six weeks of building the wrong thing. Keep asking until the sentence lands cleanly.

Write it down and send it in Slack after the call. Something like:

Ideally, you create a channel for that project. Now both of you, and everybody interested in that project have it in writing.

Know Who Can Kill This Before You Build Anything

Before you write a single line of code, you need to know two things:

• who can kill this project

• who will fight for it

Most engineers talk to the person who sent the Slack message and assume that is the whole picture. Sometimes it is.

Often there is a manager who needs to sign off, a team that will be affected, or a senior stakeholder with strong opinions who has not been in the conversation yet. Finding out about them after you have built something is expensive.

You do not need a stakeholder mapping workshop, but you need to ask one question on that first call:

Is there anyone else I should loop in, or anyone whose sign-off we’ll need before this goes live?

That one question will surface 90% of what you need to know. From the answer, you are looking for three types of people.

• The decision maker: The person who can say yes or no to the final output. Everything you build needs to satisfy them, even if they are not the one who sent the request.

• The champion: The person who wants this to exist and will push for it internally. Usually the person you are already talking to. Keep them close.

• The informed: People who need to know this is happening but have no power over the outcome. A quick message every now and then is enough.

Once you know who you are dealing with, agree on delivery stages. You just need two or three rough checkpoints and an expected delivery date. Something you can type in Slack in four lines.

Here is what I send:

That message does three things. It sets expectations, commits you to a timeline, and signals that you will be showing progress before the end. Your stakeholder now knows they will not be waiting in silence for six weeks.

The RACI Nobody Will Ever See

You do not need to show anyone a RACI diagram. But you need to have done the thinking.

Take five minutes, on your own, after the first call. Write down who is responsible for building this, who is accountable for the outcome, who needs to be consulted, and who needs to be kept informed. No template, no meeting, and definitely no slides.

When something goes wrong mid-project, and something always does, you will know exactly who to call and what to ask. That clarity is worth more than any amount of documentation.

Build the MVP in Under Five Days

McKinsey research on 5,400 IT projects found that the average large project delivers 56% less value than predicted. The number one reason is building in the wrong direction for too long before anyone checks. The fix is embarrassingly simple:

The rule I follow is five working days from the moment I actually start building. Not from the first call. From the day I sit down and open Neovim (and mostly Claude Code nowadays).

It will have hardcoded values, missing edge cases, and placeholder logic. That is fine. The goal of the MVP is to confirm you are moving in the right direction before you invest more time going in the wrong one.

Here is how I introduce it:

That framing removes the pressure from both sides. The stakeholder is helping you steer.

Don’t look for the “I love it” responses. This doesn’t matter. Listen for whether they are reacting to the right problem.

If their feedback is about polish, you are on track. If their feedback reveals a fundamental misunderstanding about what they needed, you have just found that out in week one instead of week six.

How to Handle “This Isn’t Quite What I Had in Mind”

This is the moment most engineers dread. It does not have to be.

If the stakeholder sees the MVP and tells you it is not what they expected, that is the process working. Here is what I say:

That’s really useful, thank you. Can you explain me what you had in mind? A rough sketch or an example would help me get there faster.

Then you go back, adjust, and show them again. The loop is fast because you have not built much yet.

The other outcome is rarer but worth being ready for.

Sometimes a stakeholder sees the MVP and realises they do not need the project at all. Seeing something concrete makes them understand that what they actually wanted was a process change, or a conversation with another team, or something that has nothing to do with data.

When that happens, you have saved everyone a significant amount of time. Close it and move on.

Show Progress Every Three Days or Lose the Project

Once the MVP is signed off and you are building toward the real thing, most engineers go quiet. They are heads down, making progress, and they assume the stakeholder knows that.

The stakeholder does not know that.

• After three or four days of silence, they start wondering.

• After a week, they are telling their manager the project might be stalled.

• After two weeks, they have mentally moved on and started looking for alternatives.

You are still building, but the project is already dying.

The rule I follow is simple.

No more than three days without sending something.

It does not need to be a status report, or a meeting. It can be one Slack message.

Here is what I send msot times:

This takes less than 30 seconds to write. It resets the clock on stakeholder anxiety and signals that the project is moving.

Over time, the stakeholder starts getting invested. They follow the progress, and start telling colleagues about it. By the time you deliver, they are already its biggest advocate.

That is not a small thing. A stakeholder who is invested in a project will push for its success, defend it in conversations you are not part of, and use it after delivery.

That kind of adoption happens only if you keep them close while you are building.

When Your Stakeholder Goes Ghost

Sometimes the silence goes the other way.

You send an update and hear nothing back. You share a progress demo and get no response. You follow up once and still nothing. In my course, I call these stakeholders Ghosts.

Silence at different stages means different things:

• Early in the project, no response usually means competing priorities. They are busy, the project is not urgent, and they will come back.

• Mid-project silence is a warning sign. It often means they have lost confidence, or something has changed internally that they have not told you about.

• Post-MVP silence, after they have seen something concrete and gone quiet, almost always means they did not know how to say “this is not what I wanted“.

In all three cases, the move is the same. One message that forces a yes or no without making it feel like a confrontation.

Here is what I send:

That message gives them an easy out if something has changed, and it gives you the information you need to decide whether to keep building.

Most of the time, you will get a response within an hour. Either they apologise for being slow and re-engage, or they tell you something has shifted. Both outcomes are better than building in silence for another two weeks.

Plus, having this in the dedicated channel means you have a documented go/no-go decision.

Stop When It’s Good Enough

At some point, the project is done. Not perfect, but done.

This is harder than it sounds. Engineers are wired to improve things. You finish the main deliverable and you start noticing rough edges:

• The query could be faster

• The dashboard could be cleaner

• The logic could handle three more edge cases

So you keep going, and your stakeholder is sitting there wondering why they still do not have the thing you promised them.

The signal that you have hit good enough comes from the stakeholder. When their feedback shifts from “can we change X“ to “this is great, when can we roll it out“, you are done.

Here is how I close a project:

I think we’re at a good place. Here’s what’s been delivered, here’s how to use it, and here’s who to contact if something breaks. Is there anything critical missing before we call this done?

That last question matters. It gives them one final chance to raise something real. If they say no, the project is closed. If they raise something small, you make a call on whether it belongs in this version or the next one.

And this brings you to scope creep. Every project attracts it. The stakeholder sees what you built, gets excited, and starts asking for more. New reports, new dimensions, new use cases.

These are all reasonable requests, and all belonging in a different conversation. I have a full article on how to handle that without losing the relationship, linked at the end of this one.

The other exit is the kill decision. Sometimes the right call is stopping entirely.

Final Thoughts

The engineers I have seen succeed long term are not always the most technically gifted. But they are the ones whose work gets used. Their dashboards are open every week, their pipelines run without anyone filing a ticket, and their stakeholders mention them by name in meetings they are not part of.

That happens because they treat the non-technical part of the job with the same rigour they bring to the technical part:

• They ask the right questions before they build anything

• They show their work early and often

• They keep people close instead of going silent

The process in this article is the minimum required to make sure your technical work actually lands. Most of it happens in Slack, and none of it requires a bureaucracy.

Even a project that looks doomed can be turned around with the right moves at the right time. I have seen it.

The engineer who gets that call, who steps in late and still manages to deliver something the stakeholder trusts, is never the one who worked the hardest. It is always the one who communicated the best.

—

Yordan

PS: Paid members consistently share they got promoted or praised because they apply my guides. When ready, upgrade here.

More on the Topic

• The Customer Service Mindset Is The Fastest Way To Destroy Your Data Team

• Workshop: Cross-team data project management with RACI

• How I Scope Minimum Viable Data Products That Prove Value Fast

• Why trust disappears faster than servers crash when you hide bad news

• Crush Scope Creep: Data Engineer’s Blueprint for Bulletproof Data Product Plans

A year and a half later, they quit. Frustrated, and feeling like the company did not value them.

In fact, The company did value them. They valued their execution. What they never got was somebody to listen to their ideas and judgment. Because this person never voiced any of it.

They worked on everyone else’s ideas, delivered brilliantly, and waited for recognition that was never going to come through technical performance alone.

I have seen this story play out dozens of times. And you probably recognise it too.

The Problem Is Not Performance

Brilliant engineers get great performance review, but no promotions. They are never picked for the exciting projects.

You do what you are told, you do it well, and somehow the people who get the opportunities are not the ones who write the best code.

And this is an onboarding problem.

The first 30 to 90 days in a new role set a reputation that is almost impossible to shake. The team forms an opinion of you before you have a chance to demonstrate your full capability.

That opinion determines which projects you get offered, whether your proposals get heard, and whether your manager sees you as someone to develop or someone to assign tasks to.

Most engineers get this period exactly backwards.

They arrive with strong opinions, a full toolkit, and a mental list of everything they would do differently. And then they start doing it. Immediately. Without asking why anything is the way it is.

One person I worked with joined as a new Head of Data and kicked off a full warehouse migration in their first weeks. The context they were missing could have told them why that decision was catastrophic for this specific organisation. They were gone within a few months.

Subscribe now

Three Habits That Change How You Land

This is not a framework. These are behaviours I have observed from every person I have coached or worked with who had a strong first year. They do not require a senior title to execute. They work whether you are joining a new company, a new team, or picking up a new stakeholder group at your current org.

Habit 1: Empty the Glass Before You Fill It

There is an old story about a student who goes to a master and asks to be taught. The student has already read everything. They already have opinions. The master pours tea into their cup until it overflows, then says: you cannot fill a glass that is already full.

When you walk into a new data environment, you are going to see:

• broken dbt lineage

• tests that take 12 minutes

• an #analytics-questions Slack channel full of questions whose answers exist in a Wiki nobody reads

• an infrastructure that looks like nobody ever cared about it

Your instinct is to fix it. But that instinct is wrong.

Why do those tests take 12 minutes? One engineer I worked with assumed it was negligence. After asking, they found out those tests were keeping watch on a set of records in the most critical table in the warehouse because of a recurring data integrity issue nobody had yet figured out how to solve properly.

Their first plan was to filter the lookback window to 24 hours. The right answer, after understanding the context, was a full remodelling of the upstream logic.

One of those solutions fixes the problem and one of them creates a production incident that makes you the person everyone watches carefully from then on.

Here is what you are mapping in your first 30 days:

• How code gets shipped. Pull request process, number of reviewers required, merge versus rebase conventions, who actually needs to approve before you merge. This is not about following rules. It is about understanding the norms before you violate them accidentally.

• How decisions get made. In the team I lead, nothing gets committed without a design review first. You document your proposed approach and get confirmation from someone experienced before writing a line. Some teams have nothing like this. Some have something entirely different. Ask before you assume your way is the standard.

• How stakeholder updates work. Some teams run a dedicated project Slack channel and push daily updates. Some expect nothing until the thing ships. Do not guess. Ask.

• What the actual team pain is. The problems you experienced in your last job are not automatically the problems here. Some teams struggle with data literacy across the business. Some have a perfectly functional data team sitting next to a shadow analytics function that is quietly doing parallel work and creating slow-burning turf conflict. You want to know that before you accidentally step into it.

The engineers who build trust fastest in the first month are not the ones who ship the most. They are the ones who break nothing and ask the most questions. That reputation is worth more than any quick win.

Habit 2: Form Opinions Before You Are Expected To

Asking questions without forming opinions is just data collection. The second habit is what you do with what you learn.

This is where a lot of technically excellent people stall. They go quiet. They process. They wait until they feel they have enough context to say something worth saying. By then, the window has closed and they are already seen as someone who executes rather than someone who thinks.

You do not need a lead title to have an opinion. You need observations and a reason.

Here is the method. Open a spreadsheet, a Notion board, anything. Start a running log:

• What I observed. Something specific. Not “the pipelines are slow” but “every pipeline runs once a day except this one, which runs every three hours.”

• Why I think this is the case. Based on the questions you asked. Not a guess. An informed hypothesis.

• What I would do to improve the situation. One idea. Sometimes one bullet. Sometimes a few steps.

That third column is where your reputation gets made. It turns observations into proposals. And proposals, shared at the right moment, are what shift how your teammates see you from month one.

There is an important distinction here. This is not the same as the previous habit telling you not to presume. Presuming means acting without context. Forming opinions means building a point of view with context. One breaks things. The other earns you a seat in the conversation.

The engineers who are seen as strong leaders after 90 days are almost never the ones who delivered the most. They are the ones who showed they understood the environment and had ideas about how to make it better.

You can still get it even if you prefer to remain a free subscriber. Grab the field kit here.

Premium subscribers get this FOR FREE here.

Read more

Nobody tells you when your growth stops. You ship things, solve problems, and really get better at the craft. And at some point you look up and realize the bottleneck is no longer the code. It is you. The way you think, communicate, make decisions, understand the systems around you.

That realization is uncomfortable. Most people ignore it. They go deeper into tooling because that is safe and measurable. But the engineers and leads who keep growing past that ceiling are almost always consuming differently. Not just reading docs. Reading things that change how they think.

This is that list.

Newsletters

Technical Depth

1. Data Engineering Central by — If you are looking for opinionated writing on the data landscape from a really experienced guy, this is the newsletter for you. Daniel writes a lot about Databricks, DuckDB, Polars, data quality and overall data architecture.

2. Pipeline To Insights by — Erfan shares real-world experiences, technical tutorials, and personal reflections to inspire growth and continuous learning in the world of data and AI. Plus, Erfan is a really great guy.

3. SeattleDataGuy’s Newsletter by — All things data: end-to-end data flows, MLOps, practical architecture and data leadership. Popular for a reason and consistently useful. Ben has always been nice to me.

4. The Pipe & The Line by — Hands-on guides, tools, and experiments to sharpen your Data & AI Engineering skills from someone who learned it all in the wild. Loads of practical insights on data and AI here.

5. VuTrinh by — Mostly fundamentals here. Vu reads a lot about big corp data architectures and distills it into clean, focused writing. A great place to go deep on the foundations.

6. From Data to Product by — Eric writes about bridging the gap between data and product thinking. He brings 15+ years of experience, including as Head of Experimentation at Yelp, to questions every data professional should be asking: what does this data work actually enable, and for whom?

7. Learn Analytics Engineering by — Practical analytics engineering skills, made accessible. Madison writes clearly about dbt, data modeling, and the craft of building reliable data systems. One of the most consistently useful newsletters in the analytics engineering space.

8. The Data Governance Playbook by — Charlotte writes about data governance from the inside. Ten years of consulting experience, real client stories, and no patience for governance theater. If you are trying to make data governance actually land inside an organization, this is where you start.

Engineering Leadership & Management

9. Engineering Leadership by — One of the most consistent writers on what it actually means to go from engineer to CTO. Gregor went through the whole journey himself, and it shows. I keep recommending this one to people on my team who are starting to think about the leadership path.

10. Manager.dev by — Written exclusively for engineering managers. No career advice for junior devs, no motivation content. Just practical, sometimes uncomfortable takes on building and leading teams. Anton is the kind of writer who calls out what most people are too polite to say.

11. High Growth Engineer by — Jordan writes for engineers who want to grow fast and deliberately. The articles are dense with actual frameworks, not vague advice. If you are somewhere between senior and lead and feel stuck, this is where you should be spending your reading time.

12. The Caring Techie by — Irina writes about influence, leadership presence, and the people skills that no one teaches you in a tech job. This is about leading with emotional intelligence without losing technical credibility.

13. Leadership in Change by — Joel writes for leaders trying to figure out AI without losing their voice or values. Practical frameworks, no hype. Useful if you are managing teams that are already using AI and trying to lead through that shift rather than around it.

Communication & Influence

14. Wes Kao’s Newsletter by — Wes writes about executive communication, managing up, and standing out as a high-performer. The frameworks she shares are sharp enough that I have used them directly in conversations with stakeholders. This is the newsletter I recommend most. One of my most favourite of all times.

15. Strategize Your Career by — Francisco writes about building leverage in your career, or otherwise said, how to stop drowning in the day-to-day and actually make progress on the things that matter. He talks a lot about how you present your work, manage your own visibility, and make the right people notice you.

16. Hungry Minds by — A weekly newsletter on learning, growing, and communicating as a developer. Alexandre writes with a lot of honesty about what actually works when you are trying to level up and be heard.

Strategy & Systems Thinking

17. The Data Ecosystem by — Dylan bridges the gap between data and business strategy in a way that most data engineering content does not bother to do. If you want to understand how data decisions connect to organizational decisions, this is a good place to start.

18. The Breaking Point by — Advice for leaders on how to make better business decisions. Sean is a founder who has been through the full arc and writes with the kind of hard-won clarity that you only get from having made expensive mistakes. I’ve been a dedicated reader for a few years now and I really this publication.

19. Data Operations by — Greg writes about integration, automation, and product challenges through an operational lens. Each issue is a short essay plus one thing that looks like a toy today but might matter a lot tomorrow. Absolutely worth following if you want to think more broadly about how data systems connect to product decisions.

20. The Pragmatic Engineer by — One of the most widely read engineering newsletters for a reason. Gergely covers Big Tech and high-growth company internal. Useful for anyone trying to understand the system they are operating in.

21. Wondering About AI by — Karen writes about AI tools with mixed feelings — she builds them and critiques them in equal measure. Useful for leaders trying to cut through the noise and understand what AI actually changes versus what it just hypes.

22. Product Management IRL by — Amy writes weekly about real product management challenges — the messy, stakeholder-heavy, judgment-dependent kind. Useful for data leads because the overlap between PM and data leadership is larger than most people admit.

Career Growth & Self-Awareness

23. Level Up by — Former Amazon VP writing about what it actually takes to reach executive levels in tech. No generic inspiration. Specific, earned perspective on how promotions really work, how careers stall, and what to do about it.

24. Coding Challenges by — Learn by building real tools from scratch. John gives you a challenge each week, and the deliberate practice compounds fast. This is for people who want to stay technically sharp while everything else in their role becomes more people-focused.

LinkedIn Profiles

Technical Depth

25. Joe Reis — I don’t really need to tell you anything about . He’s one of the OGs in the modern data world. Posts on architecture, the state of the industry, and the mental models behind good DE decisions. I love Joe’s contrarian takes because they have substance.

26. Zach Wilson — Distilled hyperscale DE experience from Meta, Netflix and Airbnb level problems. Skews toward fundamentals and data modeling depth. I disagree with some of his opinions, but knows his stuff.

27. Simon Späti — Deep open-source DE content. Curates the ecosystem better than almost anyone. ’s site ssp.sh is an underrated resource.

28. Maxime Beauchemin — Creator of Airflow and Superset. Less active than he used to be, but when he writes it lands. His 2018 essay on functional data engineering is still one of the best things written about pipeline design. Worth reading even if you think you already know the ideas.

29. Andreas Kretz — He posts consistently about pipeline architecture, data platform design, and the day-to-day of building data systems. Good for staying calibrated on what practitioners are actually dealing with. I’ve never seen a paid video or post from .

30. Julien Hurault — Sharp perspective on the data ecosystem from someone who lives in it. Strong voice in the lakehouse space. You should follow if you want to stay current on where the tooling is heading.

31. Dawn Choo — Data scientist (ex-Meta, ex-Amazon) who posts about career development, AI, and the data profession with unusual directness. is one of the clearer voices on what it actually takes to grow in a data career without the usual hand-waving.

Engineering Leadership & Management

32. Addy Osmani — Posts a lot about AI-assisted engineering lately, but his older content on team effectiveness and technical leadership is where the real gold is. is one of the few people at this level who writes openly and accessibly.

33. Alex Ewerlöf — Staff-plus engineering perspective from someone who has thought very carefully about what technical leadership means beyond the title. also writes at blog.alexewerlof.com and is worth bookmarking separately.

34. Anemari Fiser — Writes about the transition from senior IC to leader in a way that feels grounded and specific, not generic. is one of the more underrated voices in the engineering leadership space.

35. Adrian Stanek — Practical takes on the day-to-day of engineering management. ’s content has a great signal-to-noise ratio, no fluff.

36. Steven Claes — Leadership through the lens of engineering culture. Posts that make you think about your team differently, not just your own career.

37. Karl Ivo Sokolov — Managing Director building the Data & AI service line at Specific-Group Austria. talks about data and AI leadership with a practitioner’s frame, not a consultant’s deck.

Communication & Influence

38. Shachar Meir — Engineering leadership meets communication strategy. Posts about how to get technical decisions across to non-technical stakeholders in a way that lands. is a great guy.

39. Carmine Gallo — Communication coach for executives at Intel, Coca-Cola, and Chevron, and author of Talk Like TED. His LinkedIn content distills decades of studying what makes ideas stick in presentations and conversations. If you present technical work to leadership, follow him.

40. Matt Abrahams — Stanford lecturer and host of the Think Fast Talk Smart podcast. Writes about spontaneous communication. One of the clearest thinkers on how to communicate under pressure.

41. Clare Kitching — Data and AI strategy consultant with a decade at McKinsey and QuantumBlack. Posts about AI adoption, data foundations, and what it actually takes to make transformation work. Sharp on the gap between what organizations say they’re doing with data and what they’re actually doing.

Strategy & Systems Thinking

42. Taha Hussain — Systems thinking applied to data and engineering organizations. posts about how platforms, teams, and architectures interact in ways that most practitioners miss until it is too late.

43. Vin Vashishta — Data and AI strategy at the organizational level. thinks about data differently from most engineers, through the lens of business value, competitive positioning, and organizational readiness. Follow him to develop a more strategic frame for your own work.

44. Cassie Kozyrkov — Google’s first Chief Decision Scientist, founder of the Decision Intelligence field, now CEO of Data Scientific. has over half a million followers for good reason. Posts that make statistical thinking feel urgent and applicable. Required follow for anyone making data-backed decisions at scale.

Career Growth & Self-Awareness

45. Ryan Peterman — Staff engineer at Instagram who writes about career progression with unusual honesty. talks about the parts of growing that are uncomfortable, not just the milestones.

46. Neo Kim — Author of the System Design Newsletter. has a sharp perspective on what it means to be known for something, how to build a reputation in the field, and how to make technical work visible. Plus, he’s really kind!

47. Daria Rudnik — Career growth and self-awareness content for data professionals. covers the stuff that technical training ignores: knowing your own patterns, managing energy, making better decisions about your own path.

Books

Technical Depth

48. Designing Data-Intensive Applications by — The foundational text for understanding distributed systems at the infrastructure level. Not DE-specific but irreplaceable for anyone who wants to understand why their stack makes the choices it does.

49. Fundamentals of Data Engineering by Joe Reis & Matt Housley — The clearest mental model for the full DE lifecycle. Read it to find the gaps in your own mental model, not to learn syntax. Also, the data modelling book is shaping very well.

50. The Pragmatic Programmer by David Thomas & Andrew Hunt — A classic for a reason. But what makes it relevant here is not just the technical advice. It’s actually is the philosophy of craftsmanship and continuous self-improvement that runs through the whole book. The engineers I respect most have internalized this way of thinking, whether or not they have read it.

51. Your AI Survival Guide by Sol Rashidi — helped IBM launch Watson in 2011 and has spent the years since doing real-world AI deployments across industries. This is not a book about AI theory. It is a book about what breaks when you try to ship AI in an organization and how to fix it.

52. The Data Hero Playbook by Malcolm Hawker — spent over 25 years working with CDOs and data leaders and got fed up watching the same mistakes repeat. This book is about the mindset problems that sink data initiatives, and how to fix them.

Engineering Leadership & Management

53. High Output Management by Andrew Grove — Written by the former CEO of Intel, this is still the most rigorous book on management ever written for people who came up through engineering. Grove writes about meetings, decisions, performance reviews, and organizational leverage with the precision of someone who built one of the most operationally excellent companies in history. This book was mandatory for every manager in my org.

54. The New One Minute Manager by Ken Blanchard & Spencer Johnson — Short enough to read in an afternoon. The core ideas, sound almost too simple until you realise how rarely anyone actually does them. A good early read before you have your first direct report.

55. The Manager’s Path by Camille Fournier — The foundational text for the engineering management track. Camille mapped out the whole journey from tech lead to VP in a way that actually prepared me for what was coming. Required reading before your first direct report, not after.

56. An Elegant Puzzle by Will Larson — Systems thinking applied to engineering organizations. Will Larson writes about team sizing, migration strategies, and organizational design with a level of rigor you rarely see outside of academic papers. The org-chart chapter alone is worth the price.

57. Staff Engineer by Will Larson — If you are approaching the staff level or managing people who are, this is the clearest map of what that role actually looks like across different companies and archetypes.

58. Resilient Management by Lara Hogan — Short, dense, and written by someone who spent years as VP of Engineering at Kickstarter and Engineering Director at Etsy. writes about the fundamentals of managing engineers: how to build trust, give feedback, navigate team stages, and grow people without burning them out or yourself. This book shaped a big part of my management philosophy.

Communication & Influence

59. How to Win Friends and Influence People by Dale Carnegie — Published in 1936 and still one of the most practically useful books on human dynamics ever written. The title makes it sound manipulative. The content is mostly about listening, showing genuine interest, and making people feel valued.

60. Captivate: The Science of Succeeding with People by Vanessa Van Edwards — Not a tech book. That is exactly why it belongs here. is a behavioral researcher who has spent years studying how people actually communicate, build rapport, and earn trust. The frameworks in this book are more applicable to one-on-ones and stakeholder conversations than most “communication for engineers” content I have read.

61. Cues: Master the Secret Language of Charismatic Communication by Vanessa Van Edwards — The follow-up to Captivate. More focused on the nonverbal and micro-behavioral signals that shape how you are perceived in meetings, presentations, and conversations. Read this one twice. Oh, also, check her YouTub channel!

62. Never Split the Difference by Chris Voss — A former FBI hostage negotiator writes about negotiation and influence. It sounds like it has nothing to do with data & engineering leadership. It has everything to do with it. This book prepares you for difficult stakeholder conversations, budget discussions, or pushback on scope.

63. On Writing Well by William Zinsser — A book about writing clearly and with purpose. The kind of writing that gets your ideas across in a design doc, a Slack thread, or a post-mortem without anyone having to read it twice. Most technical writers benefit more from this than from any course on technical writing.

64. Talk Like TED by Carmine Gallo — Gallo broke down hundreds of TED talks to find what made the best ones land. The result is a practical framework for any presentation where you need to make a complex idea stick with a non-technical audience. Useful every time you walk into a room to justify a platform decision or a team investment.

Strategy & Systems Thinking

65. Good Strategy / Bad Strategy by — The clearest book I have read on what strategy actually is and why most of what gets called strategy in organizations is not strategy at all. Every data lead who has ever sat in a planning meeting wondering why nothing sticks should read this.

66. The Goal by Eliyahu Goldratt — A novel about a manufacturing plant manager trying to save his factory. Goldratt’s theory of constraints is the most useful mental model I have applied to pipeline architecture and team throughput. Read it once and you will never look at a slow pipeline the same way again.

67. Playing to Win by & A.G. Lafley — Strategy as a set of explicit choices: where to play and how to win. Martin strips out all the planning theater and gets to what strategy actually requires. More rigorous than Good Strategy Bad Strategy and more actionable for people who need to make real platform or team decisions.

68. The Effective Executive by Peter Drucker — Written in 1966 and still more relevant than most modern management content. Drucker writes about time, priorities, and decisions in ways that apply directly to anyone in a senior technical role. I re-read sections of this every year.

69. Upstream by Dan Heath — About solving problems before they happen rather than reacting to them after. The mental model maps directly onto data platform design, incident prevention, and technical strategy.

Career Growth & Self-Awareness

70. So Good They Can’t Ignore You by Cal Newport — The antidote to “follow your passion” career advice. Cal argues that career capital is what gives you leverage, options, and eventually, work you care about. I think about this book every time I talk to someone who is unsatisfied with where they are.

71. A Few Wise Words by Peter Mukherjee — A collection of success stories from accomplished people across different fields, each sharing in their own words what the journey actually looked like. is one of the smartest and humble people I know.

72. Man’s Search for Meaning by Viktor Frankl — Written by a psychiatrist who survived the Nazi concentration camps and spent the rest of his life studying what keeps people going when everything is taken from them. The answer is purpose. It’s not a career book. But every engineer I know who has read it has come back with a clearer sense of what they are actually working toward.

73. The Subtle Art of Not Giving a F*ck by — A blunt, practical argument for choosing your problems deliberately rather than chasing the illusion of a problem-free life. Useful for anyone who finds themselves grinding on things that do not actually matter, or avoiding the hard conversations that do. This book was a blog post, btw.

74. What Got You Here Won’t Get You There by Marshall Goldsmith — About the specific behaviors that hold successful people back as they move into leadership. Not the obvious stuff. The subtle habits that made you effective as an IC and will quietly undermine you as a lead.

75. Radical Candor by Kim Scott — How to care about people and challenge them directly at the same time. Most managers do one or the other. Kim Scott makes the case that doing both is not a contradiction, but the job. Read by almost every engineering manager at some point. Worth reading before you need it rather than after.

76. Thinking, Fast and Slow by Daniel Kahneman — The science of how we make decisions and where we reliably go wrong. Long, dense, and worth every page. Once you understand the two systems Kahneman describes, you start recognizing their fingerprints on every estimation, every post-mortem, every hiring decision you have ever made.

77. The 5 Elements of Effective Thinking by Edward Burger & Michael Starbird — A short, dense book on how to think better. The book applies directly to how you approach problem-solving, architecture decisions, and career growth. I return to this one more than most.

Podcasts

78. Data Engineering Podcast by — The most technically rigorous DE podcast running. Petabyte-scale systems, Iceberg table management, orchestration failures. Consistent quality since 2017.

79. Soft Skills Engineering by Dave Smith & Jamison Dance — They answer engineering career questions in a format that is somehow both funny and genuinely useful. It covers everything from how to handle a difficult manager to whether you should take a promotion. This podcast actually taught me that it takes more than great code to be a great engineer.

80. Think Fast Talk Smart by Matt Abrahams — Stanford podcast on communication under pressure. Short episodes, high density. The focus on spontaneous speaking makes it more practical for working engineers than most public speaking content.

81. Acquired by & David Rosenthal — Long-form deep dives into how great companies were built. Not a strategy framework podcast, but something better. You walk away understanding how specific organizations made specific decisions over time. The compounding effect of listening to a dozen episodes is a permanently better sense of how businesses actually work.

82. The Knowledge Project by Shane Parrish — Farnam Street’s podcast on mental models, decision-making, and the habits of people who think clearly. Every episode is a masterclass in how to reason better under uncertainty. Slow to binge but the kind of content that compounds over years.

Final Thoughts

Do not follow everybody on this list. Do not subscribe to every newsletter. That is not how this works.

Pick two or three sources per category that actually match where you are right now. Follow them consistently. Read them when they land. Let them compound.

Most of the people on this list are not just newsletter writers or LinkedIn creators. They have books, courses, podcasts, YouTube channels, and communities built around the same ideas they post about for free. Once someone’s thinking starts landing for you, go deeper. Find them on every platform they are active on. Buy the book. Take the course. Join the community. The newsletter is usually the smallest part of what they offer.

Two or three resources you actually read will do more for you than twenty you subscribed to and forgot about. The goal is not to consume more. The goal is to think better.

—

Yordan

More on the Topic

• The Smart Engineer’s Framework to Staying Current Without Noise

• The Certifications Scam

• 5 Red Flags of Mediocre Data Engineers

Presenting Yuki Kakegawa

Yuki is a Staff Data Engineer, author of the Polars Cookbook, and the founder of Orem Data. He writes about data tools and independent consulting on Substack and LinkedIn.

I asked , Staff Data Engineer and author of the Polars Cookbook, what the biggest adjustment was when he became a team of one.

He skipped tooling. He skipped workload. He said this:

It’s a shift in mindset. You’re not a data engineer anymore. You’re a data person helping the business with data and analytics

That sentence landed harder than I expected, because most people assume the challenge is the technical breadth: wearing all the hats, being the analyst, the engineer, and the data scientist rolled into one.

That part is visible. What nobody talks about is the identity part.

You Were Hired as a Data Engineer. That Is the Problem.

At a large company, your identity is your scope. You do pipeline work, pass it to the analyst, the analyst makes the report, the report goes to the business. You are one node in a chain, and that chain insulates you from the messiness of what the business needs.

When you’re a team of one, that chain is you.

Yuki described his current day-to-day:

• talking to the business to understand what they care about

• translating that into projects

• building the pipelines

• building the models,

• building the reporting layer

• delivering insights directly to stakeholders

He skips the handoff entirely.

That scope describes a different job, built around a different identity.

Subscribe now

The Selfishness That Kills You

He used a word that surprised me: selfish.

When I was first getting started, I wanted to work on pipelines and I didn’t want to work on reporting. That selfishness kills you in this role. You have to be flexible and you have to care about the business first.

Most data engineers have strong opinions about which work is worth doing. Pipelines are interesting. Reporting is boring. Data modeling is craft. Dashboards are noise.

Those opinions are how you survive in a large org where you can negotiate your scope.

A team of one has no scope to negotiate. The business has no interest in which part of the stack you find meaningful.

The work that needs doing is the work you do, and if you have not made peace with that before taking the role, the first six months will feel like a slow grind against a situation you agreed to.

What Is Broken at Every Startup You Walk Into

I asked Yuki what he finds broken almost every time he walks into a young company.

Tooling is rarely the issue. It’s the processes around the processes that produce the data used for reporting and analytics downstream. And the alignment on what’s important, the definition of metrics, what we want to build.

Two things. The upstream processes that generate data, and whether the business has agreed on what the numbers mean. The stack is almost never the problem.

The Metric Definition Problem

This is the one that is hardest to fix and most commonly ignored. Yuki described the ideal state: every metric the business cares about is written down, defined, and agreed on before the data team touches a model.

When that is true, the data team’s job is implementation. The hard part is already done for you.

The real state at most companies is three departments with three definitions of the same number.

If you use one team’s definition, you put another team in a bad spot. If you try to reconcile them, you are suddenly in a political conversation nobody hired you to have.

I’ve been in that position. That’s the part I hated the most.

Defining core metrics early, before the company grows, before each department builds its own reporting layer, before everyone has opinions baked into their own numbers, is more valuable than any pipeline you will build.

If you’re walking into a company where this work is undone, do it first.

How to Handle the Stakeholder Who Thinks Your Work Takes Two Weeks

Yuki described a pattern that every team-of-one data person will recognise. A stakeholder requests a report, thinks it can be done in two weeks, and the data behind it is messy enough that you know it will take four.

I can try, but I can’t promise, because I think these things will be bottlenecks.

Two things are happening in that exchange. Setting expectations is the obvious one. Making the complexity visible is the one that changes the relationship long-term.

When you’re the only data person, the rest of the company defaults to assuming data work is fast. Pull the numbers, build the report, done.

They genuinely have no frame of reference for what it takes to model messy source data into something accurate enough to make decisions with. Your job is to narrate the work before you do it, and skip the explanation after you miss the deadline.

The Transparency Stack

Yuki added something that makes the whole prioritisation problem easier: making your priority stack visible to the entire business.

Being transparent about what you’re working on and what the priorities are is important. Because if one stakeholder thinks his project is the top priority, but I’m working on a priority item requested by the CEO, then that stakeholder will understand that his project is not at the top.

This works because it shifts who does the priority negotiation. When everyone can see the queue, the conversation moves from “why isn’t my thing done“ to “is my thing in the right place in the queue“. The second conversation is faster and involves fewer emotions.

Accuracy vs. Speed Is a Trade-Off to Name, Not a Choice to Make Alone

I pushed Yuki on a question that sounds simple: accuracy or speed?

Definitely accuracy. But that’s where your skill comes in. How do you deliver projects fast while ensuring accuracy?

The real answer lives in the communication around the trade-off, not the trade-off itself. If you can deliver in one week at 80% data quality, or in two weeks at 100%, the stakeholder should make that call. They can only make it if you put the options in front of them explicitly.

If you wait two weeks, I can ensure 100% accuracy. If you want it in one week, there might be things that still need to be pinned down.

Yuki’s underlying point is worth sitting with: making decisions on low-quality data defeats the entire point of data-driven decision making. Speed that produces bad numbers is a liability that takes three times longer to fix than the shortcut saved.

On Using AI When You Have Nobody to Think With

One thing Yuki said is worth pulling out directly, because it is the most honest framing of AI use I have heard from anyone working in the data space:

I use AI especially when I want to bounce ideas around. I use it because I don’t have anybody else to talk to, because I’m the only data person.

AI as a rubber duck rather than a replacement for judgment. At a startup where you’re the only data person, you have no peer to sanity check your modeling approach, your architecture choices, or whether your prioritisation call makes sense. AI fills a small part of that gap.

But Yuki also admitted he is not sure AI is making him faster overall. The time he used to spend building the solution, he now spends validating what the AI built. The total may net to zero, with the shape of the work changed and the volume unchanged.

That matches what I have seen. AI handles narrowly scoped, well-defined tasks well: understanding what a table column means by parsing the codebase, generating boilerplate inside a framework you have already defined, drafting initial SQL that you then refactor.

For architectural decisions and anything that requires sustained judgment, the model is an input, and the judgment stays with you.

Connect With Yuki

Yuki is very active online. Here are some of the best ways to connect with Yuki:

• Substack profile

• The Data Toolbox

• The Independent Insight

• LinkedIn profile

• The Polars Cookbook

• Consultancy website

—

Yordan

I was coaching Hamza last year.

He was one of the best engineers I had worked with outside my team. Sharp, reliable, the kind of person who fixes the production incident at 2am and never makes it anyone else’s problem. He had delivered more that year than most people deliver in two.

He got a 3% raise in January.

When we talked about it, the pattern was immediate:

• He had done everything right technically and nothing right strategically.

• He never flagged his expectations.

• He had no record of what he had delivered.

• He walked into the review meeting with memories and feeling instead of a number.

His manager liked him, but had no ammunition.

Getting a raise has almost nothing to do with whether you deserve one. It has everything to do with whether your manager can build a case for you in a discussion you are not in. The people who get raises are the people whose managers have the data to justify it, the evidence to present it, and the confidence the conversation will stay professional.

The research backs this up. According to Pew, 38% of workers who did not negotiate said they felt uncomfortable asking. The same study found that 66% of workers who did ask got what they asked for. Two thirds. The ask works.

This article is the system Hamza did not have before we worked together.

Download the complete manual at the end of the article.

Why Good Engineers Stay Underpaid

Most of the data engineers I know who are underpaid are genuinely strong. They ship, fix things before anyone notices they are broken, and mentor the junior engineers without being asked. They are the people their companies cannot afford to lose.

And yet they lose money every single year.

The problem is structural. Salary decisions do not get made by the person who sees your work every day. They get made in budget meetings, by people who know you mostly by reputation, based on recommendations from managers who have five other people to advocate for at the same time.

The engineer who gets the raise is the one whose manager walks into that room with the strongest case.

Everything else is secondary.

The math your company will never show you

Here is something your HR department knows and hopes you never think about:

According to SHRM, replacing an employee costs between 50% and 200% of their annual salary. For senior roles, the Center for American Progress puts that number at up to 213%. Recruiting fees, onboarding time, lost productivity, the six months before a new hire operates at full speed.

Giving you a 10% raise costs them 10% of your salary.

The math is on your side. The problem is you are not using it.

Subscribe now

Why the conversation never happens

The Pew Research Center found that 38% of workers who did not negotiate said they simply felt uncomfortable asking. Not a bad manager. Not bad timing. Discomfort is the real enemy.

So engineers stay quiet. They assume good work speaks for itself. They wait for their manager to bring it up. And their manager, who is busy and conflict-averse and assumes you would say something if you were unhappy, never does.

Nobody brings it up, and another year passes.

The 90-Day System

A raise is a system you run across the whole year.

The engineers who get what they ask for flag their expectations early, build a running record of their impact, research their market value before they need it, and invest in the right relationships long before budget season.

By the time the review meeting happens, the outcome is mostly already decided.

The rest of this article walks through each part of that system in full:

• How to flag your expectations early enough to actually influence the outcome

• How to build a brag list that gives your manager something to fight with

• How to find your market number before the conversation

• How to win the sponsors who have real budget influence

• How to run the conversation itself, including what to do when they say no

This is the system I walked Hamza through. He got a 13k salary increase. Keep reading and download the ebook at the end.

The content below is for paid subscribers. If you are not subscribed yet, this is the part worth paying for.

Read more

Presenting Prajakta Yerpude

Prajakta spent a decade climbing every rung of the data engineering ladder, intern, engineer, senior, lead, manager, and somewhere along the way realized her biggest impact was no longer in the code she wrote but in the people she unblocked.

Connect with Prajakta

Getting promoted into management felt like winning. I had the title, the 1:1s, the org chart with my name at the top. What nobody told me was that everything I had spent years getting good at had just become irrelevant.

The skills that got me the promotion were the wrong ones for the job. Speed, ownership, technical control, those are IC superpowers. In management, they become liabilities.

figured this out the hard way too, after a decade climbing every rung of the data engineering ladder. What she learned on the other side is clearer than anything I’ve read on the topic, and it maps almost exactly to where most senior data engineers quietly stall

The data teams that are ahead right now aren’t just experimenting with AI. They’re shipping agentic analytics systems that reason, recommend, and explain their work. And they’re learning things the rest of the industry hasn’t caught up to yet.

Cube’s Agentic Analytics Summit on April 29 is where some of those teams share what they’ve found. Dan Meshkov from Brex will talk about what a data foundation looks like for a mission-driven company. Gabe Romero from Jobber will cover how financial reporting changes when you move beyond charts. Joe Reis will dig into data engineering in the agentic era.

If you lead a data team or build data infrastructure, the insights here could save you months of trial and error.

Grab your free seat here

You Are Already a Manager Before the Title

Most people wait for the promotion to start operating differently. That is the wrong order.

The data professionals who get promoted into leadership are not the ones who wanted the title. They are the ones who were already doing the work before anyone gave it to them. Clarifying requirements with stakeholders when nobody asked. Helping teammates get unblocked when they had their own deliverables to ship. Asking the why behind the problem instead of just solving the what.

The Week Your Code Sits Untouched

There is a specific moment that signals the shift. You get to the end of a week and realize you made almost no progress on your own work — but the team moved forward because of the conversations you had.

That discomfort is the job changing underneath you.

If you wait until the title to start operating at the next level, you are asking your manager to take a bet on future behavior. That is a harder sell than showing them behavior that is already there.

Speaking Up Is a Skill

Early in any leadership journey, the most uncomfortable moment is the same for almost everyone: being in a room of more experienced people, knowing something is wrong, and deciding whether to say it.

The imposter syndrome is real. The difference is learning not to let it make the decision for you.

Facts Remove the Politics

In data, you have a specific advantage: you can ground a challenge in numbers and evidence. When you do that, you shift the conversation from opinion to information. The most experienced person in the room does not win by default anymore.

Leadership is about stepping up when something needs to be said. That is available to you at any level. An intern can flag a bad assumption. A senior IC can challenge a decision made three levels above them.

The cost of staying quiet is harder to measure than the cost of speaking up. But it compounds over time.

Empathy Is Leverage.

As engineers, we are trained to solve technical problems. The higher you go, the more you realize the hardest problems are people problems.

Misalignment. Stress. Lack of clarity. Someone having an off day. These do not have a clean solution. Some of them do not need a solution at all. Instead, they need listening.

The Problem-Solver Trap

The instinct to fix things immediately is exactly what gets senior ICs into leadership. It is also the thing that makes early management hard.

Not every situation calls for a solution. Sometimes the person in front of you just needs to feel heard. When you learn to read that distinction — when you can tell the difference between a problem that needs solving and a person who needs to know you are paying attention — the team responds differently.

People who feel understood and supported perform better without you pushing harder. You do not manufacture that with a process or a framework. It is built through consistent, genuine attention to what is actually going on beneath the surface.

Technical skills get you to the role. Empathy and emotional intelligence determine how far you go inside it.

Subscribe now

Your Impact Becomes Invisible. That Is the Whole Point.

As an IC, your output is visible. Code you wrote. Pipelines you fixed. A cost number you moved. You can point to it directly.

As a manager, your impact shows up through other people. Better decisions. Stronger execution. A team delivering consistently and growing in the process. None of that has your name on it.

Unlearning the Need to Own the Outcome

The hardest thing to unlearn is tying your personal value to what you directly produce.

Andy Grove put it clearly in High Output Management: your output as a manager is your team’s output. That is the measure. You do not have a separate output anymore. The team speaks on your behalf.

That means impact can look like:

• Creating the right direction when things are ambiguous

• Removing friction before it slows the team down

• Helping someone succeed in a way they would not have without your support

• Building the environment in which good work happens consistently

You stop building systems. You start building the conditions in which good systems get built. That is more scalable than anything you could ship yourself.

The Myth That Needs to Die

The most persistent management myth: a good manager always has to be in control of everything.

New managers fall into it. Experienced managers fall into it. They believe that effectiveness means knowing every detail, monitoring closely, and constantly stepping in. What that actually creates is dependency. It slows people down. It makes you a single point of failure.

The Real Measure

The actual measure of good leadership is when your team can collaborate, problem-solve, and resolve issues without you needing to be in the room. When something gets fixed before you even know it happened. That is the job done well.

High standards work better when trust already exists. When people know you genuinely support them, they are more open to feedback, more willing to stretch, more willing to take on work that makes them uncomfortable.

You can be kind and still be clear. You can be supportive and still hold people accountable. The balance is a more effective version of both.

Final Thoughts

The move from IC to manager is a step sideways into a completely different job that happens to sit inside the same organization.

The data professionals who stall at senior are almost always technically strong. They can build. What they have not yet built is the capacity to make others better at building.

If you are waiting until you feel ready to step into that, here is the honest version: you will never feel fully ready.

Growth happens because you stepped forward before you did.

—

Yordan

More on the Topic

These are some of the articles Prajakta mentioned in our chat:

• The Operating System Every Data Engineering Leader Needs

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

• How To Stop Waiting For Permission To Lead Data Engineering

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

Reading time: 17 minutes

Nobody teaches you how to manage a data engineering team. You get promoted because you were good at the technical work, handed a calendar full of meetings, and expected to figure the rest out. Most people never do.

Less than half of data and analytics teams effectively deliver business value to their organizations, according to Gartner.

Not because data engineers lack skill. Because the leaders above them have no system for turning that skill into consistent delivery.

Why Managing Data Engineering Teams Is Hard

The skills that got you promoted are the wrong skills for the job you now have

You spent years mastering pipelines, architecture, and debugging. Those skills made you visible. They also made you exactly the wrong candidate for what leadership actually requires.

Technical skill is individual, but leadership is organizational. The moment you become responsible for a team’s output rather than your own, you need a completely different set of tools.

Nobody in data engineering ever gets taught what those tools are.

The instinct most new leaders follow is to stay close to the technical work. It feels productive, because you can add visible value there. What you are actually doing is avoiding the harder, less legible work of building a functioning team.

Most data engineering teams run on luck

85% of big data projects fail, and the primary causes are not technical. They are misalignment, poor communication, and leadership that cannot bridge the gap between what engineers build and what the business needs.

Your team probably looks fine from the outside. People are busy, work is moving. Nobody is visibly on fire. What you cannot see without a system:

• Who is blocked but not saying it

• Which project is slipping its deadline

• Whose work is duplicating someone else’s

• What the team thinks is a priority versus what actually is

By the time those things become visible, you are already behind.

The consequence of no system is invisible, until it isn’t

Failure in data engineering leadership accumulates.

A blocker sits for four days because nobody asked the right question. A project drifts because the goal was never written down. Someone burns out because you had no signal they were underwater. A stakeholder loses confidence because the same incident happened twice without any visible response.

Only 48% of digital initiatives meet or exceed their outcome targets globally. The organizations that hit 71% success rates share one thing: co-owned delivery with clear accountability structures between technical and business leadership. Not better engineers. Better operating infrastructure.

You need a system. Here it is (download the templates at end of the article).

The Operating System

The OS has two layers:

• Rhythm is the recurring rituals that create a shared cadence, so everyone knows what is happening, when, and what is expected.

• Memory is the processes that capture information so the team is not dependent on any individual’s recall.

Most leaders have a broken version of the rhythm layer. Almost nobody has the memory layer. That gap is where teams fail.

The four rituals that run a high-performing data engineering team

Each ritual has a specific job, and when you know what that job is, you stop letting them bleed into each other.

• Standups stop turning into planning sessions.

• 1:1s stop being status updates with one person.

• Check-ins stop being the meeting where people vent and nothing changes.

• Retros stop being a fake appraisal meetings.

The Daily Standup

Most standups are not a ritual

Your standup probably goes like this: everyone says what they did yesterday, what they are doing today, whether they have blockers. People say no blockers. The meeting runs 45 minutes. Nobody learned anything useful.

You keep running it this way because it feels like structure. It seems to work.

It does not work. It is a reporting session disguised as a coordination ritual. And the reason blockers never surface is that you are asking a binary question about blockers. But things slow you down long before they stop you completely.

Run the standup in three phases

Phase 1: Catch-up (first 10 minutes). No agenda. People talk, share what is on their mind, ask each other things. Research on high-performing data teams consistently identifies strong cross-functional relationships as a differentiating factor. Those relationships do not build inside structured agendas.

Phase 2: The three questions (remaining time). Every person answers:

• What are you currently working on? Not yesterday or tomorrow. Right now.

• Is anything slowing you down? Not “do you have blockers“. Slowing you down catches problems before they become stops.

• Do you need anything from anyone in this room? This is the question that makes the standup a coordination tool instead of a report.

Phase 3: Announcements (if time remains). Anything that does not fit elsewhere. If there is no time, skip it and end.

What to watch for

The standup tells you more through silence than through words. Watch for:

• The same task appearing three standups in a row without progress

• The person who never has anything slowing them down

• Everyone’s answers clustering around the same project for days

Each of those is a signal that a conversation needs to happen outside the standup. Never handle it inside it. The standup is not a debugging session for individual blockers. It is a radar sweep. You note what looks wrong and follow up separately.

The standup is not your briefing

If you are using the standup to find out what your team is working on, your system has a gap somewhere else. By the time your standup starts, you should already know.

The standup confirms what you know and surfaces what needs attention, it does not reveal your team’s work to you for the first time.

The 1:1

Most 1:1s are status updates with one person

• You meet

• You ask what they are working on

• They tell you

• You talk about a project

• You schedule the next one

That is a meeting that could have been a Slack message and would have been better as three bullet points.

You keep running it this way because it feels efficient. What is actually happening is that you are using the highest-leverage ritual in your calendar to do the lowest-leverage thing possible.

70% of the variance in employee engagement is attributable to the quality of management. The 1:1 is the primary channel through which that quality gets expressed, or wasted.

Structure the 1:1 so the engineer sets the agenda, not the manager

The 1:1 runs in three parts:

• Their agenda (first 10-15 min): Ask “what do you want to cover today?“ then stop talking. If they have nothing, that is the most important signal in the room.

• Your agenda (next 20-30 min): Feedback collected since the last 1:1. Career conversations. Tensions you observed. Things that have no home in any other ritual.

• The close (last 5-10 min): Two or three things most important for them to focus on before you meet again. Anything you committed to follow up on.

Silence in a 1:1 is the most important data point

When someone has nothing for their agenda, there are two explanations:

• They are heads-down and genuinely fine

• They have learned that bringing things up here does not lead anywhere

Your job is to figure out which one it is. Ask directly: “Is there anything you have been sitting on that you have not brought up?“ Most people will tell you if you actually ask.

Forgetting what you committed to is a management failure

Every commitment you make in a 1:1 and forget by the next one erodes trust. The person noticed. They always notice.

Keep notes after every 1:1. Just two or three sentences: what was discussed, what you committed to, what to follow up on. This is the difference between a leader who has a relationship with each person on their team and one who is starting from scratch every two weeks.

By 2028, one in four regretted staff attritions will be attributable to managers’ lack of data literacy. Employees leaving not because they lack skills, but because their managers cannot develop or support them. The 1:1 is where that problem either gets caught early or quietly compounds into a resignation.

The Sprint Check-in

Skipping the sprint check-in is why your delivery keeps drifting

Most data engineering leaders skip this ritual. They have standups and 1:1s. But because you have no prioritization process and put fires all the time, you never really need a planning meeting.

The standup is too short for sprint-level visibility. The 1:1 covers one person at a time. The sprint check-in is the only ritual where the whole team looks at the same picture together and asks whether it is accurate.

Without it, delivery drift is invisible until it becomes a missed deadline.

Review delivery honestly

The sprint check-in runs in three parts:

Delivery review.

• What was the sprint goal?

• What got done?

• What did not?

For everything that did not land, the question is not who is responsible. The question is “what did you not understand when you planned this?”. Estimation fails because of missing information. Naming what was missing is the only way to plan better next sprint.

Blocker review. Not individual blockers that got resolved, but patterns. If access issues slowed three engineers this sprint, that is a systemic problem someone needs to own.

Research on data team performance specifically identifies shared accountability for outcomes over reactive firefighting as a behavior that distinguishes high-performing teams. The blocker review is where that distinction gets made real.

Next sprint preview. Ten minutes of context before planning starts.

• What matters most in the next two weeks?

• What is the business reason?

• What does the team need to know that will change how they work?

This is where you close the gap between engineers who are executing tasks and engineers who understand why those tasks exist.

Patterns you refuse to name in the check-in become permanent

The temptation in every check-in is to stay positive. Things mostly went well. The miss was a one-off. You will do better next sprint.

That refusal to name patterns is how recurring problems become permanent friction. The same root cause surfaces every two weeks. Everyone knows it. Nobody says it out loud.

Nothing changes.

Say it out loud. Assign it. Fix it or decide you are not going to fix it. Either is better than pretending it is not there.

The Team Retro

Most retros fail because they produce catharsis, but not change

People raise the same things retro after retro. Requirements come in incomplete. Estimation is always off. Two people are still not communicating clearly. And nothing is different.

Eventually, people stop raising real issues. You have trained them that feedback is a ritual, not a mechanism.

You keep running retros this way because producing a long list of observations feels productive.

It is not. A list with no owner, no timeline, and no definition of done is documentation of complaints.

One change per retro, not a wishlist

Run the retro in three columns:

• What went well (5 min). Round-robin, read aloud, group themes. Skip this column and the team starts feeling like everything is broken.

• What could be better (15 min). Push for specificity. “Communication is bad“ is not a problem. “I found out the pipeline broke the downstream model when three stakeholders were already angry“ is a problem.

• What we are doing about it (remaining time). One thing per owner. One definition of done.

That constraint is the entire point. One change per retro means it actually happens. Three changes means two of them disappear by Tuesday.

Protect the third column

The reason most retros fail is that the first two columns consume almost all the time. The third column gets five minutes of tired people picking something vague before everyone has to leave for the next meeting.

Timebox the first two. Hard stop. The third column is the only reason you are in the meeting.

The Memory Layer

Your team runs on short-term memory and it will eventually cost you

Most data engineering teams capture almost nothing. Work moves through people’s heads, conversations happen in Slack and evaporate, decisions get made and their reasoning is never recorded.

This looks fine until someone is out sick for a week, or a senior engineer leaves, or a stakeholder asks why a pipeline works the way it does and the only person who knows has not worked there for two years.

Silos of knowledge, where critical information exists only in individual heads, are one of the four core failure modes of data science teams, alongside deployment friction, tool mismatches, and unmonitored models. The fix is building the habit of capturing information as a team practice.

Know your people beyond what they are working on

Before you can lead someone well, you need to know them. Not their job title or years of experience. Who they actually are as an engineer and where they are trying to go.

For each person on your team, you need a current, accurate picture of:

• What they are actively developing this quarter

• What their current capacity actually is, not what it looks like in the standup

• What kind of work drains them versus what makes them do their best work

• When you last had a real career conversation with them

Research on team development identifies consistent failure patterns in poor management: waiting too long to address issues, and treating development as one-size-fits-all. Both failures come from the same root cause:

The manager does not have an accurate, current picture of each person.

Update what you know about each person after every 1:1 cycle. The leaders who skip this are running their team on impressions. They are surprised by resignations that should not have been surprising.

Track active work so the standup confirms what you already know

Every piece of active work needs four things:

• One owner. Not a team, not a pair, one person accountable for it moving

• A current status - Not Started, In Progress, Blocked, In Review, Done

• The project it belongs to

• A flag if it is blocked or at risk

That is the whole system. Five status states. One owner. Two flags.

The hardest part is getting the team to maintain it. If you are updating the task list yourself, you have taken ownership of something that belongs to your engineers. Your job is to check it, ask about what looks wrong, and make updates non-negotiable.

Watch the Blocked status most closely. Anything sitting there for more than two days without movement is a conversation you need to have before the next standup.

Document projects so decisions survive the people who made them

Every significant project needs a goal, a set of stakeholders, a timeline, and a definition of done, written down before the work starts.

When a project does not have a documented goal, the first thing that happens when it hits a snag is that everyone has a different idea of what success was supposed to look like. Scope drifts. Decisions get made by whoever speaks loudest. The timeline slips in ways nobody can explain because nobody wrote down what was originally intended.

Only 48% of digital initiatives meet their outcome targets globally. The organizations that hit 71% share one characteristic: success was defined and co-owned before delivery started, not reconstructed after it missed.

Review active projects weekly. Look for what is at risk and what has not moved. Both are signals that need attention before they become announcements in a stakeholder meeting.

Treat meetings as data

Every meeting your team has should produce three things:

• what was discussed

• what was decided

• what happens next

Write three or four sentences somewhere the whole team can find them.

The reason is pattern recognition.

When the same problem surfaces in sprint three that surfaced in sprint one, you want to know whether you discussed it before. When a retro action disappears without anyone noticing, the record shows it was assigned. When a stakeholder claims a decision was never made, you have the date it was.

High-performing data teams consistently maintain visible decision logs and documented assumptions. Most teams treat meetings as ephemeral. The teams that learn fastest treat them as the raw material for every difficult conversation they will eventually need to have.

Run postmortems to learn from failures, not to survive them

Things will break. Pipelines will fail. Data will be wrong. Incidents will happen.

The question is not whether. It is whether anything changes because of it.

A postmortem is a structured conversation after a failure:

• What happened

• Why it happened at the system level

• What the fix was

• What changes prevent the same failure recurring

Blameless postmortems are not a kindness to your engineers. They are the only way to get accurate information. When people fear blame, they tell you a version of events that protects them. You treat a symptom while the root cause stays intact and the same incident happens again six weeks later.

Unmonitored systems and processes without structured review are a core failure mode of data science teams, and the damage compounds. Each unresolved failure erodes stakeholder confidence and makes the next investment request harder to justify.

Over time, the postmortem record becomes a knowledge base:

• why things work the way they do

• where the structural fragility is

• what has been tried before

Most data engineering teams treat incidents as things to get through. The teams that improve treat them as information.

Your First Week With the OS

You do not need to build the whole system at once. You need to start it.

Day 1: Know your people. Write down everything you know about each person: current focus, development goals, capacity. The gaps you find are your agenda for the first 1:1 cycle.

Day 2: Set up the standup. Do not just block the calendar. Send a message explaining the format, the three questions, the catch-up phase. Set expectations before the first one runs.

Day 3: Pull active work into one place. Whatever lives in Jira, Notion, Slack, or someone’s head, get it into a single list with one owner, one status, one flag for blocked or at risk.

Day 4: Schedule 1:1s. Five or fewer reports: weekly. More than that: bi-weekly. Send the invite with a short note about what you want to cover in the first one, and that the first ten minutes are always theirs.

Day 5: Put the sprint check-in and retro on the calendar. They do not have to happen this week. They have to exist in the calendar so they do not become things you fight for space for later.

The goal is that next Monday looks different from last Monday.

What Changes When You Have an OS

You stop being surprised by things that were always visible

The most significant change is timing.

When work is tracked, when standups surface blockers, when projects have documented goals and weekly reviews, you see problems coming.

Not always early enough to prevent them, but hopefully, early enough to respond before they escalate.

The shift from reactive to proactive is the one that changes what leading a team actually feels like.

Your engineers stop carrying problems alone

One of the most expensive things that happens in data engineering teams is invisible load: Someone is stuck. They do not want to admit it. They sit on it for three days. By the time it surfaces, a week is gone and the sprint is already at risk.

Rituals designed to surface that load. People stop carrying things alone because the system makes it normal to say when something is wrong.

Your most difficult conversations get easier

Performance reviews stop being stressful when you have 1:1 notes instead of six months of impressions. Reliability conversations with stakeholders have postmortems behind them. Headcount requests have project history and capacity data to support them.

48% of HR leaders agree the demand for new skills is evolving faster than existing talent structures can support, which means every conversation about team development and investment is becoming more important, not less.

The leaders who can back those conversations with evidence have more credibility and get more resources. The ones running on instinct get told to come back with data.

You are a data person. Come with data.

Get the Full System

Everything in this article is built into a Notion template you can copy and use today. All five components:

• team tracking

• active work

• project management

• meeting records

• postmortems

Everything is pre-configured with the structures, properties, and templates that match what you read above.

Paid subscribers get the Operating System for free here

Read more

I had a chat with Mihail, a software engineering lead who also lectures at Plovdiv University. He teaches data engineering as an elective because the core CS curriculum has zero room for it.

That tells you everything about the state of data education.

Universities produce graduates who know SQL syntax, basic normalization, and enough theory to pass an exam. Then those graduates walk into jobs where the theory is the easy part. The pipelines, the warehouses, the cloud platforms, the stakeholder conversations, the ambiguity of real problems. None of that shows up in a lecture hall.

I got my databases grade in university and it was mediocre. I didn’t care because the course felt abstract and disconnected from anything real. Most students feel the same way. And the system does nothing to change that.

The gap between what university teaches and what the job demands keeps growing. But the fix is simpler than most people think, and it starts long before graduation day.

The Curriculum Stops at SQL

University data education peaks at a single databases course in your second year.

You learn what SQL is, what a database does, and some theory about normalization and data storage. The course is abstract. Students treat databases like glorified Excel files because nobody shows them why the syntactical overhead matters.

Until you work on large-scale projects, the difference between a spreadsheet and a relational database feels like a bureaucratic formality.

And that databases course is the baseline for everything data-related in the entire degree.

Everything Beyond SQL Is “Too Specialized”

From that point, data science branches into math and statistics. Data engineering branches into pipelines, warehouses, cloud platforms, ETL, governance. The university follows neither branch with any depth.

The reason is structural. Introducing a new subject into a CS curriculum takes years of bureaucratic and administrative effort.

Universities teach foundations because foundations are stable. Specific technologies move too fast for a system designed to change slowly.

• SQL is foundational enough to make the cut

• Snowflake, Databricks, dbt, Airflow are all “too specialized”

• Anything resembling a real data engineering stack gets classified as professional training, outside the university’s scope

The 10-Year Lag Is Built Into the System

Mihail put it bluntly. Universities are roughly a decade behind the industry. By the time a discipline earns a permanent spot in the curriculum, the profession has already moved on to the next generation of tooling.

The workaround at Plovdiv University is elective courses. Mihail and his colleagues created an entire data engineering track outside the required curriculum.

Students who are dedicated sign up semester after semester and piece together the big picture on their own initiative. A full data engineering discipline exists in the master’s program, but only because individual lecturers pushed for it.

The core curriculum still treats data engineering as a niche profession. The students who figure out it matters do so despite the system, not because of it.

Hard Skills Used to Be Enough. They Aren’t Anymore.

A few years ago, knowing one programming language and one framework got you hired.

The COVID-era hiring boom rewarded narrow skill sets. Companies needed seats filled. They needed people who could write code in a specific technology and ship tickets.

Thousands of junior developers entered the industry every month on the back of a single concentrated skill. No curiosity required and no product understanding expected. Know React, get a job.

That worked because the economics supported it.

The Market Shifted and the Craftsmen Got Stuck

The economics changed. Companies stopped hiring for volume. AI tools absorbed the foundational knowledge work.

People who built their entire career around one framework or one language found themselves competing with a chatbot that explains object-oriented programming better than most university courses.

Information is everywhere now. What separates a valuable engineer from a replaceable one is everything around the information.

• Understanding the product and the customer

• Adapting when the tooling changes underneath you

• Operating with judgment in ambiguous situations

• Communicating with stakeholders who speak a different language than you do

Universities Still Train for the Old Game

The university teaches you how to use tools. The job requires you to understand why you’re using them and what problem they solve for the business.

Mihail made a sharp distinction. Universities produce IT people, not developers. The degree gives you logic, math, and a surface-level tour of programming concepts.

But the industry needs people who solve problems related to communication, technology, and economics. Those are three different skill sets, and a CS curriculum addresses one of them on a good day.

The people who stall are the ones who treat graduation as the finish line. The ones who keep going treat it as a starting point for a much longer education that happens inside the business, inside the community, and inside the messy reality of real projects.

Your Network Is Your Actual Career Engine

The cliche says your network is your net worth. It holds true even when you look for a job.

Blasting CVs across LinkedIn is the path of least resistance. It feels productive because you’re doing something. But it’s a low-leverage move that puts you in a pile with hundreds of other applicants who look identical on paper.

Mihail’s company has never posted a single job offer on a popular platform. They hand-pick students directly from the university. Every hire comes through relationships built during lectures, projects, and community events.

That pattern repeats across the industry more often than people realize.

Show Up Where the Decisions Happen

Conferences and user groups are where project leads, hiring managers, and senior engineers gather to talk about the work they care about. These people are approachable in that setting. They want to talk shop.

The move is to ask about their problems, not their openings.

• What kind of scaling challenges are you dealing with?

• Where does delivery break down on your projects?

• What does your data stack look like and where does it hurt?

These questions signal curiosity and understanding. “Do you have any open positions?“ signals desperation.

One leads to a conversation. The other leads to a polite nod and a business card that goes nowhere.

Subscribe now

Make Yourself Visible Before You Need a Job

If you’re early in your career and don’t have deep experience to share, you still have options. A GitHub project, a blog post about a technology you’re learning, a short tutorial, a LinkedIn thread documenting what you figured out this week. None of these need to be brilliant. They need to exist.

Visibility compounds. The people who run conferences and user groups see the same faces year after year. They remember your questions, and when a role opens up on their team, they think of the person they’ve been talking to for the last six months before they think of the 200 CVs sitting in their inbox.

I found my current company through conferences. Several people I’ve worked with came from user groups and community events. This is how the industry works when you look past the job boards.

Find Misho

Here’s how you can find more about Mihail and his initiatives for data newcomers.

Everything he does at this point is in Bulgarian, but Mihail promised to start building educational content in English, too.

• LinkedIn profile

• Snowflake user group

• Free Snowflake course

Closing Words

The university gives you a starting line. Logic, math, a community of confused peers who share your ambition. That matters more than the cynics admit.

But the finish line is somewhere else entirely.

The skills that make data engineers valuable are built in the space between academia and industry. Pipelines, product thinking, stakeholder conversations, judgment under ambiguity.

No curriculum covers this. No lecture hall prepares you for the moment a stakeholder asks you to scope something that has never been done before and expects an answer by Thursday.

The people who figure this out early have an unfair advantage. They show up at conferences while still in their second year. They build side projects that prove curiosity, not mastery. They surround themselves with people who are ahead of them and ask questions until the vocabulary clicks.

The people who wait for a curriculum to teach them what the job demands graduate with a degree and a gap where their career momentum should be.

University is a foundation. Treat it as one. Build everything else yourself.

—

Yordan

More on the Topic

• The Surprising Trait That Beats Experience

• Level-up Data Engineering

• Why the Hard Skills Obsession Is Misleading Every Aspiring Data Engineer

Subscribe now

I walked into a performance review expecting a conversation about growth. My manager told me he saw me staying close to data architecture, going deeper into technical design, owning more of the platform layer.

I wanted the opposite. Ten years in tech at that point, and the purely technical challenges had stopped being the draw. I enjoyed talking to people, managing people, making decisions across teams. I had spent the past year doing more of it informally and assumed everyone noticed.

My manager had no idea. His response stuck with me: “You should have told me this months ago. We needed time to set the right goals and show results before this review“.

He was right. I had been skipping 1:1s, walking in with “I don’t have anything to share,” or spending the full 30 minutes listing what my team shipped that sprint. The one meeting designed for me to shape my own direction, and I treated it like overhead.

Your 1:1 is the single most strategic meeting on your calendar, and chances are you prepare for it the least.

“I Don’t Have Anything to Share”

Five words that cost more than any failed project.

I used to say this all the time. The week felt routine, nothing blew up, the team was heads down on planned work. Cancel the meeting, reclaim the 30 minutes, get back to real work.

The Hidden Assumption

The assumption behind this is that 1:1s exist for problems. If nothing is broken, the meeting has no purpose.

Data professionals fall into this trap faster than most because the work feels self-evident. The pipeline runs or it doesn’t. Progress is visible in commits and deployments, so reporting it out loud feels redundant.

But your manager is not tracking your commits. They are building a mental model of who you are, what you want, and where you are headed.

Every time you cancel, every time you show up with nothing, you hand them a blank canvas and let them paint whatever picture makes sense from their vantage point.

Silence Gets Filled With Assumptions

My manager painted a data architect, but I wanted to lead people.

That gap did not form in one bad conversation. It formed across years of silence I chose because I thought the work spoke for itself.

The work says what got done. It says nothing about where you want to go, what is frustrating you, or what you need next. Those things come out when you say them, and the 1:1 is the meeting built for exactly that.

If you keep canceling it, your manager will fill the gap with assumptions. And you will sit in a performance review one day hearing a version of your career you never signed up for.

Give the Update, Skip the Details

People hear “stop giving status updates“ and swing to the other extreme.

They walk in talking about career goals and strategic direction while their manager sits there wondering if the migration is still on track.

The Update Serves a Purpose

Your manager needs a status check. They need to know you are spending time on the right things and nothing is stuck. The update gives your manager confidence that the team is pointed in the right direction and no one is burning cycles on low-leverage work.

Give them the high-level overview. Five minutes, tops. What is in progress, what shipped, what is blocked.

If your manager is technical, they will follow fast and ask sharp questions. If they are not technical, they do not care about the implementation details anyway.

The Mistake Is Filling 30 Minutes With Five Minutes of Content

The real problem is stretchingthe update to fill the entire slot because you did not prepare anything else to talk about.

The update is the warmup. It earns you the right to spend the remaining 25 minutes on the things that shape your role, your trajectory, and your relationship with your manager.

What comes after the update is where the 1:1 becomes a strategic meeting instead of an administrative one. And that is where most data professionals leave the biggest gap.

Now let me break down exactly what to bring to that remaining time, how to prepare for it in ten minutes, and how to reset the dynamic if you have been running empty 1:1s for months.

Read more

This article is part of the Lead & Grow playlist. Click here to explore the full series.

I spent three years shipping some of the best engineering work of my career and getting almost zero recognition for it. I built solid pipelines, clean models and efficient infrastructure. And nobody outside my immediate team had any idea what I had done or why it mattered.

I thought the work would speak for itself. It didn’t. Work never does.

The problem was the language. I described everything in the terms I built it in, and those terms meant nothing to the people who controlled my career trajectory. I had a translation problem, and I didn’t even know it existed.

The Language Gap That Keeps You Invisible

Here is the thing about technical work: The better you do it, the more invisible it becomes.

A pipeline that runs flawlessly at 3am generates no Slack alerts, no urgent emails, no visible crisis for anyone to notice. Your success looks like nothing happened.

So when someone asks what you have been working on, you say something like “I migrated the ingestion layer from ETL to ELT“ or “I refactored the dbt models to use incremental materialization“. And the person in the Zoom square nods politely and moves on, because those words carry zero weight in their world.

The people deciding your promotion, your project funding, your headcount don’t think in pipelines and materializations. They think in revenue, cost, and risk.

They won’t. They have their own problems to think about.

So the credit goes to whoever already speaks their language. The PM who presents the dashboard you built, the analyst who shares the insight your pipeline made possible get the visibility because they describe the outcome, and you described the plumbing.

This pattern is career poison, and it compounds. One invisible quarter becomes a year of “solid contributor“ ratings that never break through to “high impact“. The frustrating part is that you are already doing high-impact work. You are describing it in a way that buries the impact.

The Three-Column Translation

I use a framework with my direct reports that fixes this. It forces you to take any piece of technical work and push it through three columns until it lands in language a CFO would repeat back to you.

Column 1: Technical Input. What did you change? Eight words max. Use past tense. “Migrated ETL to ELT“. “Refactored the ingestion layer“. This is where most engineers stop, but that’s the least important column.

Column 2: Enablement Outcome. What became faster, more reliable, or self-serve as a result? Put a number on it. Percentage improvement, hours saved, or direct dollar impact. “Analysts build and modify transformations without engineering tickets“ or “Query runtime dropped from 90 to 18 minutes“.

Column 3: Business Driver. Which business bucket does this fall into: revenue, cost, or risk? Name the specific stakeholder behavior or decision that moves the number. This is the column that matters, and this is the column most engineers skip entirely.

Here is what the full translation looks like in practice.

An ETL to ELT migration:

• Column 1: “Migrated ETL to ELT”

• Column 2: “Analysts build and modify their own transformations directly in the warehouse without filing engineering tickets“

• Column 3: “Product team runs independent analyses, cutting 2 weeks from the launch decision cycle“

A dbt refactor:

• Column 1: “Added daily partitions“

• Column 2: “Runtime dropped from 90 to 18 minutes, 80% reduction“

• Column 3: “72 analyst hours freed per month, equivalent to $1.2M in retention analysis capacity“

Look at the difference between Column 1 and Column 3. Column 1 is what you did. Column 3 is why anyone should care.

Read your Column 3 out loud and ask yourself if the CFO would repeat it in a sentence. If it still sounds technical, it hasn’t crossed the line yet.

Stories Beat Updates

Translation is half the problem. Delivery is the other half.

Most data engineers send updates. You share what you did, what changed, and what comes next. The information is accurate and nobody acts on it, because updates are passive. You inform, but you don’t move anyone toward a decision.

The fix is a four-part structure that turns any update into something people act on:

• Context: what problem were you solving?

• Insight: what does the work show?

• Impact: why does this matter to the business?

• Action: what should happen next?

That last step is the one everyone leaves out, and it is the most important one. Send an update without a recommended next step and your audience will do nothing. They will read it, nod, and go back to their inbox. End with a clear recommendation or a specific decision you need from them, and the message becomes a conversation.

The language matters too. Drop the engineering voice when you talk to business stakeholders. Lead with what surprised you and what changed. Use phrases like “what stood out to me“ and “the implication for the team is“ because they signal there is a human being behind the update with a point of view, not a system generating a status report.

A story that leaves someone thinking the same way they started is unfinished. If your update doesn’t change what someone believes or what they do next, it was noise.

Final Thoughts

The data engineers I see get promoted are rarely the best builders on the team. They are the ones who learned to describe their work in terms that register with the people holding the budget, the headcount, and the promotion decisions.

This is a skill. It’s easy to learn, and most people never develop it because nobody tells them it exists.

Everything I covered here is a piece of a larger system I built and use with my own team. The Business Translation Kit, including the interactive worksheet, the KPI mapping framework, and the executive framing templates, is available as a free resource.

Shut up and give me the kit

More on the Topic

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

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

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

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

See what people say about working with me.

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went!

Upgrade Now

Data-driven the way subscription businesses actually operate it. Numbers connected to decisions, decisions connected to outcomes.

Below are the ideas she shared. The full conversation is in the video above.

Stakeholders Make Emotional Decisions First (and They Have Good Reason To)

The standard data professional complaint is that stakeholders ignore data and run on gut. Yana flips that framing.

Her view:

Most people are wired to make emotional decisions first and look for data that confirms them second.

From her background in neurolinguistic programming, she puts the share of people who genuinely process the world through numbers at around 15%. Everyone else needs a different approach.

Showing up with a dashboard and expecting it to land is wishful thinking. Data needs a story around it. A number without context gets interpreted differently by every person in the room. One sees growth, another sees underperformance, a third questions whether the metric tracks the right thing at all.

Yana learned this early. Every conversation with engineering teams felt like friction. She was asking questions they thought she should already know. They were building things that missed what she actually needed. The gap cost both sides time.

What closed it was her decision to learn enough about how systems work to ask better questions. To stop being helpless in technical conversations.

The One Move That Ends Arguments in Any Meeting

Yana has one technique she uses across every organization. It works in telecom. It works in banking. She has a perfect record with it.

Before any contentious conversation, find the data that links your ask to what the organization actually cares about. Customers, revenue, profit. Those three. Then add competitive benchmarks if you can find them.

In her current bank, she came in and asked how many successful app registrations they were getting. She pulled the internal rate, found competitor data, and discovered some competitors were achieving double or triple the registration conversion rate. She put that in front of the team.

The conversation changed.

People stop defending their position when the data shows the position is costing them. Go into the meeting with the numbers already pulled. Link them to something the people in the room care about. Then let the data do the work.

This applies directly to data teams. When a project needs prioritization, funding, or unblocking, skip the technical justification. Show the business number it connects to, then show where a competitor is already ahead.

What Yana Actually Tracks on Substack

Substack’s native analytics fall short. Yana built her own spreadsheet and tracks the following every month:

• Total subscribers

• New subscribers

• Total paid subscribers

• New paid subscribers

• Churned paid subscribers

• New revenue

• Average revenue per subscriber per month

• Average revenue per subscriber per year

• Free-to-paid conversion rate

• Net Promoter Score

The benchmark Yana uses for revenue per subscriber is the email marketing industry average, ranging roughly from $1 to $12 per subscriber per year depending on niche. Above average means the business is healthy. Below average means something needs auditing.

The NPS tracking is the piece most Substackers skip. She uses Substack’s survey feature to ask paid subscribers one question: on a scale from 1 to 10, how likely are you to recommend this publication to someone you know. That one question, run through the standard NPS formula, tells her whether her paid tier delivers real value. Her target is above 70.

Yana’s reasoning:

NPS is the only reliable signal for whether paid subscribers are satisfied or are simply on their way out.

How She Runs a $10K/Month Business in the Hours Left Over From a Full-Time Job

Yana works five days a week, eight hours a day, in an office. She can answer Substack comments during lunch or late after work. That’s the window she operates in.

AI handles everything operational. Formatting, research, scheduling, the mechanical parts. For writing, she trained a system on her own content. She extracted all her published articles into a database, connected it to an MCP server, and built what she calls a second brain. She can query it for content gaps, understand what paid subscribers want more of, and run analysis on her own business data.

She writes in her voice, informed by her own data, with AI executing the work that requires no judgment.

Her warning about AI:

It pulls you into rabbit holes when you let it.

Every answer suggests the next step, and the next step, and an hour later you have built something with no clear business purpose. Use it to execute a decision. Know exactly what you want before you open it.

Yana also made the point that the 9-to-5 built the Substack. The telecom career gave her subscription business knowledge, customer journey expertise, conversion rate benchmarks, and an understanding of which metrics actually predict business health.

All of it went directly into how she runs the newsletter. The side business grew because of the day job.

Final Thoughts

Yana has 15 years of subscription business experience, a disciplined tracking system, and a clear rule: link your ask to numbers that matter, then find the benchmark that shows where you stand.

That’s the part worth sitting with. Data professionals spend time arguing that stakeholders ignore data. Yana learned enough about systems to have real conversations with engineers. She built her own analytics because the platform’s fell short. She tracks NPS because her industry background taught her it mattered.

The gap between business and data closes when people on both sides decide to move. Yana moved. The engineers still telling business people to figure it out on their own are the ones falling behind.

Interested into growing your Substack? Subscribe to Yana’s publication.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

See what people say about working with me.

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went!

Subscribe now

I got this wrong. I read the counterarguments. I talked to people who genuinely believe in the credential economy. And I arrived at an uncomfortable conclusion: the market has spoken, and the market wants badges.

So I built one.

If you have been waiting for a certification that actually reflects what the modern data industry rewards, your wait is over. You can get certified today, and it will take you less time than your next standup.

What You Can Get Certified In

There is only one credential that matters right now, and it is the Licensed AI-Powered Insights Leverage Specialist™.

It validates your enterprise-grade proficiency in leveraging cross-functional data synergies across the modern AI-powered stack. If you have ever sat in a meeting where someone said something like that and nodded along, you are already overqualified.

The exam is five questions. Multiple choice. The pass rate is 100%, which puts it well ahead of most vendor certifications in terms of respecting your time.

Take It For FREE

Your official certificate is issued immediately upon completion by the Data Gibberish Institute for Enterprise Excellence & Advanced AI-Driven Thought Leadership™. No waiting. No retake fees. No two-year recertification treadmill.

Why You Should Stop Waiting

You have seen the LinkedIn posts. Someone announces their fourteenth certification. Three thousand likes. Fire emojis from people who have never shipped a pipeline in their lives. The comments say “congrats, you inspire me“.

Fourteen certifications. At some point you have to stop fighting the current.

The market does not reward taste. It rewards signals. And if a badge is the signal that gets you hired, promoted, or taken seriously in a room full of people who have no idea what you actually do, then the question is not whether to get certified. The question is why you have waited this long.

Your peers are out there collecting credentials. Your LinkedIn profile is sitting there, badge-free, quietly judging you. This is your chance to fix that.

Get Certified Today

Final Thoughts

Go get certified.

When you are done, you will hold exactly as much proof of competence as most of the certifications currently listed on your colleagues’ LinkedIn profiles. The difference is that this one is honest about what it is.

Take The Exam

Happy April 1st.

More on the Topic

• The Certifications Scam

• 5 Exclusive Soft Skill Lessons You Can Learn From Senior Data Engineers

• Beyond Senior Data Engineer: Skills & Strategies for the Next Big Step

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

See what people say about working with me.

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went!

Subscribe now

Doing the same thing with fewer people is not a transformation. It is a managed decline with better PR. And the people who pay for it are the ones who showed up every day trying to do good work inside a company that had already stopped believing in itself.

If that’s you, keep reading.

AI Expands What You Can Build

I want to be specific here, because vague encouragement is BS.

Since the newest Claude models dropped, I have been committing code to GitHub every single day. Including weekends and evenings. Not only for work. I want to build things and I finally have the tools to do it fast enough to stay interested.

I am also hiring all the time. This week I am interviewing for another analytics engineer on my team. The work is growing. The scope of what we can do in a week now would have taken a month two years ago.

That is what AI does to a team with a direction. It multiplies output. It raises the ceiling on what one person or one small team can ship. It turns “we don’t have the bandwidth“ into a much harder excuse to make.

So when a company looks at that same capability and decides the right move is to cut 15% of its workforce to maintain current output, pay attention to what they are telling you.

They are not optimizing or transforming. They looked at a bigger ceiling and decided they had no interest in reaching it.

That is a product and strategy problem. It’s a leadership failure.

AI handed every company in the world a way to do more. Some took it and used it to do less, cheaper. The ones doing less cheaper already knew they were out of moves.

The Real Leadership Problem

“Doing more with less“ sounds responsible. It gets nodded through in board meetings. It shows up in earnings calls as discipline.

It is a tell for leaders who stopped asking what’s next.

Growth requires a thesis. You need a belief about where the market is going, what your customers need in two years, what you can build that nobody else can. That thesis is what turns a capability like AI into a hiring reason instead of a cutting reason.

When that thesis is missing, every new tool becomes a cost lever. AI shows up and the question leadership asks is “how many people can we remove from the org?“

That question is a symptom. It means the people at the top are managing a position are trying to hold margin on a product they stopped believing in. The layoffs are a controlled retreat dressed up in transformation language.

And the people who get cut pay for that failure.

I have worked with leaders who had a thesis and leaders who didn’t. The difference is obvious inside six months. One type makes you feel like the work is expanding. The other makes you feel like every quarter is a negotiation over who stays.

If you have been in that second environment, you already know the feeling. It sits in your chest in every all-hands.

You Got Pushed Out of a Dead End

I know it hurts. You might have a family to feed, bills that do not pause for your job search, a mortgage that does not care about market conditions. I am not going to tell you it does not sting.

But here is what is also true.

You were working for people who had already given up on their product. The trajectory you were on was going nowhere. The ceiling in that company was coming down slowly, quarterly, in ways that got explained away in town halls.

Getting pushed out of that is an exit from a room that was getting smaller and smaller over time.

The thing that matters now is what you do with the tools in front of you. AI is not going anywhere. The capability is real. I built more things in the last two months than in the two years before them. Some were useful, some were experimental and some were pure jokes. All of them taught me something.

The knowledge you have took years to build. The context you carry about real problems in real businesses is something most people building products right now are guessing at.

Stop waiting for someone to hand you a roadmap. Build something, ship something small. Get your hands moving.

The people who come out of this period ahead treated the disruption as an opening. You got freed from a dead end. That is a brutal way for it to happen. It is still a door.

Final Thoughts

The data professionals who come out of this period ahead made a decision early. They looked at AI and asked what they could build with it. They did not wait for permission or for a company to hand them a strategy, but picked something and started.

The ones who struggled treated AI as a threat to manage. They watched the news cycle, worried about their job, hoped their company would figure it out.

WTF were those companies thinking? Honestly? A capability leap like this comes along once in a generation and the best move some leadership teams could come up with was a headcount reduction.

The tools are cheap and he knowledge you have is expensive to replicate. The gap between what a skilled person with AI can ship today versus two years ago is wide enough to build a product in, start a service on, grow a team around.

I am not special. I am just moving. If you start moving too, you will be surprised how fast the last few months start to feel like the best thing that happened to your career.

More on the Topic

• AI for Data Engineers

• What Charles Darwin Teaches You About Being A Kick-Ass DataOps Professional

• Data Engineers Are Becoming MetadataOps Engineers (And You Don’t Even Know It Yet)

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

See what people say about working with me.

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went!

Upgrade now

I’ve run hundreds of interviews over 16 years. When I ask “do you have any questions?“ and someone says no, I already know how this ends.

It’s not about the answers they gave. It’s about what that moment reveals: they came to survive the interview, not to think about the role.

The market is brutal. Hundreds of applicants per position. Everyone has the technical skills. The only thing left to separate yourself is how you think, and nothing shows that faster than the questions you ask.

At the senior level, the questions you ask are the interview.

The Market Is Brutal and That’s Exactly Why You Can’t Afford to Be Passive

The market is brutal right now. When I post about a new role, I get hundreds of applicants in just a few hours. Everyone has the technical skills, everyone has a decent CV, and everyone has prepared roughly the same answers to roughly the same questions.

So when everything else is equal, what decides it?

How you think. And nothing exposes that faster than what you ask.

A candidate who asks sharp, specific questions about the role signals something a polished answer never can: That you’ve already thought about the problems, the team, the constraints. You are not just trying to get hiredm but trying to figure out if this is worth their time.

That posture changes everything about how an interviewer perceives you. You stop being evaluated and start being considered.

Why Asking Questions Is Not Just Due Diligence

Most people treat the “do you have any questions?“ moment as a formality. You ask something polite, you show you’re interested, you wrap up. That’s the wrong way to think about it.

When you ask a sharp question, you stop being evaluated and start being considered. The interviewer shifts from “can this person do the job“ to “is this the kind of person we want making decisions here“. That is a completely different conversation.

The question you ask also tells the interviewer what you care about. Ask about tech stack and you signal you’re still thinking like a junior.

Ask about how data requests get prioritized and you signal you understand that the hardest part of a senior data role has nothing to do with the code. Ask about what happened to the last person in the role and you signal you’ve been around long enough to know that’s where the real story lives.

You ask questions to demonstrate you’ve already thought about the problems this role will throw at you before you’ve taken the job.

Here’s what to do:

Read more

Finance Year 2027 at my company starts in May. I always know company’s plans upfront. I thought FY26 was the same. By Q2 everything had shifted and what we called a roadmap was just a wishlist.

My team complained and I decided to change my tactic.

This year I grabbed my CPTO. Before any announcements, before any all-hands, before the business had even finalized anything. I asked what was coming, so I can take my team’s wishlist and map it against the company roadmap. That way we can build a plan that was realistic and OKRs we can actually hit.

The difference between a team that spends the year firefighting and a team that spends it delivering is just one conversation.

Every surprise project, urgent pivot, and “nobody told us” moment are your damn fault. That’s a business alignment problem, and it starts with you. Here’s what I mean.

The Drama Is the Point

There is a version of you that secretly enjoys the chaos. Think about it: The urgent Slack at 11pm, the all-hands pivot that wrecks your sprint, and he stakeholder who drops a critical request with a two-day deadline. You complain about all of it, and then you solve it anyway. And for a moment, you feel indispensable.

Reactivity performs well in the short term.

You look responsive, like someone who gets things done under pressure. Your manager sees you handling fires and assumes you’re good at your job. What they don’t see is that you lit half those fires yourself by skipping the data team planning conversations that would have changed everything.

The senior engineer who thrives in chaos is someone who never learned that prevention is harder to see but worth ten times more. Heroes get celebrated, so you keep choosing the version of the job that gets you noticed, even if it’s burning your team out.

Here’s what that costs you. Every urgent pivot your team absorbs without warning is two weeks of actual work gone. Retooling, re-scoping, re-explaining priorities to people who had different priorities yesterday.

Nobody tracks that cost. It just disappears into your team’s capacity and you fall behind on everything else.

Nobody Tells Anyone Anything

Here is the excuse I hear most:

The business doesn’t communicate with us. We find out about things last minute. We’re not in the meeting when decisions are made.

I’ve said versions of this myself. It’s true, but it’s also irrelevant.

PMs find out about things late. Finance gets surprised by headcount freezes. Sales hears about product changes from customers before internal announcements. Nobody in a fast-moving company has perfect information.

The difference is some functions treat that as a reason to push harder for clarity, and data teams treat it as a reason to complain.

Nobody owes you a seat at the planning table. Stakeholder alignment is not a gift. You earn it by showing up before the table is set. That means walking over to the PMs in April and asking what Q3 looks like.

It means grabbing your CPO before the roadmap is finalized and asking what bets the business is making. It means having those conversations when nothing is urgent, so you’re not having them when everything is.

The business will always move faster than it communicates. That is how companies work. Your job is to close that gap yourself, and not wait for someone to close it for you.

Every team that gets blindsided had months of opportunity to ask. But they didn’t, and when the surprise landed, they opened Slack and started typing about how chaotic everything is.

That’s your fucking choice. Own it!

Alignment Is Just a Conversation

I think data people overcomplicate this. They hear “alignment” and picture a formal process:

• A recurring meeting with an agenda.

• A shared OKR document that everyone updates religiously.

• A stakeholder map with color-coded relationship scores.

None of that is what I’m talking about.

Alignment is you walking over to your PM and asking “what’s keeping you up at night for the next quarter?”. That’s it. That’s the whole thing.

All you need is ten minutes and the willingness to ask a direct question before the pressure is on. Most data people never do it because it feels uncomfortable to show up without a specific ask.

But you’re not there to solve anything yet. You’re there to listen. That feels unproductive until the moment it saves your team three weeks of rework.

Do it early enough and you find out about the product release that was going to wreck your pipeline before it wrecks your pipeline. You find out the business is doubling down on a market segment your data model doesn’t support yet.

None of that information was secret and nobody was hiding it from you. But you never bothered to ask.

One business alignment conversation in March is worth more than any amount of sprint planning in September. By September the decisions are made, the timelines are set, and your team is already behind. In March you still have room to shape what’s coming.

Ask.

Final Thoughts

There is a ceiling reactive data professionals hit and never understand. They execute well, handle pressure, and solve hard problems fast. But they stay exactly where they are for years.

Because nobody above them sees a leader. They see someone who is very good at cleaning up messes.

The career cost is not the missed deadlines or burnt out team. It’s that you built a reputation for surviving chaos instead of preventing it. And that reputation follows you.

The people who move up are the ones who made their team predictable. The one who walked into planning conversations early. Those who stopped being surprised because they stopped waiting.

Every year you spend firefighting is a year you didn’t spend building that. Reputation compounds. The person known for calm, prepared delivery gets pulled into bigger problems. The person known for handling chaos gets handed more chaos.

You get to decide which one you are. But you have to decide in March, not in September when everything is already on fire.

Until next time,

Yordan

PS: Want to earn trust, respect and bigger budget for you and your data team? I have all the right playbooks in Premium Content Library.

Subscribe now

More on the Topic

• Your Stakeholder is Wrong (and it’s Your Fault)

• Crush Scope Creep: Data Engineer’s Blueprint for Bulletproof Data Product Plans

• The Signs Your Data Team Is Becoming a Cost Center