Dark Politics for Engineers: Part 1

“Put your sword back into its place. For all who take the sword will perish by the sword.”

— Jesus of Nazareth, 1st century Jewish Rabbi, Lord and Savior

Corporate Politics

Corporate politics: The human behaviors of exercising power and authority in the workplace.

To double-down on this: politics is always the exercise of power and authority. Not sometimes. Always.

Politics is neither good nor evil; but it can achieve both. Politics is a agent of work and change. Productive in harnessed application but destructive in unchecked liberation.

But, importantly, you cannot escape politics. You can choose not to play, but all that does is cede the power and decisions of how to employ it to someone else. Power and authority will still exist and be exercised to shape your experience.

If you have good and wise leaders, you may be happy and secure in ceding your political trust to them. We do not always have good and wise leaders. (left as an exercise to the reader to derive this fact). The onus is on you to understand what is going on, and how to deal with it.

You: “I am not interested in politics.”

Universe: “Well, politics is very interested in you.”

Corporate politics done ethically toward productivity gets good projects approved and bad projects cancelled; it gets deserving people promoted and toxic people fired.

Corporate politics done unethically toward destruction, is the opposite: bad projects approved and good projects cancelled; toxic people promoted and deserving people ousted.

You can think of politics, like The Force, as having both light and dark sides:

Luke: “Is the dark side stronger?”

Yoda: “No, no no. Quicker, easier, more seductive.”

(For years, I thought Yoda said “more destructive” instead of “more seductive”. I still like to ponder on both versions.)

Today, let’s talk Dark Politics in context of Software Organizations. All examples and references come from first-hand witness or (ashamed to say) prior usage in my decade of experience as a Software Engineer (+5 years as a Manager).

Dark Political Strategies

A strategy is a high-level, long-term goal and plan of action to achieve it: “big picture”, Commissioned Officers stuff.

These tend to be pretty broad and universal things like the following:

  1. Get promotions you do not deserve.
  2. Get your ideas approved even when they are bad.
  3. Get rid of people you do not like, because you do not like them.

We will not spend time on these, as they tend to be motivationally self-evident and, bluntly, everyone has both witnessed one or more of these first-hand, and the honest and self-introspective amongst us will admit to, at minimum, feeling the lure of them in their own lives.

Dark Political Tactics

In contrast, tactics are small-level procedures and practices to achieve immediate short-term goals: “on the ground” Sergeant/NCO stuff.

I will address only a few today.

  1. Character assassination
  2. Technical Disparagement

1. Character Assassination

As Software Engineers, we like to pretend that we are rational beings, above the petty emotional squabbles of the mere non-programmer. This is believed, by someone to some degree, in every software organization in the world. It is disbelieved by every person outside that organization looking in on it.

In actuality, as populations and samples go, the active crop of programmers at any point in time tend to skew their averages towards particular personality traits:

Or, to put in 1980s John Hughes film terms:

Or, to put in yet other terms:

Now, dear reader, I am not saying you are like this. Obviously not. But, your co-workers? Maybe some of them, just a little bit? Yeah? Yeahhhhh?

😏

NOTE: None of my current or recent co-workers are anything like this. This applies to everyone else, but not them.

Anyways, my point is that we are no more above personal insults, idle gossip, petty grievances, and High School Glee Club drama fests than anyone else. If anything, we are probably on average worse about it than many professions.

Because I, like you fellow kids, am a highly rational, intelligent, and orderly mind, I will enlighten you with this taxonomy of drama: I call it, The Division of Drama Actor Labor, and it is thus:

  1. The Victim
  2. The Instigator
  3. The Mob

The Victims: Technically, anyone can be the victim, but certain people are easier or harder to victimize than others. This is a combo of intrinsic qualities and individual choices: victim mentality, while not being 100% explanatory, is still very real. Programmers, for reasons listed earlier, have an elevated incidence rate of victim mentality: they’re simply easier to bully, on average.

The Instigators: May be “bullies”, “gossips”, or “drama queens/kings”, etc.. You know the behavior when you see it. The goal of The Instigator is to influence and manipulate The Mob.

The Mob: Arguably, the most important actor in all drama. Whether it’s traditional bullying, gossiping, back-biting, whatever, the immediate goals are always to influence The Mob: (a) decrease the social standing of The Victim among The Mob, and/or (b) increase the social standing of The Instigator among The Mob. We engineer-types, as a group, are highly susceptible to being unsuspecting drama mobs, because it takes a degree of emotional intelligence and empathy to see through The Instigator’s play.

The Mob is the one that actually applies the social costs/benefits, which is why it’s so bad to be the gullible conscript in one: you’re the one manipulated into giving The Instigator what they want, at The Victim’s expense.

When, where, and how are character assassinations, bullying, and drama likely to occur?

2. Technical Disparagement

As Software Engineers, we like to pretend that everything we do is highly scientific and objective. Furthermore, that our very subjective opinions are not opinions at all, but self-evident, rational, even universal truths. And while, when done right, our jobs have plenty of measurable, logical processes and techniques, a significant amount of our work is (a) highly subjective and (b) deeply contextual.

Software is read more than it is written, and it is executed more than it is read.

We write software for two audiences: (a) target computers and (b) future programmers. Spoiler: the target computer that will execute your software, to the delight or disgust of your customers, doesn’t care one iota about your Software Patterns, Function Purity, Monads, CLEAN Architecture, DRY principles, or white-space discipline. We write all that shit for squishy humans behind keyboards. What’s worse, the moment you hand a software project off to someone other than the original author(s), the inheritor will inevitably conclude that whatever organizational patterns and principles initially employed were hopelessly misguided.

Good software:

  1. Works for the people using it.
  2. Makes sense to the people maintaining it.

#1 is more objective (more not totally) than #2, but both are subjective and contextual to the specific people actually involved.

The key to technical disparagement is that it is biased and faux-scientific. When Done Right™, it has superficial objectivity and impartiality, but is suspiciously lacking in context and dishonest about either tradeoffs, subjectivity, or both.

Warning flags:

Code Reviews are a fantastical place to see technical disparagement, as the contestants hide personal attacks behind gossamer veils of “this is a code smell”, “can’t this be cleaner?”, 30x “whitespace problem here”.

As well, technical disparagement doesn’t require the attacker to be more technically competent than the victim. Once any person in any technical-role surpasses early mid-level experience (aka beyond entry level), they have likely acquired enough jargon, superficial understanding, and key feedback phrases to pull it off. Call this the Gainsay Threshold.

While it is easier done downward, senior to junior, because of the Gainsay Threshold, it can be effectively employed in any direction: up, down, lateral.

Solutions

  1. Recognize Drama and your role in it
    • Are you instigating?
    • Are you allowing yourself to be made a victim?
    • Are you being courted or manipulated into joining the mob?
  2. Shun instigators when they are instigating.
    • Not all instigators are lost causes, but never reward the bad behavior.
  3. Immediately critique all negatively charged emotion directed at an individual
    • Even if you may personally want to believe it.
  4. Do the self-work to purge victim mentality from yourself.
  5. Always trend technical discussions away from “absolutes” and into “trade-offs”.
    • If you mentally said “Only Sith deal…” you proved everything said in “Character Assassinations” section.
    • If you are an engineer who does not talk in trade-offs, you are not an engineer. You are a motivational speaker.
  6. Eschew jargon not common to the audience
    • The point of jargon is to save communication time and effort among people with established pools of shared meaning.
    • Keep yourself honest by defining jargon the first time you use it in a new interaction.
    • Keep others honest by asking for jargon definition when in interactions with new or mixed company.
    • Always define jargon during written work.
  7. Blameless post mortems for problems
    • This is not squishy bullshit to spare people’s feelings.
    • You are explicitly choosing to interrogate the SYSTEM and the PROCESSES for failure, not people.
    • You are bulwarking the improvement cycle from being commandeered for Dark Politics.
  8. Suffer not the toxic process to live.
    • If your code reviews are habitually nitpicky and cursed, it would be better to do away with them completely.
    • If your Annual 365 Performance Reviews™ are addicted to negative feedback, they are easy to hijack for Dark Politics.

Conclusion

I’m tired of writing. So, I’m done now.

Don’t be evil at work.

comments powered by Disqus