Alert Fatigue and Fuck Bingo

On profanity, power, and what happens when a leader becomes the noisiest alert in the system

The CTO ended the argument with his palm.

It landed on the conference table hard enough to make both of us stop talking.

"This is bullshit. You guys don’t want to just do the work."

Then he left the room.

I was the VP of Engineering. The person opposite me was our Head of Backend Engineering, and we had been fighting about more than the technical decision in front of us. He saw the Infrastructure and Security team as blockers: people that accumulated tasks, introduced rules and slowed developers down. I saw him as someone who treated every boundary as an invitation to negotiate and every proposal as something to route around.

By the time the CTO hit the table, neither of us was listening. I had pulled rank. I told the Head of Backend that the direction of the engineering organization was my responsibility and that I did not owe him an explanation for every decision. He dug in. I dug in harder.

The CTO did not create the conflict. What he did was convert it from a disagreement into an order.

He returned later, once he had calmed down. There was no apology and no attempt to untangle what had happened. We agreed to do something he had already proposed. On paper, the meeting had produced a decision. In practice, it had produced a lesson: conflict was acceptable only until the most powerful person in the room got tired of it.

I learned the lesson. I made sure not to have that kind of disagreement in front of him again. I stopped trying to lead the Head of Backend and asked the CTO to take over the relationship.

At the time, I called that de-escalation. Looking back, I had made myself smaller to avoid another explosion.

The human alerting system#

The outburst would have been easier to dismiss if it had been rare. It wasn’t.

A broken deployment could prompt "Why the fuck did you not test this before?" A problem in the mobile app became "Guys, nothing is working. Nothing. We are down right now." Developers heard that the product was embarrassing, the quality was bad, and people seemed not to care.

At one point, the company began a 30-day Hackathon in order to push the release of a product. Leadership bought large countdown clocks. For a month, the passing of time itself became an alarm.

During outages or incidents the infrastructure team reacted the way Site Reliability Teams are trained to react: calmly they jumped on the challenge, investigated and stayed alert. These were engineers working on the layer most likely to cause wide impact with a small change, so the possibility of failure was real, especially during a 30-day hackathon with low to no clear requirements from a nonexistent product team. But every defect, experiment and disagreement arrived at roughly the same rhetorical severity.

Over time the jokes started.

"This is what the CTO would say," someone would write privately. One engineer joked about keeping a "fuck bingo" for the month.

Fuck bingo was not just gallows humor. It was deduplication. The engineers had built a social filter for executive noise.

In Site Reliability Engineering, an alert is not merely a description of something a monitoring system has observed. It is a demand on a human being’s attention. A good alert signals meaningful impact and asks for an action. A bad one fires because a number moved.

Google’s SRE guidance warns that a low signal-to-noise ratio produces alert fatigue. People do not become more vigilant when a system pages them constantly. They learn that the page cannot be trusted.

Leadership language works the same way, except hierarchy adds voltage. A message from a CTO is not interpreted like a message from a peer. It comes from someone who can redirect a roadmap, overrule a technical decision and influence or decide whether you still have a job.

Every "STOP," every "ASAP," every "nothing is working" assigns a severity. If everything sounds like a SEV-1, the organization eventually runs out of language for an actual emergency.

The obvious conclusion would be that leaders should stop swearing, but to be honest I don’t think that's the right one.

There's a difference between "this fucking outage" and "What the fuck are you doing?" The first puts the speaker and listener on the same side of a bad situation. The second turns the listener into the incident.

Profanity can signal humor, intimacy, surprise or shared frustration. It can also humiliate. What changes the meaning is not the word alone, but its direction and the power behind it. Slack makes that distinction harder: it removes the grin and the cadence, but preserves the hierarchy.

Charity Majors uses plenty of profanity in her writing. She also gives managers a much better rule in "An Engineer’s Bill of Rights (and Responsibilities)": say the hard things, add urgency when it is needed, and try not to make your emotions everyone else’s problem.

That last part is where alarming language fails. It transfers the leader’s internal state to the organization and calls the result alignment.

A quieter company is not a safer one#

The company did eventually become quieter. It did not become safer.

Engineers learned to bring forward proposals only when every assumption was defensible. New architectural ideas and proofs of concept stayed out of view until they were difficult to attack, resulting in a slower iteration process. Some pipeline failures were fixed without being surfaced. Security issues were not always reported as openly as they should have been. And worst of all, conflicts between people in their roles were not raised to C-Level anymore, of course unless C-Levels would sit you down with HR in the room and ask you for feedback on someone they wanted to fire.

The bugs disappeared. The circumstances that produced them did not.

This is the cycle John Allspaw described in Etsy’s "Blameless PostMortems and a Just Culture". When people expect punishment or humiliation, they withhold the details needed to understand why a failure made sense to them at the time. Allspaw called the result "Cover-Your-Ass engineering": management knows less, latent problems remain invisible, and the same class of failure becomes more likely to return.

The team did not stop making mistakes. It stopped producing useful evidence about them.

A leader who punishes bad news eventually disables their own observability.

That, more than the profanity itself, is the cost. The organization begins optimizing the appearance of control. Leaders receive cleaner status updates and more polished proposals. They hear fewer objections. From above, this can look like discipline. From below, it feels like learning which information is safe to share.

It is tempting to make the CTO a simple villain in this story. He wasn’t.

He was one of the most technically talented people in the company. A technical discussion with him could be genuinely great. His insistence on standards most times made the code better. He cared deeply about the product and understood parts of the system better than anyone else.

That is what made the behavior harder to challenge and more instructive.

Leadership failures often begin as strengths without a governor. Technical judgment becomes the need to review everything. High standards become contempt for unfinished work. The ability to rescue a project becomes a habit of taking it over.

Sometimes the CTO would disappear into a solo burst of work and rewrite what developers had spent a week building. The rewrite might even be better. It also taught the team that ownership was provisional: your work was yours until the person with more authority decided to become an individual contributor again.

Michael Lopp calls this "Management via Worry and Crisis". His most useful observation is not that crisis-driven managers are irrational. It is that crisis can become a coping mechanism for the loss of control that comes with leadership. The organization grows; the work moves further away; other people make decisions you would not have made. Creating a crisis brings the work—and everyone’s attention—back to you.

It works, briefly. That is why the habit survives.

People stop. They listen. They move. The leader feels the organization respond.

But movement is not the same as understanding, and compliance is not the same as commitment.

Commands need an expiry date#

I have spent most of my career in Infrastructure and Security, building and coding for it... Systems really do catch fire. Sometimes the right sentence is an imperative.

"Stop deploying."

During an incident, that command can prevent five well-intentioned people from introducing five new variables. If the role of Incident Commander is understood, the team knows who is coordinating the response and when normal decision-making has been suspended. A good incident command includes enough context to act: stop deployments, checkout is failing, Maria is the Incident Commander, send findings to the incident channel, next update at 14:25.

The legitimacy does not come from the volume. It comes from the protocol. The authority is declared, limited to the incident and useful to the people doing the work.

Imperative language should have a TTL.

Joel Spolsky made a related distinction in "The Command and Control Management Method". Command and control can make sense when soldiers must act immediately in a life-or-death situation. Software organizations are different: the person closest to the work usually has more relevant information than the executive entering the room. Spolsky called the executive interruption that follows "hit and run micromanagement." The leader knocks the work off its tracks, then moves on before living with the consequences.

"Just do it and don’t question it" has no protocol and no expiry. It treats ordinary knowledge work as a permanent incident and disagreement as a failure to execute.

Decisiveness does not require that trade.

In the meeting where the CTO hit the table, he could still have interrupted us. He could have said: Stop. You are arguing about authority, not the problem. Each of you will summarize the other person’s concern. Then we will choose the smallest proof of concept. If you still disagree, I will make the decision and explain why.

Those are commands. They would also have given the conflict somewhere to go.

The harder truth is that I wanted the CTO to provide a form of leadership that I had already failed to provide myself.

I had used my title to end an argument. My language was calmer, but the message was related: I decide; you comply. When I started my career I thought that authority meant I no longer had to consult so many people. As I grew, trained, got mentored and got coaching from people I still admire like "Ingrid Rivera" I learned that authority increases the obligation to provide context, especially when other people do not have the power to refuse your decision.

Context is not consensus. Consultation is not a veto. A leader can say that a project is already moving and will not be stopped without new evidence. The door that needs to remain open is narrower: show me which assumption is wrong, and we will correct course.

I continuously work at this. Coaching and journaling help, but the useful moment is much smaller: the pause between feeling dismissed and trying to prove that I am the authority in the room. Am I defending the decision, or am I defending myself?

When I miss that moment, the repair also has to be plain: I pulled rank. That shut down the conversation. I’m sorry. Let’s reopen it.

My father had a less technical version of all this:

Tenés dos orejas y una boca: escuchá el doble de lo que hablás.

You have two ears and one mouth. Listen twice as much as you speak.

He used to say it when I was young and likely to jump into a situation before understanding it. It took me years to see that the advice becomes more important as you gain authority. The higher you climb, the fewer people will tell you that you are too loud. They will build filters instead.

Leaders rarely notice the moment their urgency becomes noise. The team notices first.

Then, if you are lucky, they make a bingo card. If you are not, they simply stop telling you what is wrong.