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.

Chain of Communication

The following is paraphrased for my benefit. It is taken from an interview with Rex Geveden documented in the book Range: Why Generalist Triumph in a Specialized World by David Epstein.

I expect disagreement with my decisions at the time we're trying to make decisions, and that's a sign of organizational health. After the decisions are made, we want compliance and support, but we have permission to fight a little bit about those things in a professional way. There is a difference between the chain of command and the chain of communication, and that the difference represents a healthy cross-pressure.

I'm going to communicate with all levels of the organization from the CEO all the way down to the interns, and you can't feel suspicious or paranoid about that. I will not intercept your decisions that belong in your chain of command, but I will give and receive information anywhere in the organization, at any time. I just can't get enough understanding of the organization from listening to the voices at the top.