Archive
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?
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
Ignore The Messenger
The more civilized, modern day equivalent of “shoot the messenger” is “ignore the messenger“. In (so-called) enlightened organizations, couriers of bad news aren’t physically eviscerated like in the old days, they’re simply ignored – at first.
If the bearers of blasphemy don’t get the hint and continue to badger the dudes in the upper layers of the corpo cake, a stronger feedback signal is emitted in the form of cleverly disguised words. Well, they’re cleverly disguised most of the time?
High Level Doers
Jim Goodnight, (CEO of the SAS Institute, Inc), writes code on the side: “His first love is programming, which he likens to solving puzzles“. Marissa Meyer (Vice President, Search Products & User Experience, Google, Inc.) writes code on the side:
I still like to write some programs every year. I do some programming on the weekends. Lately it’s been more web-centric, using PHP and MySQL. The next thing I’ll try to tackle is the Google App Engine. I’m looking to do a little more programming with Python and Ruby on Rails. But I think it’s just an element of keeping my skills fresh by exploring some of these new trends and keeping my hand in coding, even if it’s on the side of core Google work. – From the book “Making It Big In Software“
Gee, do you think this low level behavior by high level employees has anything to do with why these two companies are considered insanely great by boatloads of experts and laymen? How about your company? Forget about those in the stratosphere like Jim and Marissa, do any of your front line managers do any grunge work “on the side” to keep themselves grounded in reality? Probably not, because when they made the leap into the guild of management they became too self-important for such mundane activity. Plus, because they’re expected to be infallible, they can’t be “seen” making any mistakes by the DICforce.
Approver To Approvee Ratio
Every non-trivially sized profit-making organization has a number of approvers and approvees. For approvees to be enabled to do anything of significance like, uh, create products and respond to customers, they need the blessing of one or more approvers. As the graph below implies, it’s the “or more” word duo in the previous sentence that has an ominous connotation.
As the AAR in a group of people organized for a purpose increases, the org’s CPERF will start declining at some point in time. At a mystical value of “K”, the point of no return is reached and it’s all down hill from there. As the K threshold is exceeded, the maze of approver signatures that an approvee needs to navigate becomes untenable and the responsiveness of the “system” goes down the crapper. Even worse, the lower class approvee subgroup soon jettisons its sense of initiative and only assaults the approver fortress when a high ranking approver him/herself forces the action.
In clueless corpricracies, no one diligently watches over the AAR and prevents it from exceeding K. Quite the contrary, approvers love to hire more approvers because they have much in common with them and they love to have other approvers report to them – so they can approve the underling approver’s future requests for approval.
Approve, approve, approve your request, gently up the chain.
Sourly, sourly, sourly, sourly, work is but a drain.
Survive And Prosper
The purpose of a living system is to survive and prosper. There are different levels of systems. For example, there’s the organization, the organizational unit, the organizational group, and the organizational worker. Each of these human-composed entities can be considered a System Of Interest (SOI) unto itself and, as the figure below shows, SOIs are nested and connected.
If you believe my BS assertion that the purpose of a SOI is to survive and prosper, then each SOI may (and almost always does) choose to do whatever it can to survive, regardless of the cost to other internally nested and externally coupled systems. Of course, since everything is connected, the actions chosen by one “subsystem” to optimize its survival can (and almost always does) degrade the survival chances of those subsystems nested within it and those systems in which it is nested. For example, if a Bureaucratic Overhead Org Group (BOOG) like “purchasing” puts a boatload of Draconian procedures and forms and approval barriers in place to show how “important” they are, they degrade corpo performance by hindering timely acquisition of external equipment and services needed to get the job done. Schedules slip, which means customers aren’t delighted, and the people in other SOIs think twice about ordering tools that could make them more efficient and happy.
The dysfunction is even worse than you think. When a member of another SOI tries to point out the inefficiency of a BOOG to the so-called BOOG Leader (BOOGL), the auto-defense instinct kicks into high gear. Clever BOOGLs (and they must be clever because they got themselves appointed as a BOOGL in the first place) twist the situation out of whack. The instigator and his/her native SOI are made out to be the cause of inefficiency in the BOOG. This is done, of course, so that the BOOGL and his/her BOOG can survive and prosper. It’s so sad that ya gotta laugh…… LOL!
In Defense Of Incompetence.
When a government contractor is exposed as incompetent by an external observer (e.g. the press or a civilian group), the government agency that hired them almost always comes to its defense. That shouldn’t be surprising to you because those bureaucratic, and thus, mindless agencies:
- Will do anything to avoid looking incompetent in front of congress for hiring the nin-cum-poops
- Spend other people’s money (yours and mine) instead of their own – and we’re not talkin pocket change here
In addition, the “esteemed” government watchdog agencies (e.g. SEC and FDA and EPA) responsible for ensuring that contractors don’t perpetuate gargantuan disasters make up all kinds of excuses for not detecting the incompetence before massive stakeholder damage has been manifest (lost money, lost lives, lost livelihoods). They do this, of course, because these dudes don’t want to look incompetently asleep at the wheel either.
The system sux and the exhibited behavior is encrusted in its hierarchical, silo+caste system structure that crushes individual conscience. Expect this behavior to go on and on since complexity and the intertwining of interests and agendas will no doubt keep increasing as the world’s population increases. After all, if we can’t fix it, it ain’t broke.
All My Children
When rearranging the chairs within their stratified and siloed command and control hierarchies fails (and it almost always fails) to improve performance, mechanistically thinking patriarchs often resort to the ubiquitous centralize/decentralize cycle. However, the c/d cycle is also a stone cold loser for improving performance because all it does is spawn mini command and control patriarchies – just like daddy’s. The mindsets of daddy and his sons don’t change, so neither does performance – duh! But hey, at least there’s a lot of action taking place and it looks impressive to outsiders – til the duplication of work and resources is realized and the move back to centralization takes place.
Pick And Own
No, the title of this blost (short for blog-post and pronounced “blow-ssst”) is not “pick your nose“. It’s “pick and own“. My friend Bill Livingston uses the following catchy and true phrase throughout his book “Design For Prevention“:
He who picks the parts owns the behavior. – Unknown
This is certainly true in the world of software development for new projects. For maintenance projects, which comprise the vast majority of software work, this dictum also holds:
He who touched the code last owns the stank. – Unknown
Bill also truly but sadly states that when something goes awry, the dude who “picks the parts” or “owns the stank” is immediately sought out for punishment. When everything goes smoothly, the identity of the designer/maintainer magically disappears.
Punishment but no praise. Such is the life of a DIC. BMs, CGHs and CCRATS on the other hand, clever as they are, flip everything upside down. Since they don’t pick or maintain anything, they never get blamed for anything that goes wrong. Going one step further, they constantly praise themselves and their brethren while giddily playing the role of DIC-punisher and blamer.
WTF you say? If you fellow DICsters didn’t know this already, then accept it and get used to it because it’ll sting less when it happens over and over again. Tis the way the ancient system of patriarchical CCH institutions is structured to work. It doesn’t matter who the particular cast of characters in the upper echelons are. They could individually be great guys/gals, but their collective behavior is ubiquitously the same.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 