Communities of Practice and Centres of Excellence

This article is part of our randomised, post-structural Let’s Build a Bank series of articles.

“It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do”

Steve Jobs

This article addresses how to manage skills development in any organisation, but in particular within the Service Aligned organisation.  It expands on the theme of devolving decision rights and control to expert groups, covered in Case Managed and Core Standardised Capabilities.

Building any kind of business requires people with skills, and guidance for them on how to apply those skills.  Organisations have traditionally arranged themselves along functional lines, with people sharing skills in the same organisational unit or units.  However, as organisations grow, this model breaks, with pockets of skills forming in parallel functions across different areas of the organisation.  Banks have multiple teams supporting lending, doing process mapping, building technology, etc. and often these teams aren’t in communication with each other.  Assumptions about common practice lead to fragmentation with teams thinking they’re following a standard, but actually operating quite differently.  The people who really know their stuff aren’t listened to, not used effectively and become frustrated and disenfranchised because they’re being told to follow standards designed by someone else who doesn’t understand their customer and their day to day experience of delivering value in the business.  And of course, in the service aligned organisation, people are even more distributed, as the very essence of multi-skilled teams includes having a limited number of people with any given skillset in any one team.

In the service aligned organisation, we also break the traditional model of a leader managing and mentoring people within their own skill/experience domain.  Not only are the holders of lead roles not usually responsible for line management of their teams, their domain expertise may also be very far removed from the skillset of many or most of the people working in their unit.  So not only do they not have official responsibility for developing their people, they will probably be unable to do so from a skills perspective.  Clearly, this risks people with specialist skills or knowledge becoming isolated and their skills being diverted and not following common practices.  Service alignment also presents the challenge of people developing new skills and taking on new roles, where they will primarily pick up skills from team colleagues, but also need to keep abreast of developments in the area, and separate learned behaviours which are supportive of common practice from those idiosyncratic to individual role holders.  It is also likely that all people with roles involving a particular skillset will need to develop those skills and surpass previous practices, as industry best practice evolves.

Even in traditionally aligned organisations, all people with common skillsets benefit from learning from each other – both within and outside the organisation.  There are also clear benefits for people with common skillsets to pool methods and frameworks; the experience they deliver will be consistent, regardless of where they sit in the organisation, and of course they can benefit from sharing ideas, effort and learnings.  The traditional approach is to offer training in skills, which is a legitimate way to develop skillsets, but still risks leaving people isolated and unable to compare problems and develop solutions with others with similar sills.

Of the three leadership domains in the service aligned organisation, communities of practice are the easiest to design, largely because they fill a gap and people are keen to participate!  But they still need a kickstart, and this article describes how to build such communities.

There is also a sliding scale between Communities of Practice and Centres of Excellence; the one being more informal and self-evolving, while Centres of Excellence equate to Capabilities and tend to be more formally structured, with allocation of tasks being controlled within the community.  This article also discusses how to build CoEs, and the benefits of each type of model.

What is a Community of Practice?

Loosely defined, a Community of Practice is a group of people with the same skillset and tasks within the bank.  So your sales people would have one, while the risk people who sit in their teams would belong to a distinct community, even though they sit in the same capability supporting Lending in their day to day work.  CoPs and Centres of Excellence are both arranged by skill, rather than purpose, although a Centre of Excellence is likely to equate to a purpose and therefore a Capability within your business model.  A CoP would also include people at all levels of skill development, from the most senior to the most junior, the critical thing being the sharing of common skillsets, so it may include people with a variety of different roles, but who are either progressing along, or dipping into, a common skills development trajectory.  In Service Aligned organisations you would find more Communities of Practice supporting the Case Managed capabilities, with Centres of Excellence concentrated in Core Standardised capabilities, while in traditional organisations, Centres of Excellence are able to leverage scale and consistency to support delivery of services across the organisation.

At the more informal end of the scale, a loose Community of Practice would usually include common frameworks, a charter and knowledge sharing.  At the other end of the scale, a Centre of Excellence will also include formal career paths, a common plan, workforce management and a strategy.  In practice, most CoPs will fall somewhere in between these two extremes, with the level of centralisation and formal control depending on the type of capability and the need for centralisation.  So for example, your Infrastructure Build team is very likely to be arranged as a Centre of Excellence, with the team co-located and controlled centrally, with some individuals being allocated to projects or Case Managed teams as needed but running under a single plan, largely supporting a Core Standardised capability building hardware.  Your sales people, at the other end of the scale, will look to their community to support their skills development and tooling, but will be formally aligned to their Case Managed capabilities and their local teams for day to day work allocation.  As we’ve said elsewhere, this isn’t completely straightforward and governance will need to be both designed and constantly reviewed for effectiveness.  Conflicts, of which there will be some, need to be managed via formal governance meetings.

So why is this useful?  I like the often quoted Steve Jobs soundbite at the top of the article on this.  You’ve hired a load of people for their skills and experience, then you get some external or internal function to design how they use those skills, often at great cost, and at the same time seed disenfranchisement and frustration in the teams on the ground.  This is an elegant solution to both the cost and the enfranchisement challenge, while at the same time using the embedded knowledge in the organisation most effectively.  That’s not to say CoPs won’t use external help – they may decide they need training, or support to build frameworks, which they either haven’t got the knowledge or the bandwidth to develop internally, and that’s fine, plus they will be more accepting of any resulting framework or training programme because it’s something they’ve initiated.

Benefits of Communities of Practice include:

• Common standards developed by the experts – i.e. the people you hired because of their knowledge
• Cross-fertilisation of knowledge within the team
• Development of toolsets, approaches and frameworks by people who really understand how your organisation works
• Feeling of belonging and value within the community, addressing potential isolation issues
• Agreement on how “things should be done around here” by the people who do them and ownership of standards, tools and methods
• Mentoring and support for community members by people who can understand the challenges they are facing
• Links to related CoPs
• Significantly reduced reliance on HR and centralised functions to support training and personal growth

So isn’t this all a bit touchy-feely for a bank?

Actually, no.  Communities of Practice give your bank concrete and very measurable benefits.  Critically, they are a pivotal part of supporting your governance building, which is important in traditional organisations but absolutely fundamental to Service Aligned organisations.  They become the glue between individual teams aligned to particular services and the underlying standards they need to adopt and support.

If we think about banks as opposed to franchises, we have some unusual, but not unique challenges.  Our organisations are big, and federated, and different standards naturally evolve within the teams supporting the user experience and configuring it at the point of customer delivery.  This may be ok for an organisation supporting, say, community nursing.  After all, in these small, self-organising teams, the only important customer experience is that delivered one to one by the nurse in question, and the configuration of capabilities by that individual nurse is the only important customer experience that customer will have.  So variability is not only desirable, it’s completely practical.

Something we’ve seen from the more ecosystem based organisational strategies, while many are excellent at addressing the “how teams work” aspect, is that many either don’t formally address, or don’t need to address, the consistency question; a large corporation can adopt and benefit from consistent practices across the communities, whereas self-organising teams generally don’t where teams are closely aligned to a consistent customer base.  They use training and knowledge sharing, which is positive, but there’s an underlying assumption that self-organising teams will have the right skillsets and knowledge, or buy them from somewhere else, and that some variability of customer experience between customer sets is acceptable and probably desirable.

While this is certainly true for professional skills such as nursing and architecture, there is also a need to align more closely within larger organisations, not just to provide consistent customer experiences, but also, in many cases more importantly, consistent employee experiences.  This is especially true of banks, where customers are likely not to have a single relationship manager dealing with all of their needs, but in reality interface via a lot of different channels, with teams of people (or things that act like people).  Their relationship needs to be consistent on all of these channels, to create a seamless experience, and they may be interacting with a bot via online channels, switching to specialist humans for additional needs or specialist services, in the course of a single encounter.

Not only are our paying customers experiencing multiple instances of our organisation in terms of brand and product, via many different delivery points – channels, branches, business centres.  Our regulators and consumer protection bodies, payments schemes and governments are also expecting common standards, while the increasing need for collaboration with Fintechs and competitors will also mean we need to be reaching across the boundaries more.  So it’s not simple, and we should assume there will be a need both to develop common standards internally and to communicate and collaborate with these standards across industry and consumer bodies.

Internally, the need for consistency is also significant in teams coordinating all your core standardised activities, but also in more federated teams, such as programme delivery teams, who will again be interfacing with the same internal “customers”, whether receiving organisation teams or supporting teams such as technology delivery.  In this case, the consistency of approach reduces risk and the need to learn repeatedly.  The same also applies to any internal support capability which is federated to best leverage multi-skilled teams, and be close to the customer.

Communities of Practice can also play an important role in allocating resources to Case Managed capabilities – and, in some cases, supporting Core Standardised capabilities with either long-term or short-term specialist support.  In mature organisations with established case management or Agile delivery and strong CoPs, they will have formal role allocation responsibilities, whereas in more traditional organisations they are more likely to have more of an advisory role.  As repositories of accumulated knowledge and skills development, it’s important that they are represented within decision making bodies, and you should therefore ensure the lead roles are allocated accordingly.

Building a Community of Practice

As we’ve said above, building a CoP is pretty easy in most organisations because in most cases, the professionals in your organisation are crying out to learn and share experiences with other people with similar skillsets, and they’re very keen to use their knowledge to support building the things that will make your CoPs coherent, collaborative and useful.  In this section we give some guidance in how to go about setting one up, but obviously you’ll have many across the organisation.  If your organisation is new or relatively new to this, it’s a good idea to divide and conquer: start with the communities that are most open, are already self-organising to some extent, or are a priority for business reasons.  Don’t expect everyone to buy into it at first, use PoCs to demonstrate the benefits before asking everyone else to sign up.  And be realistic; this stuff takes time and resources, and will take people “out” of their day jobs – although those jobs and functions will benefit, it’s always going to be a conflict until they see the benefits.

Identify the Capabilities/Communities you want to build

Some of the communities will be aligned to your high level capability map, but most of them will be buried in the services and capabilities you’re developing at a macro level – as mentioned above, you’ll have people from many disciplines in a single capability.  This presents a prioritisation challenge, because you won’t be able to fix “lending” by building a couple of Communities of Practice.

A simple way to approach this is to start with your capability map at a second or third level of granularity, and ask the question, What do these people do?  Communities of Practice can be seen as analogous to traditional skills-based career paths, and you can usually group the roles you’ve identified to support the capabilities into skills-based groups.  Once you’ve identified your list, you can then start grouping them and prioritising them.  How granular the groups are is up to you, and on the whole, level 3 capabilities are a pretty good place to start. There’s no hard and fast rule, and as the communities work, you’ll learn what does and doesn’t make sense.

Each community then needs a lead role.  Like other capabilities, you have two key lead roles – one is responsible for allocating the work, and the other is responsible for representing the community to the wider organisation.  However, in the case of Communities of Practice, these two things are so closely meshed that it usually makes sense for this to be the same person, but of course you can allocate it however you like.  Importantly, while there are formal and informal development roles within the CoP, there is no management involved, and this is one of the key differences between CoPs and Centres of Excellence.  The Lead will allocate colleagues to teams or programmes, based on prioritisation amongst the CoP, but the direct management of day to day tasks will be done by the team (usually a Case Managed team) to which that resource is allocated; unlike Case Managed capabilities and Centres of Excellence, task allocation within CoPs is long term rather than day to day.

Normally, one or more obvious candidates will emerge, but in some cases, especially where a capability is immature, that may be a hard call.  Sometimes you will need to ask someone to take more than one lead role across multiple capabilities, and that’s ok, as long as it fits in with their other roles.  Once you’ve identified the groupings and the leads, the order in which you address them should emerge organically, but if not, get together a team of key stakeholders and capability owners to decide what gets tackled first.

Let’s look at a real example from a programme delivery team, within the overall capability Transformation Management:

As we can see from this example, there is potential for Communities of Practice either at the big box level or at the small box level – you could also organise the same small boxes into a variety of different big boxes, for example grouping Business Architecture under Business Change and IT Architecture under IT Change.  How you do this is up to the organisation and what suits it best.  In turn, each of the smaller boxes represents a collection of roles, which may be quite different, so it may also make sense to break down your communities further.  A lot of this depends on how large your teams are and what will work for the communities, but a good rule of thumb is to keep people who understand each other’s’ roles pretty well together, and start separating into more granular communities when they can’t understand the basics.  In the above example, which is a change community within a medium sized universal bank, we have communities for the big boxes and not for the smaller boxes, for a team of about 600 people.  If your team size were greater, it would make sense to break them down further.  As you can also see from this example, in some cases there are similar skillsets within multiple communities, and again these will develop formal or informal interaction and governance and eventually, their own communities.

Doesn’t this make things incredibly complicated?

It depends what you mean by complicated. Overlaid on a traditional, pyramid shaped organisation structure, it would look complicated on the surface.  One of the key advantages of these communities, however, is that they both remove the need for line manager based skills development and, by direct inference, for the same focus on line management we usually have in traditional structures.  We think that, together with the service aligned capability structure, this is the key to significantly reducing hierarchies from large organisations.  And holocratic organisations are more complex than traditional organisations when you look at the formal governance structure, the composition of teams, and the communication interaction – largely because these are more clearly articulated and expressed than in hierarchical organisations, where a lot of these things are left to chance or taken for granted.  What’s simpler, is that you can achieve it with fewer layers, fewer people and fewer central functions.  And of course, because of the self-organising element, you don’t need to design the whole organisation in detail, as you would in a traditional hierarchy, because the teams design their own governance, roles and communication networks.

In this case, the programmes were initially fragmented and needed some consistency fast.  There were also some key risks related to environments and bottlenecks in the receiving organisation, so the priority capabilities identified were Testing and Release Management.  There was already some CoP work going on in the Business Change community, which was relatively immature in terms of numbers and skills, so this was also designated a priority given the need for greater maturity.  An owner was identified for each capability, with the underlying assumption that as the community developed, the lead role would probably emerge from within the community and take over from the original owner.  The owner of each community was also formally included into governance meetings as a spokesperson for that capability.  We’ll return to this example later, when we address the sliding scale question.

Mobilising the Community

Identifying community members is usually not that straightforward in fragmented organisations.  If you already have a clearly defined set of roles on a centralised database, that’s great, but our experience is that the CoP is one of the key contributors to building those roles in the first place, so you’re usually in a situation where there’s a bit of an information blackspot.  Your best approach is to ask people – leaders, information gatekeepers, etc, and accept that you’ll inevitably miss some key people to start with.  But, as with everything else Service Aligned, started is better than not started.  Once you get the ball rolling, community members will self-identify and then that piece of your work is done.

We find it’s better to start with a bit of a top-down approach based on your target architecture; a set of objectives, key deliverables and boundaries to the community, so that you can align it to the overall architecture of the organisation.  Beyond that, and with some guidance and support, you can leave it up to the teams to design their outputs, domains, decision rights and deliverables.  Key things each CoP needs are:

• A Charter describing their overarching governance (weak, strong or in between), key services, roles, approaches, frameworks, career development approaches, strategy approach, governance and communication interaction with other groups
• Governance for their services related to your Capabilities – this is usually primarily concerned with allocation of individuals to teams, and application of tools and methods within the wider organisation by your community and their extended communities/skills networks

• Core frameworks and methods, together with what can be achieved internally and what needs to be bought in
• Role descriptions including accountability, domains and decision rights
• Skills development approaches – in the form of career paths for traditional organisations, but more modular for service aligned organisations, together with what can be achieved internally and what needs to be bought in; most communities will also have extension communities of “minor” skills composed of people with some responsibilities, but not necessarily deep knowledge, in the area.  Involving them both supports consistency of how the frameworks are applied, and develops a talent pool in the wider organisation
• Communication governance
• Schedule and agenda for community meetings – these should include sections on community development, new member introduction, changes to the governance framework, then specific development topics such as tools and topic frameworks.  NB in full holocracy you would have dedicated governance meetings, and this may be necessary depending on the size and complexity of the organisation, but don’t over-engineer it if the need doesn’t emerge.

Once these key deliverables have been agreed with the initial community, you then need to give the team space to develop them.  This may sound obvious, but fitting community meetings and development activities into the working day isn’t straightforward – it may involve moving people around, incurring travel costs, and it will certainly take them away from their day to day work for periods of time.  You need to be clear and specific that the benefits of doing this are worth the investment of time and resources.

Facilitation

Building communities in organisations that haven’t had previous experience of this approach can be challenging for team members, so it’s a good idea to engage professional facilitators or coaches to support the initial efforts, until the communities are comfortable to self-manage.  Or you may have some internally developed facilitators or coaches who you can be taught these techniques, if they aren’t already familiar with them.  Once your first few communities are kicked off, you can start to identify the resources who will successfully transition to being your internal coaching strength, and they will naturally gravitate towards this role – sometimes to the cost of the communities from which they developed!  However it’s obviously desirable for your community coaches to be drawn from within your organisation, so they can communicate the way your organisation does things and its unique culture as part of building the communities.

Roadmap to a Community of Practice

It’s up to you to decide what works best for your organisation, but the usual sequence of events we’ve found effective is:

1. Identify the key resources (as we’ve said above, don’t wait until you’ve found them all)
2. Get them together and outline the guidance for building a community.  Give them space to discuss how it could work for them and what they want to get out of it.
3. Help the team to identify lead roles and someone to take them if you haven’t already identified someone
4. Run a facilitated outside-in Service Design workshop to decide what the Community is trying to achieve
5. Collect existing collateral and artefacts, and identify any gaps; prioritise how the Community will fill those gaps
6. Allow the Community to self-manage, creating roadmaps for tools and methods alongside developing its own role descriptions, mentoring, learnings, and governance
7. Support the Community in ensuring that other related groups are included in their governance ecosystem
8. Build the Community’s governance into relevant regular governance meetings and leadership teams

Remember, there’s no such thing as Done, but when you can walk away / ask the facilitators or coaches to move on to the next team, you’ve done your bit.

What can go wrong?

While most CoPs kick off pretty well as self-organising teams, priorities and politics can intervene and derail the process.  You will know if it’s not effective when you see that deliverables aren’t emerging, but root causes can be:

• Poor CoP structure – your community isn’t composed of people with sufficiently similar skillsets, so they can’t learn from each other and can’t agree on charters/strategies because they haven’t got enough common needs
• Factionalism – your team members are being driven to align with their BAU teams and roles aren’t clearly aligned with the community’s goals – while it’s good and healthy for the community members to align with their BAU teams, they will miss the opportunity to learn from the community and to take those learnings back to their teams if this happens.  Asking them to involve additional team members in the community can help with this
• Ground rules not respected – see Holocracy for this topic, but if your communities become mini-empires, with power struggles and factionalism, they will not be effective

Our overwhelming experience is that, while CoPs are usually far from perfect, they inject a strong element of common purpose and common sense into the community.  A key message is that, even if it doesn’t seem to be working, it IS working!  The simple fact that people doing the same things in different parts of your organisation are now talking to each other, where they weren’t before, is great, but if they can also self-organise to develop these artefacts, they’ve come a long way along the development journey and helped you fix your customer experience without resorting to external help.  They will start to recognise more industry standards, learn from other organisations, and inject more benefit to your organisation.

Centres of Excellence

At the other end of the community scale, a Centre of Excellence is a formally organised community of people with the same skillset, who probably also fulfil the skills element of a single Capability.  CoEs don’t exist in truly Agile organisations, but they do exist in service aligned organisations and in banks, where elements like hardware and data centres still present the challenges of physical centralisation and interface with the wider business, and other activities such as Customer Due Diligence processing may still involve large teams processing information with predictable inputs and outputs.  A Centre of Excellence is effectively analogous to a Core Standardised capability.  There may be many good reasons for organisations to manage their own Centres of Excellence rather than buying in services, however you should also consider whether it is more effective to outsource or buy in these services, rather than investing in the infrastructure and organisation to support them internally, if they’re not key differentiators for your business model.

The key differentiators by which you would recognise a Centre of Excellence as opposed to a Community of Practice are:

• Composed of people with a narrow range of skills supporting a single Purpose of your organisation, rather than contributing to a composite purpose supported by multiple skillsets
• Usually arranged in the traditional skills-aligned way under one “roof”, either virtually or physically
• Manages skills development within the capability
• Leaders usually responsible for both skills development and for work allocation
• Procedures are streamlined and very standardised, with little variation

However, in common with Case Managed capabilities, these teams are still largely self-organising and self-developing and, like Communities of Practice, will have significant autonomy in prioritisation of work, development of skillsets and allocation of tasks within the teams.  NB in Service Aligned organisations, you will almost always have a thin service layer overlaying large Centres of Excellence (see Case Managed and Core Standardised) but for the sake of argument we’ll treat the whole unit as a single entity.

Community of Practice or Centre of Excellence?

The major differences between CoPs and CoEs are listed below.  In essence, if you’re working in a Case Managed capability, you probably belong to a CoP as well.  If you’re working in a Core Standardised capability, your home capability is also your CoE.

However, as we’ve said, it’s not usually that straightforward, in the same way that the Case Managed/Core Standardised model isn’t really that pure – albeit a very good guide.  Capabilities and Communities will operate best under different levels of autonomy and management, depending on what they’re for, how big they are, and the level of central interaction that best fits their purpose.  To return to the Programme Management example above, we have some obvious elements that fit neatly into Core Standardised:

• Environments Management
• Reporting
• RAID Management
• Financial Control

Where you would expect centralised or federated units, effectively doing one thing (each); others that are clearly Case Managed/Agile:

• Planning
• Business Requirements/Business Change
• IT Solutions Development

where you would need CoPs to support the individual skillsets, such as Business Analysis, Project Management, Solution Development, Process Modelling, Development Skills, Unit Testing, etc etc; while others still have elements both of Centres of Excellence and of CoPs:

• Business Architecture: will be heavily centralised in planning, but syndicated into Agile teams to support development
• Deployment: again (in this case) heavily centralised in planning and execution, but seeded into the individual projects and programmes to support the release managers in detail

And as you work through your organisation, just like with the Case Managed/Core Standardised model, you will find that it’s not as simple as putting every area into one bucket; it’s also worth noting that the model that works for you today, is likely to evolve and change, so as with Case Managed/Core Standardised, you should ensure your governance supports regular reviews and the ability to flex over time to support changing customer needs.

Conclusion

In this article we’ve described what a Community of Practice is, the benefits of building them and why they’re important not just in a Service Aligned organisation, but in any large organisation.  We’ve described some steps for establishing Communities of Practice and how to deal with the challenges of prioritisation and some practical tips – although we can’t stress enough that how you attack this should be up to you!  We’ve provided some ground rules to follow:

• Give the communities autonomy to self-learn and self-manage; you’re not so constrained in Communities of Practice as you are in your broader Operating Model, as they effectively form a shadow organisation.  Give them the tools and structure to start up, and they’ll manage themselves
• Ensure formal governance is established, just like in your Capabilities.  Be clear what the roles are and who’s accountable for what
• Use them for their subject matter expertise and their ability to learn and generate ideas!  You can save a lot on consultancies with these guys
• Use them to build skills, mentor each other and design career paths.  This will remove the need for a lot of the HR training you do and some of the more challenging aspects of line management.

We’ve also presented the outlines of a Centre of Excellence and how this differs from a Community of Practice; together with the Case Managed/Core Standardised capabilities, these four concepts form the heart of the organisational construct in the Service Aligned organisation.

We’ve briefly described a real example in a bank of how this has been built for a support function, and illustrated how the lines are blurred and there is a sliding scale between CoPs and CoEs, and that the governance structure needs to be carefully designed to manage this effectively.