Y’all asked for another Mongo Monday. Who am I to say no? Business Technology’s resident U.S. blogger Keil Hubert returns to a popular tech executive who never adjusted his leadership style when the world overtook him.
Director Sam Peckinpah earned a reputation for being an iconoclast. His movies – especially his Western genre films – were shockingly graphic for their time and tended to unsettle audiences that came to the theatre expecting more conventional stories. Wikipedia’s profile of the man says it best:
‘Peckinpah’s films generally deal with the conflict between values and ideals, and the corruption of violence in human society. He was given the nickname “Bloody Sam” owing to the violence in his films. His characters are often loners or losers who desire to be honorable, but are forced to compromise in order to survive in a world of nihilism and brutality.’
There’s a lot of truth in Mr. Peckinpah’s worldview. Most of us struggle to in our professional lives to hold on to our integrity while beset on all sides by scheming peers, irrational customers and abusive bosses. Even if we can somehow manage to avoid becoming corrupted by it all, a decent into despair is often inescapable.
That’s why I’ve been telling stories about a fellow named ‘Mongo’. Mongo was a terrifying presence in his company. He wasn’t ever intentionally abusive towards anyone (as far as I could tell). He wasn’t sadistic. He did have a temper, though, and a tendency to demand that others indulge his whims. In many respects, he resembled Vincent D’Onofrio’s astounding performance as the supervillain Kingpin from Netflix’s Daredevil series. That is to say that Mongo was a large and physically imposing man who frequently and randomly boiled over. When Mongo got mad, he’d lash out at everyone around him. Oddly, Mongo’s more seasoned people had learned how to weather the man’s outbursts and stopped being overly afraid of him. If anything, they went entirely too far the other way: his old-timers were fiercely loyal to him, even though they also feared being in his presence.
Mongo’s connection to the works of Sam Peckinpah resonates best with Peckinpah’s classic 1969 cowboy movie The Wild Bunch. The movie itself is dark; it’s a story about aging outlaws who attempt one last bank robbery, knowing that the world has changed so much that their way of life has become obsolete. The story transitions quickly to a hopeless moral quandary: when a member of their band is captured, the survivors have to decide whether to remain loyal to their own (and, thereby, assuredly die in a futile rescue attempt) or to abandon their failed lives, flee and thereby survive. It’s a gripping film, and it raises more questions than it answers.
It resonates here. The bombastic and charismatic Mongo represented a bygone era in his industry. When he first started off in IT, he managed tech in a small and dynamic company. According to some managers that knew him back-when, Mongo came into his preferred leadership style early: he managed his engineers largely by force of personality. When his people weren’t meeting deadlines or needed to change priorities, Mongo would square his shoulders, glower, and roar… and it worked.
People responded to Mongo’s bluster swiftly and positively. That created a sort of feedback loop for him. Rather than use the technique when it was the optimal choice (and, by extension, use other techniques when warranted), Mongo used the same approach for pretty much every encounter. He brought that approach with him to his next company and to the one after that according to a person who came along for the ride. In each of those outfits, the dominant office culture was that of a small- to medium-sized tech sector start-up. In those environments, personality and momentum were more effective virtues than logic or documentation. Why rely on policy when you could energize an entire team to follow whatever great idea you thought up on the spot? Give the man credit: his approach made him very successful, very popular, and very rich.
By the time I met Mongo, he was no longer part of a free-for-all, wild-and-crazy, start-up style culture. A multinational corporate giant had gobbled up his previous company and kept him on in roughly the same capacity. Mongo was expected to change his approach to resemble the dominant (and often mandatory) practices of his new mother company. He needed to become regimented, predictable, data-driven… attributes that he was intellectually capable of, but that didn’t fit his preferred style. Since Mongo was successful, popular and well-compensated, he must have figured that he’d carry on with his winning approach, and that the rest of the global corporation would eventually conform to accept his way of doing business. This caused us all a lot of grief.
As an example: one of Mongo’s team’s key applications had grown obsolete and was scheduled to be retired. The company had a half-dozen apps that all performed the same function for different product lines. The apps had each been inherited during acquisitions and mergers, and got progressively less funding as time went on in favor of the mother company’s flagship standard version. There’s nothing necessarily wrong with that; most large companies operate this way. Anyway, Mongo’s bosses had committed to retire one of the older applications and decided that all clients affected by the change would be migrated to a newer, better-supported version. Fine.
One of Mongo’s more important clients got wind of the pending change and got anxious about the switch. Would they lose functionality? Would they lose visibility into open jobs? Would the change negatively impact their ability to do business? They cornered Mongo and demanded assurances. Mongo promised the head of the client company that he’d personally guarantee that they could keep using the old version of the application even while all of our other customers switched over to the new one. ‘No problem!’ he said. ‘We’ll do whatever it takes to keep you happy.’
It’s okay to admire Mongo’s commitment to customer satisfaction. He wanted to preserve the trust and loyalty of a valued customer and was willing to move heaven and earth to allay the client’s fears. Mongo even put his personal reputation on the line in the process. He was bold! Decisive! Even admirable, from a certain point of view. What he wasn’t was sensible. Mongo never bothered to check with any of his engineers first to see if what he’d promised the client was even feasible.
Mongo came back to the office and demanded that his managers come up with a solution that would allow him to deliver on what he’d promised to the client. From what I was told, everyone in the room squirmed uncomfortably. The application transition was being handled by corporate IT – not by anyone in Mongo’s department. No one within Mongo’s domain could change the timeline or meaningfully affect the plan. They weren’t sure what to do and said so. Mongo coloured (or so I was told) and demanded that his people ‘find a way to make it happen’. The managers quickly fled.
Special Projects Group was tasked with coordinating the operation. I, in turn, was tasked with coordinating the effort across all of the different groups within the department. [2] We only had seven weeks to design and deploy a working solution. I scheduled a brainstorming session for the senior managers and key engineers and let them pitch ideas until we found one that made sense.
The systems experts eventually decided that the best way to attack the problem would be to not do it at all; the amount of resources required to accomplish anything useful far outweighed the value that the upset customer would receive. We reported our conclusion to Mongo and got immediately shot down –as expected. Mongo told us to make something happen to satisfy his promise or else.
So be it. Our next best idea was to create a bespoke application that would sit on a server between the old application and the new one to act as a synchronizing liaison. The new tool would query each system every few minutes to look for new jobs associated with the one unique client that had been created in either system. If the liaison found a new job in one system, it would then duplicate all of the relevant information in the other. The line workers would stop using the old app on the switchover day, but the customer wouldn’t; they’d keep entering their jobs in the old system as per usual, and our liaison tool would copy the job to the new system to be worked behind the scenes. When our techs finished running a job in the new system, the liaison tool would note that and would close the duplicate job in the old system. It wasn’t elegant, but it met the operational requirements.
Unfortunately, this proposal required a staggering amount of people and permissions to bring about. We needed a developer to create the new tool – and we only had one in the entire department. That guy was swamped trying to finish another of Mongo’s urgent projects. We also needed a new server built and deployed. That had to be done outside of our department by folks who demanded three months’ notice for such work. We needed network engineers to integrate the new tool and its host into the production network. We needed tools experts to test the back-and-forth synchronization process between the two applications. Finally, we needed a tech writer to draft the instructions for the support staff so that they’d how to deviate from standard procedure for this one unique customer for a ‘special’ processing period of 11 days.
Wait, what?
Yeah, see, that’s the thing… all of this effort was being expended to mollycoddle a difficult client for a period of only 11 calendar days. Without belabouring the story, the ‘temporary appeasement’ solution would only run for a week and a half; after that, a completely different system-to-system synchronization tool – that did exactly the same thing as our temporary fix – would take the liaison work (and would do it better than our ad hoc solution). We only had to run ours for 11 days.
We told Mongo this and suggested that we just use manual workarounds for the 11-day gap. Mongo got angry and demanded that we deploy ours anyways. We saluted smartly and got to it.
In the end, more than three dozen people invested somewhere north of 800 hours of labour bringing the solution to life. Our coder scrambled madly for all six weeks to build, test and deploy his application. He got his part finished 48 hours before the team’s go-live target. Despite some 11th-hour hysteria [2] the conversion happened as promised. The liaison tool went live. Jobs synced. Mongo never said a word. The customer never seemed to notice. All was… well?
No. No, it wasn’t. Nearly a third of the special projects group had been utterly consumed with this initiative. Every participant had to drop some other assignments and endure ‘crunch time’ in order to meet Mongo’s deadline. Most team members had wasted days futility trying to interface with other departments. It wasn’t until the last days of the initiative that the key components went into operation. People were fried: they were exhausted, emotionally numb and thoroughly dispirited.
To express his deep satisfaction with the team, Mongo demanded updates on where everyone stood with all of their other projects – those same projects that had been suspended in order to create Mongo’s ‘bridge to nowhere’. Mongo was furious. He made it clear that it was utterly unacceptable for his workers to ‘slack off’ on their other high-priority assignments. He growled that everyone would need to double down. There weren’t going to be any rewards for a job well done. Just more demands to ‘volunteer’ unpaid nights and weekends to catch back up.
Team morale never recovered. Four months later, Mongo laid off most of the department and broke up what little was left.
- The developer who created the bespoke tool? Sacked.
- The network engineer who got the tool and the apps communicating? Sacked.
- The head trainer who generated all of the training content? Sacked.
- The project coordinator who got all the different workers synchronized? Sacked.
- The leader who was in charge of the entire operation? His employees were all reassigned and he was and busted down to an individual contributor.
It was a fine ‘thank you’ for all of our dedication and hard work. This, from a senior leader who couldn’t even be bothered to attend 95 per cent of the project meetings and didn’t bother reprioritizing his people’s work to accommodate his new assignment.
What fascinated me about Mongo’s approach was that he never once modulated it to suit the circumstances. When the customer demanded irrational coddling, Mongo gave it to them without hesitation. When his own lieutenants counseled him that he was imperiling other activities, Mongo crushed their objections. When Mongo’s workers completed the endeavour, Mongo berated them for not having worked harder. From start to finish, Mongo was consistently Mongo. He never once acknowledged the damage that he was inflicting on his team’s productivity and esprit de corps.
Throughout it all, most of Mongo’s underlings continued to hold him in awe. They served as volunteer apologists for his aggressive and domineering behaviour (‘He’s under a lot of stress right now’). They tried to interpret his will from second- and third-hand retellings of his statements (‘If he used the word “vital”, that means it’s a higher priority than “important”’). They exhorted others to work harder and to put in longer hours (‘We need to get this win so that Mongo will be pleased with us.’). The long-termers’ sychophancy and codependency never wavered when it came to the Almighty Mongo.
The thing was… Mongo didn’t deserve their blind and fervent loyalty. I understand some of it; his two-fisted, take-no-prisoners leadership style was thrilling to watch. His willingness to face adversity head-on was admirable. Unfortunately, his dot-com era ‘ogre style’ of leadership was completely wrong for the business. The workers who stuck by his side throughout all the chaos that he himself had created were spending their loyalty poorly, especially when it became clear that Mongo had no loyalty to them.
Like the characters from The Wild Bunch, Mongo’s people had invested their faith in a leader whose best days were behind him; a leader whose skills were no longer effective in a world that had changed around him, leaving him an ineffective relic of a bygone era. In the end, most of Mongo’s people were rewarded for their loyalty with career death, just as Pekinpah’s band of aging outlaws were rewarded for their loyalty with actual death at the end of the film. Mongo’s emotional, inflexible and bombastic leadership style created an office culture of career nihilism and brutality that Sam Pekinpah probably would have recognized… and loathed.
[1] Although I wasn’t given any authority to compel anyone involved to actually do anything, as per usual.
[2] One of our team members waiting until the moment that the team threw the metaphorical switch to raise a bunch of ‘issues’ in an attempt to make the project fail.
Title Allusion: Sam Peckinpah, Walon Green, and Roy Sickner, The Wild Bunch (1969 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.
