So there you are, with your bare face hanging out, when a staff member — call him George, on the grounds that we have to call him something and his name isn’t actually “George” — has decided to take advantage of your open-door policy, thereby revealing a flaw in the policy: It’s possible for you to get caught inside the door when it’s open.
Nor is this visit a social call. George had decided that, in his spare time, he should perform an informal technical architecture review. Which he did, and it revealed several areas of significant fragility in the architecture’s layers and stacks.
Of course, this would have been an opportunity, not a problem, had the fragilities belonged to the head of IT infrastructure operations, application integration, or cloud services. Mistakes made by organizational rivals are always opportunities. But George reports to you, and he limited the scope of his investigation to your areas of responsibility.
Engineers: Can’t live with ’em; can’t drown ’em in WD-40.
Worse, shortly after yet another company’s data breach made headlines not long ago, the CEO asked you whether all your company’s systems were backed by the multi-factor authentication controls she’s been reading about. Caught off-guard, you assured her that everything had been bulletproofed even before that attention-getting breach.
It’s too late to wish you’d asked George what, exactly, multi-factor authentication is before you blithely reassured the CEO.
Now you’re going to have to explain the rules of a certain kind of engineering to George — one essential to, let’s call it, leadership survival architecture — and hope he’s willing to follow them.
The principles of political engineering
So you thank George for his diligence, and you make an appointment — late next week, to buy yourself some planning time — to discuss the situation with him.
What George will expect is to plan a remediation program. What he won’t be anticipating will be a crash course in Political Engineering 101. What you’ll be doing your best to anticipate is what will George find persuasive, in order to explain the subject to George in a way he won’t reject out of hand.
As is general-purpose engineering, political engineering is rooted in a set of principles that are abstractions of the World As It Is. It starts with these core principles:
Principle #1: The situation is always what your audience wants it to be. Given a choice between what’s actually true and what someone wants to be true, what’s actually true doesn’t stand a chance.
Principle #2: If a problem can’t be recast to be what your audience wants it to be, it must be recast as somebody’s fault. Whose fault? Ideally, someone who has recently left the company, and so can’t defend themself. If that’s not an option, it will have to be the fault of someone who isn’t in a position to defend themself. Like, for example, a politically naïve engineer.
Principle #3: No matter what the problem is, the CEO and other big cheeses are actually already aware of it — whether or not they’re aware that they’re aware of it.
They aren’t aware of it, you say? Of course they are. They might not think so, but when the time comes, you’ll explain it to them. With confidence.
Probably, you’ll confidently explain, their awareness got lost in the translation of technical detail to business-speak. Back when you explained it (long enough ago for memories to be unreliable) the clear consensus was that there was no budget to fix it. Sometimes, in risk management, hope, also called “accept,” is the only plan worth management’s time and attention, so that’s what everyone agreed the company would do.
Principle #4: Executive management’s general-purpose solution to difficult-to-understand and expensive-to-fix problems is to shoot the messenger. Unless, that is, the messenger is “one of us” — a member, that is, of the loosely defined club that includes all the organization’s executives plus those of their proteges who exhibit the proper degree of clubbiness. Then they’ll find someone else who can’t defend themself to shoot.
Principle #5: Successful prevention is indistinguishable from absence of risk. The more successful past interventions have been in keeping something bad from happening, the more your audience will consider it likely that this time you’re just crying wolf to get a bigger budget to squander.
But there’s a catch
Articulating these principles isn’t all that difficult. Mostly it requires a strong sense of irony, and an equally strong drive for self-preservation.
The hard part will be persuading George that political engineering isn’t something sleazy. Quite the opposite, you’ll explain. Solutions that fail to adhere to these principles not only won’t work; they’ll never be tried.
Consider your persuasiveness on this front to be an example of Principle #1.
Did I say persuading George is the hard part? Sorry. Yes, it’s hard. But there’s an even harder part, which will be what comes after you’ve persuaded George. That’s when the two of you have to come up with a solution that adheres to both the principles of political engineering and the principles of IT architecture.
And you thought you weren’t already having enough fun.
See also:
