Archive
Don’t Listen…. Imitate
To most (but not all) corpo execs and fatty middle managers everywhere, take heed:
“Children are never good at listening to their elders, but they never fail to imitate them.” – James Baldwin
OMG, I’m so embarrassed! In yesterday’s post, I hinted that I sort-of wanted to do away with my Father Guido Sarducci “find-the-poop-in-the-picture” pattern of immaturity. Nevertheless, if this quote from the “Wilde” man doesn’t hold a grain of truth to it, then I’m hopelessly hosed:
Life is too short to be taken seriously – Oscar Wilde
Peer Relationships
As you move up into the Bozone layers in a DYSCO, in addition to honing your Kiss-Up-Kick-Down skills, your horizontal relationships with your peers mysteriously start to change…..
Of course, the diagram is totally wrong and it lacks credible scientific evidence to back it up, no? Hey, what do you expect from a L’artiste?
Nice And Competent
It’s prolly just me, but I can’t seem to fully accept that most people equate niceness with competence – especially in the guild of layered management. Oh sure, there are lots of cases where people are both nice and competent, but there may be more cases where people are both nice and incompetent. What does your experience indicate?
One reason why there may be a lot of people who are both nice and incompetent is because niceness can camouflage incompetence – at least temporarily, and at most, till retirement. If you’re nice, your boss won’t scrutinize your work output (if he can understand it and isn’t incompetent himself) as closely than if you’re not nice. Thus, it’s better to be nice and incompetent than to be mean and incompetent – duh. Hell, niceness counts so much at top tier DYSCOs that it’s better to be nice and incompetent than not-nice and competent. Niceness trumps competence at these back asswards citadels.
If you’re a DICster, where it’s easier to “measure” competence by the material results you either do or don’t create, the cover up of incompetence by niceness doesn’t work nearly as well than if you’re a BM, SCOL, CGH, or BOOGL in a CCH org. Why? Because it’s much harder to measure middle management output. Most managers don’t create much of anything (except for angst and turmoil), so how can their performance be meaningfully measured? Plus, the senior managers who are supposed to do the “objective” measuring of their appointees don’t want to look bad by admitting that they knighted incompetent subordinate managers and incompetent, elite staff members.
So, what about me? I’m not nice and I’m incompetent, so this blarticle doesn’t apply to me. What about you?
Note: One way for a senior manager to measure a “junior manager’s performance is to ask junior’s people how he/she is helping them to grow and do a better job. Do you think this is done often in the corpo world? Even when this skip-level technique is miraculously performed, do you think honest feedback is obtained? Why or why not?
Where’s The Bug?
When you’re designing and happily coding away in the application layer and you discover a nasty bug, don’t you hate it when you find that the chances are high that the critter may not be hiding in your code – it may be in one of the cavernous homegrown libraries that prop your junk up. I hate when that happens because it forces me to do a mental context switch from the value-added application layer down into the support layer(s) – sometimes for days on end (ka-ching, ka-ching; tic-toc, tic-toc).
Compared to writing code on top of an undocumented, wobbly, homegrown BBoM, writing code on top of a professionally built infrastructure with great tutorials and API artifacts is a joy. When you do find a bug in the code base, the chances are astronomically high that it will be in your code and not down in the infrastructure. Unsurprisingly, preferring the professional over the amateur saves time, money, and frustration.
For the same strange reason (hint: ego) that command and control hierarchy is accepted without question as the “it just has to be this way” way of structuring a company for “success“, software developers love to cobble together their own BBoM middleware infrastructure. To reinforce this dysfunctional approach, managers are loathe to spend money on battle-tested middleware built by world class experts in the field. Yes, these are the same managers who’ll spend $100K on a logic analyzer that gets used twice a year by the two hardware designer dudes that cohabitate with the hundreds of software weenies and elite BMs inside the borg. C’est la vie.
It Has To Be This Way
This Fortune blarticle, “When you’re the boss, who gives you reviews?”, starts out with:
“A chief executive at a fast growing tech start-up recently approached executive coach Dave Kashen with an all-too common problem. The CEO frequently reached out to his executive team for feedback, but whenever he sought their opinions, his subordinates seemed to shut down and withdraw.”
Well, duh. This systemic behavior is the result of the cultural environment that CCH forms of governance auto-install into each bozone layer – all the way down the pyramidal stack. In corpo CCHs, the dudes at level N-1 are “taught” by the system to be subservient to their bosses at level N. Dudes at level N-2 are “taught” to be even more subservient to the bosses at level N than their own boss man at level N-1.
This “that’s just the way it has to be” indoctrination is so successful that it works the other way too. The dudes at level N are “taught” by the system to require subservience by the lessers at all levels below them. I wonder if the flustered CEO in the quote realizes this.
If the corpo system wasn’t designed to work this way, there would be anarchy and annihilation. No “ifs“, “ands“, or “buts” about it……… right?
FOSTMA And NASHMA
Whoo Hoo! I thought of a positive complement to my negative FOSTMA acronym. It’s, it’s, it’s….. NASHMA = Nayar, Semler, Hsieh MAnagement:
Of course, in order to prevent chaos, NASHMA orgs still have hierarchical structures, but they’re not run as stratified caste system CCHs. In NASHMA orgs, there’s real, two way accountability; and symmetric relationships exist up and down all levels. Most managers in NASHMA groups are PHORs and not STSJs who spend all their “valuable” time planning, watching, controlling, and evaluating.
Now mind you, to avoid the trap of dualistic thinking, an org shouldn’t be judged as fully belonging to one class or the other. There can be pockets of FOSTMA groups in a NASHMA org and vice versa. Nevertheless, my scientifically collected and analyzed data revealed this current distribution of institutions along the FOSTMA-NASHMA continuum:
Over time, hopefully the threshold will move to the left – increasing the currently miniscule NASHMA to FOSTMA ratio. However, there will always be powerful and scary psychological forces opposing the movement.
Double Loop Learning
Chris Aryris is a giant in the field of organizational development. LinkedIn e-colleague Gene Bellinger recently posted this classic Argyris article, “Teaching Smart People How To Learn“, to his “Systems Thinking” group. In the missive, Mr. Argyris gives a great example of double loop learning:
I have coined the terms ‘‘single loop’’ and ‘‘double loop’’ learning…. To give a simple analogy: a thermostat that automatically turns on the heat whenever the temperature in a room drops below 68 degrees is a good example of single-loop learning. A thermostat that could ask, ‘‘Why am I set at 68 degrees?’’ and then explore whether or not some other temperature might more economically achieve the goal of heating the room would be engaging in double-loop learning.
Because of the Law Of Impermanence (LOI), it’s inevitable that what worked in the past won’t work at some unknowable time in the future. The top half of the figger below illustrates the LOI in action. On the left, we have a successful org or individual happily humming along. The successful “entity” repeatedly performs actions that lead to success. As long as the external environment doesn’t change, this self-reinforcing loop of success can be sustained for quite a long time. However, since the LOI is constantly and relentlessly operating in the background, insanely doing the same thing over and over again will eventually guarantee failure. The failure may occur instantaneously like a broken axle while driving on the freeway, or it may manifest gradually like an excruciating death by a thousand cuts. Bummer.
Possibly the only way of keeping the LOI at bay is to institute double loop learning. The figger below shows the painful, transformational process of adding a second action-result-reflection loop to the system. By adding the skill of reflection, deteriorating results can be detected and action can be periodically tuned to accommodate a changing world.
Just because “deteriorating results can be detected and action can be tuned” doesn’t mean they will be. The forces against truthful org and individual reflection on poor results are formidable. Denial, angst, and fear, which are all dysfunctions of the individual and collective human ego, conspire against improving system robustness and viability via change. Reorgs, appointing the same people to funky new titles, bumping up compensation/perks, cutting costs, and attempting to apply all other textbook management tools amount to wrapping bandaids around a massive hemorrhage. Double bummer.
The hardest aspect of getting a double learning loop into operation is connecting the “Reflection” node back to the “Action” node so that actions can be changed. As I know too well, it’s relatively easy to reflect on one’s actions while exhibiting the same insane behavior over and over and over and over………..
“Without deviation from the norm, progress is not possible.” – Frank Zappa
Dilbert Disservice
Merry Christmas and Ho, Ho, Ho! Dear reader, if you don’t want to be negatively influenced today, then please move on and don’t read any further.
Before Dilbert and Scott Adams rocketed to fame and fortune by speaking about the unspeakable, DICsters toiling down in the boiler room at least had hope that the grass was greener on the other side. However, the Dilbert strip has unveiled what many didn’t know prior to its public emergence: the grass most likely isn’t greener “over there“.
Every day, Dilbert and his cohorts drive home the point that dysfunctional corpricracies are as ubiquitous and pervasive as the weeds in your garden. The strip has actually helped CCFs by demotivating DICsters from leaving toxic environments – because now they think that “it’s the same everywhere“. D’oh!
The Curiously Recurring Scramble Pattern
It’s funny to watch software development teams hack away for months building a just barely working patch-quilt monster that they can hardly understand themselves – and then scramble at the last minute generating design documents for some big upcoming management design review or “independent” auditor dog and pony show (woof woof!).
In this Curiously Recurring Scramble Pattern (CRSP), a successful attempt to avoid the labor of thinking is made as developers frantically sprinkle Doxygen annotations throughout the code and/or load the beast into a reverse engineering tool that mechanistically generates UML diagrams to model the as-built mess. It goes without saying that the tool’s “verbose” mode is selected in order to obscure meaning and promote the illusion of high falutin’ sophistication. Of course, all of this is a waste of time (= $$$$) because the dudes doing the reviewing (self-important managers and bureaucratic auditors) don’t want to understand a thing.
When the review or audit does take place; a couple of cream puff questions and comments are bantered about, check boxes are ticked off, a couple of superficial “action items” are generated, and the whole lovefest is rubber-stamped as a great success. Whoo Hoo, we rock!
Without a doubt, you and I have never been culturally forced to participate in an instantiation of the CRSP. We are above that nonsense, right? We do something like this.
“A meeting is a refuge from the dreariness of labor and the loneliness of thought.” – Bernard Baruch
void Manager::pitchInWhereNeeded(const Work& w){}
Unless you’re a C++ programmer, you probably won’t understand the title of this post. It’s the definition of the “pitchInWhereNeeded” member function of a “Manager” class. If you look around your immediate vicinity with open eyes, that member function is most likely missing from your Manager class definition. If you’re a programmer, oops, I mean a software engineer, it’s probably also missing from your derived “SoftwareLead“, “SoftwareProjectManager“, and “SoftwareArchitect” classes too.
As the UML-annotated figure below shows, in the early twentieth century the “pitchInWhereNeeded” function was present and publicly accessible by other org objects. On revision number 1 of the “system”, as signaled by the change from “+” to “-“, its access type was changed to private. This seemingly minor change broke all existing “system” code and required all former users of the class to redesign and retest their code. D’oh!
On the second revision of the Manager class, this critical, system-trust-building member function mysteriously disappeared completely. WTF?. This rev 2 version of the code didn’t break the system, but the system’s responsiveness decreased since private self -calls by manager objects to the “pitchInWhereNeeded” function were deleted and more work was pushed back into the “other” system objects. Bummer.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 