Archive
My Leadership Cut
This is the way it is……
Is it the way it should be? Are there any alternatives that could “work”? Are there even any slight variations on this same-old, same-old, scheme that can make it work better compared to the rest of the herd? Nah. No way, right?
A Change In Funding Source
The figure below shows a dorkily simplistic UML sequence diagram example of the provision of service from a support group (e.g. purchasing, quality assurance, configuration management) to a product development group within a CCH patriarchy. During product development, the team aperiodically requires and requests help from one or more corpo groups who’s raison d’etre is to provide timely support to those who need it. 
Depending on who’s leading the support group, the service it provides can be highly responsive and of high quality. However, since the standard “system” setup in all CCH corpocracies is as shown in the sequence diagram below, the likelihood of that being true is low. That’s because in centralized patriarchies, all budgets, salaries, and token rewards are doled out by the sugar daddys perched at the top of the pyramid. On the way down, the middlemen in the path take a cut out of the booty for, uh, the added-value “leadership” they provide to those on the next lower rung in the ladder.
In exchange for their yearly/quarterly investments in the lower layers of the caste system, the dudes in the penthouse require periodic status reports (which they can’t understand and which are usually cleverly disguised camouflage) that show progress toward wealth creation from the DICs below.
Since their bread is buttered from the top and not their direct customers, the natural tendency of support groups is to blow off their customers’ needs and concentrate on maximizing their compensation from the top. They do this, either consciously or unconsciously, by adding complexity to the system in the form of Byzantinian procedural labyrinths for customers to follow to show how indispensable they are to the b’ness. As a result, their responsiveness decreases and their customers experience an increase in frustration from shoddily late service.
So how does one fix the standard, dysfunctional, centralized, CCH setup? Check out and ponder the sequence diagram below for a possible attempt at undoing the dysfunctional mess. Can it work? Why, or why not?
By definition, if everyone is doing industry best practice, it’s not best practice. It’s average practice.
Bureaucracy Reinforcement
In the “Bureaucracy Formation” post, I hypothesized about how orgs can undetectably transform from vibrant and flexible citizens into rigid and slovenly slow, bullies. As a refresher, the figure below carries over the pre- and post-transformation “system” states from that post. Sadly, after the t=Bureaucracy time threshold is passed, the situation gets worse than the picture implies.
In order to survive, thrive, and indisputably “show” their importance to the well being of the whole, each support group continuously adds more and more time sucking and money hogging work of questionable added-value to the system. However, the work they add is not for them to do. Incredulously, it’s red tape work they impose on their clients (a.k.a. customers), which are the product group and “other” support groups that are forced to use their service.
Early on in the stages of org development, it’s relatively easy to get support. You ask a person for help and you get it in a timely fashion. If you have to supply input along with your request, like a piece of software, or hardware, or a document, you don’t have to meet any arcane content, formatting, or packaging requirements. Over time, however, everything changes. First, a simple form is required. Then, a more detailed form. Then, more than one form. Then multiple forms and multiple signatures are required. Then you are required to follow a detailed step by step procedure that is so arcane and unmemorable that you have to look it up every time you need service. Then, if you do something wrong, you’re scolded for not knowing the process. On and on it goes. You get the picture, no?
Where You Stand
In “Making It Big In Software“, author Sam Lightstone quotes former GE CEO Jack Welch:
You want to make sure everyone knows where they stand in the organization. It’s a leader’s obligation. In most companies, the leaders stand back, and people don’t know where they stand. – Jack Welch
Do your performance appraisal and compensation systems allow you to clearly determine where you stand? If not, do you know what’s missing (hint: a clear and unconfusing connection between the two)? If you do know what’s missing, have you raised your concern to management? If you haven’t raised your concern to management, why not (hint: fear)?
Bureaucracy Formation
Since I’m not a big fan of bureaucracies, let’s have some fun and see how these resource sucking and dehumanizing orgs are naturally formed right under the noses of the high paid corpo dudes who are ironically “responsible” for keeping costs down. As you’ll see, it may even be worse than you think. The infallible, know-it-all, multi-titled CGHs in charge not only allow their bureaucracy to flourish, they feed and water it as a result of the unconscious and self-centered need for ego expansion.
Check the figure below out for a hypothetical example of the formation of a bureaucracy over time. As usual, I’ve made the example up (cuz I’m a L’artiste) and I’ve simplistically decomposed a complex org into two group archetypes; product and support. In my obviously wrong dream-world, the otherwise highly esteemed management class is a support group sub-type, of course.
At t=Start, when a vibrant and competent startup org is initialized, there are no “support” groups: nada, zilch. There’s only a product development (or service provider) group that does everything needed to sustain and grow a business around the wealth-creating product (or service).
As time tics by and the fledgling enterprise grows, one support group after another is added as another ring of fat around the product development group core. At the beginning, the support groups are few, and they’re subordinate both in stature and compensation to the wealth creation group because everyone knows that the product and/or service brings home the bacon.
As the org matures, an incredulous flip in the stature structure snaps into place (t=T3 in the example above) because, well, because that’s the way it is. The first of many subsequent support groups to rise in stature is the executive level management cadre. As even more corpo maturation accrues, all emotional enthusiasm and passion is expelled from the org because the same-old, same-old, mechanistic, B-school and Wall Street psychology usurps the childlike and immature “let’s change the world” mindset which birthed the org in the first place. The so-called management leadership cabal catalyzes and accelerates the move to bureaucracy by; treating wealth creators as easily replaceable DICs, punishing any publicly expressed passion and enthusiasm, cloning themselves in newly added middle management layers, and growing their personal empires in order to inflate their pocketbooks and sense of importance at the expense of the org as a whole. Bummer.
“Are you here to build a career or to build an organization?” – Peter Block
Herman Miller’s Design for Growth
Herman Miller Inc, of Aeron chair fame, is a rare breed. They consistently morph with the times and remain profitable in turbulent waters. This article, Herman Miller’s Design for Growth, tells the compelling story of the genesis of a new suite of products named Convia that spawned a brand new subsidiary business.
The terrific strategy + business article not only recounts the technical story behind the convia product line, it tells the story of the innovative management practices employed by the company’s leadership over the lifetime of the company:
The creation of Convia might sound like a tale of pure product innovation, or even of technology adoption, but it is actually a story about management — and only the most recent of several similar stories at Herman Miller. Over many decades, the company has made itself a laboratory for testing new management ideas and turning them into effective practice.
First, the hard evidence that the company is highly successful despite its repeated forays into the unknown:
Herman Miller competes in an industry slammed by arguably the worst commercial real-estate crisis in a generation. Still, despite a 19 percent plunge in sales for fiscal 2009 (ending in May), the US$1.6 billion company reported a $68 million profit, albeit down from $152 million in fiscal 2008. Over the last 10 years, its stock has consistently outperformed the Standard & Poor’s 500 index.
Next, the snippets that yield insights into the off-the-beaten-path management mindset of the company’s leaders:
…two key principles that continue to inform the company’s management approach. One was a commitment to participative management; the other, a problem-solving approach to design.
Max De Pree, CEO from 1980 to 1987, drew broad attention to the culture at Herman Miller by writing the bestselling Leadership Is an Art (Dell, 1990). Of participative management, he wrote: “Each of us, no matter what our rank in the hierarchy may be, has the same rights: to be needed, to be involved, to have a covenantal relationship, to understand the corporation, to affect our destiny, to be accountable, to appeal, to make a commitment.”
He (Brian Walker, the company’s former chief financial officer, who took over as CEO in 2004) wanted everyone at the company to calculate the financial effect of decisions big and small. It didn’t matter if they were involved in buying, selling, building, designing, billing, paying, or financing. Or whether they were charged with controlling quality, reliability, inventory, waste, energy use, scrap, or the kinds of staples people used.
As Long (now director of the corporate HMPS team) toured the file cabinet plant recently, a visitor paused by a welding robot and asked, “Why don’t you use more robots?” “Robots,” Long said, “can’t make themselves better.”
The objective was to have top decision makers invest themselves in the work — to be companions on the journey, not simply judges of it. “The idea,” Miller says, “was to change the dynamic from traditional review-and-approve to advocacy.”
But Walker argued that in the feeble economy, the main goal was to keep the business sustainable, not to increase profitability at the expense of employees.
Walker says he has no regrets about paying people for time not worked, as the program generated a lot of goodwill and credibility for top management.
So, what do you think? Is the image of Herman Miller Inc. different from the stale corpo model entrenched in your brain?
Exaggerated And Distorted
The figure below provides a UML class diagram (“class” is such an appropriate word for this blarticle) model of the Manager-Developer relationship in most software development orgs around the globe. The model is so ubiquitous that you can replace the “Developer” class with a more generic “Knowledge Worker” class. Only the Code(), Test(), and Integrate() behaviors in the “Developer” class need to be modified for increased global applicability.
Everyone knows that this current model of developing software leads to schedule and cost overruns. The bigger the project, the bigger the overruns. D’oh!
In this article and this interview, Watts Humphrey trumps up his Team Software Process (TSP) as the cure for the disease. The figure below depicts an exaggerated and distorted model of the manger-developer relationship in Watts’s TSP. Of course, it’s an exaggerated and distorted view because it sprang forth from my twisted and tortured mind. Watts says, and I wholeheartedly agree (I really do!), that the only way to fix the dysfunction bred by the current way of doing things is to push the management activities out of the Manager class and down into the Developer class (can you say “empowerment”, sic?). But wait. What’s wrong with this picture? Is it so distorted and exaggerated that there’s not one grain of truth in it? Decide for yourself.
Even if my model is “corrected” by Watts himself so that the Manager class actually adds value to the revolutionary TSP-based system, do you think it’s pragmatically workable in any org structured as a CCH? Besides reallocating the control tasks from Manager to Developer, is there anything that needs to socially change for the new system to have a chance of decreasing schedule and cost overruns (hint: reallocation of stature and respect)? What about the reward and compensation system? Does that need to change (hint: increased workload/responsibility on one side and decreased workload/responsibility on the other)? How many orgs do you know of that aren’t structured as a crystalized CCH?
Strangely (or not?), Watts doesn’t seem to address these social system implications of his TSP. Maybe he does, but I just haven’t seen his explanations.
Cradle To Grave Indoctrination
“Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are even incapable of forming such opinions.” – Albert Einstein
To me, the second sentence is the most insightful part of this quote. My subjective interpretation is that Einstein discovered that the cradle-to-grave indoctrination of most individuals teaches them to become subservient to the herd mindset prevailing during their time on earth. This indoctrination is so effective and so complete that they don’t have a clue that their capacity to think afresh has been vastly constrained by their social environment. What do you think Einstein meant when he said the words? Your interpretation is as invalid as mine.
I don’t think there’s any conspiracy theory here, it’s just the natural course of development in any society that has been “trained” to revere human-concocted hierarchical structures of governance. I say “human-concocted” because there are no hierarchies in nature. We automatically and impulsively impose hierarchies on everything we observe because that’s the only way we know how to make sense of, understand, and (attempt to) control the world. Building command and control hierarchies and requiring unquestioning subservience to those arbitrarily placed “above” you in the caste system is the way of the human race – today. Do you think this situation will remain that way for your lifetime? How about, forever?
Double Whammy
Five Principles
Watts Humphrey is perhaps the most decorated and credentialed member of the software engineering community. Even though his project management philosophy is a tad too rigidly disciplined for me, the dude is 83 years young and he has obtained eons of experience developing all kinds of big, scary, software-intensive systems. Thus, he’s got a lot of wisdom to share and he’s definitely worth listening to.
In “Why Can’t We Manage Large Projects?“, Watts lists the following principles as absolutely necessary for the prevention of major cost and time overruns on knowledge-intensive projects – big and small.
Since nobody’s perfect (except for me — and you?), all tidy packages of advice contain both fluff and substance. The 5 point list above is no different. Numbers 1, 4 and 5, for example, are real motherhood and apple pie yawners – no? However, numbers 2 and 3 contain some substance.
Trustworthy Teams
Number 2 is intriguing to me because it moves the screwup spotlight away from the usual suspects (BMs of course), and onto the DICforce. Watt’s (rightly) says that DIC-teams must be willing to manage themselves. Later in his article, Watts states:
To truly manage themselves, the knowledge workers… must be held responsible for producing their own plans, negotiating their own commitments, and meeting these commitments with quality products.
Now, here’s the killer double whammy:
Knowledge worker DIC-types don’t want to do management work (planning, measuring, watching, controlling, evaluating), and BMs don’t want to give it up to them. – Bulldozer00
Besides disliking the nature of the work, the members of the DICforce know they won’t be rewarded or given higher status in the hierarchy for taking on the extra workload of planning, measuring, and status taking. Adding salt to the wound, BMs won’t give up their PWCE “job” responsibilities because then it would (rightfully) look like they’re worthless to their bosses in the new scheme of things. Bummer, no?
Facts And Data
As long as orgs remain structured as stratified hierarchies (which for all practical purposes will be forever unless an act of god occurs), Watts’s noble number 3 may never take hold. Ignoring facts/data and relying on seniority/status to make decisions is baked into the design of CCHs, and it always will be.
It’s the structure, stupid! – Bulldozer00
Open Loop
I’m currently working on a really exciting and fun software development project with several highly competent peers. Two of them, however, like to operate open loop and plow ahead with minimal collaboration with the more disciplined (and hence, slower) developers. These dudes not only insert complex designs and code into their components without vetting their ideas before the rest of the team, they have no boundaries. Like elephants in a china shop, they tramp all over code in everybody else’s “area of ownership”.
“He who touches the code last, owns it.” — Anonymous
Because of the team cohesion that it encourages, I’m all for shared ownership, but there has to be some nominal boundary to arrest the natural growth in entropy inherent in open loop systems and to ensure local and global conceptual integrity.
Even though these colleagues are rogues, they’re truly very smart. So, I’m learning from them, albeit slooowly since they don’t document very well (surprise!) and I have to laboriously reverse engineer the code they write to understand what the freak they did. Even though feelings aren’t allowed, I “feel” for those dudes who come on board the project and have to extend/maintain our code after we leave for the next best thing.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 