Why Your Best Ideas Keep Losing?


Hello Reader,

I spoke with an old friend last week. He told me he spent 4 years as a senior engineer watching less experienced engineers get to the next level ahead of him.

His designs were cleaner. His solutions were faster. His technical reviews were thorough.

But he kept getting the same feedback: "You need to be more visible and strategic"

He thought that meant talking more in meetings.

He was wrong.

What he lacked was influence at work

The Real Problem

Here’s what actually happens when you lack influence as an engineer:

You wait until your analysis is perfect before sharing it.

Meanwhile, someone else frames the problem, sets the constraints and aligns the stakeholders.

By the time you present your solution (even if it’s objectively better), the decision is already made.

Your idea doesn’t lose because it’s wrong, It loses because it arrived too late.

The Shift That Changed Everything

I discovered something that transformed my career:

Influential engineers don’t start with solutions. They start with problem ownership.

Here’s what this looks like:

A project proposal drops in Slack. Most engineers wait to be assigned tickets.

The influential engineer types: Before we jump to solutions, are we optimizing for speed or system stability?

These lead to very different solutions.

That’s it.

One question asked early.

That question reframes the entire discussion. Now you’re shaping the solution space before anyone implements any solution.

Why This Works

When you determine how the problem is defined, you influence which solutions get considered.

You’re not waiting for permission. You’re not being political. You’re clarifying the actual problem before the team wastes time solving the wrong thing.

This doesn’t require authority.

It requires timing.

Your Action Step This Week

Pick one upcoming decision at work.

Don’t wait until you have the perfect solution.

Instead, ask a clarifying question about the problem definition in the first 24 hours.

Examples:

What’s the primary constraint we’re solving for here?

What does success look like in 6 months vs 6 weeks?

Are we treating this as a temporary fix or a long-term foundation?

These questions position you as strategic, not just technical.

They give you a seat at the table where decisions actually get made.

Try it once this week.

You’ll be surprised how one early question changes the entire conversation.

See you next Monday,

Kayode

The Modern Engineer

Join 1k+ other forward-thinking professionals who receive the weekly newsletter, where I provide actionable strategies, insights and tools to escape the grind and build influential, future-proof careers. Sign up and I will send yoy a FREE copy of my 5-Stage playbook to multiply your impact and build a career that AI can't replace.

Read more from The Modern Engineer

Hello Reader, A few years ago, I proposed adding automated rollback capabilities to our deployment pipeline. The system was fragile—on-call rotations were painful, incidents were frequent, and small changes could break the entire workflow. The refactor wouldn't ship new features, but it would make everything more reliable six months from now. The response was polite: "Sounds sensible. Not right now. Let's revisit next quarter." Next quarter came with new deadlines, new priorities and other...

Hello Reader, A few months ago, I spoke with an engineer who described a design review he could not stop thinking about. It was a standard meeting. A dozen people on the call, a couple of senior voices leading the conversation and a solution that already felt decided before anyone joined. Halfway through, he noticed a scaling issue that would only show up during edge cases. He thought about bringing it up then he looked at the room. A senior engineer had already said it looked good. The...

Hello Reader, Understanding this distinction would have saved me years of frustration in my engineering career. Every organization has two kinds of engineers. There are functional engineers and there are vital engineers. Most people never realize this, and it keeps them stuck far longer than necessary. I learned this the hard way, after confusing output with outcome for a long time. At first glance, functional engineers look impressive. They deliver tickets, close incidents, follow processes...