The CoE should be a value driver in the organization, and not an impediment to teams’ progress. In other words, teams shouldn’t be forced to work with a CoE, but rather choose to do so because the CoE makes their lives easier (e.g. by providing reusable tools such as standard accelerators, or off-the-shelf components like libraries).
One of the biggest barriers to overcome is the notion that an automation CoE is an “ivory tower” and doesn’t generate value to the organization. As a result, it’s important to set out quantifiable key performance indicators (KPIs) as a CoE, and measure them frequently to demonstrate success.
Some may perceive that the CoE is detached from automation teams’ day-to-day reality.
A related risk is the idea that CoEs are the “governance police.” That dynamic may happen if the guidelines are too strict and don’t take into account the real challenges developers experience on the ground. As a result, developers may hesitate to cooperate with a CoE, especially if they’re used to working with small, agile, iterative implementations.
Other risks may come from laying the groundwork improperly. Without authority or executive buy-in, many CoEs fail. Alignment and goal-setting should apply to both business and technical stakeholders. What’s more, a CoE should be scaled to the resources you have. Instead of taking on overly ambitious goals, adapt your CoE’s vision and approach by starting small.