Archive

Posts Tagged ‘organizational behavior’

A Loss Of Heart

The Unwanted State Transition


Humor me for a moment by assuming that this absurdly simplistic state transition diagram accurately models the behavior of any given large institution:

Culture STM

In your experience, which of the following transitions have you observed occurring most frequently at your institution?

management xitions

Better

April 5, 2016 2 comments

Consider a classic, straight-line, hierarchical organization:

hierarchy4

Because of the structure of the vertical communication links that tie the org together into a system, the dudes at the top are guaranteed to have a distorted understanding of what the dudes at the bottom are doing – and vice versa. With no direct lines of communication between non-adjacent layers, how could it be otherwise?

Of course, everyone who has ever toiled in the lower layers of such a “classic” hierarchy has railed against what they perceive as the unfairness and inhumanity of participating in such a system.

So then, if the classic, straight-line, vertical hierarchy is so bad for those grinding it out in the lower layers, which is a better system structure:

WhichIsBetter

If you’re expecting BD00 to definitively choose sides, extolling the virtues of “the good one” while denigrating the vices of “the bad one“, fuggedaboudit. There is no universally applicable “good one“. Or is there?

The Real And The FAKE

March 20, 2016 2 comments

Event Driven Behavior

February 21, 2016 2 comments

Stuck On

September 20, 2015 Leave a comment

My Fitbit Flex has served me well for over 3+ years. However, it’s time to replace it. A hardware fault has mysteriously manifested in the form of the middle status LED switch being stuck in the “ON” position all the time:

Flex Fail

Every time I look at it, it appears to be giving me the middle finger. LOL.

Interestingly, the step-tracking functionality still works fine. The downside is that instead of having to charge the device every 5 days, the battery discharges so fast that I don’t get an auto-generated e-mail notifying me of the low charge status. I have to remember to charge it every 2 days. Bummer.

I wanted  to tell the Fitbit folks about the fault just in case they hadn’t seen this particular fault before and because the info might help them preclude it from happening again in the future, but there seems to be no way to directly relay the information to them. I browsed through their web site for 5 minutes trying to find a way to e-mail them, but I gave up in frustration. I finally ended up tweeting the picture to @fitbit.

 

Fitbit

I e-mailed Fitbit just as @fitbit suggested, but I didn’t hear anything back from them. Nada, zilch.

Perhaps FitBit should be  more Zappos-like; obsessed with customer service. As you can see below, the zappos.com front page prominently shows that it has real people waiting to talk to me 24/7, via three different communication channels.

zapposhelp

Flat, Independent, Hierarchical, Inter-Dependent

August 17, 2015 Leave a comment

Flat And Independent

Assume that company ABC develops products for customers in domain XYZ as follows:

P1P2P3

To remove the “development process” variable from further consideration in this post (because, thanks to consultants, it seems like everybody and their brother thinks process (traditional, Scrum, XP, LeSS, SAFE, Lean, etc.) is the maker or breaker of success), assume that all the teams use the same development process.

As the figure implies, each product is tailor-made for each customer. Since there are no inter-team dependencies and there is no hierarchy in the organizational structure, each team is an island unto itself and fully responsible for its own success or failure.

The tradeoff for this team independence is that the cost of development for company ABC may be higher than alternative strategies due to the duplication of work inherent in this Flat And Independent (FAIN) approach. For example, the above figure shows that components A and B are developed from scratch 3 times and component 2 is developed twice. What a waste of resources, no? However, assuming that components A and B only need to be developed once and reused across the board requires that component A is identical for all customers and component C is identical for customers 2 and 3. However, even though the products are targeted for the same domain this may not be true. The amount of overlapping functionality for a given component is dependent on the amount of overlap between the customer requirements applicable to that component:

ReqsOverlap

If there is zero requirements overlap, or the amount of overlap is so small that it’s too expensive to gauge, then financing three separate component development efforts is more economically viable and schedule-friendly than trying to ferret out all overlaps and embracing the alternative, Hierarchical And Inter-Dependent (HAID) strategy…..

Hierarchical And Inter-Dependent

Now, assume that company DEF also develops products for customers in domain XYZ, but the org employs the HAID strategy as follows:

HAID

In this specific instantiation of the HAID (aka product line) approach:

  • Core asset component B is developed once and reused three times
  • Core asset components A and C are developed once and reused twice

Beside the obvious downside of core asset components D, E, and F being developed but not reused at all (violating YAGNI in this specific case when it actually applies), there is a less obvious but insidious inefficiency in the two layer hierarchical structure: the product teams are dependent on, and thus, at the mercy of the core assets team. The cost and schedule inefficiencies introduced by this hierarchical dependency can make the HAID approach less economically viable than the traditional, seemingly wasteful, FAIN approach. But wait! It’s worse than that. If you’ve been immersed in the HAID way of life for too long, like a fish in water that has no concept of what the hell water is, you may not even know that you’d be better off if you initially chose, or currently revert to, the FAIN strategy.

FAIN HAID

Inappropriate application of, or poor execution of, the HAID approach to product development reminds me of the classic framework dilemma in software development. You know the feeling. It’s when you break out into a cold sweat after you choose a development framework (or development process!) and you suddenly realize that you’ve handcuffed yourself into submission after it’s too late to reverse the decision. D’oh!

I guess the moral of this story is nothing new: “just because you changed strategies to become more effective doesn’t make it so.” Well, maybe there is no moral, but I had to end this post some-freakin’-how.

Follow

Get every new post delivered to your Inbox.

Join 679 other followers

%d bloggers like this: