Archive
Steered, Or Unsteered
Schein On You Crazy Diamond
Edgar Schein is a well known MIT expert on the topic of organizational culture. In “A Corporate Climate of Mutual Help“, Mr. Schein describes his method for taking on the huge challenge of changing institutional culture. Wisely, he harbors a:
deep respect for the power and legitimacy of ingrained assumptions and attitudes that people develop together gradually.
While talking about the approach that CGHs, BUTTs, and SCOLs typically pursue when trying to improve their CLORG‘s culture, he sez:
they think that to change culture, you simply introduce a new culture and tell people to follow it. All you’ve done is stated the obvious, like “We’re for motherhood.”
Mr. Schein goes further in peeling the onion:
It’s the very nature of authority to say, “Don’t be a squeaky wheel. You made your point, but we’re going to go ahead anyway. I don’t want to hear any more.”
In lieu of the easy “dictate-and-skidaddle-away” strategy, Mr. Schein’s painstakingly thoughtful and time consuming approach to cultural change (which makes it unacceptable to most institutional SCOLs) is:
…one of observation, inquiry, and leverage.This means observing the ways in which an organization’s employees act; deducing (or inquiring about) the ways they think; and putting in place small behavioral changes that lead them, bit by bit, to think about things differently.
Notice that to execute Mr. Schein’s strategy requires sustained commitment, hard work, and empathy. You know, those traits that SCOLs demand from their subordinates but not themselves.
So, why is designing and implementing a healthy culture becoming more and more important in this era of social networking and instantaneous connectivity? It’s because:
…work in many companies is getting more complex, and subordinates have more relative power by virtue of their specialized expertise. If they choose to not tell the boss about problems, the company will never know that there’s an issue until it’s too late. The people with the most authority and established knowledge must make the others feel psychologically safe; everyone will speak up freely when something is wrong.
Of course, if institutional leaders auto-assume that their culture matches the esprit de corps they espouse it to be, then they don’t have a clue that it needs maintaining or (heaven forbid) improving. They then deserve what they get – a deterioration in the quality of work life for all (which includes themselves), which leads to increased apathy at the workface, which leads to decreased commitments to efficiency and innovation, which leads to a degradation in the borg’s products and services, which leads to an incremental (and undetectable) decline in long term financial viability….. until it’s too late and a hairball crisis appears seemingly out of nowhere.
Doc Maturity?
In his classic and highly referenced but much vilified paper, “Managing The Development Of Large Software Systems“, Winston Royce says:
Occasionally I am called upon to review the progress of other software design efforts. My first step is to investigate the state of the documentation. If the documentation is in serious default my first recommendation is simple. Replace project management. (D’oh!)
Before going further, let me establish the “context” of the commentary that follows so that I can make a feeble attempt to divert attacks from any extremist agilistas who may be reading this post. Like Mr. Royce, I will be talking about computationally-intensive software intended for use in these and other closely related types of application domains:
spacecraft mission planning, commanding, and post-flight analysis
Ok, are we set to move on with his shared contextual understanding? Well then, let’s go!
The figure below shows what should happen on a well run, large, defense/aerospace industry system development project. As the recorded info artifact set matures (see the post-post note below), productivity increases and the need for face-to-face communication decreases (but never goes to zero ala the “over-the-wall” syndrome).
Using this graph as a reference point, here’s what often happens, no?
On big, complex projects, mature but incomplete/inconsistent/ambiguous documentation tends to cause an unmanageable increase in face-to-face communication frequency (and decrease in face-to-face communication quality) as schedule-pressured people frantically try to figure out what needs to be built and what elements they’re personally responsible for creating, building, and integrating into the beast. Since more and more time is spent communicating inefficiently, less time is available for productive work. In the worst case, productivity plummets to zero and all subsequent investment dollars go down the rat hole…. until the project “leaders” figure out how to terminate the mess without losing face.
Note: Since “maturity” normally implies “high quality”, and that’s not what I’m trying to convey on the x axis, I tried to concoct a more meaningful x axis label. “Documentation Quantity” came to mind, but that doesn’t fit the bill either because it would imply that quantity == quality in the first reference graph. Got any suggestions for improvement?
Concrete Crown
This is a rare sighting, so ya gotta check it out: The Humility Imperative: CEOs, Keep Your Arrogance in Check. Reformed CEOcaholic Dave Balter starts out his plea with:
This is a message to every entrepreneur, CEO, and leader: Dig a hole, throw your ego into it, and pour concrete on top. Find humility instead. – Dave Balter
The MFC
In The Management Myth, Matthew Stewart rags about how, despite the proven inapplicability of FOSTMA techniques in the 21st century, “modern” management theory continuously repackages the same old wine (vinegar?) in a new bottle via the Management Fad Cycle (MFC). MBA snake oil salesmen simply use new words to cloak the same worn and tired underlying themes in order to make a buck.
The thing that makes modern management theory so painful to read isn’t usually the dearth of reliable empirical data. It’s that maddening papal infallibility. – Matthew Stewart
Adders, Subtractors, Creators
In a perfect world, every person involved in an org is either a value creator or a value adder. Although there are a handful of hard to find examples of the (almost) perfect org, the landscape is littered with these types of mediocre and poor performing orgs:
Effective And Ineffective
In the 50 year old book, “The Human Side Of Enterprise“, Douglas McGregor lists the attributes of effective groups as follows:
- The atmosphere is informal, comfortable, relaxed.
- There is lots of pertinent discussion and it stays on track.
- The group’s task is well understood and accepted.
- Members listen to each other and have no fear of looking foolish.
- There is disagreement and no conflict avoidance.
- Decisions are made mostly by consensus.
- Criticism is frank, frequent, relatively comfortable.
- Members freely express feelings on problems and group operation.
- Clear assignments are made and accepted.
- The group lead doesn’t dominate and there is no struggle for power.
- The group is self-conscious and periodically reflects on performance.
So, do you think this list is outdated and inapplicable in this day and age? How many effective groups have you had the privilege of participating in?
For grins, let’s look at an inverted version of the list:
- The atmosphere is formal, uncomfortable, tense.
- There is lots of impertinent discussion and it wanders all over the map.
- The group’s task is vague, undefined and thus, unaccepted.
- Members ignore each other and put on a mask of infallibility.
- There is no disagreement and conflicts are avoided.
- Decisions are made by authority
- Criticism is personal and uncomfortable.
- Members cover up and suppress feelings.
- No assignments are made and tasks fall though the cracks – accepted by no one or the ubiquitous “we”.
- The group head dominates and there is much politicking to curry favor.
- The group is unconscious.
Which of these lists feels more familiar to you?
Downward Dependence
Almost everybody knows about, and behaves in accordance with, the concept of “Upward Dependence“. You know, the hapless dependence of the many toiling in the lower levels of a hierarchically structured org upon the few in the higher levels for financial, psychological and, in extreme cases (e.g. despot-commandeered governments), physical health. However, in CLORGs and DYSCOs, the reality of “Downward Dependence” is willfully ignored in the minds of the DICforce and the SCOLs who rule over them.
The term “Downward Dependence” captures the fact that the health of the whole org, which obviously includes its upper echelons, depends heavily on the quality and efficiency of the work performed in the lower tiers. As a minimum, a recognition of the reality of “Downward Dependence” requires:
- humility on the part of SCOLs
- assertiveness on the part of DICsters
In viable and cutting edge orgs, these behaviors are on display daily, but not in CLORGs or DYSCOs. In these types of monstrosities, the 18th century reward and punishment system they utilize requires the org’s SCOLs to don masks of infallibility and its DICs to be unassertive – regardless of whether the participants know it or not. Bummer for the “whole“, no?
Keep Outta The Kitchen!
… there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things. For the reformer makes enemies of all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order… – Niccolo Machiavelli
In all companies, both leading and lagging, it’s only natural that people at all levels in the hierarchy will complain about various aspects of day-to-day operations that they feel are holding them and the company back. At leading companies, gripes are actively solicited, listened to, and thoughtfully evaluated. Those deemed to be valid are acted upon to improve performance and morale. At laggard borgs, all gripes that cry out for a deviation from the status quo are either pooh-poohed away as non-issues (especially if they bubble up from the bottom) or they’re outright ignored.
In the sad extreme, leaders toiling in laggard borgs who know that valid gripes are slooowly killing the enterprise, feel powerless to act. It’s sad because, even though they have the stature and power to influence change, they don’t feel it’s worth the effort to champion and diligently follow through on a much needed change initiative. By keepin’ outta the kitchen cuz they can’t stand the heat, they religiously follow Harry Truman‘s sage advice.
These Guys “Get It”
In the freely downloadable National Academies book, “Critical Code: Software Producibility for Defense“, the dudes who wrote the book “get it“. Check out this rather long snippet and place close attention on the bolded sentences. If you dare, pay closer attention to the snarky Bulldozer00 commentary highlighted in RED .
An additional challenge to the DoD is that the split between technical and management roles will result (has already resulted) in leaders who, on moving into management, face the prospect of losing technical excellence and currency over time. This means that their qualifications to lead in architectural decision making (and schedule making) may diminish unless they can couple project management with ongoing architectural leadership and technical engagement. The DoD does not (and legions of private enterprises don’t) have strong technical career paths that build on and advance software expertise with the exception of the service labs. Upward career progression trends leading closer to senior management-focused roles and further away from technical involvement tend to stress general management rather than technical management experience (well, duh! That’s the way status-centric command and control hierarchies are designed.). This is not necessarily the case in technology-intensive roles in industry (not necessarily, but still pervasively). Many (but nearly not enough) of the most senior leaders in the technology industry have technical backgrounds and continue to exercise technical roles and be engaged in technology strategy. Nonetheless, certain DoD software needs remain sufficiently complex and unique and are not covered by the commercial world, and therefore call for internal DoD software expertise. In the DoD, however, as software personnel take on more management responsibility, they have less opportunity and incentive to stay technically current (<- this “feature” is baked into command and control hierarchies where, of course, caste and who-reports-to-who is king – to hell with excellence and what sustains an enterprise’s health and profitability). At the same time, there is an increasing need for an acquisition workforce that has a strong understanding of the challenges in systems engineering and software-intensive systems development. It is particularly critical to have program managers who understand modern software development and systems (If that’s the case, then the DoD and most private enterprises are hosed. D’oh!).
Could it be that unelected, anointed “managers” in DoD and technology industry CLORGs and DYSCOs are still stuck in the 20th century FOSTMA mindset? You know, the UCB where they “feel” they are entitled to higher compensation and stature than the lower cast knowledge workers (architects, designers, programmers, testers, etc) just because they occupy a higher slot in an anachronistic, and no longer applicable, way of life – no matter what the cost to the whole org’s viability.
In command and control hierarchies, almost everybody is a wanna-be:
“I wanna rise up to the next level so I’ll: make more money, have more freedom, be perceived as more important, and rule over the hapless dudes in my former level“. Nah, that’s not true. BD00 has been drinkin’ too many dirty, really really dirty, martinis.










