Sometimes you just gotta make some noise

Oh bloody hell not this again

You might be lucky enough (and I do mean lucky) to hear some feedback like this:

"well, X is awful, we can't use it at all"

They may not say this, but it's what they are communicating.

And turns out, you already advocated for this at some point internally before and were pushed back. Other priorities. Not in the strategy. Etc.

And it's going to hurt initially to let that voice escalate round the company.

And you have a choice:

1. calm the situation down
2. amplify the noise

Noise can often been seen as "not managing things correctly".

I promise I did not break these servers

I accidentally learnt this very early in my career. I was a baby sysadmin for a small company (around 50 people), and I noticed that the servers that ran everything for the company (apps, email, file hosting - not cloud then!) were out of warranty. By a good year or so. So the support company would not consider them part of their normal support that they paid a lot of money for.

I raised this via the normal routes. "It's not broken". Oh, ok then.

About a month later, the Exchange server had a motherboard failure. That's 50 staff, across 3 offices in two countries, unable to send or receive email. In the days that email was the primary form of office communication. The new motherboard arrived next day, an support invoice for the parts and services afterwards. And after that point, the warranty aspect was understood. Within a few months, I even had approval (and budget?!) to move email hosting partly to BPOS (what became Office365, or whatever MS is calling it this week).

I had already supplied the information. The organisation had decided it wasn't important. Reality eventually supplied the information in a form that couldn't be ignored. This taught me something very early on - sometimes your job isn't to prevent operational pain or noise. It's to make sure the right people experience enough of it to make good decisions.

Noise is operated on a slider, not a switch

One of your capabilities as a professional software person is your judgement on whether you want others to receive a little noise or pain. Because it's not vindictive, it's more performing the Vulcan Mind Meld via performance art. And overall, if you judge it right, both parties at the end should end up better off.

If you live all the time at one end of the slider, you are the BOFH from the infamous column from The Register. You're vindictive. You live in every Malicious Compliance story on reddit. These people in real life are very often arseholes or burnt out.

If you're always at the other end, you silently fix and calm everything, without allowing the vital bits of feedback to course correct. These people are also often burnt out too!

So your escalation button is less like a button. It's actually that you have a slider and you can choose whether you escalate and stop protecting that KPI, uptime or SLA to communicate something bigger from reality to the wider business. Something to make another department understand what is going on, to force them to adjust position.

Why is this not natural already?

Turns out, very few people like delivering bad news.

If you haven't come across the SCARF model, it explains why this is the case.

Giving people that noise, breaks a few things in your colleague's mental model which makes the information feel like a threat rather than well, feedback:

• Sense of Status, eg am I going to get sidelined/fired/less good review if I do this? Does my manager also value noise, or do they prefer quiet? Or have I escalated far too much and they can't prioritise anymore, thus making my competence look less good?
• Sense of Certainty, eg this isn't the strategy, this makes the future harder to predict.

So often, you're fundamentally breaking a mental model in your colleagues' heads about how something works when giving them this new information.

And denying the bad news is rewarded systematically. If left unchecked, it becomes self reinforcing in a company culture.

Support get praised for "calm customers". Project Managers get praised for "quiet" projects. Engineers get praised for building things quietly on time without fuss. Engineering Managers are praised for reducing escalations. And not complaining about tech debt. Product Managers get praised for writing the user stories and releases happening with the features from those user stories. KPIs and SLAs have to be 0% or 100%. Sales have to always hit the target. Company stock value has to quietly always go up every quarter (and never down then double up later!).

Individually, all these things make sense in some way, in their lens, scope or context. But collectively, they reward an organisation ignoring reality.

Human in the loop: retro style

So bearing the above in mind, it's more refined than "make others feel pain or noise".

It's more:

For example, I recently had a flustered call from an engineering lead asking what I wanted on a ticket. It turned out I hadn't escalated it at all (I had a workaround) but another department lead had because the bug was distorting their team's metrics.

(Your curated reality you need to share will depend on your specialism - eg engineering, product, customer success, etc. If you are an engineer and this has taken your interest, Charity Majors has written extensively about engineering feedback loops).

Eg:

• Setting a ticket to "high priority" to make it a different team's problem than it orginally sat
• Letting a visibly annoying but non-impactful bug become more visible and understood to show the wider impact of significant technical debt
• Choosing KPIs or metrics to allow a sufficient feedback loop between groups eg customer and supplier, or ops vs support.
• Not always calming the customer down when you need leverage to get a feature on the roadmap
• Letting a small sale fail in order to win a much bigger one, or open a new market

Noise and feedback loops

So your noise isn't "noise"... it's your organisation's systems regulating itself back to reality. Stopping technical debt becoming technical bankruptcy. Or preventing the "glass cliff" occurring on a Feature Factory. Or giving a founder a little bit of hope that actually, there's a market for their product.

Stafford Beer would probably describe the absence of the above as a broken feedback loop.

If you're curious about how that works in a wider system, Stafford Beer and specifically, a revisiting of the Viable Systems Model seems to be having a bit of a moment in the tech community right now, I suspect partly down to this awesome book by Dan Davies, and partly the resurgence in people interested in various systems thinking topics as part of augmenting LLM output (I'll leave that one without comment).

Be the grease, not the glue

You're not trying to become a bad colleague. You're using your professional judgement to communicate with colleagues, teams, departments, and customers something like "wait, does this need a bigger audience? do we need to course correct more widely based on this?"

Sometimes solving a problem is about not solving the problem yourself. It's about ensuring the organisation solves it.