My wife and I had a pretend row during our morning constitutional Sunday about what you call the parts of a door. After years of enduring soul-corroding IT project work, our argument didn’t surprise me all. If anything, it illustrated exactly why so many big IT initiatives fail: terms.
For context, we replaced our home’s front door last week. We’d wanted to replace the darned thing since we moved in. The house’s previous owners had replaced the original door with an odd-sized steel monstrosity. They’d probably done the work themselves given the shoddy quality. We’ve been undoing all the original owners’ “improvements” since we moved in.
The front door was one of the last projects on our to-fix list and we were quite pleased with our contractor’s results. Everything in and around the doorway had to be rebuilt to return the front of the house to industry standards. New framing, new trim, new baseplate … if it had something to do with the idea of “door,” it got replaced. That’s where our follow-on problem started.
We’d been talking about how best to pain the new door since we chose which door we wanted. I’ve consistently wanted the outside of the door to match our house’s paint scheme (the one decision the previous owner had gotten right if I’m honest). My wife said she agreed with me, so we’d move on. Every time we discussed the paint scheme, I thought the topic was settled and I wondered why she kept bringing it up. This morning, we’d barely made it a hundred metres from the new door when she brought up the door painting plan again.
“So, you want the front of the door to match the light blue of the outside of the house?” she said.
“Yes,” I said.
“And you want the door trim to be the dark blue of the outside of the house.”
“Again, yes. We covered this yesterday …”
“But what about the wood bits around the window?”
I blinked, confused. “I want that to be the dark blue of the outside of the house. I just said that.”
“No, you just said you want the trim to be dark blue. I mean the wood that frames the window.”
“Right! The ‘trim.’ I thought that’s what we’ve been talking about for the last week.”
“No, no!” she said, exasperated. “The trim is the part the covers the frame the door is set in!”
“What the what? You mean the wooden slats that are nailed to the house trim and aren’t part of the door itself? Those bits?”
“Yes! The door trim!”
“Those aren’t part of the door! You’ve only ever asked me about my opinions on the door, not about the wooden trim on the house that needs repainting.”
“But it all went in together so that makes it part of the door!”
“What?! Are you drunk? We bought a dog bed when we got the dog but that doesn’t make the dog bed part of the dog … You don’t take the dog bed out back for a wee before bedtime, do you?”
The joggers that passed us side-eyed us like we were crazy. They probably had the right of it. My wife and I were both gesturing wildly while we bickered and used our best exaggerated argument voices, more for our own amusement than because we were truly upset. It’s an entertaining way for us to blow off steam.
In truth, I realized from our latest argument we had been talking past one another for days; that’s why my wife kept restarting the conversation. She visualized something completely different from what I’d said (and to be fair, vice versa). The problem wasn’t a disagreement over visual aesthetics; the problem was neither of us knew the obscure builder’s terms for the various parts of a door assembly. Not being construction workers, we’d each picked up bits of … let’s call it “door lore” … from friends, family, colleagues, and home repair sales weasels.
In truth, both of us were wrong. We had been inadvertently talking past one another. According to this diagram (which I’ve seen versions of on a dozen other home improvement sites), the wooden trim-like bits that cover the place where the “lite” (the glass embedded in the door) are called either a “stile” or a “mullion” depending on the person making the diagram. The part that my wife was calling “trim” is consistently called “casing” by builders.
Had either of us left the other to paint the door and surrounding bits on their own, the other person would have been perplexed and angry at the result. It took several arguments to figure out where we were failing to synch up.
This is a normal part of married life … and of work life, too. If you don’t believe me, serve a shift or two on the Help Desk. You’ll experience the same shared vocabulary problem. For illustration, I’d like to offer a sanitized example from one of my own shifts:
“Help Desk, how can I help you?”
“Yes, I’m having trouble with my computer displaying colour.”
“I see. Has this problem just started since you last rebooted?”
“No, it’s been going on for a week now and it’s getting worse.”
“Oh no! Let’s see if we can help get this solved. Does it affect the entire screen or just a part?”
“What are you talking about? The screen is fine! I’m talking about the display.”
“I … um … sorry, what? Can you describe the problem from start to finish?”
“Aren’t you listening? I said that the computer won’t display my colour documents correctly after I finish them!”
“That’s where I’m getting lost. How do you know your PC isn’t displaying colour correctly? Are the colours changing on the screen while you work? Or are the colours changing after you save and re-open your documents?”
“Stop being an idiot! I complete a project in PowerPoint and tell it to display and it comes out missing all the red bits.”
“Ah, hrm. What do you mean by ‘I tell it to display’?”
“I go to the ‘file’ menu, choose ‘print,’ and the display comes out without any red in it.”
<long pause while I fight the urge to reach for the “clue bat”>
“Just so I have this right, you print your file to the printer by using the print command to tell the printer to print your printout and that is what you mean by saying you ‘display’ your work?”
“Of course! Can you please transfer me to someone who knows about computers?”
That example isn’t as fictional as I’d like it to have been. Nonetheless, it provides a fine example of my previously described “door spat” problem: normal people frequently learn technical vocabulary incorrectly. They know what they’re trying to say; their explanations or questions are only gibberish to people who know the correct terms for the things the speaker is misdescribing.
Like every other communication problem in the workplace, the risk of financial and reputational disaster increases exponentially every time a bad decision is made a step up the organisational power structure. By that I don’t just mean “rank” in the traditional sense; I mean one’s ability to commit the organisation. In some cases, a senior individual contributor or project manager can inflict just as much damage as the CEO. If you’ve ever had a procurement clerk lock your org into a multi-year global contract for the wrong kind of printer ink, you know what I mean.
This goes double for tech and security initiatives. Our profession uses so many obscure acronyms, initialisms, and buzzwords that each require extensive technical education to understand in context that it must be accepted as an omnipresent project risk that some critical stakeholder or decision maker will have a completely and dangerously incorrect understanding of what’s really happening. This isn’t an insinuation that senior leaders are stupid. Rather, I’m arguing that our obscure and proprietary professional lexicon is a distinct project impediment in and of itself.
We cannot keep blithely referring to terms like “SIEM” and “CASB” and “XaaS” in our project plans and status reports and assuming that everyone listening knows exactly what the hell we mean! Down that path lies disaster. Eventually – inevitably! – every project is going to experience a major screwup where it’s discovered that two or more project teams or critical stakeholders held incompatible, contradictory, or simply wrong understandings of how some technology or function or process was supposed to operate … all because of definition failures.
This is usually a minor irritation in a marriage. Doors can be repainted, and everyone can laugh about it. In business, though, such “wacky misunderstandings” can be hellishly expensive in time, treasure, and stakeholder patience. The best practice to pre-emptively mitigate this risk involve clearly defining your technical terms up front, regularly checking to ensure everyone shares a common operational picture and avoiding technical jargon to the maximum extent practical.
That, and make it a point to push back every time you think someone might be using a term incorrectly. Make sure you’re all on the same page. If they really care about you, they’ll do the same to you when they think you’re talking nonsense.
