Office politics is always a hot topic – even though it is actually pretty hard to define. What if what seems to be “politics” actually is just a huge misunderstanding? – Let’s investigate how this can happen and what to do about it.
While I was working at the W3C, two interesting things coincided:
On the one hand, people from a team came to me.
One group claimed: “the others” have totally lost their mind. What they want is self-serving and not for the benefit of the Web at large.
The other group claimed: “the others” have totally lost their common sense. What they want is ridiculous and obviously doesn’t solve the problem at hand.
Now, in an environment built to foster constructive co-opetition to lead the Web to its full potential, this kind of situation is happening every second, and at the time it was largely due to Tim Berners-Lee’s and Jean-François Abramatic’s (and the rest of the teams’) leadership that we always found constructive ways out. This time, it became clear to me what was going on:
On the other hand, I was reading Paul Watzlawick et al.’s “Pragmatics of Human Communication”, specifically the part about “The Punctuation of the Sequence of Events” (Link: Google Books. Read that page. It is fun, and it is full of insight), where Watzlawick explicitly writes:
… Unresolved discrepancies in the punctuation [… lead to …] mutual charges of madness and badness …
OK… Watzlawick was writing about a clinical context… schizophrenia and such, and here we’re “just” writing about office politics (though you’d be surprised… but more on that at some other time). So: how do “mutual charges of madness and badness” translate to a corporate environment?
Translating “badness”, bad intentions, is easy: bad intentions are what most people call “office politics”.
How about “madness”? – Well, the above suggests that in a reasonably healthy office environment, “madness” can be translated as lost competence and/or lost common sense.
Since then, I have consciously observed “mutual charges of madness and badness” wherever I went, often in distributed teams. From start-ups to some of the largest software companies on the planet, and it has always been an indicator for “discrepancies in punctuation”, or practically: broken context. People using the same words to talk about similar things, but with different meaning, different intentions. As a consequence, communication breaks down totally – in a way nobody recognizes.
But once we realize the context is broken, we can fix it.
For example, many years later, we were working on an important software product with teams in Germany, India and Japan, and something was seriously wrong between the teams. This thing about “mutual charges of madness and badness” didn’t go away, no matter what we tried. Team C always felt like relevant information was withheld from them, accusing team A and B of attempts to sideline them. Team A and B in turn accused team C of not understanding their job. After all, their job is simple. They have everything they need directly from team B, why do they keep poking around in team A’s business?
Eventually, we drew dependencies on a whiteboard, and team A claimed we have “A depends on B, B depends on C” dependencies, team C claimed “A depends both on B and C” (team B wasn’t even represented).
(Here’s a sketch of what we had on the whiteboard. Literally this, nothing more.)
Once we had drawn that, everybody in the room went “duh”. We all suddenly understood that both were right (A has a direct dependency on both B and C, and B has a dependency on C), and we all understood how we managed to misunderstand each other so thoroughly. Needless to say, we lived happily everafter reached a quantum leap in productivity as well as in happiness after that conversation, because one of the major impediments was gone.
And I have many more examples like that.
So, once you realize context is broken, what can we do?
Fix the context, obviously. Investigate the relationships. Elicit and challenge which patterns people apply to the present situation, even if it’s only subconsciously. Human beings are involved, so it’s emotional. Look for hopes and fears based on past experience. In software development, making non-functional requirements explicit (both on the project and on the product level) can help. Talk to people, and even more importantly: listen. Take your time, it is well invested. Listen to the nuances that reveal the presuppositions people operate on and discuss mismatches.
Do not fall for the inevitable technical or political arguments. They may or may not be factually correct, at any rate they don’t contribute to a lasting solution at this point in time. In that situation, many arguments will be – unknowingly – based on false assumptions. You need the entire team without exception to share the same understanding of the entire topic (inclucing its context) before you can meaningfully resolve whatever remains of the “real” conflict.
Lessons learned
What can we learn from these examples?
- Symptom: Mutual charges of “office politics” on the one hand and “lack of competence” on the other are – in this combination – a dead-sure sign of broken context.
- Cure: Invest the time to fix the context. Do not fall for the inevitable technical or political arguments. Fix the context, then fix the content.
Mind you: I’m not saying office politics doesn’t exist. But before we accuse others who may work as hard and passionately as we ourselves, we should rule out misunderstandings as a cause.