Archive
Troubleshooter
Assume that your company is cruising along and creating high quality products, happy customers, and making money. The drawing below shows this situational bliss – a well oiled machine.
Now assume that something in your previously flawless system has gone bad. Your product quality has tanked, your customers are angry, and your profitability has shrunk. The lightning bolts in the figure below show places of potential dysfunction that are causing and contributing to the mess.
So, how do you figure out what’s gone wrong so that you can fix the stank? Of course, if you’re in the management group, you’ll automatically discard yourself and your brethren as a source of the problem(s). Since you have an agenda to look good and an unshakable self-image of infallibility, you’ll go poking around in all areas and cross-group interfaces except your own.
Since almost all corpo performance problems are the result of bozo management actions and a lack of leadership, one effective way of diagnosing and fixing what ails you is to bring in an objective outside troubleshooter who will tell you the unabashed truth. Alas, since you’ll be sourcing the income for any outside troubleshooter, he/she will most likely milk the job and tell you what you want to hear: you’re not the problem.
Layers Of Value Streams
An organization of people assembled for a purpose runs on all cylinders when every layer in its control structure creates a value stream that puts more into the org than it takes out. The higher you go up the pyramid of privilege, the less visible the added value, but the more the impact. In dysfunctional orgs, the upper layers don’t create any value and their impact is damaging to the whole. Like leeches, they suck the blood out of the org without contributing anything of substance.
It’s the responsibility (or, it should be) of each upper layer to sample the value stream produced by the lower layer(s) to ensure continuous excellence and improvement. Except for the DICforce (at rock bottom of course), each upper level can sample and measure any/all of the value streams below them.
In screwed up and inefficient corpocracies where the upper layers are too lazy or incompetent to sample the lower layer value streams, the only value stream samplers are the customers. This means that if crap makes it out the door, they’re the ones who discover and report it. At worst, they don’t report it and they silently blow off the org. They never buy anything from it again, and they tell all their peers to stay away from the crap factory. Meanwhile, everyone back at doo-doo ranch is asking each other; “Lucy, whuh hah-penned?”.
Buffer Gone Awry
Assume that you’re a manager enveloped within the predicament below. On a daily basis, you’re trying to coordinate bug fixes and new feature additions to your product while simultaneously getting hammered by internal and external customers with problem reports and new feature requests.
In order to reduce your workload and increase productivity, your meta-manager decides to add a “buffer” manager to filter and smooth out the customer interface side of your job. As the left side of the figure below shows, the hope is that the team’s increased productivity will offset the doubling of overhead costs associated with adding a second manager to the mix. However, when your customers find out that they now have two managers to voice their problems and needs to, the situation on the right develops: your workload remains the same; you now have an additional interface with the buffer manager (who has less of a workload than you); the overhead cost to the org doubles. Bummer.
Dude, Read It The Freakin’ First Time
Recently, I was asked by Joe Manager to estimate the amount of resources (people and time) that I thought would be consumed in the development of a large, computationally-intensive, software-centric system. I dutifully did what was asked of me and posted a coarse, first cut estimate on the company wiki for all to scrutinize. I also provided a link to the page to Joe Manager. Unsurprisingly (to me at least) , at the next “planning” meeting I was asked again by Joe, on-the-spot and in real-time, what it would take to do the job if I were to lead the project. Since my pre-meeting intuition told me to bring a hard copy of my estimate to the meeting, I presented it to Mr. Manager and gently reminded him that I had forwarded it to him earlier when he asked for it the (freakin’) first time.
Apparently, besides being forgetful, poor Joe wasn’t told of the not-so-secret policy that I’m not allowed to lead anyone, let alone a team on a large and costly software development project that could be pretty important to the company’s future. Plus, since Joe’s last name is “Manager”, isn’t he supposed to at least consider planning and leading the effort his own freakin’ self? Or is he just envisioning someone else struggling to get it done while he periodically samples status, rides the schedule, and watches from the grassy knoll.
In a bacon and eggs breakfast, the chicken is involved, but the pig is committed – Ken Schwaber
Ya Can’t Put The Cat Back In The Bag
Check out this snippet from “Can Larger Companies Still be Passionate and Quirky?“:
Writing for The New York Times, Adam Bryant conducted an interview with Tony Hsieh, the chief executive of Zappos.com. Part of the interview that intrigued me was Hsieh’s explanation of why he and his roommate sold their company LinkExchange to Microsoft in 1998.
Part of it was the money, he admits. But, mostly, it was because the passion and excitement that permeated the company in the beginning was gone, and he’d grown to dislike its culture:
“When it was starting out, when it was just 5 or 10 of us, it was like your typical dot-com. We were all really excited, working around the clock, sleeping under our desks, had no idea what day of the week it was. But we didn’t know any better and didn’t pay attention to company culture. By the time we got to 100 people, even though we hired people with the right skill sets and experiences, I just dreaded getting out of bed in the morning and was hitting that snooze button over and over again.”
To avoid this happening with Zappos, Hsieh says he formalized the definition of the Zappos culture into 10 core values; core values that they would be willing to hire and fire people based on. Read the interview with Hsieh for details on how they went about this.
With LinkExchange, Tony was wise enough to know that it was fruitless to try and restore the company’s original esprit de corps culture. Once the cat gets out of the bag, it’s pretty much a done deal that you won’t get it back in.
What’s mind boggling to me is that leaders of startups that grow and “mature” over time don’t even have a clue that the vibrant culture of community/comraderie that they originally created has petered out. They get disconnected and buffered from the day to day culture by adding layer upon layer of pyramidal stratification and they delude themselves into thinking the culture has been maintained “for free” over the duration. Those dudes deserve what they get; a transformation from a communal meritocracy into a corpo mediocracy just like the rest of the moo-herd.
Byzantine Labyrinth
During the birth and growth of dysfunctional CCHs, here is what happens:
- silos form and harden,
- a bewildering array of narrow specialist roles get continuously defined,
- layers of self-important and entitled RAPPERS emerge, and
- a byzantine labyrinth of processes and procedures are created by those in charge.
This not only happens under the “watchful eyes” of the head shed, but incredibly, those inside the shed-of-privilege are the chief proponents and instigators of all the added crap that slows down and frustrates the DICforce. Peter Drucker nailed it when he opined:
Ninety percent of what we call ‘management’ consists of making it difficult for people to get things done – Peter Drucker
On the other hand, T.S. Eliot also pegged it with:
“Half of the harm that is done in this world is due to people who want to feel important. They do not mean to do harm… They are absorbed in the endless struggle to think well of themselves.” – T. S. Eliot
Scalability: The Next Buzzword
Since I’m currently in the process of trying to help a team re-design an existing software-intensive system to be more scalable, the title of this book caught my eye:
It’s just my opinion (and you know what “they” say about opinions) but stay away from this stinker. All the authors want to do is to jump on the latest buzzword of “scalability” and make tons of money without helping anybody but themselves.
Check this self-serving advertisement out:
“The Art of Scalability addresses these issues by arming executives, engineering managers, engineers, and architects with models and approaches to scale their technology architectures, fix their processes, and structure their organizations to keep “scaling” problems from affecting their business and to fix these problems rapidly should they occur.”
Notice how they try to cover the entire hierarchical corpo gamut from bozo managers at the peak of the pyramid down to the dweebs in the cellar to maximize the return on their investment. Blech and hawk-tooey.
BTW, I actually did waste my time by reading the first BS chapter. The rest of the book my be a Godsend, but I’m not about to invest my time trying to figure out if it is.
Context Switching
“There is time enough for everything in the course of the day, if you do but one thing at once, but there is not time enough in the year, if you will do two things at a time.” – Lord Chesterfield (1740)
Study after study after study have shown that, due to the natural imperfections built into human memory, multitasking is inefficient and unproductive compared to single-tasking. The bottom line is that humans suck at multitasking. Unlike computers, when humans switch from doing one thought-intensive task to another, the clearing out of memory content from the current task and the restoration of memory content from the previous task greatly increases the chances of errors and mistakes being made.
So why do managers multitask all the time, and why do unenlightened companies put “multitasking prowess” on their performance review forms? Ironically, they do it to reinforce an illusion that multitasking is a key contributor of great productivity and accomplishment. When a “performance reviewer” sees the impressive list of superficial accomplishments that a multitasker has achieved and compares it to a measly list of one or two deep accomplishments from a single-tasker, an illusion of great productivity is cemented in the mind of the ignorant reviewer. Most managers, huge multitaskers themselves, and clueless to the detrimental effects of the malady on performance, tend to reward fellow multitaskers more than non-multitasking “slackers“. Bummer for all involved; especially the org as a whole.
Unscalable Orgs
My friend Byron Davies sent me a link to this 3 minute MIT Media Lab video in which associate Media Lab Director Andy Lippman challenges us to recognize four common flaws plaguing all of our institutions. Obtaining a new awareness and understanding of the plague is the first step toward meaningful redesign.
According to Lippman, the top four reasons for organizational decline are:
- They’re out of scale – they’ve grown too big to perform in accordance with their original design
- They’re monocultures – they all act the same
- They’re opaque – nobody from within or without understands how they freakin’ work
- They’ve lost their original mission – A summation of the previous three reasons.
Because of the pervasive institutional obsession for growth, Lippman seems to think that solving the scaling problem through the development of nested communities is the most promising strategy for halting the decline.
Staffing Profiles
The figure below shows the classic smooth and continuous staffing profile of a successful large scale software system development project. At the beginning, a small cadre of technical experts sets the context and content for downstream activity and the group makes all the critical, far reaching architectural decisions. These decisions are documented in a set of lightweight, easily accessible, and changeable “artifacts” (I try to stay away from the word “documentation” since it triggers massive angst in most developers).
If the definitions of context and content for the particular product are done right, the major incremental development process steps that need to be executed will emerge naturally as byproducts of the effort. An initial, reasonable schedule and staffing profile can then be constructed and a project manager (hopefully not a BM) can be brought on-board to serve as the PHOR and STSJ.
Sadly, most big system developments don’t trace the smooth profiling path outlined above. They are “planned” (if you can actually call it planning) and executed in accordance with the figure below. No real and substantive planning is done upfront. The standard corpo big bang WBS (Work Breakdown Structure) template of analysis/SRR/design/PDR/CDR/coding/test is hastily filled in to satisfy the QA police force and a full, BM led team is blasted at the project. Since dysfunctional corpocracies have no capacity to remember or learn, the cycle of mediocre (at best) performance is repeated over and over and over. Bummer.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 