Behavioral & Leadership — Fundamentals

My tech lead wanted to migrate our CI pipeline to a new tool primarily because it was newer and had better marketing, on a fairly aggressive timeline right before a major release freeze.

I believed the timing created unnecessary risk to the release and wanted to make that case without just saying "no."

I asked for 30 minutes to put together a short write-up: the migration's actual benefit versus our current pain points (which were minor), the risk window it created right before freeze, and a proposed alternative — do the migration two weeks later, right after release, when we'd have slack to absorb problems. I brought data, not just an opinion, and was explicit that I'd support whatever the final call was.

My tech lead agreed to push the migration two weeks. It went smoothly with no impact on the release. Afterward he told me he appreciated that I'd brought a concrete alternative instead of just objecting — that's stuck with me as the model I use for pushing back since: don't just flag a risk, propose what you'd do instead.

Two weeks before a committed launch date, we discovered a security issue in a third-party dependency that meant we couldn't ship on schedule without unacceptable risk.

I had to tell the product and leadership stakeholders we'd miss a date they'd already communicated externally to customers.

I didn't wait for a scheduled check-in — I flagged it the same day I confirmed the issue was real, with a short summary: what the issue was, why it blocked launch, what the new realistic date was, and what we were doing in the meantime (a mitigated interim rollout to a smaller user segment while the fix completed). I made sure the message led with the plan, not just the problem.

Leadership pushed the external date by a week, and the interim mitigated rollout meant we weren't fully blocked in that window. The product lead specifically thanked me for surfacing it immediately rather than trying to quietly hit the original date and cutting a corner.

A junior engineer on my team was technically strong but kept getting stuck for hours before asking for help, which was slowing them down and quietly burning them out.

I wanted to build their instinct for when to ask for help, without making them feel like they needed to ask permission for everything.

Instead of just telling them "ask sooner," I set up a standing rule with them: if they'd been stuck on the same problem for more than 30 minutes, ping me — no judgment, just a quick sanity check. I also made a point of narrating my own thought process out loud during pairing sessions, including the things I got wrong first, so they could see that senior engineers get stuck too and that asking isn't a sign of weakness.

Within a couple months they were unblocking themselves faster and, notably, started proactively flagging other teammates who looked stuck — the behavior generalized past just their own work. They were promoted about a year later, and specifically mentioned that 30-minute rule in their own onboarding material for new hires on the team.