Analysis / The American View: The Towering Inferred ‘No’
The American View: The Towering Inferred ‘No’
31 July 2017 |
Maybe – just maybe – your people aren’t underperforming because there’s something wrong with them. Business Reporter's resident U.S. 'blogger Keil Hubert suggests that the root cause of the problem may lie in how your employees perceive you.
Movie goers had every reason to be anxious about high-rise living at the start of the 1970s. Truth be told, there was a lot of stuff going on to be legitimately worried about in the early seventies, but let’s focus on skyscraper anxiety for the moment. As tall urban buildings grew taller, people  discussed how dangerous living in a modern skyscraper must be. What if the building wasn’t built to code? What if it lost its structural integrity? What if there was a fire? How would the residents get out?
Those spoken fears were firmly grounded in real risk. Because of that, storytellers could play on those fears to make money off of a really scary story. Enter the movie studios. In 1973, Warner Brothers bought the rights to Richard Stern’s skyscraper-themed disaster novel The Tower while rival studio Fox bought the rights to Thomas Scortia’s and Frank Robinson’s similarly skyscraper-themed disaster novel The Glass Inferno in 1974. Rather than each put out a competing product, the two studios teamed up to split the revenue from one mega-scale disaster movie. They turned the project over to disaster movie legend Irwin Allen who brought us the star-studded epic The Towering Inferno in December 1974. The studios nail it: they grossed $139.7 million (on a $14 million budget). They also won five Academy Awards, two Golden Globes, and two BAFTAs. The movie resonated.
There’s a darned good reason for that. Unlike 2017’s effects-rich and story-bereft blockbuster disaster movies  Towering Inferno spoke directly to its audience’s anxieties about safety, security, and risk. These weren’t idle concerns. As we’ve seen, a powerful enough impact to a skyscraper can bring the entire structure down in flames. We’ve also seen all too recently that a chance combination of questionable construction decisions, inadequate fire suppression capability, and sub-optimal firefighting doctrine can quickly turn a minor, controllable structure fire in even a moderate-height tower into a death trap. Contrary to modern conceit, people weren’t stupid in the 70s  … They observed their situation and rationally calculated both the likelihood and the impact of certain risks manifesting. Those people that could afford to make a choice made pragmatic decisions about whether or not to accept the risk. Some people embraced urban skyscraper living and its inherent dangers. Others opted for the more-expensive (but possibly safer) suburban option.
It’s not that houses don’t burn; rather, that you’re a lot more likely to survive a fire when you can jump out most any window and survive the fall.
My point is that most people do make an attempt to be rational actors when it comes to dangerous situations. Yes, tons of people do amazingly stupid and self-destructive things every day. I’m not arguing that everyone is thoughtful, prudent, or responsible. If we take the loons out of the equation, though, most of the people in your office are more rational than you probably give them credit for being. That’s why they tend to (quite wisely) avoid doing things that might threaten their continued safety, like provoking the wrath of an all-powerful and vengeful boss. Even when said boss cheerfully claims that she’s everybody’s chum and swears that she’d never hurt a fly …
Here’s an example of what I mean: I was recruited to overhaul an underperforming business unit some time back. The local boss’s scope guidance to me was fairly blunt: he’d been trying to get his people focused on important work and hadn’t made any meaningful progress. His workers (he said) were vague, unreliable, spacy, prone to distraction, and unproductive. The local boss lamented that his boss – a rather overbearing fellow that we’ll call ‘Mongo’ – had run out of patience with his department’s inability to deliver results. He warned me that Mongo was considering scrapping the team if they couldn’t get their act together. My job was to get the organized and on-track.
I took the job and started interviewing the workers. I quickly noticed some crippling cultural and structural problems, the most vexing of which was that the team had no formal ‘front door’ for customers to interact with. That is, any customer could contact any team member at random and demand any service, even ones that had nothing to do with the team’s charter, skills, or capability. This had led to a massive backlog of work – both unfinished and un-started projects – which built up considerable resentment among the team’s customers. That crowd rage, in turn, fired up angry Mongo, who vented his displeasure down on the seemingly-ineffectual team boss.
The team’s situation was untenable. It didn’t take a social scientist to realize that the team’s culture was dangerously dysfunctional. They needed a rational structure, a clear mandate as to what was (and was not) in-scope for duty, and they needed a single gateway. A chokepoint, if you like, where a few dedicated sentries received, triaged, and routed new work requests, so that only viable, in-scope jobs ever got added to a team member’s queue. Supervisors, then, could prioritize and resource work to get the most important work done first. Logical. Organized. Predictable. Manageable.
Not to mention friendlier. Customers love it when cross-departmental support requests are handled without unnecessary drama.
Does this seem overly complicated? Why not just tell the workers to ‘buck up’ and cooperate? I discovered that the local boss had already tried that, and nothing had come of it. One of the main reasons why was that one team member in particular had been individually responsible for accepting 45% of the entire team’s workload, all without her boss’s knowledge or permission. The team’s customers had figured out that this particular engineer was a sweetheart; she was so loyal and kind that she’d never say no to anyone for any reason. She was also hugely embarrassed by how far behind she was in ‘her’ projects, so she never spoke up for fear of making the local boss furious with her.
Remember that motivation. We’ll come back to that in a second.
The gateway solution I’d pitched was designed to eliminate the ability of anyone other than the authorized decision-makers from accepting new work. It ensured that the people responsible for setting priorities on labour had to understand what a job was before they assigned people to work it. No more ‘stealth’ jobs sneaking in that required more time, labour, or money to complete than we’d been allocated. A project that was out of scope wasn’t accepted up-front. A customer might be irritated, but they wouldn’t be set up for crushing disappointment and betrayal a few months later.
I designed the intake function – modelled on a basic ITIL Service Desk – and wrote up the pitch for Mongo’s approval. I wrote all the process and procedure documents to go with it, so that whoever got assigned to (or hired for) the function would be ready to implement the new service management model immediately. I gave it to the local boss and … nothing happened.
A month later, I asked the local boss what had happened to the intake team proposal. Had Mongo approved it? Did he want changes? The local boss admitted that he’d never submitted the package up for Mongo’s approval because he felt strongly that Mongo was likely to deny it. Even though the structural change was crucial for the team’s recovery, he hadn’t acted on it. He’d let the proposal rot and his team keep screwing up because he didn’t want to risk antagonizing his boss.
I received one of Mongo's ‘random unexplained explosions’ shortly after I was hired. Left me more shocked than upset, but I can see why others might have been frightened of the fellow.
Hmmm. There’s that same reaction. It wasn’t a coincidence at the time, and it isn’t in this story.
As I dug into the team’s culture, I learned a why all of these seemly-self-destructive people acted so squirrelly. First, there had been several rounds of layoffs in the company’s recent past.  A little over one quarter of the team had experienced ‘layoff hell’ before, and had been traumatized by it. Everyone knew that more layoffs were coming.  Making things worse, Mongo famously had a hair-trigger temper and was known to rage at his direct reports over everything and nothing depending on his mood. It was well known that reported delays, errors, and excuses were highly likely to set him off. Therefore, his more experienced team members (like the local boss and the team sweetheart) were absolutely unwilling to say or do anything that might provoke the man.
This is where that rational actor idea comes into play: I’d thought (at first) that my teammates were being inexplicably irrational They were going about their jobs in such a counterproductive and unsustainable way that the team’s failure and collapse was inevitable. I couldn’t initially believe that they were deliberately allowing themselves to fail, especially when they had the ability to rebuild into something much more valued and productive. The more I watched people work and interviewed team members away from the office setting, though, the more that I came to realize that they weren’t crazy after all. They were just pursuing the least-painful of several awful options.
Specifically, the local boss had already learned through traumatic experience that Mongo hated organizational changes. He wouldn’t sign off on promotions or add new managers. Those things seemed (to him) to represent a response to failure, and he hated the spectre of failure. He’d explode and lash out when asked, sending the requester fleeing. If failure was guaranteed, why bother?
At the same time, the team sweetheart had learned that she daren’t ever refuse to accept new work – and couldn’t tell the local boss that she’d taken on new work either. If she turned down a job, the frustrated requester would report that up to Mongo who would, as sure as gravity, throw a fit. The sweetheart would take flack for not being a ‘team player’ (even though it wasn’t her job). Likewise, if she accepted a job and then reported that to her own boss, he would lash out at her for undermining the management chain. She was a bundle of raw nerves, and crippled by her backlog of projects.
Eventually, all of her labour was going towards keeping the proverbial tyre fire below management’s threshold of awareness. Nothing productive was actually getting done.
In each of these scenarios, the affected employees had already learned to infer their respective bosses’ intent. They knew from experience that if they asked for help, they’d be told ‘no!’ If they asked for relief, ‘no!’ If they asked for structural or organizational change, ‘no!’ Those inferred ‘no’ answers had a devastating effect on the entire team’s efficiency, productivity, and morale.
Most importantly, these were entirely rational fears. Both the local boss and his workers had observed their situations and had calculated both the likelihood (certain) and the impact (termination). None of them could risk being laid off during a down economy. Since they lacked the wherewithal to escape their inherently-dangerous environment, they did everything within their power to minimize their chances of triggering an easily-ignited boss’s temper. They weren’t being productive, but they sure as hell were being grimly pragmatic. I can’t fault them for that.
The takeaway here is that an office culture is dominated by the shadows thrown by its leaders. People are quick to recognize dangers, and they rationally attempt to evade those sources of conflict that might hurt them. They learn to recognize patterns, preferences, and reactions, and then alter their behaviour. If you’re in charge, take a very hard look at the culture you’ve created. Do your people feel comfortable bringing you bad news? Do they avoid letting you see or hear things that upset you? Do they avoid being in your presence? More importantly, do your people allow themselves to be unproductive and even court failure rather than tell you their issues?
If the answers to any of those questions are ‘yes,’ it’s time for an intervention. Despite what the Harvard MBA case studies may have told you, the problem doesn’t lie in your people. They’re not stupid or ignorant; they’re just rationally and appropriately afraid of you. If that’s the culture that you’ve created, then you’d best fix the problem – swiftly! – before your whole organization goes up in flames around you.
 … and by ‘people,’ I mean my parents and people from their social circle. Yes, I was around back then. Let’s not make a big deal out of that.
 Geostorm? I’m looking at you.
 I blame disco more on the bankrupt late 70s zeitgeist than on simple stupidity.
 A bunch of seasoned engineers were laid off the day that I signed on with the company.
 Two months later, half of our entire US division was terminated. Those jobs were all shipped overseas.
Title Allusion: Richard Stern, Thomas Scortia, Frank Robinson, and Stirling Silliphant, The Towering Inferno (1974 Film)
Photographs under licence from thinkstockphotos.co.uk, copyright: man shouting, dundanim, house fire, JohnCarnemolla, portrait business woman, JackF, frustrated office manager, OtmarW, firefighter, pavelmidi
POC is Keil Hubert, email@example.com
Follow him on Twitter at @keilhubert.
Keil Hubert is a retired U.S. Air Force ‘Cyberspace Operations’ officer, with over ten years of military command experience. He currently consults on business, security and technology issues in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo!, and helped to launch four small businesses (including his own).
Keil’s experience creating and leading IT teams in the defense, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employee development… This serves him well as Business Reporter’s resident U.S. blogger.