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

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

But before that, I have a huge news!

Clear Communication Works Like Clear Code

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

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

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

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

Replace Investigation Order With Decision Order

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

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

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

Put the Decision Before the Detail

Answer Four Questions

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

1. What changed?

2. Why does it matter now?

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

4. Which technical evidence supports that recommendation?

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

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

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

Give Technical Evidence Its Proper Place

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

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

Failure Updates Need Fewer Logs and More Control

Separate Impact From Cause

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

1. State the impact.

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

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

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

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

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

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

Put a Boundary Around Uncertainty

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

Subscribe now

Use the Pause to Think

A Pause Is Not a Failure

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

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

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

Name When You Will Return

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

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

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

Bigger Scope Follows Judgment Other People Can See

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

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

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

1. What changed?

2. Why does it matter now?

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

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

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

Final Thoughts

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

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

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

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

—

Until next time,

Yordan

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

More on the Topic

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

• Your Best Work Is Invisible Because You Describe It Wrong

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

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

• the trade-offs

• the rejected alternatives

• the stakeholder you talked out of a bad idea

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

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

The Resume Is a Weak Signal

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

The Interview Rewards Confidence

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

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

Internal Promotions Are Worse

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

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

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

You’ve Been Running on Vibes

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

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

Make the Judgment Visible

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

• the three alternatives you reject and why

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

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

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

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

The Decision Log Workbook

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

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

Final Thoughts

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

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

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

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

—

Until next time,

Yordan

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

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

book now

More on the Topic

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

• How To Stop Waiting For Permission To Lead Data Engineering

• Own it

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

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

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

The First Move: Stop Asking for a Review

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

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

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

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

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

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

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

The Engine: The Brag Document

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

This is why you need a Brag Document.

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

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

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

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

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

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

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

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

How Walt Won a 17% Raise

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

Walt stopped waiting.

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

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

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

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

Closing the Gap

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

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

The script is simple:

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

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

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

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

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

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

Final Thoughts

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

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

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

This risk is higher now than it has ever been.

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

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

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

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

unlock the guide now

—

Until next time,

Yordan

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

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

More on the Topic

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

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

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

Subscribe now

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

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

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

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

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

Playing Defense Caps You At Senior

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

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

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

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

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

Treat It Like You Actually Report To Both

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

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

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

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

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

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

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

The Weekly Habit That Makes It Work

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

The Four-Line Format

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

• Priorities this week

• Progress since last update

• Risks or blockers

• Time off or availability

The One Rule

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

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

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

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

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

upgrade now

Final Thoughts

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

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

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

Until next time,

Yordan

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

upgrade here

More on the Topic

• Where Your Data Team Sits Is a Strategic Decision

• The Operating System Every Data Engineering Leader Needs

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

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

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

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

Individual Updates Don’t Scale

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

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

The Fix Serge Told Me to Try

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

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

What Three Bullets a Week Actually Changed

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

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

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

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

Read more

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

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

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

Where Most Teams Fail

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

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

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

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

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

Daily Stand-Ups

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

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

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

1. Team bonding

2. Status update

3. Knowledge sharing

Team bonding

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

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

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

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

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

Status update

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

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

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

Knowledge sharing

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

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

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

This issue is brought to you by Cube.

Agents do the analysis. Your team does the thinking.

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

Get started for free

Pull Requests

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

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

Why do we open pull requests?

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

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

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

A good description needs at least three sections.

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

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

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

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

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

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

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

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

Micromanagement

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

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

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

• What’s your plan?

• Is it realistic?

• What’s actually blocking you?

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

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

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

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

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

Other Meetings

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

One-to-One

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

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

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

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

Retros

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

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

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

Brainstorming

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

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

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

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

Written Communication

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

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

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

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

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

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

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

BLUF

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

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

Overcommunication

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

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

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

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

Scoping docs

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

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

• Background

• Objective

• Stakeholder map

• Deliverables

• Risks

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

Postmortem reports

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

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

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

Anything that can go wrong will go wrong.

Read this article to get my incident report guide and template

SOPs

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

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

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

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

Focus Time

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

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

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

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

Stop phone notifications

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

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

The way I think about is this:

Stop computer notifications

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

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

Block time

Now about time management itself. The principle is simple:

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

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

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

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

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

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

Final Thoughts

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

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

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

—

Until next time,

Yordan

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

More on the Topic

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

• How I Apply The 5 SOLID Principles When Building Teams

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

Subscribe now

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

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

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

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

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

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

Here is how it works and how you do it.

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

This issue is brought to you by Cube.

Agents do the analysis. Your team does the thinking.

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

Get started for free

Single Responsibility Means Splitting The Work Before You Hire

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

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

I split them intentionally:

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

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

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

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

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

How You Do It

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

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

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

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

Clear boundaries fix that.

Open For Extension Means Your Team Grows Without Reorgs

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

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

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

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

How You Do It

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

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

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

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

Liskov Substitution Means Everyone Knows What Everyone Else Does

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

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

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

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

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

How You Do It

Read more

I built a live chat feature on MongoDB when the company already ran on MySQL for everything else.

I told myself it was the right call. Chat data is unstructured, MongoDB handles that better, and everyone on LinkedIn was writing about document stores as the future. I also had a quiet thought I never said out loud, that this would look good on my CV.

The founder sat on the desk next to mine. He asked why we needed to introduce a new piece of technology, and I gave him the technical answer when he wanted the business one. Over the next few months, he stopped asking my opinion on decisions he used to loop me into, and I earned that. I was building for what felt like the future, or what felt impressive, or what felt safe against some imaginary scale we were nowhere near, not for the business in front of me.

It took me years and a couple of good mentors to unlearn that habit. Once I did, the same instincts that picked MongoDB for the wrong reasons picked our move from Redshift to Snowflake, our shift from ETL to ELT, and the status page that ended our incident-question flood, for the right ones. That shift took me under four years from data engineer to head of data engineering. I have been writing strategy documents for close to a decade now, and the framework underneath all of them is simpler than anyone selling you a maturity model wants you to believe.

This issue is brought to you by Cube.

Agents do the analysis. Your team does the thinking.

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

Get started for free

What Everyone Calls a Data Strategy

Ask ten data teams what their strategy is and most will name a tool.

• “Our strategy is moving to Snowflake“

• “Our strategy is finally adopting AI“

• “Our strategy is switching to data mesh“

Those are purchases wearing a strategy costume, the same mistake I made with MongoDB when I picked a tool and backfilled a reason for it instead of starting from a reason and letting the tool follow.

This especially bites small and mid-sized teams. You don’t have the headcount or the runway to recover from a wrong bet the way a 10,000-person company can. Data Mesh proves the point: only 10% of companies under 50 employees adopt it, against 27% of large enterprises, while 43% of small teams centralize around a single warehouse compared to 29% of enterprises, per the 2026 State of Data Engineering Survey by . Small teams already apply real-gap thinking to architecture. The habit just hasn’t spread to every other tool decision yet.

Search “data strategy“ and you’ll find the same pattern from consultancies and platform vendors, long guides on maturity models and governance frameworks that confidently define what a data strategy is while skipping the five decisions that actually produce one.

What a Data Strategy Actually Is

A data strategy is the connection between where the company is going and the specific data infrastructure, pipelines, and capabilities you fund to get it there. It’s not a tool, and it’s not a slide of principles. It’s an answer, backed by a real price tag, to what data capability the business needs and how you’re closing the gap between that and what you can actually deliver today.

You get to that answer by working through five decisions, in order:

1. Where the company is actually going

2. What that growth demands from data specifically, in volume, speed, sources, and metrics

3. Where your current data infrastructure falls short of that demand today

4. The portfolio of data projects that closes the gap

5. The price of each project

Skip any one of the five and you get a tool decision masked as a strategy. I skipped the first step for years without realizing it.

Here’s how to build it step by step:

1. Where The Company Is Actually Going

Most engineers and tech leads don’t know where the company is headed in the next 12 to 24 months, and that’s not a personal failure. Nobody hands you that information by default, and most technical roles are structured so you never have to ask for it.

It’s your manager’s job to know this, or to go find out, since that’s part of what they’re paid for. If you don’t have this information, ask for it instead of guessing.

Bring this into your next 1:1: ask what the business needs to be true in 12 months, and what changes for the team if it happens. If your manager doesn’t have an answer, that’s useful information too. It tells you the gap starts above your team.

Don’t skip this step if you aim and building your data strategy at any capacity.

2. What That Growth Actually Demands From Data

This is where “what if we suddenly had 100,000 users“ belongs, and where I used to get it wrong. The instinct to plan for scale isn’t wrong, only pointed at a number you invented instead of one the business gave you.

A semantic layer is a good test case for how this is supposed to work. A year ago, teams argued over whether a standalone semantic layer was worth it for a small setup. Adoption has since tripled, from roughly 8% to 28%, and none of the data leaders tracked in the latest survey still question its value, per Hex’s State of Data Teams report. The debate ended because the demand became real: too many teams needed one place where a metric meant the same thing everywhere.

Once you have a real growth target from step one, translate it into what it demands from data:

• How much volume?

• How fast the data needs to move?

• Which new sources show up?

• Which metrics the business will start asking for that don’t exist yet?

Every one of those demands has to trace back to something the company actually said. Do not assume.

3. Where You Fall Short Today

This is the step where the founder lost trust in me. The gap between what I built and what the business needed wasn’t technical, since I was already a strong engineer. The real gap was that my decisions and the company’s needs had stopped lining up, and I couldn’t see it because I never checked.

Name your gaps against the real demands from step two, not against what feels outdated or what a blog post said was falling behind. A tool can be old and still be exactly right for the demand in front of you.

4. The Portfolio of Projects That Closes The Gap

A strategy is the full set of projects required to close every gap you named in step three, not one project picked on its own.

Small teams that get this right tend to converge on the same kind of tools. Dagster shows almost four times the adoption in companies under 50 employees, 11%, compared to large enterprises at 3%, not because it’s trendy, but because it fits the orchestration gap a small team actually has, low administrative overhead over more knobs to turn. Meanwhile, more than 20% of data professionals surveyed still run with no orchestration at all, per the 2026 State of Data Engineering Survey, which is usually a sign nobody has walked through steps one to three yet.

This is what it looked like for me once I started doing this the right way:

• Redshift to Snowflake, because concurrent query demand from a growing analytics team was hitting a real ceiling, not because Snowflake was trending

• ETL to ELT, because the business needed raw data available faster than our transform layer could keep up with

• The status page, because stakeholder trust was breaking down over incident visibility, the same kind of trust I’d already lost once with the founder

Each project closes a named gap, not a line I wanted on my résumé.

5. The Price of Each Project

This is the step that turns a strategy into a plan, because every project on your list competes with every other project for the same headcount and the same hours.

The ELT migration cost us months of both engineers’ full attention, the entire data team at the time, and for a while it was the only thing getting worked on. There was nobody else to pick up anything else, so everything else waited, including things I wanted to build. That was the right trade, because the demand it closed mattered more than what it delayed. But it was still a real cost, and pretending otherwise would have made the next prioritization conversation dishonest.

Name the price before you commit:

• Budget

• Headcount

• Time

• What you deprioritize to fund it

If you can’t name what you’re giving up, you haven’t actually decided anything yet. Small and mid-sized businesses that adopted cloud computing and modern data infrastructure saw 19% higher turnover per worker, even after controlling for company size, per GOV.UK’s Business Data Use and Productivity Study. That’s the return on doing the work instead of buying the tool that looks good on a slide.

I turned this exact five-step framework into a worksheet, one section for each step above, so you can run your own team’s data through it instead of mine. Grab the worksheet here and fill it in against a real goal your company has right now, not a hypothetical one.

Get the strategy worksheet

Why Maturity Models Are Useless for Most of Us

Every top-ranking article on “data strategy“ leans on the same shape, a maturity model with four or five pillars, usually governance, architecture, people, and technology, each staffed by a dedicated owner and reviewed on its own cadence. McKinsey and Gartner built this model for a client with two hundred people in the data org and a budget line for each pillar, but this is is rarely the case for data teams in 2026.

If you’re running a team of two, or five, or even fifteen, data strategy is something completely different. You have no governance lead, no architecture review board, and no spare headcount, only you, maybe one other engineer, and a backlog that never gets shorter. Running a four-pillar maturity model on a team that size spends a whole quarter drawing a framework nobody on the team has the headcount to staff, instead of adding any real rigor.

Most of that content is bullshit for a team our size. The five decisions in this article are what’s actually left once you strip away every part of the enterprise version that assumes resources you don’t have.

Final Thoughts

A lot of data leaders fall for this at scale, not only individual engineers. The share naming AI their #1 priority jumped from 4% to 27% in six months, per Hex’s State of Data Teams report, and for plenty of them, AI became the strategy by default, a company-wide bet made because of the hype, not because anyone ran it through five decisions.

I’d guess an equal number work inside companies making that exact bet and recognize it for what it is. Experienced data leaders treat the mandate as the demand in step two, not something to fight, and build the actual gap-closing projects underneath it, the four decisions the company skipped, for their own team.

After seeing the this kid of tool-driven strategy many times in the past, and even making the same mistake myself, I find this “spray and pray” approach ridiculous. Obviously, you can get lucky, but luck is not enough when you are trying to build long-term career and business.

That said, I strongly encourage you to use AI and build AI-powered projects. There’s is value in this, but you need to avoid putting all your eggs in the same basket. At the end of the day, your job only matter for the business if you help it make more money, save costs or avoid risks.

—

Until next time,

Yordan

PS: Want to learn how to think and behave like a leader and actually deserve your promotion? Upgrade today.

More on the Topic

• Strategy-first tooling

• How to Think Holistically About the Data Ecosystem

• The Signs Your Data Team Is Becoming a Cost Center

Subscribe now

And still, he opened our session with a fear I hear from experienced engineers every single week.

If I don’t move beyond this, I won’t find myself anywhere.

Hari wants machine learning and AI skills before those tools make his job obsolete. This article walks through how I coached him from that vague fear to a concrete action he started within one hour of the call. Steal the process, because it works on any career goal and you need no coach to run it.

Interrogate the Fear Behind the Goal

When Hari named his goal, I played back what I heard before touching any plan.

You’re a strong engineer, you’re praised, and yet I hear a fear of becoming obsolete because of AI.

He confirmed it. The buzz says move to AI or lose your job, and he reads that buzz daily on LinkedIn.

So I pushed on the goal itself:

• Do you want this because the work pulls you, or because you believe organizations demand it?

• What happens if your company decides tomorrow that they no longer want ML engineers?

A goal built on someone else’s noise collapses the moment the noise changes direction.

Hari’s honest answer moved the whole session forward. He wants to shift from reactive work to predictive work, and he wants to show the business things nobody asked about yet. Fear was the trigger, but underneath it sat genuine curiosity, and curiosity survives obstacles far better than fear does.

Before you plan any skill jump, write down your reason and read it back. If the reason quotes the internet instead of you, keep digging until it quotes you.

The Four Jobs Hiding Inside “Learn AI”

Most people who say they want AI skills have never separated the jobs behind that phrase. I gave Hari four lenses, and the one you pick changes everything downstream.

• MLOps engineer. You deploy what others build. CI/CD, resources, servers. You live between infrastructure and machine learning.

• AI engineer. You build applications with AI. Hari’s three-day Streamlit dashboard, built with Claude, is this lens in action.

• Machine learning engineer. You build models. You spend weeks, sometimes months, perfecting something that predicts churn, device failure, or a financial forecast. Deep, slow, less flashy work than the hype suggests.

• Data platform engineer. You build the platform where models learn and pipelines run. My team currently works through this lens on a project that reads conversational data and surfaces what customers complain about.

These are different jobs with different daily work, and a plan aimed at all four hits none of them. Hari picked prediction. He wants forward-looking models built on business data he already understands, which meant we finally had something specific enough to plan.

Walk the Goal Backward With 5-4-3-2-1

Big goals fail for a predictable reason. The picture is vague, the plan is huge, and nobody knows what to do today, so nothing happens. I borrowed a fix from a journaling book years ago, and I still use it for myself. The 5-4-3-2-1 cascade walks one goal backward through five horizons, from five years out to the next sixty minutes, and every level produces one specific commitment that supports the level above it.

This is how it goas

Read more

This is not how you lead a team. You got the title, but are still thinking and acting like a senior engineer, who gets paid more.

I was harsh, but Nikol needed to hear this.

She came to me asking why her manager, and her own team, do not like working with her. I heard her side of the story, and my answer was instant.

I was harsh, but Nikol needed to hear this.

She came to me asking why her manager, and her own team, do not like working with her. I heard her side of the story, and my answer was instant.

I have seen this exact pattern too many times. I lived it myself.

How The Trap Sets In

You are the best engineer on the team. Every hard task goes to you, and nothing feels impossible with enough time. You help the junior engineers get unstuck before they even ask their manager.

So you get promoted. Not because anyone taught you how to lead, but because you are clearly the strongest engineer in the room, and the company had to put that title somewhere.

You don’t get any handover, training or mentor.

Everybody expects you to figure it out, because obviously you are the best engineer they have.

And while we are on the topic, bookmark Your First 60 Days as a Data Engineering Lead. I did this for leads who are never going to get a mentor handed to them.

The Promotion Changes The Job

Suddenly you own every project timeline on the team. You inherit:

• roadmap conversations

• headcount requests

• standups you used to sit through half listening

You join stakeholder meetings and one to ones that used to belong to someone else. And underneath all of it, you are still trying to do the engineering work you did before, because that is where the real output is.

Nikol told me she was still reviewing every pull request on the team personally, the same way she did as a senior engineer.

I used to do the same. When a project slipped, the instinct kicked in, I got nervous, and made a comment about someone’s code quality or their speed, in front of everyone, in the standup.

Then I took the ticket back and finished it myself, faster than they would have.

That feels like leadership, but isn’t.

What This Looks Like Week To Week

It rarely looks dramatic from the outside. It looks like a string of small decisions that add up.

• You rewrite a teammate’s PR instead of leaving a comment explaining what to change

• You pull the ambiguous stakeholder request into your own inbox instead of pushing your team to scope it themselves

• You stay the on call escalation point months after you should have handed it off

• You measure a good week by how much you personally shipped, not by whether your team unblocked itself without you

Together, they tell your team you don’t trust them with the job you were supposedly promoted away from.

From Engineer To Operator

As an engineer, your output is your code, but as an operator, your output is your team’s code, and most of your day goes into things that do not look like work: conversations, decisions, unblocking, and deciding what not to build.

The instinct that made you a great engineer, write more, ship more, prove it yourself, is the instinct that now holds your team back. Here is what actually has to change, one reflex at a time.

Your Output Stops Being Your Own Work

The fastest way to check where you actually are: look at last week’s calendar. If most of it happened inside a codebase and not inside a conversation, you are still operating like an engineer with a bigger title.

The new measure is not how much you personally shipped. It is whether the work landed, whether your team is better than it was last quarter, and whether your manager can stop checking on your project without you noticing.

Stop Being The First Responder

You are the fastest debugger on the team, so you jump in and fix most incidents before anyone else even opens the alert.

That instinct solves the incident once. It also teaches your team to wait for you every single time, because you keep proving that waiting is faster than trying.

Nikol was the fastest responder on every incident her team had. That is not why her team resented her, but was one of the reasons nobody else on the team ever got faster.

Stop Translating Requests Into Tickets Yourself

A stakeholder asks for something vague, and you are the person who turns it into a scoped, technical ask in five minutes.

This is not your job anymore.

Every time you do the translation yourself, your team gets instructions instead of context. They stay one layer removed from the actual business problem, and you become the one person who cannot take a vacation without something breaking.

Sit in the stakeholder meeting. Let a senior engineer take the first pass at scoping the request. Correct it after, not before.

My team hates this, because this actually requires more effort than writing code. But this is how they grow.

Stop Avoiding The Conversation

Nikol never told her team their scope was wrong or their pace was too slow. She took the ticket back and fixed it herself, every time it happened.

The conversation is uncomfortable exactly once. Doing the work quietly and resenting your team for needing you to repeats every single sprint.

I recently read a post by asking if you can be a good manager if you hate conflict. An yes, you absolutely can. But you can’t avoid it.

As a leader you can’t avoid hard conversations. Not with stakeholders, not with your manager, and definitely not with team members. You are getting paid to have these conversations.

The more you avoid them, the deeper problems get. Bu do it with respect.

What Actually Makes You Effective Now

Here is the part that took me the longest to accept. The more senior you get as a leader, the less your technical skill is the thing carrying you.

At some point the job stops rewarding the person who solves the hardest technical problem personally, and starts rewarding the person whose team solves problems without them.

This is a completely different job.

Nikol is still leading with the one skill she trusts, because nobody told her the other skill exists. Nobody told her that her team was slow because she had never once told them, directly, what she actually needed from them.

What Making The Shift Actually Looks Like

The next time a project slips, do not open the ticket.

Ask what got in the way, not to assign blame, but to find the actual blocker. It might be unclear scope, a missing dependency, or a skill gap you can now train for instead of working around.

Then say the thing you were avoiding. Something close to:

I expected this by Thursday. It is Monday and it is not done. Walk me through what happened.

That sentence takes ten seconds, and does more for your team than three hours of rewriting their code ever will.

The Operator Audit

Nikol did not fix this in the one conversation where I called it out. This change doesn’t happen overnight. But in the 2 months we worked together she got significantly better. She has the tools to deal with it now.

Here are the five points Nikol and I were working on. Run this audit occasionally and go wild. Score yourself if needed.

1. Your output

Did you write code this week to prove a point, not because nobody else could do it?

Before you open your IDE (I use neovim, btw), ask whether a teammate could do the task with the right context. If yes, give them the context instead of doing it yourself.

2. First responder

Were you the first person on the last incident, even when someone else was on call?

Next time, wait ten minutes before touching anything. Let the on-call engineer make the first move. Step in only if they ask.

3. Translating requests

Did you personally turn a vague stakeholder ask into a scoped ticket?

Next request, bring a senior engineer into the conversation and let them draft the first pass of the scope. Correct it after, not before.

4. Avoiding the conversation

Did you skip a hard conversation and hope the problem would resolve itself?

Book fifteen minutes this week with the person whose work you have been quietly redoing. Name the specific gap you have noticed. Ask what is actually blocking them.

5. Measuring effectiveness

Do you know if your team is better this quarter than last, without checking their commit history?

Write down one thing your team now does without you that they could not do three months ago. If you cannot name one, that is this month’s actual project.

Answer honestly on all five. Then pick one action and do it this week. Not all five. One.

—

Until next time,

Yordan

PS: Reading about the operator shift is free, but the guides, scripts, and frameworks that make it happen live in the paid tier.

PPS: If you are living Nikol’s exact situation right now, that is what coaching is for. Book a call and let’s build your plan instead of guessing your way through it.

Let’s Connect

Connect on LinkedIn: https://www.linkedin.com/in/ivanovyordan

Work with me: https://www.ivanovyordan.com/coaching

Start journaling: https://www.dearself.ai

More on the Topic

• Why Senior Data Engineers Lose Their Velocity

• Two Ways to Disagree With Your Lead But Only One Is Right

• How To Stop Waiting For Permission To Lead

Most data professionals I talk to work incredibly hard at their craft. They go deep on Python, on dbt, on Spark, on whatever the stack is.

They take courses, they build side projects, they read documentation on weekends. And then they watch someone else get promoted. Someone who, honestly, is probably less technically sharp than them.

Introducing David Langer

Dave Langer has been in technology for almost 30 years. He started on the help desk, wrote COBOL on a mainframe at an insurance company, moved into software engineering, and lived through the dot-com crash in the early 2000s.

The last 15 of those years have been in analytics, starting with traditional BI and data warehousing, Kimball star schemas, the whole thing, and then moving into more advanced analytics.

Dave worked at Microsoft leading a data and analytics team, then at a startup called Schedulicity as VP of Analytics, and at Data Science Dojo. He is a Microsoft Excel MVP, not for writing formulas, but for evangelizing Python inside Excel, which he got early NDA access to in 2023.

David wrote a book on Python and Excel published this year, and his second book on SQL for Excel users is coming in 2027.

These days Dave is an independent consultant and trainer. He runs a Substack called The DIY Data Scientist, which is exactly what it says: practical tutorials on data analysis for professionals who want to use data better, regardless of their background.

We had a live conversation, and this is everything worth taking from it.

The Value Ladder Is Not What You Think It Is

Every organization has a value ladder. A rough hierarchy of what it perceives as worth paying for, promoting people for, and building strategy around.

The problem is that your version of the value ladder and your organization’s version are often completely different things.

When you are early in your career, this does not matter much. You are rewarded for technical output:

• Write good code.

• Ship clean pipelines.

• Produce accurate models.

That is the ladder, and being technically excellent gets you up it.

But at some point the ladder changes. And nobody tells you.

What the organization starts rewarding is perceived strategic value.

That could mean designing systems instead of building them. It could mean being able to translate between the data team and the C-suite. It could mean understanding enough about the business to push back on a requirement intelligently, not just implement it.

If you keep climbing the old ladder while the organization has already moved to a new one, you plateau. Only because you are solving for the wrong problem.

Subscribe now

The Outsourcing Lesson

Think about what happened to a lot of senior engineers in the early 2000s. They had gone deep on C++ (Qt will stay in my heart forever), and read all the right books, so they could architect complex object-oriented systems.

And then globalization happened, and suddenly all of that specialized knowledge became a commodity. You could hire it for a fraction of the cost from an outsourcing firm.

The people who survived that shift asked: what is the value ladder actually rewarding right now? And the answer was architecture, system design, coordination, the things that required judgment and organizational context. Not just technical execution.

The same question applies to you today. Not “how do I get better at this tool?“ but “what is my organization actually paying for?“

If you want a concrete way to map where you actually sit on your organization’s value ladder, that is exactly what the Career Progression Matrix in the premium library does. Paid subscribers get access to it on day one. Upgrade here.

Data Problems Are Not Technology Problems

Here is what nobody told me early in my career:

The hardest part of working in data is not the data itself, but people

If you’ve been in data long enough, you’ve probably been in meetings about the definition of a customer for way too longs. And all of that, just because four departments each had a different answer, and each answer made a different executive look better or worse.

This is what senior data professionals figure out. And it is what a lot of talented junior and mid-level people never fully internalize.

If your goal is to do technically excellent work in a well-scoped problem, you can stay in your lane and deliver. That is a legitimate career.

But if you want to actually drive decisions, if you want your work to change how an organization operates, you are going to spend a significant amount of your time as a mediator.

• Between engineering and business.

• Between what the data says and what someone wants the data to say.

• Between this year’s urgent request and the foundational investment that would make next year’s requests 10x easier to answer.

The people who succeed in that space are not always the most technically gifted. But they are always the ones who learned to sit in an uncomfortable call, name the real disagreement out loud, and not flinch when someone gets defensive.

Why Teaching Is a Career Asset

One of the underrated ways to build this skill is to teach.

Not necessarily a course or YouTube tutorial. Just the act of explaining complex technical concepts to someone who does not share your context.

It forces you to leave your own head and think from the other person’s perspective. You cannot fall back on jargon. You have to find the analogy that lands for this specific person, not the definition that would satisfy a technical reviewer.

That skill transfers directly to stakeholder work. Every time you explain a data model to a VP, every time you scope a request with a product manager who is not sure what they are asking for, every time you push back on a dashboard request by asking “what decision are you trying to make?“ you are doing the same cognitive work.

Data professionals who build that muscle early tend to accelerate later. The ones who skip it hit a ceiling.

Show & Tell is where I work through exactly this kind of thing live. One paid subscriber brings a real situation, and we work through it together in front of the group. Every session is recorded, and included in a paid subscription. Join here.

Executives Are Running the Same Hype Cycle Again

A few years ago, the mandate was “we need to be data-driven“. Companies hired data teams, built dashboards, set up data warehouses. Most of them never actually became data-driven. But “data-driven“ was the thing, so they built it anyway.

Now the mandate is “we need to be AI-first“.

The structure is identical:

• An executive reads something.

• The pressure cascades down.

• Someone, often the data team, gets handed the brief: implement AI.

The business problem that AI is supposed to solve is treated as secondary. Sometimes it is not even identified.

I have seen a company run a churn model comparison: a basic logistic regression built by a data scientist, versus an LLM-based approach. The logistic regression hit 80% accuracy. The LLM hit 50%, which is coin-flip territory. The traditional model also cost a fraction as much to build and run.

And that is before you account for what happens when AI pricing moves from flat subscription to usage-based. When your CFO is looking at a bill where the token cost exceeds the salary of the team that could have built a simpler model, the conversation changes fast.

Most organizations are not thinking about this right now. They are still in the “we need an AI use case“ phase. The ROI calculation comes later, usually painfully.

The Hadoop Lesson Is Already Written

During the Hadoop hype cycle, an executive asked Dave whether the company could move their SQL Server databases to run on top of Hadoop instead of fast disks. Because Hadoop storage was cheaper. The executive had read about it in a trade magazine.

The answer was no. Obviously. But the fact that the question was asked at all tells you something about how technology hype filters through organizations.

It’s all about the anxiety of not being part of the trend.

• MongoDB was supposed to kill relational databases.

• Excel has been declared dead every year for 20 years.

• SQL was going to be replaced by query builders.

None of that happened.

Some things change. Programming languages come and go. Platforms rise and fall. But the underlying problems stay the same: organizations need to make better decisions using data.

The data needs to be clean, structured, and understandable. The people consuming it need context.

The Two Questions Worth Asking

Here is what I would take from all of this.

First, be honest about your organization’s value ladder. Not the one you wish existed, but the one that actually exists.

• What gets people promoted here?

• What gets people noticed by leadership?

• Is it technical depth, or is it business impact, or is it visibility, or is it the ability to manage up

Because the answer changes your strategy.

Second, ask whether that ladder aligns with what you are actually trying to build. If it does, optimize hard for it. If it does not, that is useful information too. The organization where the ladder aligns with your goals exists. Sometimes you have to find it.

The data professionals who stall out tend to do one of two things: they optimize for a ladder that their organization does not value, or they assume the ladder they are on right now is the one they will always be on.

Neither is true.

Find More From Dave

Dave’s Substack is The DIY Data Scientist. Every issue is a hands-on tutorial with workbooks, code, and data included, free. If you work with data in any capacity and want to actually understand what you are doing with it, it is worth subscribing.

He is also active on LinkedIn, where his content leans more toward the enterprise and organizational side of analytics.

His book, Python for Excel, is available on Amazon and in Barnes & Noble stores.

—

Until next time,

Yordan

PS: Paid subscribers get the Career Progression Matrix, the full Show & Tell archive, and the entire premium resource library. Upgrade here.

PPS: The next Show & Tell session is coming up. A paid subscriber and I will be working on a long on a long therm-career plan. Join here.

Let’s Connect

Connect on LinkedIn: https://www.linkedin.com/in/ivanovyordan

Work with me: https://www.ivanovyordan.com/coaching

Start journaling: https://www.dearself.ai

More on the Topic

• The Other Half Of The Job

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

• Your Best Work Is Invisible Because You Describe It Wrong

If you’ve been in data for a while, something feels different now.

The job you spent years getting good at has quietly changed around you. Everything is different, now. Not just tools and pacing. What leadership expects from you barely resembles the job description you, barely resembles the job you signed for.

You are watching a job you love change in front of you, without feeling ready for what it’s becoming.

Here’s what I think is happening, and why most of what you’re reading about it is making it worse.

What’s your leadership experience

The Truth About AI in Data

You know how the famous saying goes.

AI is like teenage sex. Everybody talks about it. Everybody thinks everybody else is doing it. Nobody really knows how to do it. And if you are actually engaged in it, you do it really badly.

You just need to open LinkedIn, or read any of the big data engineering blogs, and you’d think you’re dangerously late. You’d think every other company already has autonomous agents in production, a fully deployed semantic layer, and AI-generated pipelines shipping while the team goes for coffee.

So you shift roadmap, add a tool or two for evaluation, and somebody ships a workflow nobody asked for against a deadline nobody set. When it goes badly, nobody understands why, because the whole thing is about catching up to a benchmark that doesn’t even exist.

And you know what? Nobody is ready for this. Everybody is doing stupid shit and calling it strategy.

Companies used to have one goal: make more money. This goal is tangible and measurable. You knew if you were winning. Now the goal is “adopt AI“. And when you cannot define success, you cannot recognize failure either.

This issue is brought to you by Cube.

The best way to support me and this Newsletter is to check out the Sponsor below and click the link.

Cube Is the AI-Native BI Platform for Your Databricks Lakehouse

Cube is the agentic analytics platform for teams on Databricks. One platform for internal BI, embedded analytics inside your product, and an AI Analyst that answers questions in plain English.

All of it runs on a governed semantic layer, so a metric defined once means the same thing in a dashboard, a customer-facing app, and an AI query. Databricks holds your data. Cube is what your team, your customers, and your agents actually ask.

The Cube team is running a free 45-minute webinar on June 30 (1:00 PM ET / 10:00 AM PT) with a live demo connecting Cube to Databricks and exploring the same governed metrics through a dashboard, an embedded app, and the AI Analyst.

If you’re on Databricks and deciding what to standardize on, this is the session to watch.

Register free for the webinar

What the Race Produces

Data democratization

Every platform now enables agentic workflows. And since building is trivially easy, everyone builds their own thing. Your CEO probably has a workflow that pulls data from your BI tool. And your head of finance has one pulling from a different source, with a different definition of the same metric.

Call it democratization if you want. To me that’s decision surface area with no shared truth underneath it.

Give people access without defining what the metrics mean, and your org starts running on wrong numbers. At some point everyone’s dashboard shows something, and something feels like progress.

Don’t get me wrong, this problem existed forever. Now, it’s just appears at scale.

Staling innovation

There’s a deeper problem though, and this one bothers me more.

AI learns from existing code. It reproduces what the industry already built. AI can’t invent what nobody has built yet.

Things like DuckDB, Polars and Arrow came from people doing non-consensus work. A model trained on yesterday’s patterns would never be able to produce these.

If you outsource thinking to AI, the field converges. You get well-executed mediocrity, forever. I don’t think enough people are saying that out loud.

One thing that held though is code. Whatever AI generates, you can read, version, and test. The craft is the same.

Subscribe now

The Mess Is Your Backlog

Here’s what I’m watching happen.

The more carelessly people adopt AI, the more broken processes pile up. All these AI-generated assets that I told you a second ago are the natural output of an industry that moved fast without thinking.

And they are your backlog. Try this process just once:

1. Go talk to someone who isn’t on the data team.

2. Find the process that makes them want to throw their laptop.

3. Ask what they’re doing with AI and watch what happens.

I find something worth fixing almost every week.

And you know what? The more people use AI carelessly, the more stupid shit piles up for someone like you to fix.

The Raise Of Governance

That’s also why governance matters more right now than it has in years. Keeping your org from drowning in wrong numbers is the work.

Semantic layers used to feel like a gimmick to me. A nice idea that never justified the overhead.

I’ve changed my thinking on that. When your CEO, your CFO, and your VP of Product are each pulling “revenue“ from three different sources, a semantic layer is the only thing that gives you a shared definition both humans and machines use.

One source of truth that doesn’t depend on who built the dashboard.

I’m working on a project that helps us solve this in my org, and I’ll post a proper write-up when I have results.

Final Thoughts

I don’t know where this is going. Nobody does, and I’m skeptical of anyone who says otherwise. But I’m not worried, and I don’t think you should be either.

I believe you are fine as long as you stay current, solve real problems and skip the hype.

Every new type of work has something interesting in it if you go looking, and the people who adapt are always the ones who go looking. The job title might change, and the tools will definitely change. But the skill of finding a real problem and fixing it doesn’t go anywhere.

If this whole thing goes sideways, I’m genuinely good at building, electricity, and plumbing, although that last one is not my favorite. That was never the plan, but it’s a real option in case of disaster.

—

Until next time,

Yordan

PS: If you’re an experienced engineer trying to figure out the next move, the premium library is where I put everything on navigating the leadership ceiling, stakeholder politics, and getting paid what you’re worth. Chek it here.

PPS: If you’re figuring out your next move, a promotion, a raise, or what your career actually looks like in this market, I do one-on-one coaching with data people. Learn more when you are ready.

Let’s Connect

Connect on LinkedIn: https://www.linkedin.com/in/ivanovyordan

Work with me: https://www.ivanovyordan.com/coaching

Start journaling: https://www.dearself.ai

More on the Topic

• Intro to MetadataOps with Alejandro Aboy

• Why projects die

• Self-Service BI Is a Lie: 3 Problems You Can Resolve Today And Improve It

Every time something breaks in our data platform, somebody posts an announcement in the 6 Slack channel. Every single time, we get the same questions:

• “Is the Bookings dashboard affected?“

• “What about the ML report?“

• “Are the numbers in the product usage report going to be wrong?“

Three to five variations of the same question, from different people, about different things, all asking me to do the work they should do themselves.

Not that the announcements are unclear about what’s wrong, but we can’t list everything that’s fine. So they do the only thing available to them and asked.

And that’s only a part of the story. When a failure happens at the ingestion layer, we do not always know immediately what downstream data it affects. The lineage from a broken pipeline to a broken dashboard is not always obvious without the right tooling.

I decided to fix both at once. What I built is a data platform status page. The result was zero questions per incident. It has been that way since we launched it.

Here’s how you can do the same.

Data Teams Love the Word “Product” But Rarely Treat Their Platforms Like One

The data community has spent years arguing that data should be treated as a product. We now have data product managers, data product roadmaps, data product thinking and what not.

The common understanding is that data teams should operate with the same rigor, user focus, and accountability as software product teams.

And then those same teams don’t even post a Slack message when something breaks.

Every SaaS product you use has a status page. When something goes wrong with Stripe or GitHub or Claude (yesterday anybody?), there is a single place you go to see what is affected, what the team is doing about it, and how long the incident has been running.

You do not send a message to the Dear Self support team (that’s just me) asking if your journal processing is working. You go to status.dearself.ai.

Data teams do not do this.

They:

• sometimes announce incidents in Slack

• generate a thread of panicked questions

• answer those questions individually

and repeat the process next time.

The data as a product positioning is real in the planning meetings, but always disappears the moment something breaks.

The gap is in mindset, and the tooling to close it has been available for years.

Status pages are a basic operational practice that product teams figured out long ago, and somehow you don’t have them for your data “products”.

What You Need to Build This

If you’re running a modern data stack, you likely have most of the pieces already. Here’s what our setup looks like:

• An ELT process that lands raw data in the warehouse with a schema that mirrors the source. Everything in the lineage graph starts here.

• Two dbt repositories. One handles data engineering transformations. The other handles business-level transformations. This is has nothing to to d

• A data observability tool with column-level lineage. We use SYNQ. Without column-level lineage, the question “what downstream assets does this failure affect?” has no reliable answer.

• A BI tool. We use Omni. The specific tool matters less than whether it exposes an API.

And a few notes on that.

First, the process obviously works with ETL, but it’s slightly easier with ELT. We switched to ELT long ago, and our reasons may not be true for you. Don’t change your process if it works well.

Second, you absolutely don’t need 2 dbt projects. I decided to keep them separate, so I don’t mix skills, standards and workflows for our 2 subteams, DataOps and BI.

Last, but not least, you don’t need SYNQ specifically. Any observability or cataloging tool with column-level lineage works:

• Elementary is a solid open-source option.

• OpenLineage works if you’re building from scratch.

The principle is the same: you need a system that knows how data moves from source to consumption layer and exposes that through an API.

The Mapping Problem (And How AI Solved the Boring Part)

And here’s what makes this harder than it looks. SQNQ knows plan_id in the accounts table flows through some transformation int the bookings model. But it doesn’t know is which dashboard tile queries bookings.

Without that mapping, the status page tells stakeholders a dbt model failed and nothing about whether their report is affected.

SYNQ doesn’t support Omni out of the box. So we built the bridge. I wrote a script that:

• pulls a selected set of official dashboards from Omni’s API

• extracts every tile in those dashboards

• retrieves the query each tile executes

That gives us a map between Omni tiles and the underlying dbt models. Combined with SYNQ’s lineage graph, we trace a failure at the ingestion layer all the way through to specific dashboard tiles and surface exactly which reports are affected.

How an Incident Works

When a test fails or a pipeline breaks, we get a notification. So we run a quick triage: is this a real incident affecting stakeholders, or a transient failure we resolve quickly and silently? If it’s real, we go to SYNQ and declare an incident.

That declaration triggers a Slack notification to the channel. The notification includes a link to the status page, where stakeholders see exactly which data products and reports are affected. They don’t need to ask. The answer is already there.

As we work through the incident, we add comments and updates directly in SYNQ. Each comment triggers another Slack notification. Stakeholders get a running update without anyone on the team writing a separate message or copying the same information across threads.

Stakeholders follow the link, see the state of their data, and go back to their work.

What the Status Page Shows

The page is structured around data products, instead of incidents. The whole point is to give them access to something user-friendly that’s structured around how they think about data.

Here’s what they see:

• Selected data products. These are groups of dashboards. They have no idea about tables or pipelines.

• Reports per product. A list of reports associated with each data product.

• Current status, which we pull in real time from SYNQ.

• Status history showing the track record over time.

• Individual incident detail pages, including affected reports and a full timeline of updates.

Scoping the page to the products stakeholders care about is what makes it useful. Everything else would be noise.

The page has no database. It makes API calls to SYNQ at request time and renders the current state. Less infrastructure to maintain, and nothing to keep in sync.

Why Showing Failures Builds More Trust Than Hiding Them

The instinct when something breaks is to fix it quietly and move on. You might post a minimal announcement, keep the details sparse, resolve it fast, and say as little as possible.

I know that every incident announcement feels like an admission, and the more you say, the worse it looks.

That instinct is backwards.

Stakeholders lose trust when the team goes quiet during an incident and offers nothing useful until it’s resolved. The team that declares incidents publicly, posts running updates, maintains a visible history, and posts postmortem reports earns a different kind of reputation.

When a random manager raises data reliability as a concern, most data leads respond defensively. They explain the complexity, list the improvements they’re making, and leave the room without having changed anyone’s mind.

With a status page and twelve months of history, the conversation is very different. You pull it up, and show incident count, average resolution time, and trend. The conversation moves from subjective complaint to documented fact, and the documented fact works in your favor.

The status history is the part people underestimate. When you have a year of publicly visible incidents with response times and resolution notes, nobody tells you the data is always broken.

There’s also a simpler mechanism at work. When stakeholders know you’ll tell them when something goes wrong, they stop checking.

They stop asking “is this dashboard up to date?“ as a routine question, because they know that if it weren’t, they’d have heard from you.

That baseline confidence is worth more than any data quality initiative or SLA document you write. A status page operationalizes it so it happens automatically, every time, without anyone on the team having to think about it.

Data teams that earn strategic partnerships with the business are the ones whose stakeholders trust they’ll hear about problems before they have to ask.

Final Thoughts

None of that code was written by me. I read the API documentation for both tools, described what I needed, and handed it to an AI coding tool. The status page, the mapping script, the full integration. The whole project was complete in a matter of days.

The truth is that you don’t need to be a strong engineer to build this.

You need to recognize the problem, read some documentation, and spend a couple of days on it.

Every senior data professional has the ability to make this kind of impact. Most haven’t built it because they’ve never thought to look at what software product teams do and ask what they’re missing.

The skill here was identifying the gap.

AI allows you to go give life to your ideas faster than ever.

—

Until next time,

Yordan

Subscribe to Data Gibberish: https://www.datagibberish.com

Connect on LinkedIn: https://www.linkedin.com/in/ivanovyordan

Work with me: https://www.ivanovyordan.com/coaching

Start journaling: https://www.dearself.ai

PS: Paid subscribers get monthly Show & Tell sessions where you bring a real career, leadership or stakeholder problem and we work through it live together. Upgrade here, when you are ready.

PPS: Also, remember to check my Premium Content Library here.

More on the Topic

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

• Bad news

• Your Best Work Is Invisible Because You Describe It Wrong

You are better at filtering other people’s ideas than your own.

When a stakeholder comes to you with a request, you slow down. You ask what decision this changes, who will use it, what happens if you don’t build it. Most requests don’t survive those questions. You know this. It’s part of the job.

But when the idea is yours, something shifts. The filter goes quiet.

• The shiny new initiative you want to take but that would pull you away from the work that matters.

• The cross-functional opportunity that flatters your ego but doesn’t serve your team.

• The tool you want to introduce but won’t help.

• The migration that’s interesting to do but doesn’t move anything.

• The architectural rewrite that’s been sitting in your brain for two years.

These feel different because they’re yours. You built the case in your head. You refined the idea in isolation, without the friction of someone else needing to fund it, sponsor it, or use it. That’s the problem.

Your Ideas Deserve the Same Scrutiny

The same questions you ask the head of sales when they come to you with a request apply to your own backlog. “What decision does this change? Who’ll use it? What happens if we don’t?“ Most of your ideas won’t survive the filter either.

The filter needs to start earlier than the idea itself.

I run bi-weekly calls with a few selected people across the org. My jov in those calls is to listen. They tell me about their plans and frustrations, what’s slowing them down, what they’re worried about heading into the next quarter. I don’t need to invent problems. People tell me about them.

This matters because the filter only works if the pain is real and externally verified. If the idea starts inside your own head and you go looking for evidence that the pain exists, you’re just looking for a confirmation.

The calls flip the sequence. The pain comes first, from the source, and then you decide whether it’s worth solving.

Once you have a real pain, run it through four gates before you commit a single hour of your team’s time.

Here’s the framework

1. Start with the pain

Describe it precisely:

• Does it have a measurable cost when it goes unsolved, or is it mostly an irritant?

• Is it something others in the org feel, or is it your version of the problem?

2. Research

• What’s the standard outside your org?

• Is this the most important pain to be solving right now, or is there something more load-bearing sitting ahead of it?

Most engineers skip this step. They feel the pain, design a solution, and ship. The research gate is where you find out whether you’re solving the right thing or the familiar thing.

3. Think of different solutions

If you go into solution mode with the one you already want to build, you’re defending an idea, not evaluating a problem. Generate at least two alternatives before committing to an approach.

4. Talk to the people it affects

• What do they think about the pain?

• What do they think about your solution?

• Are they willing to sponsor this, or do they have other initiatives that matter more to them right now?

This last question kills the most ideas, and rightfully so. A pain that nobody will prioritize is a pain the org has decided to live with.

If all four come back green, ship.

Subscribe now

Remember to download the complete audit at the end of the article.

Read more

He wrote the playbook down in his book Your Fractional CDO, after watching the same failure pattern repeat across years of client work.

A data team builds perfectly modeled tables, clean naming conventions, a finished warehouse, and still fails at the one job that matters.

The failure starts in the hiring order, months before anyone touches SQL.

The Pattern Behind Almost Every Broken Data Team

A company grows, raises money or bootstraps itself, and builds product and marketing first. Data waits. By the time anyone notices, the gaps have already turned into blind spots in real decisions.

The fix usually starts with a data analyst, hired to both analyze the data and build the warehouse underneath it. He patches things together with whatever is closest: ad hoc imports from spreadsheets, quick pipelines wired through whatever tool is available. It works until it doesn’t.

So the company hires a data engineer to rebuild the plumbing properly. Pipelines get rebuilt, structure improves, the technical layer finally looks right.

It still doesn’t work. Nobody ever agreed on what the numbers mean.

A clean warehouse built on an unresolved disagreement only makes the disagreement faster.

This is the gap a fractional Chief Data Officer gets hired to close. The job is the translation layer between what the business is trying to decide and what the data team is building. Head of Data, VP of Data, Chief Data Officer, the title changes. The job underneath stays the same: turn business priorities into a data roadmap, then close the distance between the two.

Three People, Three Numbers, One Metric

When the role gets done right, the first move rarely touches the warehouse.

On one project, the opening round of conversations with C-level stakeholders surfaced a single metric, active subscriber, calculated three different ways by three different executives. Each one trusted their own version. Nobody had flagged it as a problem, because nobody had compared notes.

The fix starts with a written catalog of every metric that matters: what it counts, what it excludes, who owns the definition. It lives somewhere simple, a Notion page, an Obsidian vault, plain markdown files, and every stakeholder signs off on a definition before a single pipeline gets touched.

Skip that step and the technical work inherits the argument anyway. A warehouse with perfect naming conventions and a properly modeled transformation layer still produces three different numbers for active subscriber, because the disagreement never lived in the tables. It lived in the room full of people who never sat down to agree on what the word meant.

What AI Changed

The Audit That Used To Take A Month

When Nick onboarded onto a new client’s stack, he inherited a Metabase instance holding around 2,000 saved questions, each one a SQL query sitting on top of the warehouse. Reading through that by hand to figure out which tables and metrics mattered used to eat him three to four weeks.

He connected an LLM to Metabase’s API and turned the same task into a question-asking exercise: which tables get used most, which metrics get calculated more than one way. The 2,000 saved queries referenced around 90 tables in the warehouse. Only 12 of them turned out to matter.

The same pass produced a first list of conflicting metric definitions, the kind of list that used to take weeks of stakeholder interviews to assemble by hand. It became the opening line of the metric catalog conversation. The conversation with stakeholders still had to happen.

A Personal Operating System

Outside of any single audit, Nick’s daily workflow runs through a stack of connected tools: email, Slack, Telegram, WhatsApp, Jira, Google Calendar, a meeting note-taker, a task planner, a personal fitness tracker. Each one is wired in through its own API, feeding into folders organized by client, by teammate, by personal project, written up as markdown files an AI assistant reads for context.

A new lead from the website used to mean reading an email and booking a call. Research on the prospect now happens automatically, the call transcript gets analyzed for next steps, and a draft proposal and CRM update follow without him typing either one by hand.

He still types every prompt himself. Roughly 90 percent of his working day still happens inside an editor, reading something, asking a question about it, deciding what happens next.

The Rules That Don’t Bend

Speed doesn’t extend to trust. A short list of rules stays fixed regardless of how good the tools get:

• Every SQL statement an AI writes gets verified by a human before it touches anything live or anything tied to budget.

• Raw client data never goes into a public AI tool. Only metadata about the data does, table names and query structure, never the rows underneath.

• Sensitive processing happens through local models inside the client’s own environment instead of commercial platforms.

Delivery got faster. The job grew, because speed opens room to take on more work.

Judgment Became The Scarce Skill

As AI absorbs more of the execution, headcount on this kind of team is shrinking on purpose, driven by a bet: enable each remaining data analyst and engineer with AI rather than hiring more people to do routine work that AI now does faster, the documentation nobody wanted to write, the boilerplate code, the first draft of a pipeline.

Not everyone takes that bet. Some experienced data engineers distrust the output outright or keep working the old way out of habit.

That resistance is becoming the dividing line. Once anyone is able to write a working SQL query or stand up a dashboard with AI’s help, calculation stops being the skill that earns a senior title. Reasoning about why a stakeholder cares about a specific number takes its place. The valuable hire thinks strategically about the business and catches the cases where the fast answer is the wrong one.

Reporting Lines Decide Whether The Job Works

Where this role sits on the org chart changes what it’s able to do, regardless of the title on the business card.

Put the data function inside engineering and it drifts toward whatever a chief technical officer recognizes as good work: pipelines, infrastructure, technical correctness, thinly connected to what the business is trying to decide.

Put it inside finance and a different bias shows up. Finance’s own questions get solved first simply because of who the team reports to, while marketing or product priorities wait their turn even when they matter more to the business right now.

Neither placement is wrong on paper. Both pick a winner without saying so.

The function works best as a peer to product, marketing, and finance rather than a report inside any one of them, sitting at whatever level makes the final call on what the company builds next: a CEO in most structures, whoever arbitrates between general managers in flatter ones. The job stays the same either way. Listen across every department, then build the data foundation that unblocks all of them instead of only the one holding the budget.

None of this requires the word “Chief” in the title. It requires someone willing to do the unglamorous work of getting people to agree on what a number means before anyone touches a pipeline, and the discipline to use AI as a way to do that work faster rather than as a reason to skip it.

Find Nick Online

You can find Nick on a number of places. I strongly recommend following Nick on LinkedIn and subscribing to his Substack.

• Valiotti Data, the agency Nick runs as a fractional CDO for growing companies.

• LinkedIn, where most of this thinking shows up first.

• Substack, where Nick writes long-form content.

• Your Fractional CDO, the book written for executives building a data function for the first time.

—

Yordan

More on the Topic

• Where Your Data Team Sits Is a Strategic Decision

• Data Platforms Exist to Enforce Consistency, Not Enable Insight

• The Operating System Every Data Engineering Leader Needs

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