Setting up a Community of Practice – how and why you should do it

Does your business operate Communities of Practice? At Equal Experts we believe a Community of Practice isn’t just a ‘nice-to-do’ – it is an important part of building and maintaining a strong network.

As business recovers from the Covid-19 pandemic, and with remote-first working practices increasingly common, there’s never been a better time to re-establish our CoPs. In this post we use the example of setting up a Community of Practice for our Delivery Lead profession, and showcase a Community of Practice model you might like to use in your own organisation. 

“One of the most effective ways of creating communities at scale is to introduce Community of Practice throughout a large network.” Werner Smit – Equal Experts Delivery Lead, South Africa

Creating a Community of Practice model for your business

First of all, it’s important to create a Community of Practice model that reflects the structure of your business. Within Equal Experts, a Community of Practice (CoP) is related to a specific discipline e.g. Delivery Leads, Business Analysts, etc. Each CoP has an identified group of leads that head it up, and is focused on addressing the following two areas for their community:

  1. Ensuring that we are actively engaging with people in the network, sharing knowledge of what works between different engagements, and giving people a place to share ideas and stories and ask for support from their peers.
  2. Defining and maintaining hiring standards to ensure that people are brought into the network with the right skills in a consistent, timely fashion that is fair to the candidates, well understood by the interviewers and makes referrals easy.

Next, you’ll want to determine the priorities for your CoPs, and how those relate to the goals of your organisation. For example, at Equal Experts our Delivery Lead network has grown dramatically over the last couple of years, on a global scale. We were concerned to make sure that tribal knowledge didn’t get lost in that process, and that we continued to facilitate the sharing of expertise at scale. 

Next comes organisational culture – an essential consideration of any business. Remote-working necessitated by lockdowns had meant fewer opportunities for in-person experience of our cultural values, so we wanted our CoPs to mitigate this by supporting the onboarding of new network members, to ensure they could get under the skin of our culture quickly.   

We also wanted our CoPs to work closely with our people team, to ensure that our recruitment processes evolved to reflect inevitable changes in working practices, and resulted in more consistently successful Delivery Lead recruitment. 

Setting up a Community of Practice for Delivery Leads

We set up our Delivery Leads CoP first, to establish best practice ahead of a potential CoP relaunch for all the disciplines within Equal Experts. We put together a small team of Delivery Lead practitioners and members of our recruitment team who’d worked closely with the Delivery Lead population, to create the following mission statement for our work: 

Make Equal Experts the best place for Delivery Leads to practice their craft and increase the sense of belonging.

Next, we listed our desired outcomes: 

  • Remind people of the power and benefits of the network and help them navigate it
  • Establish a frictionless recruitment process 
  • Increase sense of belonging
  • Make Equal Experts the best place for Delivery Leads to practice 

 Finally, we determined our areas of focus for the Delivery Lead CoP. This included defining what good looks like for a Delivery Lead in Equal Experts, measuring the current health of the network, enhancing our interview and recruitment procedures, and setting up community events such as  co-working days to strengthen the community. These are some of the processes we used to ensure our Delivery Lead CoP had strong foundations: 

What does good look like (WDGLL)? To determine this starting point, we gathered a small working group of Delivery Leads, as well as people who use Delivery Lead services, using multiple approaches including workshops, 1-2-1 interviews, surveys and asynchronous workshops over slack to gain feedback. From this input, we defined the skillset, behaviours and attributes of what we believe makes an excellent Delivery Lead. 

Measuring current health: We commissioned a number of surveys aimed at Delivery Leads within our network, and analysed the results to help us identify the biggest opportunities for improvement in our practices. 

Frictionless recruitment: We reviewed our existing recruitment processes once we knew what good looked like, to check if they matched. Where we used these findings to inform our new job descriptions, and our interviewing and onboarding procedures. As a result of these changes we’ve seen significant improvements in both the quantity and quality of our recent Delivery Lead appointments. We’ve also had extremely positive feedback from interviewers, with 75% preferring the new procedures, as well as an increase in referrals from our existing Delivery Lead community. 

Strengthening the Delivery Lead community: We’ve re-established co-working days and other networking opportunities for our Delivery Leads and associated people teams, and relaunched our buddy system, with the result that communication channels have become more active We’ve also seen some excellent cross-functional movement, with conversions from other disciplines to Delivery Lead roles. 

Community of Practice ways of working

As a foundation to the relaunch of our CoPs we felt that the following principles and ways of working were essential: 

  • Treat the CoP as a continual service, not just a one-off piece of work 
  • Incorporate our people team in the CoP, so we build stronger relationships, build empathy, and create a common purpose
  • Maximise visibility and accountability in all our work 
  • Establish measurable outcomes for all work
  • A piece of work is not completed until the whole community has accepted it

We continually look for ways to support Delivery Leads from both a practical and pastoral perspective. We crowdsource ideas from the Delivery Lead community, and currently have some very exciting initiatives to consider. This will now be an ongoing process to replicate a healthy Community of Practice for other business units across our business. 

What do you think? Could your business benefit from setting up a Community of Practice? Share this article with anyone you think might find it useful.

Here’s another in a series about transitioning from being a QA to becoming a delivery lead. The hope is that people who are considering becoming a delivery lead use these posts to make a more informed choice – by identifying the skills required to make the transition, and highlighting the similarities in the two roles.

Today I am interviewing Karunakar Thedla​.

“I always tried not to constrain myself to my role and responsibilities. I tried to contribute beyond my role.” Karunakar Thedla​ 

What inspired you to make the move from a QA to a delivery lead?

I spent a major part of my professional life working as a QA. I wore multiple hats as QA, BA and iteration manager, always working closely with my team members and project stakeholders. Working for the betterment of the project/process/product was always at the forefront of everything I did. Despite that, I always looked for additional challenges and stepped up to help the team and business owners in any shape or form. Then I realised that there is only so much I could do on top of my day job, and the drive to have a much bigger influence made me switch to the delivery lead path. It gave me immense pleasure to use all my technical skills to contribute to every discipline in the software engineering process.

What are the key skills you have gained as a QA that have helped you as a delivery lead?

As a QA, I had a good understanding of the end-to-end development process along with a deeper technical knowledge of software engineering practices. I gained this by working closely with various disciplines e.g. architects, developers, UX/design, user research, and product/business owners. This helped me a lot as a delivery lead and the benefits are many. It helped me plan the project delivery better and achieve a shorter time to market whilst focusing on user needs and business goals.

I was also able to challenge and help development teams where necessary. I once worked with a third-party supplier development team who were building APIs for the client team. To our surprise, a simple API call was taking a few seconds to return data. They said they did everything they could but were unable to improve the performance and blamed the volume of the data. I asked them to check if the indices were added to MongoDB. This simple suggestion brought the response times down to a few milliseconds. I didn’t have to be an excellent developer but was able to understand the problem and help!

The technical knowledge also enabled me to help the business better understand the challenges faced by the development team and the complexities involved in delivering software. This is a particularly important skill to have when dealing with demanding clients who have set project targets.

What do you see as the major differences between the two roles?

I think that both roles have an overlapping wish list, i.e., customer satisfaction, quality of product, and better ways of working. However, I need to understand and respect what is expected of my role. For example, the QA in me wants an enhancement to a feature which adds a better user experience and might seem simple to build. But the delivery lead in me needs to manage expectations in terms of timelines so might have to be strict with scope. So, I try to remind myself of the role I play and make the right decisions. At the end of the day, making the client and users happy is key to whatever role I play!

Any advice for prospective delivery leads out there?

I always tried not to constrain myself to my role and responsibilities. I tried to contribute beyond my role. As a QA, I created user stories, wrote production code, set up CI pipelines, ran workshops, and held show and tells. I made a sincere effort to pair with my delivery leads, and along the way, I learned a lot. This helped me to understand the ups and downs associated with every role and gave me a greater insight into different aspects of project delivery. I would say this is a great way to transition to any role.

Do you have any regrets about making the move?

I sometimes miss being hands-on. I miss the joy of testing a complex feature and finding that impossible-to-discover bug, but I compensate by trying to be hands-on wherever possible, be it pairing with a developer to write production code, or analysing a story for a BA. However, the fact that I have a much larger influence on everything now keeps me going!

Here’s another in a series about transitioning from being a QA to becoming a delivery lead. The hope is that people who are considering becoming a delivery lead use these blog posts to make a more informed choice – by identifying the skills required to make the transition, and highlighting the similarities in the two roles.

Today I am interviewing Bejul Shah.

What inspired you to make the move from a QA to a delivery lead role?

I have been a QA for over 15 years, eight of which have been with Equal Experts. I have particularly enjoyed roles where we were key influencers for the client’s digital transformation journey. I was part of the first UK team to help set up our South Africa business unit, where we  promoted a flat team structure with our first client there. Together with the QA tasks I was advising on plus shaping better ways of working to deliver at pace and being hands-on, I found it exciting to see visible improvements. This inspired me to work closely with the delivery leads, and eventually I transitioned into the role having passed the internal interview process. 

What are the key skills you have gained as a QA  that have helped you as a delivery lead?

There are several skills that have helped me as a delivery lead. The QA role requires an holistic approach to product thinking as well as team contribution. A key skill is the ability to build close relationships with stakeholders and team members. Contributing to the code for test automation and pipeline setup has helped a lot with being able to talk in the technical domain and make those connections. I try to be hands-on with the delivery lead role, helping the team whenever needed. This particularly helped recently when we lacked operability knowledge within the team. The focus on shifting testing left and minimising bottlenecks was a valuable experience in the challenges of efficient project delivery. 

What are the major differences between the two roles?

Both roles have a responsibility to keep a positive and good interaction within the team, however, with the delivery lead role, the importance is amplified. Ensuring that the team feels empowered, energised and engaged is key for successful project delivery. 

As a QA, I used to be aware of the intricate detail or quirks of a product. I now find myself asking my team QAs for this. At least the inquisitive and exploratory mindset of a QA has stuck with me. 

I have always tried to be proactive about continuously improving ways of working and how to be a better performing team. Now as a delivery lead I have a lot more focus on that and appreciate all the various enablers, processes and roles that results in a team being high performing.     

Any advice for prospective delivery leads out there?

If you are considering transitioning to the role, reach out to the delivery lead community or the recruitment team where you work. You will find a lot of encouragement and flexibility. In my case, I tried a 50/50 role split between QA and delivery lead that a client was in support of. This may not always be possible, but I found it a great insight into the delivery lead role which I was then able to move into 100%.

While you’re moving into a delivery role, you may initially focus more on improving QA processes within the team. Whilst this is important, it is good to be equally attentive of other areas that could be improved. Each role within the team has its challenges and understanding and addressing them will lead to a healthier team.

Do you have any regrets about making the move?

I do miss the technical aspect of the QA role, however, I do not regret making the move as I try to be hands-on and keep those technical skills up to date. Starting out as a QA means that you come into the delivery lead role with a great skill set that keeps getting broadened.  I thoroughly recommend it.

What exactly is a Delivery Lead, what do they do, and why is it different from other Delivery roles?

EE Product Manager Neha Datt asks colleagues Rebecca Stafford and Lyndsay Prewer to explain the nuances, and what kind of interpersonal skills you’ll need to be a Delivery Lead at Equal Experts.

They talk about the following to really give you a feel for the role:

  • How they work alongside others to mentor and share knowledge, so that they can walk away leaving customers enabled to sustain development without them. They call this #ResponsibleRedundancy. 
  • The challenges of the role, from managing multiple stakeholders’ expectations to balancing detail with the bigger picture
  • Tools of the trade a Delivery Lead can’t do without
  • What they love about the community of Equal Experts consultants.

Watch the video to see exactly why our Delivery Leads love their jobs:



If you’d like to learn more about the roles available within our network, check out Equal Experts’ LinkedIn page, or learn why you might like to join us on Glassdoor.

Following on from the moving from being a software engineer to data engineer blog series, I thought it would be useful to follow a similar pattern looking at how business analysts migrate to the role of delivery lead.

The hope is that people who are considering becoming a delivery lead to use these blog posts to make a more informed choice, by identifying the skills required to make the transition, and highlighting the similarities in the two roles.

Today I am interviewing Raz Rafiq.

What inspired you to make the move from a business analyst to a delivery lead?
Since I started contracting around seven years ago my roles have always been more hybrid BA/DL than DL alone. When working as a contractor you just chuck all the hats on! During this time, I realised that my skill set and way of working aligned more to the DL role in terms of process improvements and coaching.

I found I really enjoyed the flexibility of looking at a bigger and more holistic picture and helping a team to achieve their full potential. DLs I worked with in the past recognised this and advised me to go forward for the DL interview. Imposter syndrome kicked in, and as a result, I never went for it! More on that later…

I eventually decided to go for it though around 18months ago, and 9 months later landed my current position of DL at HMRC.

What key skills have you gained as a business analyst that has helped you as a delivery lead?
Key skills that I’ve built on from my life as a BA can be whittled down to the following categories:

People – the ability to connect with team members, understand their needs and help them grow, all while keeping an eye on team success.

Organisation – being able to absorb the big picture but then also break it down into its smaller parts to ensure we as a team can deliver on the expectation.

Diplomacy – as a BA you always have to meander difficult conversations with tact and skill. This is even more important as a DL with the extra layer of senior stakeholders.

What do you see as the major differences between the two roles?
The increase in the number of meetings you need to facilitate and attend. Although I have a feeling if you speak to my current team they would probably say I’m my own worst enemy on that front!

I’ve found that the key difference between the roles has been the leadership and direction that is now expected from me. As a BA, the team members often looked in my direction from a requirements perspective with regards to direction, this has now changed and is more in the sense of delivery.

Alongside this, I’ve found that as a DL I’ve learnt to become more confident in my decision making in ‘delivering the right thing’ – it’s not all on the shoulders of the DL as what we do is a team sport – but coupled with the expectation of servant leadership, sometimes I’ve found that means coming forward and making that decision with confidence.

Any advice for prospective delivery leads out there?
Don’t delay and apply today! I deferred my application for a while, partly due to imposter syndrome, and partly due to the right opportunity not presenting itself.

The great thing about making the transition here at EE is that a helpful and engaged community is never further away than a Slack channel. I’ve found that knowing this has given me confidence in sanity checking thoughts, keeping up with best practices, and also that feeling of belonging.

Also, worth noting that as a BA, you’re probably already well on your way in terms of skill set!

My only other key bit of advice is to assess the many opportunities available for you to transition and as there are many out there, pick the one that you feel is right for you in terms of making that transition.

Do you have any regrets about making the move?
Only one…not taking the plunge sooner!

Following on from the moving from being a software engineer to data engineer blog series, I thought it would be useful to follow a similar pattern looking at how business analysts migrate to the role of delivery lead.

The hope is that people who are considering becoming a delivery lead to use these blog posts to make a more informed choice, by identifying the skills required to make the transition, and highlighting the similarities in the two roles. 

Today I am interviewing Paul Cardiff.

What inspired you to make the move from a business analyst to a delivery lead?

I have been a business analyst for over fifteen years within both traditional, waterfall teams and within cross functional, collaborative agile teams. Throughout that time I have always taken on aspects of the project management/scrum master/delivery lead roles, whether that be covering for sickness, holidays or just supporting the team in achieving their goals. I have taken on the delivery lead role on a number of occasions, but always came back to the role of the BA. I suppose a catalyst to make the move more permanent was completing my MSc in Agile Leadership in 2020. Then early in 2021, whilst working as a BA within HMRC’s DPS platform team, there was a requirement for a new delivery lead. I had been covering aspects of that role for a while so I thought I would try and make the transition permanent. I successfully passed the delivery lead interview process, and so took on the opportunity to lead the CDS Platform team.

What are the key skills you have gained as a business analyst that has helped you as a delivery lead?

I believe that there are a number of skills that cross both roles, and it is utilising these skills that has helped with a smooth transition. A couple of key ones are:

  • Facilitation skills – a key skill of a good business analyst is being able to facilitate workshops and effectively draw out user needs or requirements and helping to encourage problem solving within a workshop or collaborative session. Utilising these skills has helped in facilitating our end of sprint retrospectives, and sprint planning sessions to ensure effective participation of the whole team.
  • Relationship building – a key strength of a BA is building relationships with both the team and stakeholders external to the team to try and create a shared vision of what is being built. I feel that as a delivery lead this is even more critical, as delivery, first and foremost, is about people. Encouraging collaboration, helping people to build relationships, and having those key conversations with all those involved.

What do you see as the major differences in the two roles?

The softer skills aspects take more of a front seat as a DL, with your focus shifting to the needs of the team, along with the needs of the project/product. You are now the person that the team comes to with their problems, and you have a responsibility to protect the team as well as removing any blockers that might be impacting delivery. Not only that but you are now responsible for ensuring you get the correct balance within the team, including identifying what skills shortage you may have, assisting with getting those skills in the team, and onboarding any new team members.

As I have a keen interest in agile and lean ways of working, as a BA I was always proactive in helping the team apply these principles.  However, since I have made the transition, encouraging continuous improvement and trying to improve the flow of work is always at the forefront of my mind.

Also, be prepared to be involved in a few more meetings

Any advice for prospective delivery leads out there?

I would say go for it. There are plenty of people in the network that have made the transition so speak to them to get their thoughts. 

From a personal perspective, I would say ‘remember you aren’t a BA anymore’. I have sometimes felt it difficult to leave that role behind, which can be a help but can also be a hindrance. When making the move it might be best to start fresh in a new team rather than making the transition in the same team, as you can start to be viewed with both hats on.

Most importantly, I would say always be there for the team to help support them and continually improve together.

Do you have any regrets about making the move?

There is a little more time commitment required but I don’t have any regrets in making the move as there are plenty of benefits in accepting a new challenge and expanding on your skillset.