One of the biggest misconceptions I had early in my career was this:
Speaking up is risky. Staying quiet is safe.
It sounds reasonable.
After all, if you’re one of the younger people in the room, surrounded by senior managers and directors, it’s easy to assume your job is to listen, take notes, and execute.
I thought that too.
Until one meeting taught me otherwise.
Ironically, I learned that staying quiet is often the riskier option.
Two Goals. Both Completely Valid.
At the time, I was responsible for fraud strategy for a new financial product that was about to be launched.
The product was exciting.
An external partner had already been promised a launch timeline.
Engineering teams were building.
Product teams were coordinating.
Business teams were preparing communications.
Everyone wanted the same thing:
Launch successfully.
And that was a perfectly reasonable goal.
The faster we could launch, the sooner customers would benefit from the new product.
Nobody in those meetings was trying to cut corners for the sake of it.
They were trying to honor commitments.
I was trying to honor a different commitment.
My Job Wasn’t to Launch Products
It was to make sure customers didn’t become victims of fraud because of them.
And when I started evaluating the portfolio, one thing became immediately obvious.
We simply didn’t have enough information.
This was a brand-new product.
There wasn’t historical fraud data.
There weren’t mature data pipelines.
Several signals we normally relied upon didn’t even exist yet.
Some of the data would have to come from proxy sources.
Some would have to be collected after launch.
Some assumptions could only be validated through limited pilot testing.
In other words…
The very things I normally used to build a reliable fraud strategy simply weren’t available.
The Obvious Proposal
As discussions continued, a fairly practical suggestion emerged.
“Let’s use whatever data we have today, launch on time, and we’ll improve the fraud strategy later.”
From a product perspective…
That made perfect sense.
From an engineering perspective…
That made perfect sense.
From a partnership perspective…
That made perfect sense.
Unfortunately…
From a fraud perspective…
It didn’t.
There Was One Small Problem
Around the same time, my manager went on a long sabbatical.
Normally, discussions around timelines and stakeholder negotiations would have been handled by them.
This time…
It was just me.
Suddenly I found myself sitting across from senior leaders, product managers, engineering teams, and directors, all discussing delivery timelines.
The pressure wasn’t aggressive.
Nobody was trying to intimidate me.
But there was an unmistakable expectation.
Can your team deliver this by the committed date?
Technically…
I could have said yes.
I could have delivered something.
I could have documented the missing pieces, added a few caveats, and hoped we’d improve things after launch.
It would’ve been the easier answer.
Instead, I Said Something I’d Never Said Before
I took a deep breath and said,
“I don’t think we should launch this the way we’re discussing.”
The room became noticeably quieter.
I continued.
“It’s not that we can’t build something in time. We absolutely can.”
“My concern is whether what we build is good enough to keep customers safe.”
That distinction mattered.
I wasn’t saying the timelines were unreasonable.
I wasn’t criticizing anyone’s planning.
I wasn’t refusing to do the work.
I was questioning whether meeting the timeline and meeting our responsibility to customers were currently pointing in the same direction.
At that moment…
I didn’t think they were.
Saying “No” Wasn’t Enough
One thing I’ve learned over the years is that disagreeing without offering a path forward rarely helps.
So I didn’t stop there.
I said,
“I think there’s another way.”
Instead of launching the entire product at once, I proposed a phased rollout.
The customer segments where we already had reliable data and mature engineering pipelines could go live first.
The remaining segments could follow as additional fraud signals became available.
That approach would allow us to:
- Deliver value to customers.
- Honor the partnership.
- Collect real-world data.
- Strengthen fraud detection before expanding further.
It wasn’t the fastest plan.
But I believed it was the safest.
Not Everyone Agreed
The proposal wasn’t immediately welcomed.
That wasn’t surprising.
Changing timelines isn’t easy.
Especially when commitments have already been made outside the organization.
Every adjustment has a ripple effect.
Roadmaps change.
Partner conversations change.
Executive updates change.
In fact, the discussion eventually made its way to my own director.
I later learned that concerns had been raised about my unwillingness to commit to the original timeline.
I’ll admit…
That wasn’t a particularly comfortable realization.
Then Something Happened I Didn’t Expect
A follow-up meeting was scheduled.
This time, my director joined.
I honestly didn’t know what to expect.
Maybe I’d misunderstood the risks.
Maybe I’d be asked to find another compromise.
Instead, after listening to the discussion, they said something I’ll probably remember for the rest of my career.
“This team’s responsibility isn’t just to launch products.”
“Their responsibility is to make sure customers are safe when those products launch.”
Then they supported the phased rollout.
Almost immediately, the tone of the conversation changed.
The discussion shifted from whether we should address the risk…
…to how we could make the phased rollout successful.
The goal hadn’t changed.
The approach had.
The Lesson Was Bigger Than Fraud
Looking back, this wasn’t really a story about fraud strategy.
It was a story about professional responsibility.
Everyone in that meeting was optimizing for something important.
Product wanted to deliver value quickly.
Partnership teams wanted to honor commitments.
Engineering wanted to build.
Operations wanted readiness.
I wanted customers to be protected from fraud.
None of those goals were wrong.
The challenge was finding a solution that respected all of them.
That’s very different from simply winning an argument.
Speaking Up Isn’t About Being Right
Sometimes people imagine that speaking up means you’re absolutely certain.
In reality…
You’re often not.
I’ve spoken up before and later discovered someone else’s solution was better.
And that’s perfectly fine.
The objective isn’t to always have the winning idea.
The objective is to make sure important risks are visible while there’s still time to do something about them.
Because once a product launches…
The opportunity to prevent a problem becomes much smaller.
Looking Back
When I think about that meeting today, I don’t remember the roadmap.
I don’t remember the delivery dates.
I don’t even remember all the technical discussions.
What I remember is realizing that my job wasn’t simply to execute requests.
It was to represent a perspective that nobody else in that room was responsible for representing.
If I had stayed quiet, the meeting probably would’ve ended sooner.
The timeline probably would’ve remained unchanged.
And if fraud losses had occurred a few months later, nobody would’ve cared that I had privately disagreed.
They would’ve asked a much simpler question.
“If you saw the risk… why didn’t you say anything?”
That question has stayed with me ever since.
Speaking up isn’t about proving you’re the smartest person in the room.
It’s about making sure the room has the information it needs to make the right decision.
Sometimes the most valuable thing a junior engineer can contribute isn’t another idea—it’s the courage to say, “I think we’re missing a risk.”