Archive
Initiative Initiation
Assume that the graph below describes the rise and fall of a hypothetical CCH (Command and Control Hierarchical) business. During the party time phase of increasing profits (whoo hoo!), the CCH corpocrats in charge pat themselves on the back, stuff their pockets, and slowly inflate their heads with bravado and delusions of infallibility.
In order to extend the increasing profit trajectory, an undetectable status quo preserving mindset slowly but surely kicks in. Hell, if it ain’t broke, don’t touch the damn thang. Since what the CCH (so-called) leadership is doing is working, any individual or group from within or without the cathedral walls who tries to deviate significantly from the norm is swiftly “dealt with” by the corpocrats in charge. Everthing needs to get approved by a gauntlet of “important” people. However, while the shackles are being tightened and the ability to scale for success is being snuffed, the external environment keeps changing relentlessly in accordance with the second law of thermodynamics. Profit starts eroding and tension starts ratcheting upwards. Out of fear of annihilation, the cuffs are tightened further and the death dive has begun. Bummer.
During the free fall to obscurity, the now brain-dead and immobile corpocrats in charge start “taking aggressive action” to stem the flow of red ink. Platitudes and Matt Foley-like motivational speeches are foisted upon the DICs (Dweebs In the Cellar) in frantic attempts to self-medicate away the pain of stasis and failure. Initiatives with cute and inspiring names are started but never finished (because it takes real hands-on leadership, sweat, and work to follow through). As corposclerosis accelerates, silver-bullet-bearing consultants are brought in and the frequency of initiative initiation increases. Calls for accountability of “them” pervade the corpocracy from the top down and vice versa.
After being hammered by pleas to “improve performance” and being pounded by the endless tsunamis of hollow initiatives, the DICs disconnect and distance themselves from the lunacy being doled out by the omnipotent dudes in the politboro. Since the DICs expect the corpocrats to effect the “turnaround” and the corpocrats expect the DICs to strap on their Nikes and “just do it”, no one takes ownership and nothing of substance changes. As you might surmise, it’s a Shakespearian tragedy with no happy ending. Bummer squared.
Leaderless CCHs deserve what they get; a fearful, disconnected workforce and a roller coaster ride to oblivion.
Scaleability
The other day, a friend suggested plotting “functionality versus size” as a potentially meaningful and actionable measure of software development process prowess. The figure below is an unscientific attempt to generically expand on his idea.
Assume that the graph represents the efficiency of three different and unknown companies (note: since I don’t know squat and I am known for “making stuff up”, take the implications of the graph with a grain of salt). Because it’s well known by industry experts that the complexity of a software-intensive product increases at a much faster rate than size, one would expect the “law of diminishing returns” to kick in at some point. Now, assume that the inflection point where the law snaps into action is represented by the intersection of the three traces in the graph. The red company’s performance clearly shows the deterioration in efficiency due to the law kicking in. However, the other two companies seem to be defying the law.
How can a supposedly natural law, which is unsentimental and totally indifferent to those under its influence, be violated? In a word, it’s “scaleability“. The purple and green companies have developed the practices, skills, and abilities to continuously improve their software development processes in order to keep up with the difficulty of creating larger and more complex products. Unlike the red company, their processes are minimal and flexible so that they can be easily changed as bigger and bigger products are built.
Either quantitatively or qualitatively, all growing companies that employ unscaleable development processes eventually detect that they’ve crossed the inflection point – after the fact. Most of these post-crossing discoverers panic and do the exact opposite of what they need to do to make their processes scaleable. They pile on more practices, procedures, forms-for-approval, status meetings, and oversight (a.k.a. managers) in a misguided attempt to reverse deteriorating performance. These ironic “process improvement” actions solidify and instill rigidity into the process. They handcuff and demoralize development teams at best, and trigger a second inflection point at worst:
More meetings plus more documentation plus more management does not equal more success. – NASA SEL
Is your process scaleable? If so, what specific attributes make it scaleable? If not, are the results that you’re getting crying out for scaleability?
Percent Complete
In order to communicate progress to someone who requires a quantitative number attached to it, some sort of consistent metric of accomplishment is needed. The table below lists some of the commonly used size metrics in the software development world.
All of these metrics suffer to some extent from a “consistency” problem. The problem (as exemplified in the figure below) is that, unlike a standard metric such as the “meter”, the size and meaning of each unit is different from unit to unit within an application, and across applications. Out of all the metrics in the list, the definition of what comprises a “Function Point” unit seems to be the most rigorous, but it still suffers from a second, “translation” problem. The translation problem manifests when an analyst attempts to convert messy and ambiguous verbal/written user needs into neat and tidy requirement metrics using one of the units in the list.
Nevertheless, numerically-trained MBA and PMI certified managers and their higher up executive bosses still obsessively cling to progress reports based on these illusory metrics. These STSJs (Status Takers and Schedule Jockeys) love to waste corpo time passing around status reports built on quicksand like the “percent done” example below.
The problems with using graphs like this to “direct” a project are legion. First, it is assumed that the TNFP is known with high accuracy at t=0 and, more erroneously, that its value stays constant throughout the duration. A second problem with this “best practice” is that lots, if not all, non-trivial software development projects do not progress linearly with the passage of time. The green trace in the graph is an example of a non-linearly progressing project.
Since most managers are sequential, mechanistic, left-brain-trained thinkers, they falsely conclude that all projects progress linearly. These bozelteens also operate under the meta-assumption that no initial assumptions are violated during project execution (regardless of what items they initially deposited in their “risk register” at t=0). They mistakenly arrive at conclusions like: ” if it took you two weeks to get to 50% done, you will be expected to be done in two more weeks”. Bummer.
Even after trashing the “percent complete” earned-value-management method in the previous paragraphs, I think there is a chance to acquire a long term benefit by tracking progress this way. The benefit can accrue IF AND ONLY IF the method is not taken too seriously and it’s not used to impose undue stress upon the software creators and builders who are trying their best to balance time-cost and quality. Performing the “percent complete” method over a bunch of projects and averaging the results can yield decent, but never 100% accurate, metrics that can be used to more effectively estimate future project performance. What do you think?
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?
Stacks And Icebergs
The picture below attempts to communicate the explosive growth in software infrastructure complexity that has taken place over the past few decades. The growth in the “stack” has been driven by the need for bigger, more capable, and more complex software-intensive systems required to solve commensurately growing complex social problems.
In the beginning there was relatively simple, “fixed” function hardware circuitry. Then, along came the programmable CPU (Central Processing Unit). Next, the need to program these CPUs to do “good things” led to the creation of “application software”. Moving forward, “operating system software” entered the picture to separate the arcane details and complexity of controlling the hardware from the application-specific problem solving software. Next, in order to keep up with the pace of growing application software size , the capability for application designers to spawn application tasks (same address space) and processes (separate address spaces) was designed into the operating system software. As the need to support geographically disperse, distributed, and heterogeneous systems appeared, “communication middleware software” was developed. On and on we go as the arrow of time lurches forward.
As hardware complexity and capability continues to grow rapidly, the complexity and size of the software stack also grows rapidly in an attempt to keep pace. The ability of the human mind (which takes eons to evolve compared to the rate of technology change) to comprehend and manage this complexity has been overwhelmed by the pace of advancement in hardware and software infrastructure technology growth.
Thus, in order to appear “infallibly in control” and to avoid the hard work of “understanding” (which requires diligent study and knowledge acquisition), bozo managers tend to trivialize the development of software-intensive systems. To self-medicate against the pain of personal growth and development, these jokers tend to think of computer systems as simple black boxes. They camouflage their incompetence by pretending to have a “high level” of understanding. Because of this aversion to real work, these dudes have no problem committing their corpocracies to ridiculous and unattainable schedules in order to win “the business”. Have you ever heard the phrase “aggressive schedule”?
“You have to know a lot to be of help. It’s slow and tedious. You don’t have to know much to cause harm. It’s fast and instinctive.” – Rudolph Starkermann
Endless Loop
Are you a player in an endless loop like this:
If so, are you the pontiff? A cardinal? A bishop? A “mass”? If you ARE a player in this endless loop, do you aspire to play a different role, and why? Do you want to be the selector and promulgator of the next “j” proclamation? Do you fancy the bling that the cardinals, bishops, and pontiff adorn themselves in? Do you want to change the content of one or more of the loop steps, especially number 9?
Motivility
In one of the Vital Smarts crew’s books (I forget which one, and I’m too lazy-ass to look it up) they mention motivation and ability as two important metrics that leaders can leverage to help people improve performance. To make things simple, but hopefully not simplistic, I’ve constructed a “Leader’s Action Table” (LAT) below using a binary “Present” or “Absent” value for each of the motivility attributes.
Since, by definition, a leader is pro-active and he/she cares about people and performance (both), he/she will take the time and effort to get to know his/her people well. The leader can then use the simple, two attribute , four action LAT to help his/her people grow and develop.
With bozo managers, the story is much different. Even if they stopped thinking about themselves and their careers long enough to consider the individual needs of their people in terms of the two motivility attributes, those bozeltines would get it back-asswards and hose everything up – of course. Instead of a LAT, they’d wield the BAT shown below. BATter up!
Do you think the LAT could be useful? What would your LAT look like? Are there any important attributes that you think are missing from the table? Should one or either of the motivility attributes be multi-valued instead of binary? Meh?
“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
Problems And Challenges
It’s easy to view a situation that requires action as a “challenge” instead of a “problem” if you don’t personally have to effect the change yourself. That’s why managers talk about challenges and workers talk about problems. Since hierarchical command and control corpocracies are inherently stratified caste systems, managers and workers don’t have a chance of seeing the same thing – a prallenge.
Best Of The Best
The breadth of variety of companies, markets, customers, industries, products, and services in the world is so wide and diverse that it can be daunting to develop objectively measurable criteria for “best in class” that cuts across all of the variability.
Being a simpleton, my pseudo-measurable criteria for a “best in class” company is:
- Everybody (except for the inevitable handful of malcontents (like me?) found in all organizations) who works in the company sincerely feels good about themselves, their co-workers, the products they build, their customers, and the company leadership.
That’s it. That’s my sole criterion (I told you I was a simpleton). Of course, the classical financial measures like year-over-year revenue growth, profitability, yada, yada, yada, matter too, but in my uncredentialed and unscholarly mind, those metrics are secondary. They’re secondary because good numbers are unsustainable unless the touchy-feely criterion is continuously satisfied.
The dilemma with any kind of “feel good” criteria is that there aren’t many good ways of measuring them. Nevertheless, one of my favorite companies, zappos.com, has conjured up a great way of doing it. Every year, CEO Tony Hsieh sends an e-mail out to all of his employees and solicits their thoughts on the Zappos culture. All the responses are then integrated and published, unedited, in a hard copy “Zappos Culture Book”.
The Zappos culture book is available free of charge to anyone who emails Tony (tony@zappos.com). Earlier this year, I e-mailed Tony and asked for a copy of the book. Lo and behold, I received the 400+ page tome, free-of-charge, four days later. I poured through the 100’s of employee, executive, and partner testimonials regarding Zappos’s actual performance against their espoused cultural values. I found no negative entries in the entire book. There were two, just two, lukewarm assessments of the company’s cultural performance. Of course, skeptics will say that the book entries were censored, and maybe they were, but I doubt it.
How would your company fare if it compiled a yearly culture book similar to Zappos’s? Would your company even entertain the idea? Would anyone feel comfortable proposing the idea? Is the concept of a culture book only applicable to consumer products companies like Zappos.com, or could its value be industry-independent?
Note: Zappos.com was recently bought out by Amazon.com. It should be interesting to see if the yearly Zappos culture book gets squashed by Jeff Bezos et al.
Man, These Guys Are Good
In general, I think that management consultants are way overpaid and full of themselves. These bozos with fat heads come waltzing in to a company in trouble and:
- analyze the “situation” from afar without getting their hands dirty,
- dispense all kinds of “proprietary” voodoo advice,
- collect their fee,
- and then bolt – leaving the ineffective corpocrats (who caused the mess in the first place) to clean up their own dung.
Notwithstanding the vitriolic diatribe in the previous paragraph, I think the following consulting dudes are the real deal: Vital Smarts. They’re people-oriented instead of mechanistically process-oriented. Collectively, they’ve talked with tens of thousands of workers; from the dweebs in the cellar to the exalted royalty in the corner of the building. They’ve also analyzed a ton of academic research to derive some down to earth, pragmatic, and potentially actionable direction for everyone – not just the patriarchs who direct the horror show. I’ve read all of their terrific bestselling books:
I’ve actually tried to employ their teachings in an attempt to be more effective in the workplace, but Ive failed miserably. Of course, it’s not their fault. It’s me and my “Unshakeable Cognitive Burden” of negativity toward all man-made command and control hierarchies.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 