Archive
Three Ways
Oh crap! If you think my Rush Limbaugh-like, anti-hierarchical rants are over the top now, they may get “worse” moving forward. I just discovered a small, academic publisher in the U.K. that solely publishes books on alternatives to hierarchical org structures: Triarchy Press. Since books like these are either burned, shunned, or ignored by those they are intended to help, I hope they don’t go out of business.
Have you even ever heard of the “heterarchy” or “autonomous responsibility” alternatives to the hierarchy beast? If not, it shows how firmly entrenched the hierarchical mindset is in most people’s psyches, no?
In one of Triarchy Press’s flagship books, “The Three Ways Of Getting Things Done“, author Gerard Fairtlough postulates that some magic combo of the three legs of triarchy is the most economically efficient and socially redeeming way of achieving org goals.
Hierarchy is so entrenched that a complete replacement, if it does prove desirable, will take centuries. – Gerard Fairtlough
Hierarchy will never go away. Never! – Tom Peters
Culture Shift
In the video “Hacking Your Organization“, Lloyd Taylor states that low org productivity is often caused by a mismatch between explicit and implicit culture. When the espoused culture doesn’t align with the actual day-to-day operating culture of an org, people (because they’re not dumb asses) get disillusioned and turned off by the hypocrisy. Hence, it’s only natural that many people will “hang up the phone” and “disconnect & distance” themselves from their work and do what little they can to get by. Of course, the BM hypocrites responsible for keeping the implicit and explicit cultures unsynchronized judge these DICs as lazy under-performers. That’s because there’s no way that they, themselves, can be the catalyst of a disillusioned workforce. In their minds, they’re infallible and whatever they say about the culture is auto-magically true.
Mr. Taylor’s model, and he stresses that it’s just a model, partitions corpo cultures into four archetypes: communal, mercenary, networked, and fragmented. The criteria he uses to diagnose a culture are sociability and solidarity:
In Lloyd’s view, virtually all startups begin with vibrant communal cultures. As a company grows, because of the physical limitations of the human brain, a cultural shift has to occur at some point:
If, during growth, the company’s leaders don’t steer the org toward the culture that they want, or they hard-headedly maintain that their culture is still communal when a shift has occurred, then the implicit-explicit cultural mismatch that triggers low productivity will manifest. Bummer for all involved.
Mr. Taylor stresses that no culture is fully good or bad and that success can be sustained in all four culture types as long as the espoused culture is aligned with the actual culture – especially during cultural shifts. This is possible because each individual will know where they stand and what they need to do to become successful themselves. They can also decide whether they are comfortable operating in the org culture, and when to move on.
The hour long video is highly informative and Mr. Taylor uses all kinds of examples to bolster his theoretical views: Enron, Anderson Consulting, Lehman Brothers, Apple, Zappos.com, Hewlitt Packard, Oracle, etc. Hop on over to InfoQ and check it out if you’re interested in the fascinating topic of group culture.
The BCMT
Print out, copy, distribute, collect, and evaluate. If the results aren’t to your liking, ignore and bury them. Otherwise, toot your horn loudly and frequently.
Culture Convergence?
Many, many articles and books targeted at executives and senior managers spew out all kinds of elixirs, formulas, and lists guaranteed to catapult a business to the top of the heap. For example, take this squeaky clean and slightly redacted list from a book that will remain unnamed.
The one common, across the board demand that all these gurus impose on top leadership teams is that “you must change the culture“. The hidden assumption in these words is that one culture exists. Well, does it?…….
Maybe all these revered business gurus should talk about culture convergence instead of changing “the one culture“…..
How naive of me to think that there are two or more cultures in an org, no?
My Erlang Learning Status
Check out this slide from Erlang language co-designer Joe Armstrong’s InfoQ lecture: “Erlang – software for a concurrent world“. I’ve circled the features that have drawn me to Erlang because I’m currently developing product software where those qualities are hugely important to my customers. Despite their importance to success, they’re almost always given second class status by programmers and managers because they’re not domain-specific, “glamorous“, features.
The blue arrow is my sore spot. You see, I’ve been programming imperatively in FORTAN, then C, and then C++, since Jesus was born. Thus, learning the stateless, recursive, functional programming mindset that Erlang is founded upon is a huge hurdle for me to overcome. Nevertheless, as I’ve stated before, I’m half-assedly trying to learn OMOT how to program in Erlang with the aid of this very good book:
Here’s my learning “status” in terms of the book’s table of contents:
I don’t have an ironclad, micro-scheduled plan or BS risk register pinned on the wall in my war room, so I have no idea when I’ll be 100% done. But who knows, if I don’t abandon the effort:
Note: OMOT = On My Own Time
Look Ma, No Makeup!
From Livescribe dot-paper directly to blarticle, warts and all:
A Steady Drumbeat
In the context of getting a message to sink in, a wise and dear friend once told me: “it’s not a cymbal crash, it’s a steady drumbeat“. The reason this quote came to mind is because my blog dashboard says that I’ve published 607 posts to date and I was wondering how many of them were redundant – repeating the same message over and over again.
I have no freakin’ idea how many published posts seem redundant to you, but if they do, I’ll use that musical quote as the excuse for my narrow minded focus and lack of breadth. Plus, repetition is a powerful tool for brainwashing others into doing what you want them to do. Moooo Hah Hah!
The Wevo Approach
The figure below shows an example of a one-size-fits-all, waterfall schedule template that’s prevalent at many old school software companies. It sure looks nice, squeaky clean, and controllable, but as everyone knows, it’s always wrong. Out of fear or apathy, almost no one speaks out against this “best practice“, but those who do are quickly slapped down by the anointed controllers and meta-controllers of the project.
A more insidious, micro-grained, version of this waterboarding fiasco is shown below. It’s a self-medicating attempt to amplify the illusion of control that’s envisioned to take place throughout the execution of the project. Since schedules are concocted before an architecture or design has been reasonably sketched out and no one can possibly know up front what all the micro tasks are, let alone how long they’ll take (unless the project is to dig ditches), it’s monstrously wrong too. But shush, don’t say a word.
Once a monstrosity like this is baked into a huge Microsoft Project file or company proprietary scheduling document, those who conjured up the camouflage auto-become loathe to modify it, even as the situation dynamically changes during the death march. Once the project starts churning, new unforeseen “popup” tasks emerge and some pre-planned micro-tasks become obsolete. These events disconnect the schedule from reality quicker than you can say “WTF?“.
Moving on to a sunnier disposition, the template below shows a more “sane“, but not infallible, method of scheduling. It’s a model of the incremental “evo” strategy that I first stumbled upon from Tom Gilb – a bazillion years before the agile movement rose to prominence. In the evo(lutionary) approach, stable working software becomes visible early with each RDCT cycle and it grows and matures as the messy (it’s always messy) project lurches forward.
The figure below shows a tweaked version of the evo model. It’s a hybrid concoction of the waterboard and evolutionary development approaches – the “wevo“. Some upfront requirements and architecture exploration/definition/specification is performed by the elected team technical leaders before staffing up for the battle against the possibility of building a BBoM. The purpose of the upfront requirements and architecture efforts are to address major cross-cutting concerns and establish contextual boundaries – before letting the dogs loose.
Of course, the wevo approach is not enough. Another necessary but insufficient requirement is that the team leaders dive into the muck with the “coders” after the cross-cutting requirements and architecture definition activities have produced a stable, understandable blueprint. No jargon spewing software “rocketects” or “pure” software project leads allowed – everyone gets dirty – and for the duration.
Chain Of Responsibility
One of the well known design patterns in the object-oriented software world is named “Chain Of Responsibility“. The UML sequence diagram below shows an example of how the software objects in the pattern collaborate with each other in order to ensure that a user initiated help request is handled somewhere in the GUI of an application.
As you might surmise, the world of hierarchical superiority has an analogous pattern, err anti-pattern, named “Chain Of Irresponsibility“. Do ya think I need to add words to explain the inter-object collaborations for this pattern as shown in the UML sequence diagram that follows?
In case you were wondering, S = Senior, BM = Bozo Manager, and DIC = Dweeb In the Cellar.
The Language Of The Language
I found it amusing that “Gotcha” number 9 in Stephen Dewhurst’s wonderful “C++ Gotchas: Avoiding Common Problems in Coding and Design” is titled “Using Bad Language“. At first, I thought: “Come on, why require such stuffiness and rigid formality on matters so trivial?“. However, upon reflection, it does make sense that the careless abuse of the “language defining the language” can contribute to time being wasted and bugs being inserted and BBoMs being created.
Since it’s a powerful general purpose programming language, C++ is necessarily complex. Thus, it requires a creative mangling of the English language to carefully define C++’s features, syntax, semantics, and usage idioms. Understanding and memorizing this myriad of details in order to continuously move toward excellence is a time consuming process – no matter what those “Learn C++ in 24 hours” type books promise.
I consider myself a decent, intermediate level C++ programmer, but I’m constantly probing, sensing, and discovering new terms along with having to refresh my memory and understanding of “the language of the language“. How about you? Do you practice continuous learning and refreshment about your job and tool set?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 