One of the important concepts I stress when mentoring young professionals is that practical life lessons can be extracted from the strangest of personal encounters. Effective communication requires the receiver to be interested in understanding the speaker’s message. Personal stories resonate, especially when they’re ridiculous, scandalous, or funny. That in mind I advise that my mentees find stories that support the lessons they want to teach. They don’t have to be their own stories; just ones that will help make their point. People like being entertained more than they like being lectured.
That in mind, my ears perked up when my oldest came home after his usual Saturday wargaming session severely annoyed. For context, both my boys are enthusiastic Warhammer players. I don’t see the appeal myself; for what it’s worth, they seem enjoy the model building and painting part every bit as much as they enjoy squaring off against opponents at the Citadel game shop up the road in Grapevine.
This last Saturday, my oldest took part in a massive 3 X 3 player Age of Sigmar match. This was a fantasy game where three random players teamed up to take on three different players on a massive 6-ft by 8-ft gaming table festooned with 3D city terrain models. These random matches are great opportunities for each player to show off their skills as each player manoeuvres their plastic monsters, rolls lots of dice, and argues over obscure rules.
This time, one of the players on my oldest’s team – let’s call him “Bob” – had a miserable day. Bob’s carefully constructed army of heavy infantry models [1] started the game on the long edge of the table. Every time his turn came around, after the other five players had fought, Bob’s models could only creep towards the fray 4-inches at a time. On an eight-foot table where everyone else was on the opposite side of the battlefield, that meant luckless Bob had literally nothing to do for the entire game. By the time his army reached had advanced 16-inches, the other players had called the game. Bob’s “contributions” had been a complete waste of his time. He might as well have stayed home.
I’m forced to admit that I was impressed (in a perverse sort of way). If Bob learned from his experience that real soldering consists mostly of pointless waiting around, bad luck, and creative swearing, that would make Warhammer the most accurate military life simulator ever written. I can corroborate this. For maximum realism, all Bob needed to add were random halts complete useless mandatory training and he’d be qualified to attend officers’ candidacy school.
That, however, wasn’t the most useful content Bob might have taken away from the experience. Personally, I suggest that that Bob might have learned a valuable lesson about business life from his disappointing wargame session as well.
For context, young people are often taught about the principles of business IT at university. Activities like systems integration, network design, and software development are presented as tightly integrated, well planned, and rigidly organized endeavours. Undergraduate students are taught IT the same way they’re taught physics: using an impractically simplified conceptual model that omits all the real-world complications like friction drag, inertia, etc. I say this because of the many fresh-faced workers I’ve counselled over the years to lower their expectations when came to planning their work.
New hires often have an endearing optimism about the workplace thanks to their instructors’ utopian assumptions. The new graduates thoughtfully consider what they’re capable of achieving based on their limited personal experience at university and meticulously plot how they’ll hit their milestones based on a theoretically fully available forty hours per week of sincere best-effort. It depressed me to disillusion the new folks by teaching them that the real world doesn’t function the way that the academic models might have led them to believe.
In pedestrian reality, IT work often resembles my kids’ Warhammer games more than it does their textbooks’ models. Everyone goes into each new project with a common understanding of the basic rules and expectations (e.g., average worker output, etc.). Everyone makes a personal plan. Then every contributor attempts to implement their part of the plan in good faith, only to discover that random chance, institutional inefficiency, and bureaucratic obstacles had disadvantaged nearly everyone.
For example, the development team might have planned to use a bunch of open source software to speed up their coding effort, only to discover that the company’s software standards team won’t allow it. “No open source code use without an extensive vulnerability review” is a universal rule in corporate cybersecurity. Suddenly, the dev team has their own “Bob’s bad positioning” moment: they had a great plan for getting their work done on time but were forced to start the project from a disadvantageous position. Suddenly, their plan for, eight weeks of coding becomes eight months of bureaucratic manoeuvring before they can start writing a line of code. The entire project schedule slips because of an unforeseen or misunderstood stakeholder requirement.
This … is … normal. Seriously. Large IT projects almost always go over time and over budget because their complexity and interdependencies inevitably unearth every conceivable obstacle, mostly by blundering into them. No matter how precisely the project managers attempt to wargame their plans, the real world inevitably introduces extreme versions of “friction” that were innocently missed.
Heck, oftentimes a project plan can be perfect and still run aground when a company’s rules change in the middle of a project. The planners might have accounted for every possible risk to the schedule, only to get blindsided when one of their stakeholders unexpected changes a critical business practices. This is so common an occurrence that jaded old technologists reflexively double every written project schedule estimate to account for the impact of real-world jackwagonry. As old soldiers warn, no battle plan ever survived first contact with the enemy. “The enemy,” in this case, is the inherent and inescapable complexity of the company itself.
Time and again I’ve watched new workers learn this bitter lesson after their hard work came to nought due to unforeseen circumstances. It wasn’t that the workers’ intent or commitment had been wrong; the universe simply knocked them over and kicked them in the unmentionables because large projects simply have too many “moving parts.”
I’ve helped dozens of new workers navigate through their “but it’s not fair” phase in much the same fashion that my oldest counselled his new pal Bob at the wargames table. “Yeah, that’s true,” we say, “but anything that could go wrong probably will.” Long term success requires patience, flexibility, and a grudging appreciation for the absurd.
I think it would be easier to introduce this concept to new hires be opening our discussion with the story of Bob’s botched Warhammer game. His awful Saturday is a mildly humours cautionary tale where no one was at fault, and no one need be embarrassed. Bob did everything right; unfortunately, one bad dice roll at the start of his “project” made him start so far behind the other players that he could never catch up or contribute. That same sort of bad luck plagues IT workers everywhere. It’s no one’s fault; it’s just the irritating reality of trying to implement ideal-world plans under real-world conditions.
To his advantage, Bob could at least take his little pained orcs home and hope for a better random outcome next time. He wasn’t forced to keep inching his useless models down the table for weeks while incredulous project managers castigated him for not “meeting his milestones.” God knows, after three or four stupid encounters like that, everyone is inclined to take after Bob’s orcs by letting out a deafening “Waaagh!” and swinging a club.
[1] “Orc brutes,” if that means anything to you.
