The Trap of Reliability

I used to think being reliable meant never saying “no.”

If a Product Manager or Designer came to me 1 or 2 days before a release with a “small tweak,” I would almost always agree. “Can we just move this button?” “Can we quickly change this flow?”

My answer was always: “Sure, I can do that.”

I wanted to be the guy they could count on. I didn’t want to be the blocker. I wanted to be helpful. In my head, I was being agile and responsive.

But I was missing the bigger picture.

The Wake-Up Call

It took some constructive criticism from my Team Lead to shatter that illusion. He pulled me aside and told me something I didn’t expect:

“You shouldn’t say yes to every request.”

He wasn’t telling me to be lazy. He was teaching me about second-order impacts.

I was only looking at the coding effort. “It takes me 10 minutes to change this code.”

But I wasn’t seeing the ripple effect:

• QA: They need to re-test the feature.
• Regression: A “small change” might break something else entirely.
• Dependencies: Other teams relying on my feature might get blocked or see unexpected behavior.
• Release Risk: That 10-minute change could delay the entire release if something goes wrong.

By trying to be helpful to one person (the PM), I was actually being unreliable to the rest of the team (QA, Release Managers, other devs).

The New Approach

That feedback changed how I work. Now, when a last-minute request comes in, I don’t just look at the code. I look at the blast radius.

I’ve replaced the automatic “Yes” with a process:

1. Gauge the Impact: How much testing will this actually need? What could break?
2. Check the Timeline: Is this worth risking the release date?
3. Notify Stakeholders: Before writing a single line of code, I talk to the TL, the QA team, and anyone else involved.

“We have this request. Here are the risks. Should we proceed?”

Closing Thought

I realized that true reliability isn’t about blind compliance. It’s about predictability.

Sometimes, the most “helpful” thing you can do for your team is to say: “We can do this, but not for this release.”

It protects the quality, it respects the QA team’s time, and it keeps the release on track.