
In tech support, platform engineering, and SRE work, how you raise an issue often matters as much as the issue itself.
A broken customer website, a misbehaving server, or a failing deployment can trigger wildly different outcomes depending on whether the response creates more work… or removes it.
One of the clearest ways I’ve seen this articulated is Daniel Debow’s Helpful Hierarchy — a simple pyramid that ranks responses from least helpful to most helpful.
What makes it powerful is that it maps almost perfectly onto the real world of running customer-facing systems.
Based on https://www.youtube.com/watch?v=ULszsXDyjMY & https://medium.com/helpful-com/how-to-be-an-effective-early-stage-employee-hint-be-helpful-e681b456a01f

The Helpfulness Pyramid (Tech Ops Edition)
At its core, the pyramid describes levels of ownership.
Let’s translate each level into a tech company that supports a customer website and the infrastructure behind it.
🧱 Level 1 – “There is a problem.”
Least helpful
“The website is down.”
True — but incomplete.
This is the classic drive-by alert. No context, no impact, no attempt to help resolve it. The problem is now someone else’s cognitive load.
In ops terms:
- A Slack message with no timestamps
- An alert forwarded without investigation
- A ticket raised with a single sentence
You’ve identified pain — but passed it on untouched.
🧱 Level 2 – “There is a problem, and I’ve found some causes.”
“The website is down. Looks like the web server isn’t responding.”
Better — now we’re narrowing the blast radius.
At this level, someone has:
- Looked at basic logs
- Checked server health
- Identified where the issue might live
Still, the next person must now decide what to do.
🧱 Level 3 – “Here’s the problem, possible causes, and possible solutions.”
“The website is returning 502s. Likely causes are a crashed app service or exhausted memory. Restarting the service or scaling the instance may help.”
This is where engineering thinking kicks in.
You’re now:
- Framing the problem clearly
- Showing you understand the system
- Reducing uncertainty for the decision-maker
Most competent teams live here — and that’s not a bad thing.
🧱 Level 4 – “Here’s what caused it, and here’s the solution I recommend.”
“The website went down due to a memory leak in the app service after last night’s deploy. I recommend rolling back the release and increasing memory limits before redeploying.”
Now you’re doing systems ownership, not just support.
You’ve:
- Investigated root cause
- Evaluated trade-offs
- Proposed a clear path forward
At this level, managers and customers can act quickly because the thinking has already been done.
🧱 Level 5 – “I fixed it — here’s what happened.”
Most helpful
“The site went down due to a memory leak introduced in the last deploy. I rolled back the release, restarted the service, and confirmed recovery. I’ve raised a follow-up ticket to address the root cause.”
This is the gold standard.
Not reckless heroics — but responsible autonomy.
You:
- Acted within agreed boundaries
- Restored service
- Communicated clearly
- Created a paper trail for learning
As Daniel Debow puts it, this is the level where you remove work from everyone else rather than creating it.
(From How to Be an Effective Early-Stage Employee — Hint: Be Helpful
https://medium.com/helpful-com/how-to-be-an-effective-early-stage-employee-hint-be-helpful-e681b456a01f)
Why This Matters in Customer-Facing Tech
When you’re supporting a live website, customers don’t care:
- who owns the server
- which team caused the bug
- how complex the architecture is
They care about:
- impact
- clarity
- confidence
The higher up the pyramid you operate, the calmer everything becomes:
- Fewer escalations
- Faster decisions
- More trust from customers and leadership
This idea also aligns strongly with the mindset described in this talk:
https://www.youtube.com/watch?v=ULszsXDyjMY
— where ownership, intent, and thinking ahead matter more than raw technical skill.
A Final Thought
Not every situation allows Level 5 — and that’s okay.
But if you ever wonder:
“How can I be more valuable in this incident?”
The pyramid gives you a simple answer:
Move one level up.
Less noise.
More clarity.
Better systems.