Four Anti-patterns When Establishing Centres of Excellence

In most organizations, the bottleneck is at the top of the bottle.

—Peter Drucker

Should technology be centralised or decentralised in an organisation? An easy question to ask, and one where leaders can talk themselves into believing there is a simple solution to a normally messy problem. If you accept that organisations are complex adaptive systems, then you’d appreciate that the answer is “it depends.”

Experience shows that while many organisations do accept this view, they don’t rigorously apply this perspective when they embrace new technologies or capabilities. They often rightly start by centralising experts to jumpstart efforts using a Centre of Excellence (COE) which can provide new practices, technology building blocks, mental models, and advice to help accelerate the adoption of new capabilities. Unfortunately this approach can then go awry. Frequently the COE is not initially excellent, and/or can overdo the centralisation over time. What started off as a function intended to create “freedom in a framework” for the line of business functions to maximise the value of the new capability ends up becoming a bottleneck for the rest of the organisation.

So what causes these issues, and how can we avoid them? I’ve seen four archetypal anti-patterns when establishing COEs. I share these below, along with some things to consider as you establish your own COE.

Anti-pattern 1: COE on the Critical Path

COEs tend to be a jump-start for a new skillset or technology. A small team develops competencies that they can replicate through a business, acting as much as an educator as a technology team. The first anti-pattern is that over time, COEs can forget about the education part. After all, teaching others is nowhere near as exciting as doing tech stuff to most people in tech. While it might have been intended as a transitionary structure, the COE becomes a permanent fixture. As new technology adoption accelerates across a business, the COE fails to keep up with new demands and support incidents. In response, they demand internal customers wait for the COE. The last thing an agile organisation wants to do is wait for anything. I hear about this issue several times a month.

Anti-pattern 2: Wrong Scope

In “Reaching Cloud Velocity,” Jonathan Allen and Thomas Blood articulate the reasons for having a COE, advice that is so often ignored. What starts off in good faith as a group whose sole purpose is to develop the foundational elements and guardrails for cloud usage slowly grows to take on more and more duties. Aspects best left to product teams are claimed by the COE, as is new scope, which by rights should sit closer to the customer in the Lines of Business (LOBs). I am a proponent of appropriate standards and standardisation which enables an entire organisation, not to justify the existence of the COE. The COE establishing a single sign-on process that product teams can integrate with via an API or defining resource tagging standards makes sense; building business functionality or inserting the COE into a gatekeeper-cum-auditor role, less so. Yes, some duplication may occur as a consequence. But in organisations such as Amazon Web Services, this is seen as preferable to slowing down delivery teams, and something that self-corrects over time.

Anti-pattern 3: Wrong Decision-Makers

I empathise with leaders who, shortly after joining a company, find out that what they were told about decision-making in their interview was disconnected from reality. I’ve seen leaders told that decisions are centrally made only to find out that the LOBs disregard this direction or vice versa. Rather than accepting how the organisation actually operates or being prepared to tackle this as a culture change, leaders have been known to use the establishment of a COE to reflect their aspirations of, say, centralisation, or to lay claim to a new initiative, rather than having it work within the existing culture. They are then surprised when friction develops with the LOBs when deep collaboration is required. The COE slips from being an enabling function to attempting to become the decision-maker, disempowering and antagonising the very people it is meant to be helping. Delusions of speed through ownership quickly unravel.

Anti-pattern 4: Wrong Team Composition

It’s easy to unwittingly establish a COE with a particularly functional bias. If the infrastructure leader establishes it, it might be heavy on infrastructure skills and mindset, lacking empathy for the app dev team. If a data COE is established by the technology leader, it might be light on a business perspective. These biases tend to then have implications for the work the team commissions. The infrastructure-centric COE might prioritise building (important) environment automation scripts for their internal use over API standards that would give app teams more autonomy and speed. The technology-centric data team might prioritise the technology platform and tools over driving data insights into action. In both cases, the COE staff members have narrow skillsets and lack the diversity of thought necessary to develop a lasting transformation.

A related anti-pattern is staffing the COEs based solely on technical competencies rather than including skills such as the ability to evangelise, influence, and teach. These “soft skills” are necessary for disrupting behaviours and fostering new habits across your organisation. A transformation is an opportunity to wow and empower your customers with new capabilities, not a time for hunkering down with an us-versus-them mentality.

Building a More Effective COE

How can you deliberately approach building a COE to be more effective? First, have an open dialogue with all those impacted by the COE. The COE is in service to other teams, not a gatekeeper. By building a partnership and open communication lines early on, trust can be established and course corrections made as the COE evolves. We established a practice of creating virtual teams at McDonald’s over 15 years. These teams brought together individuals from the LOBs and corporate centre across disciplines including application development, security, and infrastructure on regular basis. Part of the discussion with the team was on how the COE was performing and what changes needed to be made. The COE is a living organisation, the form and function of which will likely change over time and might even not be required at some point of maturity.

Secondly, look at embedding some or all of the COE close to their customers. The natural urge is to have “your team” sit in one place: your office. I am more used to a virtual model. While coordination becomes more challenging, it offers several advantages including faster internal customer feedback, the ability to tap into a wider range of resources, and career path options for LOB employees. It is also a forcing function, removing impediments to educate your end customers and reducing the navel-gazing that can afflict teams working in isolation.

Look at the metrics the team is judged on too. Whilst so simple, there is a reason that metrics that matter are a core part of a digital transformation. I’ve seen what happens if a central team is measured purely on building tech: more and more is built, but the use of the technology is only an afterthought or assumed to be someone else’s responsibility. Your metric could be how many other teams are enabled with self-sufficiency through the COE’s work, the number of times the COE is on the critical path for initiatives, the number of education events held, or the breadth of adoption of the COE’s output.

Finally, be honest with yourself about where decision-making power resides in your company today. A well-constructed, trusted COE can be a stepping stone to a larger organisational transformation built on trust, not a blunt instrument of change. Recognising this and making considered changes over time works, but forcing your worldview on others, well, we know how the story normally ends.

In my next post, I’ll illustrate how to apply these principles to help fuel the use of data in a business.

—Phil
Twitter | LinkedIn | Blogs | Email

More on this topic

Challenging Conventional Wisdom about How to Build a Cloud Center of Excellence, Phil Potloff

Embracing Organisational Tensions: The Balance of Power in Multi-national Companies, Phil Le-Brun

Using a Cloud Center of Excellence (CCOE) to Transform the Enterprise, Mark Schwartz