Building Skills - Centralized Expertise - Central Practices - Centers of Excellence/Communities of Practice

This discussion is about what companies can do to upgrade technical skills and implement best practices to increase the quality and capabilities of delivery teams.  It is not discussing project management or cross-team delivery issues. This is mostly built on experience with Software Delivery and Development. The general concepts are probably valid for process teams that require multiple skills.

Delivery Team Complexity

Software delivery continues to evolve requiring ever-increasing technical expertise as system complexity, system scale, and compliance regulations increase.  Modern applications face continually evolving security threats further increasing the burden on software delivery teams.  Shift Left initiatives increase the accountability and responsibilities of the same delivery teams.  

This image shows some of the roles played by delivery teams as part of historical capabilities in addition to those added as part of You Build It You Own  Agile Dev Ops transformations.  Everyone in delivery needs to be able to support each of these roles. Team members may specialize as SMEs in some areas while maintaining basic understanding in most.

Maintaining and Distributing Required Technical Skills

Organizations can take a variety of organizational approaches to increase the skills and depth of technical teams. 

1. Smart People will Take Care of It: Teams own their own everything.  Architecture and governance set guidelines.  There are no real best practices or skills-building groups unless they are self-organized.
   Some companies essentially upskill by only hiring experienced talent and dump the bottom 20%. Companies with this philosophy often also use the same approach for cross-project coordination and task management.
2. Centralized Technical Matter Experts: The traditional centralized service teams that do work on demand.  TMEs are part of the central organization and support delivery teams on a ticket or per-call basis.
   People that have been around for a while should be aware of the historical pendulum of organizational changes for Centralized DBAs and System Administrators.  PaaS services in the cloud have eliminated much of the demand on these groups. Infrastructure as Code has dramatically changed the skills requirements for Operations and Developer Operations (DevOps) staff.
3. Central Practice Matrix'd to Teams:  Technical Matter Experts are centrally managed and deployed to development teams where they act as full members.   Think of the org chart as a solid line into the practice and a dotted line to the development organizations. This is a common model for Solution Architects and System Architects.
4. Center of Excellence Matrix'd to the Center: The Technical Matter Experts are owned/tasked solely by the development teams.  Shared services resources exist in central groups that the TMEs report to in a dotted line fashion or may report to for management purposes.  This is the inverse of the Central Practice.
5. Community of Practice: This is a slightly more supportive version of Smart People will Take Care of It. All interaction with the CoP is voluntary. Architecture or Shared Engineering supports the CoPs and schedules regular meetings, presentations or events. Engineers have no leverage on their team to commit to the CoP or the practices of the CoP.

Video

Central Practice

This approach struggles because delivery team management feels like they have a lack of control over the resources. The policies and recommendations of the central practices are seen as impediments to faster delivery. 

Centralized practices can be pretty common for software testing, Dev/Ops common platforms, software architecture, and data modeling.  This model provides strong backing for TME activities aligned with best practices principles.  Development management tends to treat these resources as wholly owned and may intimidate the matrixed resources into doing development work in place of or out of alignment with the Central Practices principles.  

Center of Excellence (COE) or Community of Practice (COP )

This approach struggles because the Centers of Excellence and Communities of Practice are wholly dependent on the delivery team management for their effectiveness and influence.  Software Development Engineering operations are most often based on COE/COP because software developers are almost always totally under the control of the development team management.

The primary weakness of the CoE is that it can be ignored by Development Management hierarchies unless it has enforcement capabilities.  Security CoE can offer additional security training or provide competitions like Hackathons.  Software best practices CoE tend to really struggle without any type of automated software quality auditing.   Development management can deny CoE-related time and activities by de-prioritizing them against regular work.

Differences across the Towers/Stovepipes

Different departments in the same company can take completely different approaches  The following chart describes two VPs, each of which has its own organizational style which permeates their organization. 

The top organization is built with cross-cutting or matrix-style capabilities.

Click Image to Enlarge

The bottom organization is built as a set of standalone teams where each team is responsible for creating all its own expertise

Fiefdoms

Fiefdoms are organizations that take on the personality of their VP or senior management.  Each fiefdom operates in its own fashion with its own guidelines.  They completely own their own prioritizations cross-cutting concerns like compliance, governance, best practices, etc.  Fiefdom based organizations make many of the above patterns difficult.

Created 2022 04