How to raise concerns without being seen as the problem

Your job isn't to be a cheerleader. But it's also not to be the person who only points out problems.

Nov 25, 2025

👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

You’ve been around long enough to see the warning signs. The deadline that makes no sense. The “plan” that’s really just wishful thinking with a Gantt chart.

So you speak up. You raise the concern. You do what senior engineers are supposed to do.

And then you get the feedback: “Your tone is too negative.”

This is one of the most frustrating dynamics in engineering leadership. You’re experienced enough to spot problems early, but you don’t have the authority to actually fix them. You’re expected to be a leader, but you feel that leadership means just nodding along.

Sometimes that feedback is right. Not because your concerns are wrong, but because how you’re raising them isn’t landing.

The problem with being the problem-spotter

There’s a pattern I’ve seen play out dozens of times, and I’ve been guilty of it myself. You join a team or a project that’s clearly in trouble. You see issues everywhere. So you start pointing them out.

“The codebase is a mess.” “Feature requests are too vague.” “We’re not ready for this deadline.” “Nobody consulted the team on this decision.”

Every single one of these statements might be completely true. And every single one of them is useless on its own.

When you only surface problems, you’re essentially handing work to someone else.

You’re saying “this is broken” and implicitly expecting leadership to figure out what to do about it. But that’s not what senior engineers are expected to do. You’re expected to solve problems, not just identify them.

Truth is that 90% of the time, leadership already knows about the problems you’re raising. They might not understand the technical details, but they know things are messy. What they need from you isn’t another alarm bell. They need a path forward.

Reframe what you say

Instead of “this is a problem” convert it to: “here’s what we’re working with and here are our options.”

For example, let’s say you’re facing an unrealistic two-week deadline for a product that’s clearly not ready. Here’s what most engineers do:

“We can’t ship in two weeks. We have critical bugs, not enough time to develop the remaining features and the team wasn’t even consulted on this timeline.”

Here’s what actually works:

“If we ship in two weeks, here’s what we’ll be shipping with: these three known bugs, no documentation for the support team, and manual workarounds for that important flow. I want to make sure everyone’s aware of what the customer experience will look like. If that’s acceptable given the business constraints, we can make it work. If we need to address any of these before launch, here’s what each one would cost us in time.”

See the difference? The second version surfaces the exact same concerns. But it does three things the first version doesn’t:

It presents information neutrally without demanding a particular outcome
It acknowledges that there might be business reasons you’re not aware of
It gives leadership the information they need to make an informed decision

If you’re enjoying this article, consider subscribing to get:

✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

The magic of options

One technique I’ve found incredibly effective is presenting options with tradeoffs. Leadership loves options because it gives them agency while benefiting from your expertise.

“We uncovered a problem in the implementation for the feature we planned to deliver in two weeks. I see two paths forward:

Option one is a quick mitigation. Two engineers, for two weeks. That will allow us to deliver on time but not we’ll need to quickly follow up with a refactor (two engineers, for three weeks) as that won’t scale and we’ll hit a wall at around 50 concurrent users.

Option two is a proper implementation. Two engineers, four weeks. Delays us for by two weeks but we can scale to 50,000 concurrent users. Requires some re-architecture.

I’d recommend option two if we have the runway, but option one buys us time if we don’t. What matters most to the business right now?”

You’ve raised the concern, provided solutions, given a recommendation, and left the final call to the people who have context you might not have.

When you’ve done everything right and it still doesn’t matter

Sometimes you’ll do all of this perfectly and leadership will still choose the worst option. Or they’ll ignore you entirely. Or they’ll tell you to stop being negative even when you’re being constructive.

This is when you need to make a decision about how much you’re willing to fight.

My advice: raise your concerns clearly, in writing, once. Make sure you’ve documented your recommendations and the tradeoffs. And then let it go.

I know that’s hard. You care about the work. You want to build things you’re proud of.

If leadership wants to walk off a cliff, your job is to clearly explain that it’s a cliff, offer some alternatives, and then step aside. You’re not responsible for decisions you don’t have the authority to make.

Document everything. Do your best work within the constraints you’re given. And start thinking about whether this is somewhere you want to be long-term.

Invest in relationships

There’s one more piece to this puzzle that’s easy to overlook: relationships matter more than being right.

I’ve seen brilliant engineers torpedo their credibility by being right in the wrong way. They were technically correct about every concern they raised, but they raised those concerns in ways that made leadership or peers feel attacked or undermined.

Meanwhile, I’ve seen less experienced engineers gain enormous influence simply by building trust first. They got to know the decision-makers. They understood the business pressures. They picked their battles. And when they did raise concerns, people actually listened.

This isn’t playing politics. It’s recognizing that influence is earned, not granted. If you’re brand new to a team and immediately start pointing out everything that’s wrong, you haven’t earned enough trust for that feedback to land well. It doesn’t matter how right you are.

Final thoughts

Your concerns are probably valid. Your experience is probably telling you something right. But being right isn’t enough.

The engineers who actually change outcomes are the ones who pair problems with solutions, present information in ways that help rather than blame, and build the relationships that make their input welcome rather than dreaded.

You can be honest about challenges without being “the negative person”. It just takes a bit more work than pointing at problems and expecting someone else to fix them.

And if you do all of this and still get labeled as negative? That tells you something important about the organization itself.