Knowing when to fix and when to escalate
Engineers are trained to manage complexity. We take messy systems, unclear requirements, and partial information, and turn them into something that works. We debug. We simplify. We explain technical problems in ways non-engineers can understand. This is a valuable skill. It’s one of the reasons engineers are trusted. But if we stretch this skill too far, it can quietly turn into a liability.
Managing complexity is a strength
A lot of engineering work is invisible by design. When things go well:
- incidents don’t happen
- customers stay unblocked
- teams keep moving
Engineers absorb uncertainty so others don’t have to. We translate technical constraints into clean outcomes. That reduces noise and helps teams focus. Clear communication across roles is especially valued. Being able to explain why something is hard, risky, or slow in simple terms builds trust. Most engineers are rewarded for this early in their careers.
When clarity starts hiding tradeoffs
Problems start when clarity removes friction that the organization actually needs. If every issue gets quietly fixed:
- product priorities stay untouched
- sales commitments don’t get challenged
- capacity constraints don’t surface
From the outside, everything looks manageable. But that’s often because someone is compensating. Usually an engineer. Often a team lead. At that point, fixing problems is no longer neutral. It’s making a decision on behalf of the organization.
Fixing problems vs making decisions
I started thinking about this distinction after noticing a pattern in my own behavior. Every time something felt risky or unclear, my instinct was to reduce the risk immediately. Fix the bug. Patch the system. Answer the question. Make it work. Individually, each action made sense. But over time, I realized I was solving the same type of problem again and again - without ever having a proper conversation about whether we should keep doing so.
That’s when it became useful to separate two different activities:
- Fixing reduces immediate risk
- Deciding allocates long-term ownership and capacity
Fixing answers: How do we make this work right now?
Deciding answers: Is this worth ongoing investment?
Engineers are very good at fixing. That’s our job. But when fixes happen quietly and repeatedly, they start to answer the second question as well - without anyone explicitly agreeing to it. By making the problem disappear, we also make the decision disappear.
A familiar situation
In my case, this showed up around a domain my team technically owned. Product priorities were clear and planned quarterly. Supporting this area wasn’t disagreed with, but it was consistently low on the list. At the same time, some customers relied heavily on it. Sales had made commitments. Questions kept coming. There was no explicit decision about ownership. But the domain lived with my team, so questions landed with me. I started fixing things. Shipping improvements. Reducing risk. In the short term, this worked. Customers were stable. The roadmap stayed intact. In the long term, it created a pattern: the work kept coming, but the decision about investment never happened.
Making Tradeoffs Visible
When people talk about “being more vocal” about technical debt or risk, it’s easy to misunderstand what that means. I initially did. I thought being vocal meant explaining the problem more clearly. Or repeating it with more urgency. Or making sure everyone understood how serious it was. That didn’t help much. Over time, I realized that being vocal isn’t about volume or emphasis. It’s about making tradeoffs visible.
Being vocal does not mean:
- complaining louder
- escalating emotionally
- bypassing product processes
- pushing responsibility onto others
Those approaches usually create tension, not clarity. What actually helps is shifting how the problem is communicated.
Instead of describing pain, you describe cost.
Instead of effort, you describe impact.
Instead of urgency, you describe tradeoffs.
Here are a few concrete examples that changed how these conversations went for me.
1. Name tradeoffs, not pain
Saying “this area is painful” doesn’t give anyone a decision to make.
Saying this does:
| Supporting this will slow down feature X by Y.
Tradeoffs force prioritization. Pain doesn’t.
2. Make cost legible
Explaining how complex or fragile something is often stays abstract.
What lands better is cost:
| We’re spending about Z hours each cycle compensating for this.
Time is something product can reason about and compare.
3. Separate one-off fixes from ongoing ownership
A single fix can be handled quietly. A repeated fix cannot. If something keeps coming back, it’s no longer a one-off rescue. It’s an ongoing obligation, and that needs to be named explicitly.
Say that out loud.
4. Force prioritization without forcing outcomes
Being vocal doesn’t mean deciding for product. It means making sure a decision can’t be avoided. Your role is not to choose which work wins. It’s to ensure the tradeoff is clear enough that someone can choose. Once I started framing conversations this way, “being vocal” stopped feeling like escalation. It became a way to invite shared ownership instead of silently carrying it myself.
When fixing silently is the right call
There are times when you should just fix the problem. Production is broken. Customer trust is at risk. Time matters more than process. But silence should be temporary. Fix first. Surface the issue clearly after. Otherwise, the system learns the wrong lesson.
A simple rule of thumb
If my effort makes a problem disappear, I need to ask:
| What decision just disappeared with it?
If the same fix shows up twice, it’s no longer a fix. It’s a strategy. And strategies deserve shared ownership.
Closing
Managing complexity and communicating clearly are still core engineering skills. But leadership, at least for me, means knowing when to stop absorbing problems and start surfacing them. Fixing things keeps the system running. Escalating at the right time helps the system choose. Both matter. The hard part is knowing when to switch.