How Black & Decker Questioned Success and Discovered a New Market

(originally posted on CitizenTekk)

Like most industrial concerns at the time, Black & Decker became an integral part of the United States’ war effort during World War II, producing power tools used in the defense industry. Alonzo G. Decker, Jr., a Vice President of the company (as well as the son of one of the founders), noticed that a defense contractor was buying drills at an unusual rate:

“Are they breaking down?” Mr. Decker asked.
“No, they are disappearing. Women are taking them home in their lunch baskets,” he was told.
Mr. Decker said he replied, “When females are taking drills home, we ought to be making something just for the home.”

“Toolmaker innovator Decker Jr. dead at 94” Baltimore Sun, 3/19/2002

Aside from the sexism (it was the 1940s), two things should stand out: Decker was proactively looking for anomalies (including orders that were “too good”) that might indicate problems and he was alert to new opportunities. With the end of the war, Black & Decker launched a line of power tools for the home market, selling their millionth drill in less than five years. After nearly seventy years, the market has grown to $14.5 billion, of which Stanley Black & Decker holds $5.2 billion. Imagine the difference it might have made had he ignored either the anomaly or the opportunity.

In my previous post, “Faster Horses – Henry Ford and Customer Development”, I pointed out the importance of understanding the problem space in terms of customer needs and wants. While listening to customers is a valuable technique, Decker’s story shows that observing them can be just as valuable, if not more so. Some people dislike confrontation, some people dislike complaining, but their actions will generally conform to their feelings.

While the latest Big Data techniques can potentially give great insight into a customer’s motivations, Decker’s experience proves that lower tech metrics can work as well. The key is determine what the needs are and then pay attention to how well those needs are being met using the best methods at your disposal. Detecting issues before the customer complains can pay dividends – Alonzo Decker was looking for a problem when he found a multi-billion dollar market segment.

Advertisement

The Great Divide – IT versus “the Business”

An easy way to start a fight these days is to refer to “the business”. Whether as a grumble or a shout, the response will inevitably come: “IT is part of the business”.

Of course it is. Having written a post or two (or three or four) about that very subject, I fully agree. That being said, not all differentiation is evidence that one believes “the business” exists to be the life support system for IT.

“The business” can be a useful shorthand for “not IT” (also “not HR”, “not legal”, “not purchasing”, etc., depending on who is using the phrase). This type of differentiation is extremely useful to help ensure that we’re associating the different aspects of a system (both features and qualities of service) with their appropriate stakeholder(s) and prioritizing them appropriately. In dealing with storage, we might have concerns around time to back up (predominately an IT concern) and available capacity (more likely to concern “the business”). We can play word games to avoid using those exact terms, but ultimately we need to make sure the concerns of “the business” take priority. We also need to make sure that where IT concerns have business impact, that impact is presented in terms of business outcomes.

This is the main reason I prefer having IT’s funding reside in the budgets of those using it – nothing destroys customer service quicker than giving someone a target (e.g. cost cutting) that is at odds with serving their customer. However, it should also be noted that customers that are paying their own bills tend to be more responsible consumers. Helping business units find the most cost-effective way to achieve their ends meets the goal of providing good service to those units and serves to further the enterprise’s goal of reducing costs. Satisfying its immediate customer (the business units) and the enterprise as a whole is more important than merely paying lip service to alignment. As a support organization, it’s how IT contributes to the satisfaction of the external customer. Since IT is a part of the business, that should be our concern – whether our concept of service is contributing to the success of the enterprise, not whether we’re using the term of the day.

[Photograph by Marcin Wichary via Wikimedia Commons.]

The Never-Ending Narrative of Architecture

All of my creation is an effort to weave a web of connection with the world: I am always weaving it because it was once broken.

Anaïs Nin by way of @RuffyanMe

When is an architect’s job done? Is it upon completion of the “design phase”? Is it when the project is complete?

In my opinion, the best definition of the architectural process (see slide 16) is Tom Gilb’s: “A continuous, and lifecycle long, activity of finding means for ends”. The activities facilitated by the application are unlikely to be static, so it is unrealistic to expect it to remain the same. Even where the business doesn’t change significantly, our understanding of it may:

I bet the users are very grateful at first, but then they come to rely on it. And, what’s more, they like the system less and less over the course of time. Every time the USPS changes the price of postage you have to go into this system and made changes, and, what’s worse is that the part that generates the documents seems to break every time there’s a new version or even an update to Word.

Erik Dietrick, “Beware Mindless Automation”

Even if a particular business process was unchanging and its automation was executed perfectly, the platform on which it runs will not. Failure to plan for platform evolution is planning to fail due to lack of maintenance.

In short, an application is a relationship. Unless you plan to never see its users again, it’s a long-term commitment, not just a project. So long as the application exists, there is a need for the architect role to provide advice on the evolution of the product and its platform. Without this continuity of vision, the result is likely to be the “Shantytown” pattern described by Foote and Yoder in “Big Ball of Mud”:

All too many of our software systems are, architecturally, little more than shantytowns. Investment in tools and infrastructure is too often inadequate. Tools are usually primitive, and infrastructure such as libraries and frameworks, is undercapitalized. Individual portions of the system grow unchecked, and the lack of infrastructure and architecture allows problems in one part of the system to erode and pollute adjacent portions.

If the architectural process can be described a narrative, it should also be seen as a story consisting of several component stories, carrying the product from cradle to grave(*). Maximizing cohesion within a given narrative (release) is important. Likewise, benefits will accrue from maintaining continuity from one narrative to the next.

The connection between the application and the ends it serves is seldom static. The longer the web is left unattended, the more likely it is to break. Much can slip through a broken web, and each escape widens the breach.

Maintenance can seem costly without the perspective of the cost of replacement, not to mention value lost to obsolescence.

* It’s not exactly “never-ending”, but I like alliteration, so the title stands. 😉