A major bank was under attack, and there were more than a hundred and twenty-five people on the call.
I was the frontline. Security Operations, first contact, the person everyone turns to for the next piece of information. What I needed was firewall data, so we could size the thing: what was being hit, from where, how hard. Without it we were describing an attack we could not see.
I asked the internal team that owned the firewalls. The answer came back fast and flat.
The data could not be gathered.
What followed was twenty minutes of asking again, in different words, while a hundred and twenty-five people listened to me have nothing. Eventually, after enough pleading and enough silence, an engineer from that team joined the call.
He pulled the data in about a minute.
You could hear the call organiser’s reaction. Not at me. At the twenty minutes.
What “cannot be gathered” usually means
It almost never means the data does not exist.
It means this is not my queue. It means I would have to stop what I am doing. It means if I say yes once, I will be asked again. It means nobody is measuring whether I help you, and several people are measuring whether I finish my own list.
None of that is laziness, and that matters, because treating it as laziness guarantees you will keep getting the same answer. It is a person responding accurately to what their organisation rewards. The firewall engineer was not punished for the twenty minutes. I was.
The two companies
Most support organisations are quietly two companies wearing one name.
The outward-facing one is excellent. Customer tickets get acknowledged, triaged, escalated, closed. There are targets and dashboards and someone whose job it is to care about the number.
The inward-facing one has none of that. A request from a colleague has no SLA, no queue, no visibility, and no consequence for being ignored. So it is ignored, not maliciously, just reliably, because it is the only work on anyone’s desk with no cost attached to dropping it.
Which would be survivable if the two companies were separate. They are not. Every internal request that dies is a customer waiting, and the customer-facing numbers everyone is watching are produced by people who cannot get help.
The reluctant hero
There is a particular shape this takes, and it is worth naming because it looks like competence.
Someone is the expert. The go-to. They hold the thing nobody else holds, and they dispense it in the smallest viable quantity, late, usually after it stopped being useful. You spend the intervening time scrambling, buying time with clients, going back with answers that are half right because half right was all you could assemble.
Then, at the last possible moment, they arrive and fix it, and that is the version everybody remembers.
The organisation reads this as the expert saving the day. What actually happened is that the expert created the emergency by withholding for three days, then resolved the emergency they created, and got credit for the second half.
I do not think most people doing this know they are doing it. Being the only one who can do a thing feels like security. Teaching it away feels like handing over the only reason anyone calls you.
What I did with it
I would like to say I fixed the culture. I did not. I got good instead, which is a smaller and more selfish outcome, and it is the honest one.
Not being able to rely on anyone taught me the systems properly. Not just where the button was, but why the thing broke, which meant I could predict the next one. That knowledge is the only reason I could then train the people beside me on the frontline, which is the one part of this that actually scaled.
It also taught me to be clear while under pressure with no answer yet. A hundred and twenty-five people on a call and nothing to tell them is a specific skill: say what you know, say what you do not, say when you will know more, and do not fill the gap with noise. I use that more than anything technical I learned that year.
And it made me a much easier person to ask for help, which I suspect was the point all along. I know exactly what it costs to be stuck waiting on someone who could end it in sixty seconds.
"A bad system will beat a good person every time." - W. Edwards Deming
What would actually have fixed it
Not a culture initiative. Three unglamorous things.
Give internal requests the same visibility as customer ones. Not the same priority. The same visibility. The reason the firewall request died is that no one but me could see it had been made.
Measure helping. If every metric on a team points at their own backlog, helping another team is pure cost. That is not a values problem, it is an arithmetic one, and it is fixed with arithmetic.
Write down why, not just how. Most of what the reluctant hero holds is not secret, it is just undocumented, and the gap between a runbook that says what to click and one that says why the system behaves this way is the entire difference between a team that can act and a team that has to escalate.
None of that is hard. It is just nobody’s job, which is the same reason the firewall data could not be gathered.
