No one gets hired for clean pipelines

If your projects don’t map to business value, you’re replaceable. Here’s how to make your work un-ignorable

Hi fellow data nerd, Yordan here,

A few years ago, I was interviewing for what I thought would be my next big role. It was the kind of position I had been quietly working toward for a while. A chance to lead data efforts across teams, build systems from the ground up, and finally have a say in how data shaped the business instead of just how it moved between tools.

I felt confident going in. I had the experience. I’d shipped projects that handled complexity across multiple systems. I knew my way around infra, orchestration, testing, all the technical foundations. This was supposed to be a formality.

Then the Head of Marketing started talking about CAC. She asked how I’d worked with acquisition teams in the past. What data we used to evaluate affiliate performance. Whether I’d helped model marketing budgets or forecast spend across channels.

None of the questions were overly complicated. I understood them. But I didn’t have anything useful to say.

Because in every project I’d done, I had never followed the data past my own domain. I hadn’t asked what it was being used for, how it tied back to the budget, or whether anything changed after it shipped.

So I pivoted into the details. I explained how the pipelines were built. I talked about latency improvements. I described how we scheduled updates and ran quality checks.

She nodded politely. But I knew I’d lost her.

That conversation stuck with me. Not because it went badly. But because it showed me the gap I hadn’t seen until then.

I had spent years getting better at the technical work. But I had no language for what that work meant. And without that, I couldn’t show value. I couldn’t defend my role. I couldn’t lead.

That was the day I stopped thinking of “business impact” as fluff. And started seeing it as the one thing that would decide whether my work opened doors or kept me stuck.

I assumed it was obvious

Back then, I believed good work would speak for itself. I didn’t think I needed to explain it.

The pipelines ran reliably. Reporting was faster than before. Systems that used to break during peak hours had been stabilized. I had untangled spaghetti DAGs, cleaned up months of tech debt, built reusable models that made onboarding easier for the next person who came in.

That all felt like impact.

And to be fair, the people close to the work did appreciate it. I’d get a “thank you” when something stopped failing, or when someone noticed that their dashboard didn’t crash under load anymore.

But outside the team I got only silence.

Leadership never mentioned the improvements. I didn’t hear my name in all-hands. No one stopped by to ask how it was built or how much time it saved.

And I told myself that was fine. That I was doing the job the right way — quietly, correctly, behind the scenes.

What I didn’t realize was that while the work mattered to me, the story of the work never made it out. People saw the result, but they didn’t know what went into it. They didn’t know what changed, or why it was better now, or what risk had been removed.

To them, things just worked.

And if things just work, it’s easy to assume they always did.

So when performance reviews came up, I struggled to fill the doc. When I tried to advocate for more scope, it was hard to point to proof. And when people asked what I’d been working on, I gave vague answers. Infra. Migrations. Some cleanup work.

Stuff most people didn’t know how to engage with.

Not because I didn’t have results. But because I didn’t know how to talk about them.

---

Business value isn’t a soft skill

For a long time, I thought talking about business impact was mostly for managers. Or salespeople. Or people who were better at “positioning” their work.

I saw myself as a builder. My job was to make sure things ran, scaled, and didn’t fall apart under load. I didn’t care about headlines or credit. I cared about getting things right.

What I missed was that business value isn’t about spin. It’s not about buzzwords or writing flashy updates or trying to make every small fix sound like a million-dollar win.

It’s a skill. Just like engineering. And it’s one you can practice.

Being able to say what your work changed, not technically, but practically, is what turns effort into leverage. It’s what turns delivery into momentum.

It’s what makes your role defensible when headcount gets reviewed, when priorities shift, or when someone asks what the data team is actually contributing to the business.

You don’t need to memorize every metric in the company. You don’t need to sit in finance meetings or suddenly start using “north star KPI” in every sentence. You just need to start following the thread.

What did your project enable? Who started working differently after it shipped? What became faster, cheaper, more accurate, more predictable?

And when you don’t know the answer, ask.

The best part? Stakeholders are usually thrilled to tell you. They’ve been thinking about these numbers long before you showed up. If you give them space, they’ll give you more context than you could ever pull from a dashboard.

And the moment you show that you care about the outcome, not just the code, you stop being seen as a ticket closer. You become someone who understands what the business is trying to do. Someone who’s not just working for them, but with them.

That’s not politics. That’s partnership.

---

The first time I asked, something surprising happened

One of the first times I followed up on a project, it wasn’t because I was trying to showcase my work. I was genuinely curious. I had been working on a performance issue that had been bugging me for a while.

It was a set of reports used by the business operations team was taking too long to load, especially in the morning when everyone hit it at once.

It wasn’t a high-profile task. There were no stakeholders breathing down my neck. It was just something I knew I could improve.

So I used Snowflake clustering to optimize the query patterns behind it. Technically, it was straightforward. Nothing fancy. It dropped query times by over 40%. We reduced compute costs along the way, too.

At the time, I treated it like a quiet win. No tickets closed. No shoutouts. Just one of those invisible things that makes the system better.

But weeks later, I heard something in passing during a team sync that caught my attention. Someone mentioned that the report we’d sped up was getting way more use.

I decided to check the Looker usage logs. The answer floored me.

Usage had jumped from three daily users to fifteen. A whole team that used to skip the report because it was too slow had started checking it every morning.

The ops lead told me they had begun using it in their daily standup to review metrics together. They were making faster decisions because of it.

Not hypothetically. Literally faster, every day. I had no idea.

And it made me realize how often that kind of feedback gets lost.

We ship things, close the loop on our side, and move on. But the downstream effect, the part that really defines value, often happens quietly, in rooms we’re not in.

I started thinking: how many times had I missed the story? How many other projects had changed something without me ever knowing?

The next time I shipped something, I didn’t wait. I asked directly: “What changed after this went live?”

That one question became a habit. And that habit became the beginning of a new skill. Not technical, but just as important.

---

Contractors, this is where you win or lose

When you're a full-time employee, there's usually some buffer. If you're quiet, people might assume you're busy. If your work isn't immediately visible, there’s still time to course-correct.

You have context, relationships, history. You’ve probably been in the room before the problem showed up.

But if you're contracting? You don’t get that luxury.

You’re not hired to explore. You’re brought in to solve. Fast.

And what people care about, whether they say it out loud or not, is whether you solved the right problem. Whether you changed something that mattered. Whether your presence made the business better while you were there.

They won’t always give you a clean brief. They might not know how to describe the outcome they want. But if you can ask the right questions early, and tie your work to those outcomes clearly, you stand out fast.

And when the engagement is nearing the end, or budgets are being reviewed, or someone has to make the call about whether to extend you or not, what’s going to matter is whether your work made a dent.

That’s where this habit becomes more than just a communication tool. It becomes the difference between being rehired and being replaced.

What I’ve found, and I’ve seen this again and again, is that contractors who take the time to understand the business problem, who ask how success is measured, who talk like partners instead of implementers, get treated like trusted teammates. Not vendors.

And that trust is how you get more scope, better projects, and longer-term contracts without needing to sell yourself every few weeks.

It’s not about proving yourself constantly. It’s about making your work obvious to the people who need to see it.

Not technically. Strategically.

---

How you can apply this in your projects today