The Impactful Engineer
Chapter 02

Choose what matters

Nothing is a priority if everything is a priority.

You’ve asked why. You understand the mission, the product, and the business. You see where the team is heading. And now you’re ready to move.

But where do you start?

Ideas are everywhere. The backlog never shrinks. New requests flow in constantly. Emergencies, shifting priorities, unplanned work — they keep piling up. Every day, a new Jira ticket pops up promising to change the world — or at least to fix that dropdown.

Every moment of the workday feels like an opportunity to slice time thinner. And engineers? We’re excellent at saying yes. Curiosity, a love of challenges, and a sense of responsibility push us to take on almost every request. More work. More busyness.

If you try to chase all of them — if you say yes to everything — you’ll end up very busy but not very effective.

Effectiveness isn’t measured by how busy you are. It’s measured by the results you create. Busyness is quantity: effort without focus, speed without direction. Effectiveness is quality: effort with leverage, speed with direction — velocity.

Busyness is comforting. It feels like progress. It signals that we’re working, that we’re doing something. But effectiveness is rare. And that rarity is precisely what makes it valuable — the key to having a greater impact.

Now, sure — sometimes you don’t control the backlog. You don’t choose the roadmap. But even then, you do control how you spend your attention: where to go deep, what to simplify, what to challenge, what to ignore. Even in the worst-case scenario — when your manager is breathing down your neck and micro-managing every move — you still have choices. You still control how you organize your day, what to focus on, and what to skip. At the end of the day, you’re the one with your hands on the keyboard. Impactful engineers play the long game — they pick their battles.

The uncomfortable truth is that most ideas don’t matter. Some are noise, some are distractions, and a few — just a few — are worth your full attention.

As engineers, we’re drawn to shiny things. We love complex puzzles, technical challenges, a new technology to try. Our bias is to think that the more complex a project is, the more impactful it will be. Except that… it may not.

The most impactful work isn’t necessarily the hardest technically — it’s the one that moves the needle for the business, the product, or the users. Resisting our biases, figuring out what’s truly worth doing, and channeling our time and energy into that work — that’s what really matters.

Think beyond the code

The days when coding alone made you valuable are over.

Code is now abundant, and writing it has never been easier. Decades of abstractions, open-source libraries and frameworks, endless technical documentation, pre-cooked solutions, and — last but not least — the rise of generative AI have lowered the barrier to entry dramatically.

It might feel like everything’s getting more complex — and at a micro level, that’s true. But zoom out, and you’ll see the opposite: there’s never been a time in history when building software was easier. There’s never been a time when creating a working, useful, end-to-end product was faster than today.

Today, nearly anyone can build an application. You might argue that AI-generated software isn’t as good as yours — and sometimes you’d be right — but it’s improving fast. By the time you read this, it’ll already be better.

In a world where code is abundant and nearly everyone can write it, the value of pure coding is in decline. It’s not new; it’s just accelerating. Our job hasn’t been just “writing code” for decades — but this, right here, marks the final death of coding as a unique source of leverage.

The value isn’t in the code itself. It’s in the problems you solve and the customer needs you address. Code is a tool — not the goal. Sometimes the smartest move isn’t writing code, but deleting it, preventing it from being written, or changing a single overlooked configuration option.

So, the question isn’t whether you can build something — of course you can. AI can too, at least to some extent. The real question is whether building it makes sense. Just because you can write code doesn’t mean you should. Paradoxically, generative AI made this even more true: the easier it is to build, the more valuable it becomes to choose what to build.

Is this feature worth building, and why? Does it make the product better or worse? Does the user experience improve, or does it add another layer of confusion? Is that tiny but nasty bug worth fixing? Should this business process even exist? The real value lies in your ability to discern what’s worth doing — and what’s not.

In today’s world, if you want to make a real impact, you need to shift your mindset. Don’t just think like a coder — think like a builder. Sometimes that means wearing the hat of a product manager, a project manager, or the customer. Because the engineers who shape the future aren’t the ones who code the fastest — they’re the ones who choose best what to build.

The two laws governing every project

There are two laws governing nearly every project. Even if the authors never met in person, these laws become powerful when combined, and more than a hundred years later, they’re still as relevant as ever. I’m talking about the Pareto Principle and Parkinson’s Law.

The Pareto Principle, also called the 80/20 rule, says that roughly 80% of the results come from 20% of the effort. In software, this could mean that 20% of your features deliver 80% of the user value — or that 20% of your bugs cause 80% of the customer complaints. The key insight here is that not all work is created equal. Most of what we do contributes very little to meaningful outcomes.

Parkinson’s Law, on the other hand, is deceptively simple: work expands to fill the time available. If a task has a week to be completed, it will somehow take a week, even if it could be done in half the time. Of course, there are cases where you can’t further shrink the required time, but the key idea is that giving a project more time than it truly needs doesn’t linearly increase its value. On the contrary, the extra time is often filled with doing the 20% that nobody really cares about.

Here’s where it gets interesting. You can use these two laws as a high-level guideline to gain leverage on any project:

  • Identify the 20% of work that produces most of the value — and focus on it.

  • Force yourself to do it in less time than you think you need.

The harder question, of course, is: how do you identify where the value actually is?

Choose like an owner

Thinking like an owner starts with perspective. You’re not just completing tasks — you’re responsible for outcomes. You anticipate problems before they happen, make tough calls without being told, and act as if the success of the product depends entirely on your choices. Because, in a way, it does.

How can you apply the owner mindset to identify what to focus on?

Think in outcomes, not tasks

Many engineers focus on checklists: tickets closed, PRs merged, lines of code written. Owners think differently. Instead of treating tasks as isolated units of work, ask yourself:

  • What result am I trying to create?

  • What need am I addressing?

  • What experience am I delivering to the customer?

  • Will this attract more customers and drive higher revenue?

  • Will this save costs and improve our margins?

  • Will this make customers happier and reduce churn?

Put yourself in the customer’s shoes

Use the product you’re building as much as possible. If that’s not feasible, gather feedback from customers or proxies — sales, solutions engineers, or customer support. Then ask yourself:

  • If I were the customer, which features would I actually use?

  • What do customers complain about the most?

  • What do customers find most confusing or difficult to use?

  • Which deals are we losing to competitors, and why?

Act as if it’s your money

Use a simple mental shortcut: think about time, money, and return. Ask:

  • If I owned this company, would I still do this?

  • Is this task worth my time — and the money the company is spending on it?

  • What can I simplify, remove, or delay to get it done faster without hurting the product?

Then reverse-engineer the work that needs to be done to achieve it. It’s not about finishing more stuff — it’s about finishing what matters.

Simplify your decision process

How do you make those choices consistently? How do you decide, day after day, what deserves your attention and what doesn’t?

I love simplicity. And a simple mental framework I use every single day is the Eisenhower Matrix.

The Eisenhower Matrix is deceptively simple but incredibly powerful. It reminds you to focus on payoff, not just urgency. The core idea is to ask yourself:

  • Is this task urgent?

  • Is it important?

And then place each task, each project, each request, even the smallest one, in one of these four categories:

  1. Important and urgent
    These are the fire drills. Stuff that must get done now because it has real consequences if ignored. For example, a critical bug affecting customers, an outage, or a feature blocking a major launch. Stop everything else and do these first.

  2. Important but not urgent
    The sweet spot. Work that moves the needle but doesn’t scream for attention. For example, designing a new architecture, improving user experience, or building an internal tool to automate recurring activities. Schedule time to do these deliberately. This is where you spend most of your energy and generate most of your long-term impact.

  3. Not important but urgent
    The interruptions and distractions. Many meetings, last-minute requests, or some emails. They demand immediate attention but contribute little to meaningful outcomes. Don’t let them hijack your day: timebox them, process asynchronously where possible, or delegate.

  4. Not important and not urgent
    The noise. Probably 80% of your backlog. Low-value tasks, time-wasting requests, or features nobody really needs. Ignore them.

    Sometimes you’ll look at your list and realize there’s nothing in the “not important and not urgent” box. It typically means one of two things.

    The first - and worst - case is that everything is labeled as a priority. That’s a symptom of noise disguised as importance. When everything’s on fire, nothing really is. Your job is to spot the fake alarms — the work that feels urgent only because someone shouted loud enough. Ask yourself: If this doesn’t get done today, what actually happens? Who’s affected? What’s the real cost of waiting? Those questions quickly separate signal from noise.

    The second - and best - case is that your leadership already filters out the noise before it reaches you. In that environment, priorities stay clear by design, and you can spend your energy on meaningful work instead of firefighting fake emergencies. Treasure that — it’s rare.

The beauty of the Eisenhower Matrix is how it forces a clear separation between what matters and what doesn’t, instead of letting the loudest or most immediate things steal your attention. It makes you conscious of where your time and energy go, which is half the battle in engineering work.

No, you don’t have to grab a whiteboard and draw the quadrants every time. Think of it as a mental model. Once you get used to it, you’ll unconsciously apply it to every request you receive — tens of times a day. Build the habit of daily triage, constantly asking: Is this urgent? Is this important? And if it is, is it really the highest-leverage thing I could be doing right now?

Applied consistently, it becomes a kind of decision autopilot:

  • You stop reacting to every incoming ticket or email.

  • You start spending your energy on the work that actually matters.

  • You recognize that saying “no” or “later” is not shirking responsibility — it’s choosing impact.

This work is licensed under CC BY-NC 4.0