Archive
Islands Of Sanity
Via InformIT: Safari Books Online – 0201700735 – The C++ Programming Language, Special Edition, I snipped this quote from Bjarne Stroustrup, the creator of the C++ programming language:
“AT&T Bell Laboratories made a major contribution to this by allowing me to share drafts of revised versions of the C++ reference manual with implementers and users. Because many of these people work for companies that could be seen as competing with AT&T, the significance of this contribution should not be underestimated. A less enlightened company could have caused major problems of language fragmentation simply by doing nothing.”
There are always islands of sanity in the massive sea of corpocratic insanity. AT&T’s behavior at that time during the historical development of C++ showed that they were one of those islands. Is AT&T still one of those rare anomalies today? I don’t have a clue.
Another Bjarne quote from the book is no less intriguing:
“In the early years, there was no C++ paper design; design, documentation, and implementation went on simultaneously. There was no “C++ project” either, or a “C++ design committee.” Throughout, C++ evolved to cope with problems encountered by users and as a result of discussions between my friends, my colleagues, and me.”
WTF? Direct communication with users? And how can it be possible that no PMI trained generic project manager or big cheese executive was involved to lead Mr. Stroustrup to success? Bjarne should’ve been fired for not following the infallible, proven, repeatable, and continuously improving, corpo product development process. No?
Gift Wrap
In dysfunctional corpocracies, it’s not only acceptable, but it’s expected that STSJs (Status Takers and Schedule Jockeys) will routinely drop turd-bombs on DICs (Dweebs In the Cellar) when schedules, no matter how far off the mark they are, are not met.
However, it’s socially unacceptable for a DIC to hurl a turd-coil skyward toward an STSJ. Nevertheless, if a DIC has been trained to “communicate effectively” and is clever and skillful enough, a gift-wrapped turd-ball may be accepted “temporarily” by an STSJ – until he/she opens the box. Thus, the best course of action for DICS “privileged” enough to work in a one way command and control hierarchy is to flush turd-bombs down the toilet when they are discovered. Whoosh!
Must Be An Outsider
One must be an outsider to escape being scalded for pointing out problems within a corpocracy. Unlike insiders (except for the obligatory, once a year, watered down employee survey), outsider opinions are actually solicited by the infallible hierarchs (who confidently and assuredly think they run the show). In addition, outsider pundits with “impeccable credentials” actually get paid for their analysis and recommendations! That’s why Weinberg’s “Secrets of Consulting” is in my reading queue.
Sadly, even if the situation on the left in the above diagram never happens in your org, DICs won’t stand up and expose turds that threaten the well being of the corpocracy because the image is dogmatically burned into their mind. There’s a reason why the story of the “emperor’s new clothes” is so funny and well known. The boy who pointed out his “highny”-ness’ s wardrobe malfunction was outside of the emperor’s kiss-ass court. Had he been an insider, it would have been “off with his head”.
Six To Nine Months
As a rule of thumb, one can assume that a corpo reorg will take place every six to nine months. “Our new organization will (no doubt) increase efficiency, profitability, and align us more closely with our customers“. Yada, yada, yada. Yeah, right. Whatever you say dude.
The figure below shows sample before-and-after corpo reorg charts. After the re-org, more profit-sapping fat has been added in an ill fated attempt to increase corpo performance. In the shiny new org, less productive work gets performed because some lucky(?) or ass-kissin’ DICs (Dweebs In the Cellar) are “promoted” into the ranks of the elite. Of course, as a reward for their loyalty, and regardless of their performance (because behavior is always more important than performance), some MIMs (Managers In the Middle) are further promoted up into the rafters or reshuffled sideways. Narrow, specialized, confusing, undefined, and weird new corpo titles are conjured up like “manager of the company newsletter”, “deputy director of timecard compliance”, “director of trade show booth setup “, and “manager of coffee grounds disposal”.
After six to nine months of further deteriorating financial performance, the corpo hierarchs shrug, scratch their heads, and repeat the cycle to “(no doubt) increase efficiency, profitability, and align us more closely with our customers“. Wash, rinse, and repeat. Wash, rinse, and repeat………….
Status Takers And Schedule Jockeys
Whoo hoo! I’ve been promoted to “manager” by the Gods from above. I’m not a DIC (Dweeb In the Cellar) anymore. I’ve transitioned to the easy life of “taking status and riding the schedule”. Now I can shut down my brain because I don’t have to think or create anymore. I just have to walk around and: poll for status, look worried when people fall behind schedule, and “nicely” exert pressure on the team to perform. To top it all off, I got a big raise because of my “increase in responsibility”! Man, I love corpocracies and hieararchical gigs.
Disconnected DICs
Without continuous, sincere, hard work from the leadership in a CCH (Command and Control Hierarchy) structure of human organization, it is all but guaranteed that the communication gap size between adjacent layers will exponentially increase when one traverses from the top level down to the bottom level.
The communication gap between two non-adjacent levels is even wider, culminating with a gap size of infinity between the DICs at Level=0 and the corpo hierarchs at Level=MAX. Bummer.
The Wall
The figure below shows the financial performance of a successful hypothetical company. During the startup phase, both revenue and profit increased at a linear pace, and then something interesting happened. As revenue rose, profit growth hit a wall and leveled off. Dooh!
So, what happened? In business lingo, the costs to execute the business rose faster than the costs to acquire the revenue. Since we are not company insiders, we can only speculate as to the underlying cause(s) of the performance slip, but here are two out of a bazillion possibilities:
- More bureaucrats were added at a faster rate than people with the skills and ability to execute.
- The company’s execution processes were unscaleable.
Let’s explore these two performance busters.
More bureaucrats were added at a faster rate than people with the skills and ability to execute.
With revenue pouring in, it’s easy to become sloppy and careless with all that dough. Egotistical managers, unconsciously trying to outdo one another by building personal empires, convince their disconnected and aloof next-level managers that they need more people for business execution, regardless of whether they actually do need them. These new additions are often specialists who are only capable of executing narrow slivers of the business. Thus, they spend most of their time in idle mode; consuming more from the company than they contribute.
On the other hand, the new additions may be ambitious, unskilled fellow managers who are tasked with doing what their bosses couldn’t – increase execution performance with the people that they currently have. By adding more sub-managers, each super-manager builds his/her empire and further buffers him/herself from where the rubber hits the road in the execution trenches.
The company’s execution processes were unscaleable.
Unless the company produces widgets or some other simple product that doesn’t require knowledge synthesis and frequent human situational decision-making skills, its business execution processes may be unscaleable. In a sincere but misguided attempt to control and increase execution performance, the company’s managers actually decrease scaleability and they inhibit performance gains by piling more constraining rules and procedures on top of the people who create, manufacture, test, and sustain the product portfolio. Rather than rolling up their sleeves and jumping in with their people to help them get the job done, these managers spend all of their time running around taking status and ensuring that all the rules and procedures are followed.
Can you think of any other reasons why this successful company may have stumbled?
All in all you’re just another brick in the wall. – Pink Floyd
What Happened To Ross?
In the ideal case, an effectively led company increases both revenues and profits as it grows. The acquisition of business opportunities grows the revenues, and the execution of the acquired business grows the profits. It is as simple as that (I think?).
ROS (Return On Sales) is a common measure of profitability. It’s the amount of profit (or loss) that remains when the cost to execute some acquired business is subtracted from the revenue generated by the business. ROS is expressed as a percentage of revenue and the change in ROS over time is one indicator of a company’s efficiency.
The figure below shows the financial performance of a hypothetical company over a 10 year time frame. In this example, revenues grew 100% each year and the ROS was skillfully maintained at 50% throughout the 10 year period of performance. Steady maintenance of the ROS is “skillful” because as a company grows, more cost-incurring bureaucrats and narrow-skilled specialists tend to get added to manage the growing revenue stream (or to build self-serving empires of importance that take more from the org than they contribute?).
For comparison, the figure below shows the performance of a poorly led company over a 10 year operating period. In this case the company started out with a stellar 50% ROS, but it deteriorated by 10% each subsequent year. Bummer.
So, what happened to ROS? Who was asleep at the wheel? Uh, the executive leadership of course. Execution performance suffered for one or (more likely) many reasons. No, or ineffective, actions like:
- failing to continuously train the workforce to keep them current and to teach them how to be more productive,
- remaining stationary and inactive when development and production workers communicated ground-zero execution problems,
- standing on the sidelines as newly added “important ” bureaucrats and managers piled on more and more rules, procedures, and process constraints (of dubious added-value) in order to maintain an illusion of control,
- hiring more and more narrow and vertically skilled specialists that increased the bucket brigade delays between transforming raw inputs into value-added outputs,
may have been the cause for the poor performance. Then again, maybe not. What other and different reasons can you conjure up for explaining the poor execution performance of the company?
The Vault Of No Return
In big system development projects, continuous iteration and high speed error removal are critical to the creation of high quality products. Thus, it’s essential to install flexible and responsive Configuration Management and Quality Assurance (CMQA) support systems that provide easy access to intermediate work products that (most definitely) will require rework as a result of ongoing learning and new knowledge acquisition.
As opposed to virtually all methodologies that exhort early involvement of the CMQA folks in projects, I (but who the hell am I?) advise you to consider otherwise. If you have the power (and sadly, most people don’t), then keep the corpo CMQA orgs out of your knickers until the project enters the production phase. Why? Because I assert that most big company CMQA orgs innocently think they are the ends, and not a means. Thus, in order to project an illusion of importance, the org creates and enforces Draconian, Rube Goldberg-like, high latency, low value-added, schedule-busting procedures for storing work products in the vault of no return. Once project work products are locked in the vault, the amount of effort and time to retrieve them for error correction and disambiguation is so demoralizing and frustrating that most well-meaning information creators just give up. Sadly, instead of change management, most CMQA orgs unconsciously practice change prevention.
The figure below contrasts two different product developments in terms of when a CMQA org gets intertwined with the value creation project pipeline. The top half shows early coupling and the bottom half shows late coupling. Since upstream work products are used by downstream workgroups to produce the next stage’s outputs, the downstreamers will discover all kinds of errors of commission and (worse,) omission. However, since the project info has been locked in the vault of no return, if the culture isn’t one of infallible machismo, upstream producers and downstream consumers will circumvent the “system” and collaborate behind the scenes to fix mistakes and clarify ambiguities to increase quality. If and when that does happen, the low quality, vault-locked information gets out of synch with the informal and high quality information in the pipeline. Even though that situation is better than having both the vault and project pipeline filled with error infested information, post-delivery product maintenance teams will encounter outdated and incorrect blueprints when they retrieve the “formal” blueprints from the vault. Bummer.
Dweeb In the Cellar
Check out the figure below and please heed the advice it dispenses. If you’re a Dweeb In the Cellar (DIC), don’t piss off the people in the highlighted boxes above you. As a DIC, you can (almost) safely piss off anyone else in the corpo caste system. However, each cookie cutter corpo command & control hierarchy is slightly, just slightly, different. For example, if your direct boss and one of his level 1 peers are great friends, you can’t piss the friend off either. As you might guess, it’s usually OK to piss your fellow DICs off, but again, each corpo org is slightly different.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 