Archive
The Accumulation Of Rules
According to that dumbass BD00, in any given level in an institutional hierarsy, the number of internal org rules a member of that level is required to follow is a function of the number of levels above. Each level makes some rules for the levels below. Relatively speaking, the dudes in the head shed have to follow zero rules and they concoct the “high level” rules for the levels below them.
As one travels down a dysfunctional hierarsy, the number of rules to be obeyed is cumulative. By the time you’re down in the bilge room, the number of written and (especially) unwritten rules to follow is essentially infinite. The irony is that while the unfettered infallibles at the top keep piling on the handcuffs, they’re also simultaneously professing their love for empowerment, taking-initiative, dedication, trust, loyalty, yada-yada-yada.
T’is what it is, just another paycheck-for-repression tradeoff. You can’t have your cake and eat it too, so suck it up soldier!
Too Detailed, Too Fast
One of the dangers system designers continually face is diving into too much detail, too fast. Given a system problem statement, the tendency is to jump right into fine-grained function (feature) definitions so that the implementation can get staffed and started pronto. Chop-chop, aren’t you done yet?
The danger in bypassing a multi-leveled analysis/synthesis effort and directly mapping the problem elements into concrete, buildable functions is that important, unseen, higher level relationships can be missed – and you may pay the price for your haste with massive downstream rework and integration problems. Of course, if the system you’re building is simple enough or you’re adding on to an existing system, then the skip level approach may work out just fine.
A Double Success Story
I really enjoy reading accounts of how companies overcome a minefield of obstacles to achieve both financial and social success. It’s much easier to achieve financial success at the top in exchange for social freedom at the bottom than it is to achieve success in both areas at the same time (hint: HR groups are the greatest impediment to dual success). For confirmation of this assertion, simply look at the coupling between profit margins and social misery at any third world sweatshop.
One such double financial + social success story is told in the Fast Company article:” How Target’s CEO Inspires Teamwork At A Massive Scale”. However, BD00, the saucy and skeptical bloke that he is, always consumes such anecdotes with a grain of salt when the narrator is a single soul from the C-level suite. In the Target story, the telltaler is the CEO himself, Mr. Gregg Steinhafel.
The good news is that Gregg wasn’t appointed from without. He rose through the ranks:
“A veteran of Target’s rank and file, Steinhafel joined the company back in 1979, worked his way up over the next two decades to become president, and eventually took the corner office in 2008.“
The bad news is that when you traverse the article and pluck out his quotes, they are the same old, same old:
“We are the coaching staff that help design the playbook, but implement it at the same time.”
“At Target, nothing happens without a large, collaborative effort.”
“Everyone is a mentor and mentee. It is one of the fun and exciting parts of [any] job.”
“It’s our responsibility to act and continue to support the teams.”
“All the senior leaders like to sit down and forward think, and anticipate where the puck is going.”
“We benchmark against the world’s best to develop ideas for future growth.”
“We are constantly checking in.”
Direct quotes and disrespectfully snarky graphic aside, the double success story at Target seems genuine and I’m thrilled that the company has leveraged social media tools to improve its performance through networked collaboration. I just wish that some lower level employees were asked to contribute to its telling – anonymously, of course.
For sure, you’ll easily find a ton of one-sided, C-suite-sourced stories like this Target tale in the mainstream press and best-selling business book section at Amazon.com. However, you won’t find any in the works of Ackoff, Argyris, Deming, Block, Culbert, Cohen, Livingston, and other dirty rotten scoundrels. The stories they tell are the stories I find fascinating and mind-changing.
Note: I’ve had a vague and notional image of the pull-cord executive doll in my contaminated mind for several months now. I finally conjured up a BS post to host it. Whoo Hoo!
Irritated
Unsurprisingly, one of BD00’s posts irritated a reader who stumbled upon it. For some strange reason, BD00’s scribblings have that effect on some people. In the irritating post, “The Old Is New Again“, BD00 referred to Data and Control Flow diagrams as “old and obsolete“. In caustic BD00 fashion, the reader commented:
Use Cases and Activity Diagrams, in contrast (to the Data Flow diagram), offer little guidance in effective partitioning. They rely upon the age old “sledge hammer” approach to partitioning” (ie, just break-er-up any way you can). Sledge hammer partitioning is what cave men used to partition entities. So in a critical sense, DFD’s are new and hip, while Use Cases and Activity Diagrams are based upon logic that is older than dirt.
BD00 likes all visual modeling tools – including the DFD hatched during the heyday of structured analysis. BD00 only meant “old and obsolete” in the sense that DFDs pre-dated the arrival of the UML and the object-oriented approach to system analysis and design. However, BD00 did feel the need to correct the reader’s misunderstanding of the features and capabilities that UML Activity Diagrams offer up to analysts/designers.
Both the DFD and UML activity diagram pair below equivalently capture an analyst’s partitioning design decision (where DFD Process X == Activity Diagram Action X). Via “swimlanes“, the lower activity diagram makes the result of a second design decision visible: the conscious allocation of the Actions to the higher level Objects that will perform them during system operation. So, how are UML activity diagrams inferior to DFDs in supporting partitioning? A rich palette of other symbols (forks, joins, decisions, merges, control flows, signals) are also available to analysts (if needed) for capturing design decisions and exposing them for scrutiny.
DFDs and UML diagrams are just tools – job performance aids. Learning how to use them, and learning how to use them effectively, are two separate challenges. Design “guidance” for system partitioning, leveling, balancing, etc, has to come from somewhere else. From a mentor? From personal experience learning how to design systems over time? From divine intervention?
Not Arbiters, Nor Catalysts
When I was young and naive (as opposed to my current state: old and misinformed), I entered the werkfarce thinking that HR departments were supposed to be compassionate arbiters of disputes and employee development catalysts – until I discovered what they actually did:
HR groups are bright shining examples of POSIWID. “The Purpose Of a System Is What It Does” – not what it says it does. Alas, BD00 doesn’t think that most HR departments are maliciously evil, they’re just so indoctrinated and immersed in Tayloresque, Theory-X thinking that “they know not what they do“. How about you? Besides thinking that BD00 knows not what he does, what do you think?
You May Be Wrong
With the frequency and ferocity of attacks BD00 foists upon the guild of institutional management in this highfalutin blog, you might think BD00 is a miserably unhappy and vengeful malcontent at work. If you do, then you’d be wrong. BD00 knows for a fact that his boss’s boss reads this blog “religiously“. BD00 also knows that his company’s CEO has stopped by to sample the waters at least once. The CEO even discretely and unjudgmentally referenced an idea from this caustic blog in a large gathering (for which he received a free BD00 T-shirt).
Do one thing every day that scares you. – Baz Luhrmann (Everybody’s Free To Wear Sunscreen)
In three-plus years of blogging, BD00 has never received a peek-a-boo visit or been directly rebuked or threatened by anyone in his company’s leadership chain for exposing his wacko, close-to-home thoughts in writing. If you wrote a similar, self-exposing blog, could you confidently say the same about your management ?
It’s The Relationships, Stupid
If you read Sam Culbert’s book rant against the taken-for-granted and unassailable “annual performance review” process, you’d think he is an anti-hierarchy revolutionary deserving to be crushed. But the dude is not:
Hierarchical structure, in the form of an organization chart, serves many constructive purposes. By showing the chain of command, it allows everyone to see who is responsible for what, how organization units are being deployed, and, most importantly, who should be accountable for bottom-line results. In contrast, I can’t think of a single constructive purpose served by hierarchical relationships— that is, those in which the boss gets to dominate all conversations.
Culbert, Samuel A. (2010-04-01). Get Rid of the Performance Review!: How Companies Can Stop Intimidating, Start Managing–and Focus on What Really Matters (Business Plus) (pp. 128-129). Hachette Book Group. Kindle Edition. – Sam Culbert
In a man-made conceptual hierarchical breakdown of a tree’s “parts“, the relationships between the parts have nothing to do whatsoever with their “position” in the hierarchy. A tree’s components miraculously work together in synchronous harmony to manifest and share its beauty as a whole with all of nature – including us (perhaps undeserving) humans. Leaves aren’t pitted against leaves for the purpose of gaining more hierarchical status in the “minds” of the other tree parts. The trunk doesn’t perceive itself as “more important and deserving” than the “lowly” branches. The roots don’t talk about the topmost branches in a derogatory manner, nor vice versa.
Related articles
- He Said, He Thought, He Said, He Thought (bulldozer00.com)
Industry Best Practice
When we got the idea for this book, we expected to surely find dozens of other books with the same theme… To our surprise, however, we found no other books devoted to abolishing (the annual performance) appraisal and exploring fresh approaches to the functions of appraisal. – Coens/Jenkins (Abolishing Performance Appraisals)
Since the thought of replacing the sacred “annual performance review” is so shockingly unthinkable, any proposed alternative doesn’t have a snowball’s chance in hell of being embraced. The undiscussability of this “industry best practice” is so palpable, that not many souls even make an attempt to concoct any alternatives, let alone expose them for scrutiny. Alas, such is the power of entrenched 20th century management thinking to keep the status quo on corpo-social issues that really matter, in-situ.
Related articles
- Behind One’s Back (bulldozer00.com)
- He Said, He Thought, He Said, He Thought (bulldozer00.com)
The Real Customer
In “12 ‘best practices’ IT should avoid at all costs”, InfoWorld‘s Bob Lewis asserts:
I enjoy Bob’s books and columns, but I have to side with the likes of Russell Ackoff and Vineet Nayar on this one. All of an org’s “enabling” functions: HR, QA, Finance, Purchasing, IT, etc; should indeed serve the direct revenue-generating business functions and treat them as paying customers. Otherwise, the natural tendency of these groups in hierarchical orgs is to turn into obstacle-inserting, unresponsive, monopolistic dictatorships. Of course, in the “real world” this rarely happens because rational adults are in charge – and Bob is right. What is your opinion?
Patience Grasshoppa, Patience
It won’t arrive for awhile, but it’s on its way: the C++11 rendition of Bjarne Stroustrup‘s “The C++ Programming Language“.
In case you didn’t already know, the C++11 editions of these tomes are already available for your consumption:
But of course, you did already did know this. There are gifted copies of each of these references on your and your colleague’s desks because your company cares about you, your productivity growth, and continuously enhancing the quality of its revenue-generating product portfolio. That’s why it obsesses over little, but simultaneously huge, things like this for you, its products, and its future well being. It’s a quiet, low-key, low-cost, win-win-win situation that makes you feel warm and fuzzy each day you walk in the door to joyfully add your contribution to the whole.
And puh-leeze, no comments from the hip and cool Ruby, Python, Java, Go, Scala, C#, etc, peanut galleries. On this bogus blawg, only pope BD00 is approved to promote or trash other programming languages, ideas, groups, concepts, institutions, traditions. Well, you get the idea.
Note: I created the above image at says-it.com. It’s a wonderful site, so hop on over there and give it a whirl.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 