Archive
Get The Hell Out Of There!
When a highly esteemed project manager starts a project kickoff meeting with something like: “Our objective is to develop the cheapest product and get it out to the customer as quickly as possible to minimize the financial risk to the company“, and nobody in attendance (including you) bats an eyelash or points out the fact that the proposed approach conflicts with the company’s core values, my advice to you is to do as the title of this post says: “get the hell out of there (you spineless moe-foe)!”. Conjure up your communication skills and back out of the project – in a politically correct way, of course. If you get handcuffed into the job via externally imposed coercion or guilt inducing torture techniques (a.k.a corpo waterboarding), then, then, then……. good luck sucka! I’ll see you in hell.
The bitterness of poor system performance remains long after the sweetness of low prices and prompt delivery are forgotten. – Jerry Lim
Development And Production
I think that most people would agree that the development of a product and the production of a product are two different, but complementary processes. In a production environment, you want to minimize variation. Hence, checklists, step-by-step work instructions, templates, and quantitative statistical control techniques (e.g. six sigma) are the tools of choice for successfully ferreting out and correcting evil sources of variation. In a development environment, you want to be flexible and explore variations so that your products will stand out from your competitor’s. Thus, trying to jam fit successful production environment tools and methods into a development environment is always counterproductive. Yet, in their irrational and continuous quest for certainty, managements everywhere do just that. Handcuffs for everyone – no exceptions allowed.
Conflict Aversion And Cultures Of Fear
With no scientific backing or personal credentials to provide me with any semblance of credibility, I assert that conflict aversion and cultures of fear go together like hand and glove; Jenny and Forrest; peas and carrots; peanut butter and chocolate.
In an org that operates in accordance with a culture of fear, inter-personal and inter-group conflicts are avoided at all costs because of the fear of post-conflict consequences. If a culture of fear doesn’t already exist, all it takes is one or two publicly visible rebukes of a conflict initiator to snap a “culture of fear” into place. Common forms of rebuke are: peek-a-boo visits, compensation ceilings, withholding of career development opportunities, placement on a formal performance improvement plan (affectionately called a “PIP”), and covert persecution. The closer to home that a conflict initiator treads to a hairball problem that is eroding performance of the whole, the more severe the rebuke.
In a culture of fear, because there’s no sane incentive for motivating well-meaning people to point out emergent org problems that everybody already knows about, nobody does nuthin’ of substance until there’s a crisis. When a crisis inevitably manifests because of problem neglect, conflict aversion temporarily goes out the window because real feelings and passions bubble to the surface. Under the duress of a crisis, the conflicts that do emerge in a normally conflict averse org are much more explosive and damaging than those that occur in a continuously conflict-accepting org. Thus, when the crisis passes, the left over socio-communication system infrastructure wreckage breeds poorer future performance and a regression back into – you guessed it – the same old, same old, conflict averse way of operation. Bummer.
Machine Age Thinking, Systems Age Thinking
In Ackoff’s Best, Mr. Russell Ackoff states the following
…Machine-Age thinking: (1) decomposition of that which is to be explained, (2) explanation of the behavior or properties of the parts taken separately, and (3) aggregating these explanations into an explanation of the whole. This third step, of course, is synthesis.
The figure below models the classical machine age, mechanistic thinking process described by Ackoff. The problem with this antiquated method of yesteryear is that it doesn’t work very well for systems of any appreciable complexity – especially large socio-technical systems (every one of which is mind-boggingly complex). During the decomposition phase, the interactions between the parts that animate the “thing to be explained” are lost in the freakin’ ether. Even more importantly, the external environment in which the “thing to be explained” lives and interacts is nowhere to be found. This is a huge mistake because the containing environment always has a profound effect on the behavior of the system as a whole.
Mr. Ackoff professes that the antidote to mechanistic thinking is……. system thinking (duh!):
In the systems approach there are also three steps:
1. Identify a containing whole (system) of which the thing to be explained is a part.
2. Explain the behavior or properties of the containing whole.
3. Then explain the behavior or properties of the thing to be explained in terms of its role(s) or function(s) within its containing whole.
Note that in this sequence, synthesis precedes analysis.
The figure below graphically depicts the systems thinking process. Note that the relationships between the “thing to be explained” and its containing whole are first class citizens in this mode of thinking.
One of the primary reasons why we seek to understand systems is so that we can diagnose and solve problems that arise within established systems; or to design new systems to solve problems that need to be controlled or ameliorated. By applying the wrong thinking style to a system problem, the cure often ends up being worse than the disease. D’oh!
Growth And Development
Two of my favorite bureaucracy-busting systems thinkers, Russell Ackoff and John Warfield, died this year. I’ll miss them both because whenever I’ve read something written by these guys, I always learned something new.
In a tribute to Mr. Ackoff, I’m currently reading Ackoff’s Best: His Classic Writings On Management. One of his off-the-beaten-path insights that he’s passed on to me is the independence between growth and development. Growth is an increase in size or wealth, while development is an increase in capability or competence as a result of learning. According to Ackoff, dumb-ass corpocracies automatically and unquestioningly equate growth with development, and that’s why the vast majority of orgs are obsessed with growth at all costs. Of course, growth and development can, and often do, reinforce each other, but neither is necessary for the other.
Ackoff points out that a system can experience growth without development, and vice versa. A heap of rubbish, or equivalently, a bureaucracy, can grow indefinitely without developing, and artists can develop without growing. If an undeveloped company or company is showered with money, it becomes richer but not more developed. On the other hand, if a well developed company or country is suddenly deprived of wealth, it doesn’t become less developed.
What is your org doing? Growing? Developing? Both? Neither?
Culture Adjustment
I think that almost everyone heard about this week’s glitch in the air traffic control system that caused hours of flight delays. Here’s an interesting quote from the government’s GAO (FAA computer failure reflects growing burden on systems — Federal Computer Week):
“However, FAA faces several challenges in fulfilling NextGen’s objectives, including adjusting its culture and business practices, GAO concluded.”
Well, duh. Every mediocre and under performing corpo borg needs to “adjust its culture and business practices”. It’s just that none of them have the competence to do it, regardless of how many titles and credentials that the corpocrats running the show adorn themselves and their sycophants with.
Partial Training
If you’re gonna spend money on training your people, do it right or don’t do it at all.
Assume that a new project is about to start up and the corpo hierarchs decide to use it as a springboard to institutionalizing SysML into its dysfunctional system engineering process. The system engineering team is then sent to a 3 day SysML training course where they get sprayed by a fire hose of detailed SysML concepts, terminology, syntax, and semantics.
Armed with their new training, the system engineering team comes back, generates a bunch of crappy, incomplete, ambiguous, and unhelpful SysML artifacts, and then dumps them on the software, hardware, and test teams. The receiving teams, under the schedule gun and not having been trained to read SysML, ignore the artifacts (while pretending otherwise) and build an unmaintainable monstrosity that just barely works – at twice the cost they would would have spent if no SysML was used. The hierarchs, after comparing product development costs before and after SysML training, declare SysML as a failure and business returns to the same old, same old. Bummer.
Poor Test Dudes
Out of all the types of DICs in a textbook CCH, the poor test dudes always have the roughest go of it. Out of necessity, they have mastered the art of nose pinching.
A Flurry Of Activity
It’s always fun to watch the initial stages of euphoria emerge and then disappear when a corpo-wide initiative that’s intended to improve performance is attempted. The anointed “design” team, which is almost always filled exclusively with managers and overhead personnel who conveniently won’t have to implement the behavioral changes that they poop out of the initiative themselves, starts out full of energy and bright ideas on how to solve the performance problem. After the kickoff, a resource-burning flurry of activity ensues, with meeting after meeting, discussion after discussion, and action item after action item being tossed left and right. When the money’s gone, the time’s gone, and the smoke clears, business returns to the same old, same old.
As a hypothetical example, assume that an initiative to institute a metrics program throughout the org has been mandated from the heavens. At best, after spending a ton of money and time working on the issue, the anointed design team generates a long list of complicated metrics that “someone else” is required to collect, analyze, and act upon. The team then declares victory and self-congratulatory pats on the back abound. At worst, the team debates the issue for a few meetings, conveniently forgets it, and then moves on to some other initiative – hoping that no one notices the useless camouflage that they left in their wake. Bummer.
Process Nazis
Unlike most enterprise software development orgs where “quality assurance” is equated to testing, government contractors usually have both a quality assurance group and a test engineering group. Why is that? It’s because big and bloated government customers “expect” all of its contractors to have one. It’s the way it is, and it’s the way it’s always been.
It doesn’t matter if members of the QA group never specified, designed, or wrote a line of software in their life, these checklist process nazis walk around wielding the process compliance axe like they are the kings of the land: “Did you fill out this unit test form?” “Do you have a project plan written according to our template?“, “Did you write a software development plan for us to approve?“, “Did you submit this review form?“, “Did you submit this software version definition form?“, “Do you have a test readiness form?“, “If you don’t do this, we’ll tell on you and you’ll get punished“. Yada, yada, yada. It’s one interruption, roadblock, and distraction after another. On one side, you’ve got these obstacle inserters, and on the other side you’ve got nervous, time-obsessed managers looking over your shoulder. WTF?
Since following a mechanistic process supposedly “proven to deliver results” doesn’t guarantee anything but a consumption of time, I don’t care much about formal processes. I care about getting the right information to the right people at the right time. By “right“, I mean accurate, unambiguous, complete, and most importantly – frreakin’ useful. For system engineers, the right information is requirements, for software architects it’s blueprints, for programmers it’s designs and source code, for testers it’s developer tested software. How about you, what do you care about?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 