The American View: The Art of Deliberate Miscommunication: Decoding Office Politics

Communication is supposed to be a critical business skill. Search for the string “business communication” and you’ll get hundreds of ads for MBA programs that extol the supposed virtues of communication as a crucial business enabler (or some other pithy phrase) in their “unique” curriculum. Every leadership course I’ve ever taken devoted time to “teaching” the effective communication … as if we were aliens who’d never interacted with humans before. Everyone from Scouts to SCOTUS pretends that clear comms are critical competences.  

Why, then, do people who have presumedly been extensively trained in effective workplace communication so often foul it up? I don’t mean by accident … we all fumble words, let our dialect obfuscate our delivery, and lose the plot. I mean, specifically, why do trained and experienced professionals deliberately fail to communicate effectively with one another? Doesn’t make sense, does it? 

I contend that such a deliberate “error” makes perfect sense when you put deliberately failed communication into its proper context. As a practical example, consider an exchange I had with a junior partner a long time ago. This partner – we’ll call her “Bob” [1] – ran government IT consulting jobs Inside the Beltway. I’d never heard of her and wasn’t on her team. 

I got called in when the senior federal sector partners decided that our firm should get certified in Carnegie Mellon Software Engineering Institute’s Capability Maturity Model. Their thinking was that Bob’s project could get our firm’s certified to take on more government coding jobs. 

There was just one major hurdle to clear … Despite the firm’s insistence that we wouldn’t do any more software development work, Bob had signed a contract with an federal agency to write an application that would be used in all their offices nationwide. Since our firm had already fired all our in-house developers the year before (getting out of the segment, yeah?), Bob was forced to scramble to find coders after her contract was signed. In the end, Bob hired a brat pack of recent college grads who had never held a corporate job before and had never delivered a commercial product. Bob set her coders loose on the client’s specs and largely ignored them until close to the end of the engagement. 

Cue me: when the senior partners tasked Bob to get her project SEI CMM certified, she complained that she didn’t have anyone qualified to do the CMM grunt work … therefore she shouldn’t be expected to be the firm’s exemplar. Enter my owning partner who called Bob’s bluff. “I have a guy,” he said, “who can take care of everything. Make it happen.” 

The following Monday saw me on a plane to D.C. with a thick stack of printed SEI CMM doctrine, cramming like mad. I was not (and still am not) a programmer. I knew nothing about software quality assurance at the time and I’d never heard of the SEI methodology. My owning partner didn’t consider that an impediment; he regularly used me to “troubleshoot” his engagements as his token “pro from Dover.” His “figure it out on the plane” order was standard operating procedure for us.