Archive
What’s REALLY Required
An understanding and application of “Systems Thinking” are pre-requisites to effective leadership in any large socio-technical group endeavor. Since business schools and pundits teach so-called business skills in disconnected, specialized, fragmented chunks and the primary component of systems thinking is the opposite of this classically entrenched Descartesian way of thinking, effective large scale leadership is nowhere to be found except in rare, small pockets of brilliance.
Systems thinking employs analytical thinking as a subordinate to its opposite – synthetic thinking. Since most (the vast majority of?) elite execs intentionally fragment their time to match their thinking style and they don’t know how to synthesize anything but an inflated and infallible image of themselves, they’re eternally stuck in the quagmire of one dimensional analytical thinking without a clue. But hey, ya gotta give them credit for knowing how to stuff their pockets with greenbacks.
A $1.6M Mistake – And No One Was Fired
The other day, I discovered that a human mistake made on Zappos.com’s sister web site, 6pm.com, emptied the company’s coffers of $1.6 million dollars. Being the class act that he is, here’s what CEO Tony Hsieh had to say regarding the FUBAR:
To those of you asking if anybody was fired, the answer is no, nobody was fired – this was a learning experience for all of us. Even though our terms and conditions state that we do not need to fulfill orders that are placed due to pricing mistakes, and even though this mistake cost us over $1.6 million, we felt that the right thing to do for our customers was to eat the loss and fulfill all the orders that had been placed before we discovered the problem. – Tony Hsieh, CEO, Zappos.com
If this happened at your company, what would your management do? Do ya think they’d look at it as a learning experience?
Besides Zappos.com, here are the other companies that I love. What are yours, and is the company you work for one of them?
DICbox Be Gone!
Check out the “DIC in the box” below. The DICbox is drawn around the DICster because that’s the way BMs dehumanize the person behind the DIC label. They do this, of course, in order to make their so-called job easier and to preclude getting their hands dirty with unimportant people. In a BM’s mechanistic mind, all DICs are the same and they’re interchangeable.
In a corpricracy, DICs are given work to do and, if they’re competent and self-motivated, they create high quality work products that increase the wealth of the corpricracy – in spite of the management chicanery that takes place.
The figure below shows an expanded DICbox model with a BM integrated into the system. Since the dude is part Bozo, he doesn’t:
- have a clue (or care) what the work is,
- know (or care) what it takes to do the work,
- know (or care) what the work products are, or how to evaluate them.
That’s why there are no connections in the picture traversing from the work products or work definition flows to the BM. Of course, the BM feigns it as best he can and knows some generic technical buzzwords like “requirements”, “analysis”, “design”, etc. To a BM, all technical projects, from web site development to space shuttle development, are the same – a linear, sequential, unchangeable schedule of requirements, design, coding, testing, and delivery.
Since the BM is in over his head, he must justify his highly compensated existence. He does this via the only option available: behavior watching. Thus, all he essentially does is intently watch for non-conformance of DIC behavior to a set of unwritten and arbitrarily made up corpo rules. He really shines when he detects a transgression and issues the boiler plate “get with the program” speech (a.k.a peek a boo visit) to coerce the DIC back into the box. If that fails, he calls in the big guns – his fellow overhead management dudes in the HR silo. But that’s another story.
OK, OK. So you want to arse me on my own turf and say: “It’s easy to whine and complain about bad management. I’m as good as you are at it.” You follow that up with “How should it be, smarty pants?“. Well here’s one model:
I don’t think the above model needs to be accompanied with much explanation. However, I do think these caveats should be pointed out:
- The DICbox is gone.
- The “BM” label has been replaced by “Leader”.
- The work is co-defined by the leader and the doer.
- The leader knows what the work products should be (work products = “expected outcomes” in management lingo).
- The leader still watches behavior, not as an end in itself, but as a means to help the doer grow, develop, and succeed.
- The leader does what some people (like me) may consider – real work.
Processes, Threads, Cores, Processors, Nodes
Ahhhhh, the old days. Remember when the venerable CPU was just that, a CPU? No cores, no threads, no multi-CPU servers. The figure below shows a simple model of a modern day symmetric multi-processor, multi-core, multi-thread server. I concocted this model to help myself understand the technology better and thought I would share it.
The figure below shows a generic model of a multi-process, multi-threaded, distributed, real-time software application system. Note that even though they’re not shown in the diagram, thread-to-thread and process-to-process interfaces abound. There is no total independence since the collection of running entities comprise an interconnected “system” designed for a purpose.
Interesting challenges in big, distributed system design are:
- Determining the number of hardware nodes (NN) required to handle anticipated peak input loads without dropping data because of a lack of processing power.
- The allocation of NAPP application processes to NN nodes (when NAPP > NN).
- The dynamic scheduling and dispatching of software processes and threads to hardware processors, cores, and threads within a node.
The first two bullets above are under the full control of system designers, but not the third one. The integrated hardware/software figure below highlights the third bullet above. The vertical arrows don’t do justice to the software process-thread to hardware processor-core-thread scheduling challenge. Human control over these allocation activities is limited and subservient to the will of the particular operating system selected to run the application. In most cases, setting process and thread priorities is the closest the designer can come to controlling system run-time behavior and performance.
D4P And D4F
As some of you may know, my friend Bill Livingston recently finished writing his latest book, “Design For Prevention” (D4P). While doodling and wasting time (if you hadn’t noticed, I like to waste time), I concocted an idea for supplementing the D4P with something called “Design For Function” (D4F). The figure below shows, via a state machine diagram, the proposed marriage of the two complementary processes.
After some kind of initial problem definition is formulated by the owner(s) of the problem, the requirements for a “future” socio-technical system whose purpose is to dissolve the problem are recorded and “somehow” awarded to an experienced problem solver in the domain of interest. Once this occurs, the project is kicked off (Whoo Hoo!) and the wheels start churning via entry into the D4F state. In this state, various structures of connected functions are conceived and investigated for fitness of purpose. This iterative process, which includes short-cycle-run-break-fix learning loops via both computer-based and mental simulations, separates the wheat from the chaff and yields an initial “best” design according to some predefined criteria. Of course, adding to the iterative effort is the fact that the requirements will start changing before the ink dries on the initial snapshot.
Once the initial design candidate is selected for further development, the sibling D4P state is entered for the first (but definitely not last) time. In this important but often neglected problem solving system sub-state, the problem solution system candidate is analyzed for failure modes and their attendant consequences. Additional monitoring and control functional structures are then conceived and integrated into the system design to prevent failures and mitigate those failures that can’t be prevented. The goal at this point is to make the system fault tolerant and robust to large, but low probability, external and internal disturbances. Again, iterative simulations are performed as reconnaissance trips into the future to evaluate system effectiveness and robustness before it gets deployed into its environment.
The figure below shows a dorky model of a system design before and after the D4P process has been executed. Notice the necessary added structural and behavioral complexity incorporated into the system as a result of recursively applying the D4P. Also note that the “Behavior Monitoring” structure(s), be they composed of people in a social system or computers in an automated system, or most likely both, need to have an understanding of the primary system goal seeking functions in order to effectively issue damage prevention and mitigation instructions to the various system elements. Also note that these instructions need not only be logically correct, they need to be timely for them to be effective. If the time lag between real-time problem sensing and control actuating is too great (which happens repeatedly and frequently in huge multi-layered command and control hierarchies that don’t have or want an understanding of what goes on down in the dirty boiler room), then the internal/external damage caused by the system can be as devastating as a cheaper, less complex system operating with no damage prevention capability at all.
So what do you think? Is this D4F + D4P process viable? A bunch of useless baloney?
Ackoff On Systems Thinking
Russell Ackoff, bless his soul, was a rare, top echelon systems thinker who successfully avoided being assimilated by the borg. Checkout the master’s intro to systems thinking in the short series of videos below.
What do you think?
Seeking Trouble
I’ve had the Kindle version of it for awhile, but I’ve finally got around to reading “Gurdjieff” by John Shirley. I’m glad I did because early in the book, this passage stirred up some internal energy:
According to the Gospel of Thomas, Jesus said, ‘ Let him who seeks continue seeking, until he finds. When he finds, he will become troubled. When he becomes troubled, he will be astonished, and he will rule over all.'”
It caused an energy surge because I’ve seeked and found trouble, deep trouble, multiple times. I’ve found that virtually everyone, both individually and collectively, behaves unconsciously according to the selfish “I” thought. Of course, this mass of humanity includes me, especially.
So, I’ve seeked, found trouble, and became astonished. However, I’ve yet to “rule over all”, which I think wasn’t meant to be taken literally. Hell, I’d settle for just ruling over my false self. How about you, have you found trouble?
It’s Gotta Be Free!
I love ironies because they make me laugh.
I find it ironic that some software companies will staunchly avoid paying a cent for software components that can drastically lower maintenance costs, but be willing to charge their customers as much as they can get for the application software they produce.
When it comes to development tools and (especially) infrastructure components that directly bind with their application code, everything’s gotta be free! If it’s not, they’ll do one of two things:
- They’ll “roll their own” component/layer even though they have no expertise in the component domain that cries out for the work of specialized experts. In the old days it was device drivers and operating systems. Today, it’s entire layers like distributed messaging systems and database managers.
- They’ll download and jam-fit a crappy, unpolished, sporadically active, open source equivalent into their product – even if a high quality, battle-tested commercial component is available.
Like most things in life, cost is relative, right? If a component costs $100K, the misers will cry out “holy crap, we can’t waste that money“. However, when you look at it as costing less than one programmer year, the situation looks different, no?
How about you? Does this happen, or has it happened in your company?
Ya Gotta Use This!
It’s interesting when people come off a previous project and are assigned to a new, in-progress, software development project. Often, they demand that their new project team adopt a process/procedure/technique/design/architecture (PPTDA) that they themself used on their previous project.
This can be either good or bad. It can be good if (and it’s a big IF) the alternative PPTDA they are promoting is actually better than the analogous PPTDA currently being employed by the new project team and the cost to integrate the proposed PPTDA into the project environment is less than the additional benefit it brings to the table. It can be really good if the PPTDA has been proven to “work” well and the new project hasn’t progressed past the point where an analogous PPTDA has been decided upon and weaved into the fabric of the project.
On the other hand, a newly proposed PPTDA can be bad in these cases:
- The new project team already has an equivalent PPTDA in place and there’s no “objective” proof that the championed PPTDA really does work better.
- The new project team already has an equivalent PPTDA in place and there’s “objective” proof that the championed PPTDA really does work better, but the cost of social disruption to integrate the PPTDA into the project isn’t worth the benefit.
- The new project team doesn’t have an equivalent PPTDA in place yet and the championed PPTDA has “somehow” been proven to be better than other alternatives, but adopting it would require changes to other well-working PPTDAs that the team is using.
Because there’s a bit of subjectivity in the above list and “rank can be pulled” by a so-called superior in order to jam an unworthy PPTDA into a smoothly running project and muck up the works, be wary of kings bearing gifts.
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 