Archive
Unfriendly Fire
In Nancy Leveson’s new book, “Engineering A Safer World“, she analyzes (in excruciating detail) all the little screw-ups that occurred during an accident in Iraq where two F-15 fighters shot down two friendly black hawk helicopters – killing all aboard. To set the stage for dispassionately explaining the tragedy, Ms. Leveson provides the following hierarchical command and control model of the “system” at the time of the fiasco:
Holy shite! That’s a lot of levels of “approval required“, no?
In typical BD00 fashion, the dorky figure below dumbs down and utterly oversimplifies the situation so that he can misunderstand it and jam-fit it into his flawed UCB mental model. Holy shite! That’s still a lot of levels of “ask me for permission before you pick your nose“, no?
So, what’s the point here? It’s that every swingin’ dick wants to be an esteemed controller and not a low level controlleee. Why? Because….
“Work is of two kinds: first, altering the position of matter at or near the earth’s surface relatively to other such matter; second, telling other people to do so. The first kind is unpleasant and ill paid; the second is pleasant and highly paid.” – Bertrand Russell
People who do either kind of work can be (but perhaps shouldn’t be) judged as bozos, or non-bozos. The bozo to non-bozo ratio in the “pleasant” form of work is much higher than the “unpleasant” form of work. – BD00
Executive Proposal
The lowly esteemed and dishonorable BD00 proposes to executives everywhere:
Whenever you change your org, supply the minions with TWO complementary org charts: the usual (yawn) who-reports-to-whom chart and a system operational structure chart.
Creating the first one is an easy task; the second one, not-so. That’s why you’ve never seen one.
The funny thing is, every borg has a “System Operational Structure” chart regardless of whether it’s known or (most likely) not. Reshuffling the “Who-Reports-To-Whom” chart without knowing and consulting with the “Systems Operational Structure” chart doesn’t improve operations (unless the reshuffler gets lucky), it justs changes who to blame when sub par performance persists after the latest and greatest reshuffle.
Bucket Brigade
If you are indispensable, you’re unpromotable. – Unknown
I don’t know who said that quote, but it’s pretty true, no? Some people and groups, especially bureaucrats and those in overhead middle management and staff roles, either wittingly or unwittingly do everything they can to make their jobs so complicated and unfathomable that no one else can do them and the org that employs them would be temporarily hosed if they left. It’s the familiar “truck number of 1” syndrome.
The problem is that both managers and “regular” employees in unenlightened borgs collude to make it so. Managers want efficiency to keep operating costs low and employees want a comfort zone that minimizes the chance of them making visible mistakes. Specialization breeds specialization over time until a brittle bucket brigade of one-dimensional, highly interdependent, change-averse “parts” is set in stone.
Surpise, Suprise, Surprise
I always get a kick out of how people express great surprise when a management shakeup occurs and the old guard is sacked for the not-so-old guard. “OMG! I can’t believe so-and-so is gone“. “It’s about time so-and-so got booted“. “Why the hell is so-and-so still here?“. “Why am I still here?“.
Well geeze, the reason a change was made was because it finally became unavoidably obvious that something wasn’t working the way it should to somebody who had the power to make the change. Nonetheless, changing a leadership team in response to an existential crisis doesn’t guarantee squat. At best, the new team will propel the org out of the crisis and place it on a trajectory of success. At worst, the org’s demise will be accelerated.
What Will The Children Think?
Silo City
The title of this strategy+business article, “One Way to Lose Employees: Train Them”, is not shocking, no? If you believe it, then you’ll most likely believe a fictional, complementary article titled “One Way To Retain Employees: Don’t Train Them“.
Regarding the first, real article, the authors assert that mechanistic training is not enough to retain employees. It just makes them more marketable to competitors. If they’re not treated well and not allowed to grow, they’ll simply leave.
Regarding the second, reinforcing ghost article, the author summarizes his/her message as:
The researchers found that the deliberate withholding of funding and the lack of active encouragement to participate regularly in seminars, training sessions, and workshops kept workers from leaving because it left them thinking that their skills were becoming obsolete and feeling that they were unmarketable and “stuck” inside the borg. Additionally, the dearth of career mentoring and unhealthy boss–subordinate relationships instilled a culture of fear and an unsettling feeling of quiet desperation among employees. The lack of job rotations also decreased employees’ hopes of a bright future, the researchers found. A policy of no rotating assignments prevented employees from learning about different aspects of the company and from forming new social contacts across the organization.
Between the research findings summarized in the two articles, it’s a slam dunk. To keep employees from leaving, simply don’t train them and keep them sequestered within their one dimensional silos.
But wait! All is not lost. To retain employees while simultaneously training them to be more productive to the org, the authors of the real article recommend this multi-faceted approach:
The researchers found that regular participation in seminars, training sessions, and workshops sent an important signal to workers that the organization was investing in and valuing them. Additionally, career mentoring and healthy boss–subordinate relationships built loyalty among employees. Job rotations also increased employees’ hopes of a bright future, the researchers found. Rotations allowed employees to learn about different aspects of the company and form new social contacts across the organization.
Fuzzy And Clear
The higher one ascends up the corpo ladder, the fuzzier one’s view becomes regarding how the enterprise works and what mania takes place down in the boiler rooms. On the other hand, who reports to whom becomes clearer and clearer and perversely more important than nurturing continuous improvement and innovation. These effects can be called “losing touch with reality” and “perverse inversion of importance“.
Effective But Destructive
In “I’m Feeling Lucky”: Google Employee No. 59 Tells All , Douglas Edwards tells one story about mercurial Google co-founder Larry Page:
How Larry reorganized the engineering department, for example. He didn’t like the fact that project managers were getting between him and engineers, so he called a meeting and told them very publicly that he didn’t need them–.
I’ll assert that in lots of companies, the reverse is true. In those that are DYSCOs and CLORGs, head cheeses don’t care to understand what goes on down in the boiler rooms and they desperately need project managers to tell them what’s going on. The funny part is that the project managers most likely don’t know either. D’oh!
There’s a second part to this post and the message is at the tail end of the full version of Mr. Edwards’s quote:
How Larry reorganized the engineering department, for example. He didn’t like the fact that project managers were getting between him and engineers, so he called a meeting and told them very publicly that he didn’t need them–and those people felt humiliated. I think Larry took a lesson from that, and I think he became more adept over time at managing. A young startup entrepreneur might share some of the characteristics of Larry. “If there’s a problem, reboot, fix it, move on.” That can be effective but can also be destructive. It can tear down relationships.
A Costly Mistake For Many
In “Learning Standard C++ as a New Language“, Bjarne Stroustrup gives a slightly different take on the waterfall method of software-intensive system development:
“… treating programming as merely the handmaiden of analysis and design doesn’t work either. The approach of postponing actual discussion of code until every high-level and engineering topic has been thoroughly presented has been a costly mistake for many. That approach drives people away from programming and leads many to seriously underestimate the intellectual challenge in the creation of production-quality code.“
If your company implicitly treats software engineers like “code monkeys” and great engineers strive to “rise” into coveted management positions ASAP because the unspoken ethos is that “coders” are interchangeable cogs, then your company most likely has made costly mistakes in the past and it will most likely do so again in the future.









