In Case of Cyberattack, Schedule a Meeting
Source: TSD/ChatGPT
If you’re lonely, if you’re not sure what to do there is always one thing that you can do. You can make sure that you bring your teammates down with you at the same time (great).
You can schedule a meeting. Isn’t that nice?
The same technique can be used in the case of a cyberattack.
Book a Meeting
There’s an unspoken rule in modern software companies.
When any sort of disaster strikes. When your servers go down, when user data is exposed and prod starts behaving like the undead the first move isn’t to pull logs or cut traffic.
It’s to send out a meeting invite.
In most cases the situation will be considered to be a cross-functional situation. You’ll need 12 attendees, a 15-minute delay (where everyone connects audio) and a horde of people who were invited “just in case”.
Nothing, just nothing says decisive action like waiting for a protégé Product Owner to unmute,
Faster Than Light? Our Response Time
When a cyberattack hits you’d want someone to hit the kill switch. Invalidate credentials, and isolate systems.
Yet in the real world we know what would actually happen.
We align.
We circle back.
We escalate to managers who escalate to other managers who schedule a meeting.
Somewhere, an attacker is already on their fourth coffee while we’re still fumbling with screen sharing.
The Theater of Control
Yet the system of control is functioning as designed. A crisis is (almost) never about solving problems, a crisis is actually about showing control. They’re about each and every person saying
“We’re doing something”
Even when in practice nothing is being done at all. You need to be seen to be on the call, collecting bonus points for saying “impact radius” or “customer touchpoints” at the right time.
The engineers who actually fix the issues sit quietly while managers think about synonyms that make them look clever and expand their narrative of delivering impact.
What Real Response Could Look Like
Once upon a time, engineers were trusted to act. If they spotted malicious activity, they pulled the plug. They didn’t wait for sign-off, a Slack consensus or a sync call. They used their judgment.
Things got fixed and companies remained productive. No “looping in”, or political games when the logs say “run” and your heart says “now”.
We’ve built response protocols where velocity is measured not in actions, but in how fast you can schedule the next meeting.
That can’t be right.
Conclusion
Something went wrong when software engineering became a corporate dance. Process started to get in the way of action, even in companies where you “move fast and break things”.
I know the arguments for process. It’s about resilience, right? I disagree. This is about denial in calendar form, and the avoidance of real work and development.
This is actually denial in calendar form. It’s about performative action and scheduling the next meeting. The scary thing is that some people within the loop don’t recognise that this is bad at all, they don’t see the flaws in the system they’ve created. I’m unsure that AI can get us out of this particular hole.
Next time something breaks, and shatters you should ask yourself one thing. Are you solving the problem, or scheduling looking for a solution?
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper and regularly publishes articles through Medium.com
The Secret Developer once fixed a production issue before the emergency sync had even started. They were asked not to do that again.