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:
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.
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.
Flat And Independent
Assume that company ABC develops products for customers in domain XYZ as follows:
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:
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:
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.
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.
My previous post highlighted inter-company culture clashes. This followup highlights the most insidious intra-company culture clash:
Without deviation from the norm, progress is not possible – Frank Zappa
The further a new idea deviates from the norm, the more resistance there will be to its adoption – and the deviance/resistance relationship is ominously nonlinear:
Since it’s human nature to prefer the familiar over the comfortable, passionate purveyors of new ideas that have proven to work for themselves and their orgs better take heed: the way you promote a deviant idea matters.
The more radical your idea, the more graceful you must be in your advocacy in order for the idea to have any chance of infiltrating the mainstream. If both your idea and your approach are radically extreme, then you’ll likely be perceived as a frontal assault idiot by not only those few in power, but those many on the front lines who would otherwise become your allies.
Even if you eschew a militant stance and adopt a graceful approach toward getting your deviant idea widely accepted, the odds are still stacked against you because of the powerful “familiar over comfortable” force field that keeps the status quo in place.