American View: Junior Executive Rodeo Daredevil-June 2016

It’s another Mongo Monday! Business Technology's resident U.S. blogger Keil Hubert revisits a tech executive who had his organisation running in frantic circles because he couldn’t be bothered to ever explain what exactly he wanted his people to do... Last week, I introduced a fellow that I called ‘Mongo’ after the giant thug from Mel Brooks’ Blazing Saddles. I really like this guy as a case study – so much that some of my favourite Mongo stories have been interrupting my train of thought all week. Here’s one that I use to tell friends and family when they disbelieve how weird that office environment really was. If you’d prefer not to backtrack, the executive summary version of Mongo’s story goes like this: Mongo was a swaggering, larger-than-life division head in a very large IT company. Most of his people were awestruck by him. They were simultaneously terrified of upsetting him and utterly confused about how to handle his mercurial approach to leadership. The man epitomized the classic ‘cowboy attitude’, in that he did whatever he wanted according to his whims, and he demanded that the world bend to accommodate said whims. These were great traits for a movie supervillain; they were sub-optimal for a senior leader in a complex global corporation. One of my favourite Mongo episodes illustrates his unthinking and self-destructive approach. It was excruciating to endure at the time, but it’s grown funnier with distance. It also sheds some light on why the fellow was admired, feared and loathed by his people. [caption id="attachment_44503" align="alignnone" width="1200"] He stood alone, towering above all lesser men. He was a complete… er… bristly fellow.[/caption] Shortly after I joined the company, my boss – let’s go ahead and call him Bob – confided to me that he needed help getting his team organized. At first, they’d been just a half-dozen senior support techs. Their original remit was to solve thorny process flow and organisational structure problems in IT service delivery. Unlike a traditional ITIL Problem Management group, Bob’s team wasn’t formed to work on customer issues. Instead, they supported the business itself. They duplicated the functions of several existing groups [1] because Mongo felt that those other folks weren’t responding quickly enough to address his division’s needs. By the time I signed on, the team had tripled in size and was due to triple again as it opened branches in two more countries. It was obvious that Bob’s team was highly regarded: he got increased headcount while everyone else in the division was laying people off. Bob himself was invited to every major meeting and project kick-off. It was rumoured that Bob had Mongo’s confidence, and had more influence over company operations than the senior directors. In classic Silicon Valley style, their realty was much uglier than their marketing suggested. Yes, the team had grown fast and yes, they were tangentially involved in lots of activities. They were also flailing ineffectually at far too many ill-defined projects and weren’t accomplishing anything. Bob wanted to get us organised so that we could actually deliver some tangible value. As it stood, his group was in danger of being dissolved because it didn’t seem to actually do anything. I devoted a month to passively eavesdropping on meetings and actively interviewing my teammates to learn what they were involved in. I turned my notes into a comprehensive activity map and tried to plot the assumed priorities. Shortly before the holidays I presented Bob a chart that listed all of the known and suspected projects, tasks and activities going on in within his group. I asked him to confirm that these were, in fact, all of the things that Mongo was expecting us to deliver. Bob admitted that he didn’t know what two thirds of the entries on the list were supposed to be. [caption id="attachment_44504" align="alignnone" width="1200"] ‘I’m lost. Does the five-legged elk represent the customer, the malfunctioning equipment or the open trouble ticket?’[/caption] I went back and tried to extract more background and context from the workers. In many cases, the person assigned to a job didn’t actually know what he or she was supposed to accomplish. Usually, this was because either Bob or Mongo had told them to do something in passing, and then never explained exactly what he wanted done. Other times, an individual employee would be approached by an outsider and would be told that Mongo or Bob had committed the team to a job. The situation was an absolute mess. Work was piling up faster than it could be analyzed, and nothing was actually getting done because no one knew what to do. Bob told me that he wanted to get control of our workload, so I built him a formal work-intake process. I designed a single point-of-entry solution that screened all new inquiries, formally triaged jobs for prioritization and centrally tracked all formally-accepted work. Bob was tepid to the recommendation and never put it into operation. When that idea failed to launch, I tried getting a grip on the existing workload. I documented all of the known project-level activities, drafting a report for each one about its context, scope, desired outputs, timelines, assigned and involved workers and expected deliverables. I built a visual ‘dashboard’ for Bob to go with a ‘scope catalog’. These were meant to help Bob see how many conflicting activities he was managing. I hounded him for weeks to sit down with me and confirm that my interpreted scope statements were correct so that people would have some clear guidance on how to proceed. When Bob finally ran out of excuses and sat down with me, I learned that he didn’t know what over half of the projects on the list even were. They’d all come from Mongo, he admitted, and no one on the team knew what Mongo really wanted… including him. I was flummoxed by it all. Our group was tearing itself apart from the constant direction changes, and nothing was actually getting accomplished. There was labour, but no output. The team members were stressed out trying to meet undefined objectives that changed faster than the Texas weather. I argued with Bob that we were going to fail – and fail hard – if we couldn’t select a few projects and actually deliver on them. He said that he agreed, and promised to bring the issue up with Mongo. [caption id="attachment_44505" align="alignnone" width="1200"] ‘I totally promise to do that. Also, you’re a valued employee and I value your input.’[/caption] A week after I presented the draft scope catalog, Mongo pulled Bob aside for a private meeting. They filled an entire whiteboard with notes about the projects that needed to be completed in the new fiscal year. When the rest of us saw the list the following Monday, it felt like falling off a building: 90 per cent of the entries on the whiteboard were undefined nouns with no context, and the target dates seemed completely random. We had no way to interpret these new inputs. I asked Bob what the hell we were supposed to take away from the mess, and he said that we’d need to hold a formal meeting with Mongo and ask him. I sighed and agreed to make the arrangements. It took me nearly two months to make the meeting happen. I arranged it so that everyone in the room had a copy of the activities list, the scope catalog and our list of objectives. I opened by starting that our most important goals for the event were to clarify what exactly it was that Mongo wanted for each listed activity, and then to rack-and-stack the work according to his priorities. The event was a complete *£&$-up. As expected. Mongo was late (as always) and arrived sporting a bad attitude. His tone and body language both suggested that he was seriously put out at having to waste his time with us minions when he had so many more important executive-y things to do. As we presented our list of semi-defined projects, Mongo refused to comment as to whether or not we had the right scope and outputs. I explained that most of the people that we’d listed on the project team lists weren’t actively working on the projects, because we didn’t know what he wanted done. We were guessing at nearly everything, and we needed his guidance. Instead of giving us what we asked for, Mongo got angry and demanded that we give him freaking status reports for each of the listed projects. Right then. Tell him where we were on jobs we didn’t understand and hadn’t started. [caption id="attachment_44506" align="alignnone" width="1200"] ‘So, if Scorpio is in the house of Mars, that means we’ll get our next bug-fix from the developers on time, right?'[/caption] It got worse. After impatiently refusing to answer our questions about the first dozen projects (on a list of eighty), Mongo started demanding to know when each project was going to be completed.  A couple of our teammates workers let our side down by blurting out random dates: ‘I can have it finished by the end of May. No problem.’ I groaned. They were reflexively making dates up to try and escape Mongo’s angry glare. The projects still weren’t defined. We didn’t know what ‘success’ consisted of, so there weren’t any coherent plans. Stating a date was pure speculation. But Mongo was angry, so people caved. They threw him meaningless dates in the hopes that he’d spare them. I quietly seethed at the podium as the meeting spiraled into farce. These were all senior engineers, developers, project managers and the like. They weren’t fools, but they were completely out of their depth. They didn’t know what Mongo wanted, which meant that they had no idea how to give him what he wanted. Instead of explaining himself, Mongo seemed incensed that people weren’t taking his cryptic oracular fragments and running with them. This is where the title allusion comes in, and I want to pause to explain it because it’s a really obscure reference. Junior Rodeo Daredevils was a short educational film published in 1949 that (I assume) was intended to teach viewers about what-all happens at a rodeo. I stumbled across this gem thanks to Mystery Science Theatre 3000. They MST3K crew lampooned Daredevils as the lead-in short for their satirization of the 1959 horror movie The Killer Shrews. [2] Go watch 'em both as soon as you have time – not the original films, but the riff-enhanced versions. Anyway, Daredevils has a simple plot: some kids get caught messing about by elderly cowboy ‘Old Billy Slater’. As punishment, the two kids are forced to organise a junior (children’s) rodeo for their community. Everyone in town cheerfully participates. Rodeo things happen. The premise isn’t important; what goes unspoken in the film is that everyone in town knows exactly what needs to happen without being told or taught. The old cowboy tells the prepubescent delinquents to hold a rodeo, and they (somehow) know exactly how to plan, organize, promote, construct, staff and supervise an event involving dozens of animals and hundreds of townsfolk. Also, every child in town knew how to ride bucking broncos, rope calves, wear chaps without looking ridiculous, etc. I understand why the filmmakers did this: the backstory and logistics aren’t relevant to the main message. They had nine minutes of screen time and wanted to show as many rodeo events as could fit. They ‘hand-waved’ away the actual setup and took it for granted that everyone in the town was a professional rodeo worker with 10-plus years experience – even the five-year-old children. [caption id="attachment_44507" align="alignnone" width="1200"] ‘The best part of turning six? You get to start smoking the unfiltered Turkish brands.'[/caption] How does this fit in with Mongo? Because that’s exactly how Mongo ran his operation. In Daredevils, ‘Old Billy Slater’ only had to say one sentence in order to get small children to plan, organize and carry out a complex logistical operation. Mongo seemed convinced that all he needed to do to was utter a single word or phrase – devoid of any context – and people would magically know exactly how to execute fantastically complex interdepartmental (and sometimes international) projects. Mongo didn’t deign to explain himself, and didn’t answer requests for clarification. He simply made his royal pronouncements and expected the rest of us to magically bring his wishes to life. About halfway through the meeting, it was clear that we weren’t going to get any actionable information out of Mongo. He’d discarded our agenda and refused to entertain any more questions. He didn’t de-conflict any of the work efforts, even when it was glaringly obvious that there were too many ‘top priority’ jobs in the queue. Mongo expressed that he wanted us to commit to him that we’d deliver results on a schedule, even though he refused to explain what he wanted, and wouldn’t listen when people plaintively asked for clarification. Mongo left the meeting angry, and we all left confused and dispirited. One of our senior engineers quipped that it would have been more productive to have never met at all. He wasn’t wrong. That was Mongo’s ‘leadership’ in a nutshell. Mongo created work for others from half-formed ideas and random observations. His ‘assignments’ were often incomprehensible and context-less. He refused to explain anything, ever. When cornered, he might tell a person to do tasks X, Y and Z… but would instantly change his mind about what he wanted (and would forget everything he’d said) the moment the discussion was over. He kept his people in a constant state of directionless anxiety. Mongo seemed to consider himself a brilliant strategist; based on the meetings that I had with him, Mongo seemed to assume that his every utterance conveyed a novel’s worth of deep meaning that everyone within earshot understood perfectly. No wonder it annoyed him so much to be questioned! When Mongo spoke, all of his people nodded along. He was under the misconception that his listeners’ awkward silence indicated their comprehension and agreement. [caption id="attachment_44508" align="alignnone" width="1200"] Hint: people don’t turn deathly pale, adopt a defensive posture and begin whimpering when they want to convey confident agreement.[/caption] Worse, Mongo assumed that everyone working for him possessed 100 per cent of the skills and experiences needed to complete whatever new assignment he threw at them, even when faced with unprecedented situations, new technologies or undefined problems. Mongo was our Old Billy Slater and we were all his precocious rodeo wranglers. All Mongo needed to do was proclaim a vague objective, and we’d ensure that His Will Be Done… no leadership required. [3] The key takeaway for all aspiring and current executives is this: you are not nearly as clear as you think you are. Your grand vision is important – and necessary! – but your primary function is to empower your people to execute your will. That doesn’t mean delegating responsibility for an initiative and then walking away; it means staying engaged with your team members and constantly communicating what you want (and how you want it). It means investing in your people’s skills, equipment, and experience until they’re capable of reliably giving you what you want. It means constantly explaining the broader context and nuances of operations that the people below your echelon can’t perceive or understand so that they can make sound decisions. And finally, it means humbly listening to your subordinates when they signal that you’re not giving them what they need to succeed. Getting bellicose with your people because they can’t read your damned mind isn’t leadership – it’s infantile bullying. It alienates the only people who can make your operation succeed. Businesspeople aren’t movie characters. You can’t ‘hand-wave’ away the difficult parts of running a company because you don’t feel like dealing with your people.  For that matter, if you despise your own workers, then you don’t belong in business in the first place. Everyone would be much better off if you became a real cowboy and disappeared over the bloody horizon.

---

[1] Including Quality Assurance, Project Management, Bespoke Development, the actual Problem Management group, Business Process Improvement, Internal Audit and a bunch of others. [2] Sing it with me, fellow MSTies: Killer shrews! Killer shrews! K-I-double-L-E-R shrews! [3] The entire operation collapsed not long afterwards and the division was broken up into disparate chunks. Mongo, of course, got a new job within the company. Most everyone else got laid off. None of this came as a surprise. Title Allusion: Junior Rodeo Daredevils (1949 Short Film)

---

POC is Keil Hubert, keil.hubert@gmail.com Follow him on Twitter at @keilhubert. You can buy his books on IT leadership, IT interviewing, and Horrible Bosses at the Amazon Kindle Store. 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 Technology’s resident U.S. blogger.