Tribal Knowledge – The Anti-DevOps Culture

Developer Support

App Dev Manager Silviano Blea explores the idea of how “tribal knowledge” can work against an organization’s ability to adapt and transform in their DevOps journey.

With the adoption of all things DevOps, changing the culture of an organization has become vitally important for teams to adapt to a more dynamic world. As described by Ron Vincent’s Blog DevOps and Culture, Part 1: “Technology changes exponentially (fast) yet organizations change logarithmically (slow)”. Over time this gap widens and requires organizations to re-org/reset or simply get left behind. To adopt DevOps Principles and Practices, organization must unsure they have the culture to support this philosophy. To put it in other terms, they must ensure any negative culture habits have been rooted out, because “People don’t leave jobs, they leave toxic work cultures”. In my career, the single most detrimental culture habit has been “Tribal Knowledge” syndrome. It can severely handicap a project, a team, and even an entire organization.

I define Tribal Knowledge as the knowledge one obtains from belonging to a project, team, or organization for a long time and acquiring how-to knowledge and nuggets of information that cannot be easily obtained by other individuals. In software development teams, this often means 1) Knowing the code base, 2) Knowing certain techniques, 3) Knowing the technical debt, 4) Knowing certain processes and people to get things accomplished. Not only is this information not easily obtained by other individuals, often it is not easily shared (or intended to be shared). New team members suffer the most because they are at a severe disadvantage and may take months or years to acquire the same knowledge via the same methods. It is this behavior that I believe is the single most important factor for Software Development, IT, System Engineering, Testing and Integration teams to eliminate to improve their culture and setup for success in the new DevOps World. From Ron Vincent’s 2^nd blog, DevOps and Culture, Part 2: “We don’t change culture, we can only change behavior. Changing culture is a side effect.”

For teams and organizations to take the DevOps (or DevSecOps) next step, they must identify and remove any roadblocks to improvement if they truly want to adopt the “Agile Manifesto”. The Agile Manifesto is at the heart of DevOps. This can be summarized with several key points.

1. Things must be repeatable. If only a single individual has certain knowledge on how to do things, then it is not repeatable and counter-productive to the DevOps Culture. For example, IT teams can document the installation/configuration of server apps (SQL Server, TFS, DevOps, etc.)
2. Automate things. If processes are manual, find a way to build tools/scripts that can automate them for the entire team (not just a single individual) and make them available/known to the greater team. Build with the entire team in mind, as opposed to individualistic goals.
3. Build quality. Take the time to remove technical debt (tribal knowledge) for the greater good of the team. Managers must actively promote and reward this behavior to drive out tribal knowledge.
4. Take the long-term approach. Often times in software development projects, managers want things done ASAP without understanding the scale of the problem, time constraints, and technical hurdles (especially technical debt). By tackling smaller problems (aka Sprints and Planning) teams can slowly chip away at larger problems. Managers must also actively promote and reward this behavior to drive out tribal knowledge.

By removing or reducing tribal knowledge from projects and teams, organizations set themselves up for success in an ever-changing landscape (exponentially changing). In other words, you can add to your DevOps culture (or create one) simply by subtracting the bad habits and behaviors.

Developer Support App Dev Customer Success Account Manager, Microsoft Developer Support

Follow