Archive

Posts Tagged ‘hierarchy’

Pick Your Tyranny

August 16, 2011 Leave a comment

Given the choice between “tyranny of the majority” and “tyranny of the minority“, I’d choose the former every time – especially when the minority is a junta in the latter case. In representational democracies like the good ole USA, the “representational” aspect decreases the chance of being governed by the “tyranny of the majority“. In really bad corpricracies, the “tyranny of the minority” is the rule and, since it’s a subtle form of tyranny, everyone up and down the ladder of importance accepts it in quiet desperation – with no questions asked.

One Size Fits All

August 6, 2011 Leave a comment

On Bjarne Stroustrup’s FAQ page,  he state’s his opinion on the utility of object oriented programming:

The strength of OOP is that there are many problems that can be usefully expressed using class hierarchies – the main weakness of OOP is that too many people try to force too many problems into a hierarchical mould. Not every program should be object-oriented. As alternatives, consider plain classes, generic programming, and free-standing functions (as in math, C, and Fortran).

The same could be said of organizations of people, no? Of course, in a purposeful org of people and machines, the goal is to produce and distribute material wealth to all stakeholders: products/services to its customers and financial well-being to its employees and owners.  Thus, some sort of controller-controllee structure is required to keep the org from deviating too far from its purpose. There are alternative structures to hierarchy but, as Bjarne sez, “too many people try to force too many problems into a hierarchical mould“. Bummer.

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:

Would YOU Join My Group?

I’m recently toyed with the idea of starting a LinkedIn.com group named “Frontal Assault Idiots“. This would be the group’s logo:

Alas, I rejected the idea because the only members who would join are me & my buddy, Chetan Dhruve – and no one would post any discussions.  D’oh!

Creating One Way Dependencies

May 14, 2011 1 comment

Assume that you were totally free; an island unto yourself, independent of all other people and able to do whatever you wanted and whenever you wanted. In order to survive, you’d have to become: responsible for building your shelter, growing and hunting your food, making your clothes, and securing yourself from attacks by “other” people and animals. D’oh, that would suck!

Now assume that you wanted to be free, but you didn’t want to do all of the primitive “hunting and gathering” work required to survive. You’d have to become dependent on the skills and talents of a bunch of other people who can do the things you don’t want to do. How would you pull that off? You’d have to somehow make other people dependent on you, no?

The way I see it, there are at least three ways to become free while minimizing the effort you’re required to expend to survive:

  1. you’d have to develop a skill of your own that is needed or wanted by others so that they willingly supply you with the basics for your survival.
  2. you’d have to physically force others into supplying the basics for your survival.
  3. you’d have to psychologically force others into supplying the basics for your survival.

Numbers 2 and 3 introduce a one way dependency into your self-centric “system” – with other people depending on you, but not vice versa. Whoo Hoo! Compared to number 1, no hard work on your part is required. You receive without giving anything in return – a pure consumer.

Now, assume that you pull off the one-way dependency trick via clever application of number 2 or 3. As the left hand side of the figure below shows, a star topology with you smack in the center of the one-way dependency system quickly becomes unscalable as the number of people you desire to be dependent on you grows. You’d have to use more and more of your time maintaining your physical and/or psychological control over the growing number of people who are continuously fulfilling your needs. D’oh!

One answer to the scalability problem is to recursively apply your physical and/or psychological coercion expertise to impose a hierarchical structure on your system – with you at the top, of course. A hierarchical structure would cut down the number of people you need to physically and/or psychologically track and coerce into satisfying your needs without expecting anything in return. Hence, the proliferation of hierarchies throughout the course of human history.

Required Pretentiousness

April 11, 2011 Leave a comment

“We grow up being afraid of our own ignorance and terrified that our ignorance may show. Over time, we’re conditioned to appear as “knowledgeable” as we can, while carefully concealing the limits of our understanding.”

Does the above quote, snipped from Peter Ralston’s “The Book Of Not Knowing“, ring as true for you as it does for me? I think it’s one of the top reasons why I spend a lot of time trying to keep abreast of developments in my field and advancing my programming and design skills.

You see, I often feel uncomfortable when someone starts talking about a topic that I’m ignorant of. I used to (and still do, but much less frequently) “pretend” that I understood what was being said so that I wouldn’t appear “stupid“. Now, I rarely hesitate to say sentences like “you lost me in the dust” or “I have no idea what you’re talking about” – regardless of the social consequences. I’ve realized that “not knowing” is the natural state of being – which means that we can’t avoid dwelling in it no matter how hard we try. Trying to fight spending one second in the state of not knowing is as ludicrous as a bird trying not to fly or a fish trying not to swim. Fighting one’s natural state of being always has a cost; psychological, physical, or both.

Pretending to know” is a full time activity in hierarchically structured organizations that work with, and create, non-physical knowledge. Since knowledge is king, the higher one moves up in a hierarchy, the more pressure one feels to delude oneself into omniscience (e.g. when was the last time you asked a question that a superior didn’t whip out an answer to?). This unnatural behavior is exacerbated by the fact that all members in a hierarchy are either conscious or unconscious co-conspirators in the comedy.

I’m a conscious and willing co-conspirator. How about you?

Take Me To Your Ruler

April 10, 2011 Leave a comment

CORKA, The Killer Whale

April 8, 2011 2 comments

In case you were wondering, CORKA stands for CORpo Kiss-Ass. In DYSCOs (frequent disclaimer: not all companies are DYSCOs), the CORKA density is a function of the level one operates in within a corpricracy, no?

Performance Improvement

ASSume that within the vast lands of a self-described great kingdom, you’re the prince of the little fiefdom below. To keep you comfortably propped up on your throne, the DICforce in each of the 3 little green boxes, under the watchful eye of your enforcer (the faceless BM dude with the white name tag), performs 3 day-to-day functions critical to your, I mean your group’s, “success“. For simplicity, let’s call these functions F1, F2, and F3.

So, everything’s humming along until – BAM! – revenues start declining and costs start rising. D’oh! and WTF? After spending some time down in the puke green boxes and thoroughly observing/investigating/analyzing/evaluating the state of your state, you declare that the performance of the “F2” function is gumming up your well-oiled machine. In your wisdom, you address your minions and boldly  proclaim: “F2 Sux!“.

Uh, what change do you decide to make to “improve performance“? One option is to bring in some external “F2 gurus” to train your underperforming F2 DICsters. Another option is to fire your current F2 DICs and permanently hire new, expert, F2 DICs.

After mulling these options over, it hits you like an insight from Gawd…. you’ll hire one expert F2 enforcer dude, give him/her an ego-stroking overhead staff, and move your existing F2 DICsters into his/her newly born sub-fiefdom. So, you implement your brilliant idea and end up with this new borg:

So, besides further fragmenting your borg, increasing your overhead cost structure, pissing off your existing loyal enforcer, and having the same DICsters still supposedly screwing up the F2 function, what else can you pat yourself on the back for?

Which Path?

To all front line managers out there: “which path below did you take when you were promoted out of DIC-land?” To all DICs out there who want to, or are on a course to, move into the brave new world of management, uh, I mean formally anointed leadership: “which path below do you plan on taking?“.

To all those who took or prefer the D&D path, please leave this page now. To the remaining E&E takers and preferrers, please peruse this follow-on diagram:

Will you allow the natural and effortless course of increasing entropy occur after you’ve made your choice, or will you temporarily “hold it together” with effortful due diligence throughout your career – no matter how high you go or how much pressure you feel from your peers?

Is it even reasonable to ask for any overlap between work-work and management-work as one ascends higher up in a hierarchically structured CLORG? For example, in a 10 layer hierarchy, is it insane to expect the dudes in the upper echelons to know something, anything, about the nature of the work that goes on down in the boiler room?