Community Adoption of New Practices

Community adoption of new practices can mean a lot of things.  From getting a small team to try a new methodology or tool to convincing the world that a product or service is needed.

In 1996, Robert Metcalfe was awarded the IEEE Medal of Honor for "exemplary and sustained leadership in the development, standardization, and commercialization of Ethernet." The story of how Ethernet came to be follows the 8 steps of essential practices below. I've added headings for what departments typically handles each practice in a large company. You don't have to have different people or departments. I find it helpful to get into the mindset of each role when implementing a specific task.

• Product Management
• Sensing -- giving voice to a concern over a breakdown in the community
• Envisioning -- design a compelling story about a future without the breakdown
• Development
• Offering -- committing to do the work to produce that feature
• Sales
• Adopting -- gaining commitments from early adopters to join the innovation for a trial period
• Sustaining -- gaining commitments from majority adopters to join the innovation for an indefinite period
• Implementation
• Embodying -- working with the community until the new practice is fully embodied, ordinary, and transparent
• Navigating -- moving ever closer to the goal despite surprises, contingencies, and obstacles
• Marketing
• Mobilizing -- building a network of supporters of the innovation from within dispersed communities

Many times over my career I've been assigned the job of getting multiple software development teams to adopt a practice; coding standards, secure coding practices, SOX requirements, architectural guidelines, etc. Eventually, the above 8 practices were performed but not always in an order that was useful. I got better with experience, but my life would have been easier if I would have had those practices written down to guide me. To make notes against. And to revisit when progress was slow or stopped. I hope you'll save the above list and use it for your future innovations.

References

Denning, P., "Avalanches Make Us All innovators," Communications of the ACM, Vol. 63, No. 9 (Sept 2020), 32 - 34.

Sorry, I don't have a reference for Metcalfe's Ethernet story. I heard him talk about it at a conference in 2015 or 2016.

Misbehaving

I've been listening to Misbehaving: The Making of Behavioral Economics by Richard Thaler on audiobook. In chapter 3, "The List," there is an interesting analysis of a company losing money because managers are afraid to lose their jobs. Which leads them to avoid some projects. I saw this only a little in my work experience.

In chapter 29, "Football," there is an analysis of how to game the draft to end up with an overall better team. Basically, it is chapter 3 but told in a more interesting manner. Replace the star football player with the star project and you get the same problem of putting all your resources in one basket. The analysis goes deeper and points out that the coaches and managers are not solely to blame. They are going after the star players (star projects) because these are what the owner (CEO/chairmen) want. I saw this more often in my work experience.

The higher up in a company the less the employee looked at the project data and the more they looked at what their boss wanted. If you are a manager, director, VP, C-suite employee, or chairman then please read this book. It won't give you answers but it might force you to acknowledge that you are making decisions based on the wrong data. Then you can give the company a better chance at [overall] success.

Okay, I know, I'm skipping over the problem of "the manager who doesn't work on the boss' pet project still gets fired." Yeah, that sucks. You deserve a better boss. But guess what? You saved your department for another year and only had to sacrifice yourself. Had you done the doomed project you might have doomed the department too.

Understand Risks Up Front

On any software project it is impossible to predict exactly what will go wrong. However, something will go wrong. In the early stages of planning, delineate the largest risks associated with your project. For each, quantify the extent of the damage if the risk potential becomes a project reality and also quantify the likelihood that this will come to pass. The product of these two numbers is your risk exposure with respect to that particular risk.

At project inception, construct a decision tree that delineates all the things you could do to lower the exposure. Then either act on the results immediately, or develop plans to implement various actions at points when the exposure exceeds your acceptable limits. (Of course, specify in advance how you will recognize this situation so that you can implement the corrective action before it is too late.)

Reference:

Charette, R., Software Engineering Risk Analysis and Management, New York: McGraw-Hill, 1989.