revoke: if the company falls apart, that's their fault

Show Notes

My DBA is standing in my doorway and she is not asking permission. She's found forty-one active connections to our production database. She can explain thirty of them. Eleven, she can't, no matter how many times she asks around. So she's decided: revoke all eleven, today, and see what screams.

This episode is about the scream test, a real and genuinely useful operational technique for finding hidden dependencies, and about what has to be true about an organization before a careful, diligent person decides that revoking things blind and waiting for the fallout is the responsible move. I walk through what a scream test actually is, how access hygiene quietly rots in every org I've worked in, and what her decision was actually saying underneath the bravado.

I'm not going to tell you how it ended. I don't think the ending is the point. The point is that eleven unexplained connections don't appear overnight, and neither does the moment someone finally decides they're done being the only person worried about it.

If you've ever been the one person on your team flagging something nobody else wanted to look at, or you've ever inherited a system you couldn't fully account for, this one's for you.