Why do Enterprise Organizations Need Communities of Practice?

Many large enterprises and mid-sized organizations are looking to build and strengthen their internal culture to improve knowledge sharing, increase working morale and improve staff retention. Only a few years ago these same companies would have turned to Centres of Excellence (CoE) but instead they are looking to leverage Communities of Practice (CoP). 

So what’s the difference I hear you ask? Aren’t they the same thing? Well, a ‘centre’ is exclusive, invite only, members and regulars admission, while ‘excellence’ refers to the fact that the group are experts with nothing more, or very little to learn. Conversely a ‘community’ is inclusive, can extend across the whole organization and all are welcome to join without invite. The word ‘practice’ delivers the perception of individuals honing their skill, continually learning and sharing from their experience. 

(Photo Chef Team: Victoria Jeffrey, Hannah Maddy, Anthony Rees, Nathen Harvey and Matt Ray.)

I recently had the pleasure of spending over a week with Nathen Harvey, VP of Community at Chef. I consider myself a practitioner with a thirst for knowledge and I jumped at the chance to soak up some of Nathen’s experience around building, fostering and sustaining communities, some of which I hope to share with you here. 

Ubuntu is often referred to by Nathen. Apart from being an open source linux distribution, Ubuntu is used in a more philosophical sense to mean “the belief in a universal bond of sharing that connects all humanity”. This further embodies the art that is Community and I felt it was an excellent mantra to remember and refer to when building or participating in a CoP. When talking about Community, Nathen also refers to Adam Jacob’s Keynote from ChefConf in 2016 where he describes building Humane Systems and leaves the audience with the thoughts: ” I am because you are; When you suffer, I suffer; When you thrive, I thrive.” A simple lesson we could all remember in both our work and home lives.

One area that intrigued me was Nathen’s approach to IT based outages. He uses and practices the Critical Incident Response technique adopted by specialist response units like Fire Brigades, Emergency Services and Law Enforcement. As part of this approach, the first person on the scene takes the role of Incident Commander. This is due to the fact that they have the most context and understanding of the issue or outage. From here a set ceremony script is followed with the Commander officially calling an incident and therefore allowing them to engage the help of any team members required to fix the situation. At Chef, the Incident Commander also fulfil’s the role of the central internal and external communications officer providing status updates and shielding the team from constant questions, allowing them to get on and just fix the problem. 

This role of Incident Commander uses the OODA methodology; Observe, Orientate, Decide and Act. This technique is used by each member of the team allowing them to take the time to observe the impact,  orientate themselves to understand the extent of the issue and any flow on impact, collectively decided on the best way to fix the problem and finally act on the solution. 

The post-mortem is also quite unique. Everyone at Chef is invited to attend (Yes! The whole organization!) and if it impacts the Chef community, then it is often run on Google Hangouts and streamed to YouTube for those that cannot attend to watch later and provide feedback. All this further extends the ‘inclusion’ and strengthens the community as a whole. 

If you are interested in watching a YouTube post-mortem hosted by Nathen, check out the video below.

Again, the ceremony of the post-mortem opens stating that this is not to lay blame or point fingers but to improve the way we work together and learn from the incident. The post-mortem really concentrates on two fundamental questions.

  • How could we have detected the issue faster?
  • How could we have resolved the issue sooner?

Nothing else matters now at this stage. The incident is done, it has occurred, its fixed and you can’t turn back time…but you can learn from the event. 

The Chef community uses Slack for asynchronous communications rather than email and wherever possible video chat for meetings. Once a year the distributed community is brought together, face-to-face to meet, learn from each other and provide feedback, often over a beer or two!

So let me ask you this: is your organization fostering, building and supporting communities of practice? If not, WHY?

Continue the Conversation

Author Anthony Rees

Anthony is a member of the Chef Solutions Architecture Team helping organisations with the journey to continuous automation and is based in Melbourne, Australia with a strong background in agile application development. He has always been an active open source community member and advocate, including OpenStack since the Grizzly days, CloudFoundry from pre-v1.0 and Docker for a few years now. Anthony has a keen interest and vast experience in Continuous Delivery working with many teams around the world to implement Test Driven Development techniques, Feature Toggling best practices, late binding Platform-as-a-Service designs, Build Automation and leveraging DevOPS methodologies on both OpenStack and Public Cloud environments. He is a regular speaker at development conferences and hackathons around the world. You can follow him on Twitter @anthonyrees or watch his previous presentations on YouTube.