Archive
Underbid And Overpromise
As usual, I don’t get it. I don’t get the underbid-overpromise epidemic that’s been left untreated for ages. Proposal teams, under persistent pressure from executives to win contracts from customers, and isolated from hearing negative feedback by unintegrated program execution and product development teams, perpetually underbid on price/delivery and over-promise on product features and performance. This unquestioned underbid-overpromise industry worst practice has been entrenched in mediocracies since the dawn of the cover-your-ass, ironclad contract. The undiscussable but real tendency to, uh, “exaggerate” an org’s potential to deliver is baked into the system. That’s because competitors and customers are willing co-conspirators in this cycle of woe. The stalemate ensures that there’s no incentive for changing the busted system. As the saying goes; “if we can’t fix it, it ain’t broke!“. D’oh!
If a company actually could take the high road and submit more realistic proposals to customers, they’d go out of business because non-individual customers (i.e. dysfunctional org bureaucracies where no one takes responsibility for outcomes) choose the lowest bidder 99.99999% of the time. I said “actually could” in the previous sentence because most companies “can’t“. That’s because most are so poorly managed that they don’t know what or where their real costs are. Unrecorded overtime, vague and generic work breakdown structures, inscrutable processes, and wrongly charged time all guarantee that the corpo head sheds don’t have a clue where their major cost sinks are. Bummer.
Perverted Inversion
In simplistic terms, material wealth in the form of profits is created through the delivery of products and/or services that provide some sort of perceived value to a set of customers. The figure below illustrates the priorities, from highest on the top to lowest on the bottom, of all successful product-oriented startup businesses.
Since products create the wealth that sustains a business, they receive top billing. The care and feeding of the golden geese via a supportive product development group is next in importance. At the bottom, and deservedly so, is the management of the business. Nevertheless, the fact that it’s on the priority list at all means that managing the business is important – but not as important as the product-centric activities.
Without any facts or any background research to back it up (cuz I like to make stuff up), I assert that most entrepreneurs hate doing the business management “stuff”. Some despise the mundane activities of running a business so much that their negligence can cause the fledgling enterprise to fail just as quick as launching the business without any product or service to sell. Having said that, hopefully you’ll agree that any business priority list without the product portfolio perched at the top is a sure path to annihilation. The other two arrangements of the lower priority activities (shown below) can also work, but maybe not as effectively as the initial proposed stack.
As a business thrives and grows larger, a strange perverted inversion occurs to those who lose their way (but thankfully, not all do). The business management function bubbles to the surface of the priority stack (WTF?). This happens ubiquitously across the land because hot shot, fat headed, generic managers who don’t know squat about the org’s specific product portfolio are chaufeurred in to grow the business. These immodest dudes, thinking of themselves as Godsends from MBA city, put themselves and what they do at the top of the priority stack to…… enrich themselves no matter what. Of course, these wall street stooges perform this magic act while espousing that the product set and those that create it are forever the org’s “most valuable asset“.
Post-startup businesses can survive with the perverted priority stack in place, but they usually muddle along with the rest of the herd and they aren’t exhilarating or engaging places to work. Do you work for one?
At a certain age institutional minds close up; they live on their intellectual fat. – William Lyon Phelps
Makin’ Stuff Up
As I’ve said many times before: “I like to make stuff up“.
Two radically different ways of labeling people (I know, I know – you’re above passing judgment on people) who make stuff up are: liar and artist. After all, makin’ stuff up means that the “stuff” is new in some way. In the case of a liar, the spoken or written words assert that something exists when it doesn’t, or an event happened when it didn’t, or vice versa. The same idea holds for the case of an artist, except there are more choices of media for expression.
Now that you know what I am, what are you?
Architectural Choices
Assume that a software-intensive system you’re tasked with designing is big and complex. Because of this, you freely decide to partition the beast into two clearly delineated layers; a value-added application layer on top and an unwanted overhead, but essential, support layer on the bottom.
Now assume that a support layer for a different application layer already exists in your org – the investment has been made, it has been tested, and it “works” for those applications it’s been integrated with. As the left portion of the figure below shows, assume that the pre-existing support layer doesn’t match the structure of your yet-to-be-developed application layer. They just don’t naturally fit together. Would you:
- try to “bend” the support layer to fit your application layer (top right portion of the figure)?
- try to redesign and gronk your application layer to jam-fit with the support layer (bottom right portion of the figure)?
- ditch the support layer entirely and develop (from scratch) a more fitting one?
- purchase an externally developed support layer that was designed specifically to fit applications that fall into the same category as yours?
After contemplating long term maintenance costs, my choice is number 4. Let support layer experts who know what they’re doing shoulder the maintenance burden associated with the arcane details of the support layer. Numbers 1 through 3 are technically riskier and financially costlier because, unless your head is screwed on backwards, you should be tasking your programmers with designing and developing application layer functionality that is (supposedly) your bread winner – not mundane and low value-added infrastructure functionality.
Golf Outfit
For the past 15 or so years, I’ve been going on a yearly golf trip with a group of good friends. This year’s “golf camp 2010” starts next Saturday, 4/10/10. In preparation for the upcoming debacle, I e-mailed the group a picture of the top third of my planned opening day outfit:
I asked who wanted to be in my foursome and I received these two answers:
- “You look pretty”
- “I would, but I heard that you had three others already.”
I’m having trouble deciding which shorts to wear. I was thinking “Hot Dog”, but “Disco Balls” seems to better match my hair style. What do you think?
Bah Hum BUG
Note: For those readers not familiar with c++ programming, you still might get some value out of this nerd-noid blarticle by skipping to the last paragraph.
The other day, a colleague called me over to help him find a bug in some c++ code. The bug was reported in from the field by system testers. Since the critter was causing the system to crash (which was better than not crashing and propagating bad “logical” results downstream) a slew of people, including the customer, were “waiting” for it to be fixed so the testers could continue testing. My friend had localized the bug to the following 3 simple lines:
After extracting the three lines of code out of the production program and wrapping it in a simple test driver, he found that after line 3 was executed, “val” was being set to “1” as expected. However, the “int” pointer, p_msg, was not being incremented as assumed by the downstream code – which subsequently crashed the system. WTF?
After figuring it out by looking up the c++ operator precedence rules, we recreated the crime scene in the diagram below. The left scenario at the bottom of the figure below was what we initially thought the code was doing, but the actual behavior on the right was what we observed. Not only was the pointer not incremented, but the value in msg[0] was being incremented – a double freakin’ whammy.
Before analyzing the precedence rules, we thought that there was a bug in the compiler (yeah, right). However, after thinking about it for a while, we understood the behavior. Line 3 was:
- extracting the value in msg[0] (which is “1”)
- assigning it to “val”
- incrementing the value in msg[0]
Changing the third line to “int val = *p_msg++” solved the problem. Because of the operator precedence rules, the new behavior is what was originally intended:
- extract the value in msg[0] (which is “1”)
- assign it to “val”
- increment the pointer to point to the value in msg[1]
A simple “const” qualifier placed at the beginning of line 2 would have caused the compiler to barf on the code in line 3: “you cannot assign to a variable that is const“. The bug would’ve been squashed before making it out into the field.
It’s great to be brought down to earth and occasionally being humbled by experiences like these; especially when you’re not the author of the bug 🙂 Plus, after-the-fact fire fighting is cherished by institutions over successful prevention. After all, how can you reward someone for a problem that didn’t occur because of his/her action? Even worse, most institutions actively thwart the application of prevention techniques by imposing Draconian schedules upon those doing the work.
The world is full of willing people, some willing to work, the rest willing to let them. – Robert Frost
My contortion of this quote is:
The world is full of willing people, some willing to work, the rest willing to manage them while simultaneously pressuring them into doing a poor job. – Bulldozer00
A New Title Should Do It
“To solve our decreasing revenue and rising cost problems, we’ll just create a new title and insert the position into the org (thereby adding another layer to the stratified corpo cake). Voila! The problem will be solved (so let’s give ourselves a special bonus for being so smart).”
“But wait. What should the title be? Supervisor, Manager, Deputy Manager, Director, Deputy Director, General Manager? Should we bump it up by attaching a “Chief” and/or VP to the label? “We must be careful because the loftier the title, the more we’ll have to pay our new colleague (who will no doubt accomplish what we have failed to do).”
Such is the mindset of MBA trained corpo elites and their stooge press magazines like Business Week, Forbes, Fortune, et al. Do ya really think parachuting a messiah in to jumpstart an org with:
- an apathetic DICforce that is not as stupid as the head shed assumes and doesn’t appreciate management’s patronizing attitude
- an aging product development and manufacturing infrastructure (e.g. tools, processes, know how)
- an old and tired product portfolio that’s continually being usurped by competitor offerings
- a culture of undiscussable but obvious inter-group rivalry and disrespect
is realistic? Fragmented, hero-worshipping mindsets don’t clean up what Russell Ackoff calls, for lack of a better word, “messes”. Systemic thinking, along with the willingness to skinny dip, fully exposed, into the stinky mess is the only way to understand and clean up messes. Sadly, even if one or two dudes in the head shed junta are closet system thinkers and they try to speak out or take action, they’re promptly put back into their assigned slot….. and business resumes as usual…. while the mess grows ominously larger.
And now, for the bad news….. 🙂
Skill Acquisition
Check out the graph below. It is a totally made up (cuz I like to make things up) fabrication of the relationship between software skill acquisition and time (tic-toc, tic-toc). The y-axis “models” a simplistic three skill breakdown of technical software skills: programming (in-the-very-small) , design (in-the-small) and architecture (in-the-large). The x-axis depicts time and the slopes of the line segments are intended to convey the qualitative level of difficulty in transitioning from one area of expertise into the next higher one in the perceived value-added chain. Notice that the slopes decrease with each transition; which indicates that it’s tougher to achieve the next level of expertise than it was to achieve the previous level of expertise.
The reason I assert that moving from level N to level N+1 takes longer than moving from N-1 to N is because of the difficulty human beings have dealing with abstraction. The more concrete an idea, action or thought is, the easier it is to learn and apply. It’s as simple as that.
The figure below shows another made up management skill acquisition graph. Note that unlike the technical skill acquisition graph, the slopes decrease with each transition. This trend indicates that it’s easier to achieve the next level of expertise than it was to achieve the previous level of expertise. Note that even though the N+1 level skills are allegedly easier to acquire over time than the Nth level skill set, securing the next level title is not. That’s because fewer openings become available as the management ladder is ascended through whatever means available; true merit or impeccable image.
Error Acknowledgement: I forgot to add a notch with the label DIC at the lower left corner of the graph where T=0.
Stakeholders
The figure below shows the major stakeholders associated with a profit making institution. Except for the environment, which ironically but generously supplies the raw resources from which all value and profit are extracted, everyone wants the biggest piece of the profit pie they can get. 
Since management is the biggest influencer of org performance, the dudes in charge feel the greatest pressure to generate profits for themselves and all the other stakeholders. In order to relieve themselves of this pressure and provide themselves with the largest share of the treasury, unscrupulous executive “leadership” teams (and not all of them are so self absorbed) do everything they can to distance themselves from the “other” stakeholders:
- They hire lawyers and lobbyists to fend off taxes and regulations imposed by governments to keep their behavior in check
- They hand pick a group of yes men/women for their board of directors to keep the greedy owners one level removed from themselves
- They keep their workers in check via classic, subtle fear inducing tactics
- They ignore the environment – because it unselfishly makes no direct demands upon them
Great leadership teams don’t spend all their waking hours playing defense against the “others” and justifying their exorbitant compensation. They think systemicly and make compassionate decisions that balance the needs of all those involved in the enterprise.
And now, as a preview to next week’s self-righteous do-as-I-say-and-not-as-I-do sermon………………
Loop Dee Loo
I first learned about cause-effect diagrams from one of Jerry Weinberg’s books. I can’t remember which one because I have so many of them and I’m too lazy to browse through them all to find the exact source. Cause-effect diagrams are useful two dimensional tools that can be used to understand cyclical loops of relationships in a system of interacting components.
In the RWEP loop example below, revenue leads to work, which leads to execution, which leads to profit, which leads to more revenue. If a profit seeking organization is well run, the org leaders vigilantly keep track of the “whole” RWEP loop and influence each malleable component so that the loop is positively reinforced and the org prospers. Neglecting one or more of the dominant RWEP loop components can lead to an unstable system that breaks the loop and collapses the system.
Let’s investigate the ways the loop can break down so we can appreciate what good leaders actually do. The first obvious system buster is a halt to the revenue stream. This single point of failure can bring the whole shebang to a screeching halt in an instant. Since the importance of revenue to institutional viability is so patently obvious and measuring it is ridiculously easy, both good and bad leaders watch revenue closely and act (hopefully) accordingly to keep revenues rising.
The less scrutinized and harder-to-directly-measure system element, “efficient execution”, is a more subtle system buster. Crappy BMs who don’t (cuz they’re lazy or apathetic)) or can’t (because they’re incompetent) directly recognize efficient execution as a system buster take the easy way out by solely measuring profit as an indicator of execution performance. When profit declines, BMs thrash about because they’re at least one level of indirection away from where the rubber meets the road – execution. Since they’re out of touch, BMs make “suboptimal” decisions and issue ineffective mandates that actually accelerate the downward spiral in profits. Good leaders either directly evaluate execution efficiency according to their previous experience or they rely on frequently solicited feedback from those directly executing the work.
So there you have it in simple, maybe simplistic terms. Great leaders watch and positively influence both the (obvious) revenue and (subtle) execution contributors in the RWEP system loop.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 