There are a bunch of blog posts about building professional communities of practice. They’re often from people who help start the community. Or people that come in and support them for a period of time. I’ve not seen many that cover the history of a community over years.

I re-launched the Ministry Of Justice’s product management community of practice in 2016. It started with 10-12 people and, six-years later, it’s approaching 80 people. The same number of people have come and gone during that time. In 2021 I picked-up leadership across the user-centred, product and delivery professions, increasing my scope to 350+ people across 6 specialisms. Now’s a good time to reflect on what I’ve learned.

This is a post about what it’s like to lead the same community of practice for a long time. It’s the story of what happens as the people change, enthusiasm ebbs and flows and the community grows. Each section could be a post in its own right but I haven’t got the time or patience for that :) So here’s a single, whistle stop post about what it’s like to be six-years deep in a community of practice.

I’ve added a table of contents with links to specific sections so you can pick and choose what to read.

Contents

Prologue: The Spotify model (probably) won’t work for you

Part 1: Building a product management commmunity of practice

Part 2: Building a network of communities

Epilogue: the three things I’ve learned the hard way

Prologue

It’s ok to start with “the Spotify model” . . . and abandon it

I was hands-on in product management at the MOJ before I became Head of Product. I was responsible for a staff-facing product when I joined in 2015, our ‘Cloud Platform’ for running and changing software. This took (and still takes today) the form of a continuous integration setup built on Amazon Web Services. As part of this I had to centralise the Web Operations Engineers, helping them to switch from a being a lone wolf on each product team to being a centralised profession with consistent tooling and a shared approach to supporting all our software. So obviously I learned about Spotify’s engineering model (which subsequently became known as ‘the Spotify model’) and tried to lift it and drop it straight onto our world. Tribes, squads, chapters, guilds. The whole lot. And it didn’t work for us. At all. Spotify described the features of their approach but the benefits, the intent was implicit. So, for a short amount of time, we chased tribes, squads, chapters, guilds and what they meant for us. But without a clear ‘so what’. And then we abandoned it.

It made me feel better when, years later, I found out that Spotify also abandoned ‘the Spotify model’.

Part 1: The Product Management Community

Learn the key principles of a community and then figure out how to make them work for you

Skip to 2016 and I’m starting to lead the MOJ’s product management community of practice. I’ve started leading the profession in a sketchy, unofficial way. I still have hands-on responsibilities for product teams. There’s 10-12 folks in product management roles. Majority are contractors. There’s no clear leadership for the profession. There’s a regular meetup for those that want to attend. It’s mainly a place to talk, largely to blow-off steam, until the time is up. The role was sketchily designed and used inconsistently. Anyone could hire a product manager and use them as they wanted. There was no career pathway for permanent product managers.

Professions as a whole are in a weak place with an outgoing senior leader seeing little value in them. And even less value in heads of profession. A new senior leader joins and sees more value in professions but remains to be convinced.

‘Building Successful Communities of Practice’ by Emily Webber was released at the beginning of this year. I was already aware of some of the concepts in the book but loads were new. The book was incredibly helpful in framing my thinking and led to lots of action and decisions. Here’s what I did and what I learned in when establishing a community of practice.

  • Meeting together is important. Meetups are a part of the community. At times an important part. But they’re only one part. Trust is crucial and is earned through time together. Trust builds safety And safety promotes constructive challenge and questioning.
  • . . . but less important that you think. The most common mistake is to conflate a community of practice with meetups. Everything that follows is as important as meeting together.
  • If knowledge can be made explicit, make it explicit. A huge part of a community of practice is documenting and sharing knowledge. You’re not limited to asking someone in person at a meetup. Working in the open means that anyone can find knowledge and use it at any time.
  • Invest in shared role descriptions. Key skills and expectations of product management can still be unclear in 2022. This was even more so in 2016. We spent several months working on this. Organisations can be reluctant to adopt new things created by their own staff so I joined a cross-government working group defining product management for the whole of Civil Service. I was able to take our thinking and feed it into the working group resulting in something that immediately worked for us at MOJ. As a bonus, it was endorsed by the Cabinet Office. It cam packaged as a cross-government digital, data and technology capability framework linked to unlocking improved pay for digital specialists. This made it much easier to get buy-in for the roles within my own organisation. The role description improved professional development. It paved the way for much more open and fair recruitment and promotion too. And it helped challenge misconceptions about the role and how it’s used.
  • Create a handbook. 1:1s are a critical feature of a community of practice. I was managing all the PMs and began to spot the same things coming up time and again. I was recommending the same blog posts, books and talks again and again. So I started connecting PMs with the same interests together. And documenting the things I was recommending in a shared space. During the year this bgain as a wiki with a few links to existing posts and books. However loads of the existing stuff was for commercial organisations. Particularly Californian tech startups. It required recontextualisation tweaks to be directly useful in UK public services. So a bunch of Google Docs recontextualising existing stuff developed. By the end of the year we had a single Google Doc called the ‘product management handbook’ that pulled together all the things we most commonly used or needed. Skip ahead a year and we moved it to a Google Site to make it easier to use. A few other Depts asked if they could use it so I put a version online for others to use. It’s still there, albeit a few versions behind the MOJ one.
  • Define membership. Something we had to be explicit about was membership. Who’s in the profession? How do we gain entry to the profession? This can be difficult. It can challenge colleagues. Senior colleagues had been able to badge people as ‘product manager’ until this point. Some colleagues had applied the badge to themselves. But it was critical for the integrity of the profession. We had to create and protect a reputation for excellence. And we had to ensure entry to the profession was open and fair (versus ‘tap on the shoulder’).
  • Have some goals. It was important to have shared goals to build some momentum behind the profession. The bullet-points above give a sense of those early goals. We all wanted a clear and consistent understanding of the role. And we wanted a chance for career progression. These early goals were basic but they built the foundations of the community.
  • It’s OK to begin with a single leader. I avoided leadership for too long. It is possible for a professional community to shared leadership over time. But I’ve never seen an immediate jump to this model work. A professional community needs a traditional, single leader at the beginning. I lacked the confidence and self-awareness to go with this for at least 6 months. It took a while for me to finally pitch myself as a clear leader. And no-one blinked. They trusted me. I’d been doing it anyway. It made things simpler.

As a result of all this, starting 2017, we were able to cement our role descriptions. The only route into the profession became via open and fair recruitment. Recruitment was led by the profession. It sounds obvious now but we agreed that product managers should be managed by product managers. Until then management could end up provided by anyone. We agreement to open our first permanent, Senior Product Manager campaign. Later that year we would see our first internal promotions.

Don’t get me wrong, things could still be messy, that’s the reality of change in a large organisation. But we had a much clearer sense of what we were doing, why we were doing it, and how to do it. And a better sense of belonging to a shared profession.

‘If I knew then what I know now’ I could’ve done things better (and have done since). I was able to hire Emily and we worked together at the beginning of 2017. By this time Emily had introduced indicators of community maturity. We used it in a new area of the profession. Each indicator of maturity was a card and the PMs did a card sort. They agreed what was ‘done’ and what was ‘in progress’. This gave a sense of the maturity of the profession. What was done and what was in progress. And gave a chance to prioritise what happens next. This was a great way to build-up a 3-6 month backlog of shared community activity. I’ve used this approach several times since. You can achieve in 1-2 community meetups what it took us a few months to figure out back in 2016. Hiring an expert like Emily was a great opportunity to ask questions, test ideas and gain support. It was also useful to build trust internally about the approach we were taking.

Psychological safety

I’ve not seen much written about the emotional cost of introducing psychological safety to a community of practice. ‘Psychological safety’ was a buzz-phrase in digital circles for a while, made popular by a post on ‘the five keys to a successful Google team’. My take is that we should all feel safe to turn up to work as our true selves without fear of negative consequences. And we should feel safe to be constructively honest and challenging in our interpersonal relationships within groups at work. Organisations that foster this kind of psychological safety typically foster high-performing teams. Google repopularised this around the time we were working on our professional community.

What comes after the successful introduction of psychological safety can be hard. If you introduce psychological safety within a group it can build personal trust in you from individuals within that group. That trust is precious and has to be respected. Every time I’ve setup a community and helped build trust there’s followed a few weeks, sometimes months, of finding out what’s going on in the real lives of people in that group. I’d regularly get messages on Friday afternoon, when folks have a bit of downtime at work, asking to talk about something. And I’d learn what people had been holding onto for months, sometimes years. It could be a work life thing. A real life thing. A combination of both. Often serious stuff. We’re all people and we’ve all got a lot going on that’s often invisible when we only see each other in sporadic, formal meetings. A professional community can leave more space for us to be our true, messy selves. If you’re leading the profession you can become a focal point for this. It’s a sign that things in the community are going well and people are starting to get the space and support they need. But you must be prepared for the responsibility of being in this position. And prepared for the emotional impact of those Friday afternoon chats. Tears at work are more common than you’d think. You’ve got to step-up and help the people in your community - but realise that you can’t do it alone. You are responsible for providing a safe space for something to be shared. But you can’t solve everyone’s problems on your own. You have to get help from your peers. It’s OK to connect someone with a colleague more suited to support them. It’s OK to ask for help in talking-through how to support someone. Make friends with your organisation’s policies, guidance and helplines. They may be buried in the Intranet but I bet they’re more helpful than you realise.

It’s important that your community makes safe space for its members. You might be the person who needs to create this safety. If you are, make sure you’re prepared for those Friday afternoon chats. Think about how to have these conversations. Think about how you step-up and support without trying to be a hero. And without burning yourself out. Make sure you have the same safe space for yourself.

Head of Profession and being ‘hands-on’

We developed a rule of thumb in our early years. Below five people in a profession and you need one person to do some occasional leadership activity. 5-10 people and you need one person to be 50% on ‘Head of profession stuff’. At some point between 10-20 people you need a full-time Head of Profession.

I learned this the hard way. In 2016 I was managing 10-15 folks. Forming and leading the profession. And ‘hands-on’ in one product team and one discovery. I nearly burned out. But I had senior colleagues who agreed that we needed at full-time Head of Product. and was able to apply for (and get) this role.

It’s tricky though. There’s a lot of anxiety around no longer being ‘hands-on’ and losing your specialist skills. I was at a conference a few years ago and someone asked me if I was mainly doing people management now I was Head of Product? I said ‘yes’. And that people management was the role of a product manager, right? Product Managers don’t do anything. We listen. Think. And speak. In that order. We listen to the perspectives in our team and find value in the sweet spot where they align. A team is a team is a team. A management team is still a team. As Head of Product I had become the product manager in a management team. I was still creating value propositions, outcome-driven goals and aligning multidisciplinary perspectives. I tweaked my approach a little and to fit a management team. I remained ‘hands-on’ as long as I continually learned and improved and made products more valuable. Leading your profession and designing it to work well at scale is very much delivery. It’s delivering the capability your organisation needs to do its work. By coaching in your specialist skill at large scale. By all means reflect on how you tweak your specialist skills to work at scale within a management team.. But don’t allow yourself to get lost in worry that you’re no longer ‘hands-on’.

Sharing leadership

So a year or two into the professional community and our organisation grows. A lot. Digital and Technology within one organisation merge. And then merge with Digital and Technology teams in four other organisations. We find ourselves in a new Digital and Technology super-function. We’ve gone from a world of about 100-150 people to a world of over 1,000 people within a year. The community is now spread across several business units and many locations. We have new members and have to restart some of our community building activity. Our profession doubles in size.

Until now I’ve managed everyone. I designed the role descriptions. Designed the job ads and recruitment approach. Chaired all interviews. Made all hires. Onboarded the new folks.

I need to share leadership activity with my peers.

We have our first permanent Senior Product Managers. I’m able to share share meetups, recruitment, 1:1s, coaching and mentoring with them. This feels weird at first. Let’s take recruitment. I’m pretty anxious about relaxing my control of this activity and handing it over to others . . . but it’s fine. It’s more than fine, it’s good - the Senior PMs bringing their perspective and improve it. Sharing leadership activity with me strengthens the profession. We lose a single point of failure/bottleneck (me). And gain diverse leadership of the profession. Each I share leadership of an activity I can introduce a little more strategic activity to my role. I have the headspace to solve the root cause of some of our issues instead of treating the symptoms. You can’t do that if you’re Chairing five simultaneous recruitment campaigns and line managing 15+ people.

Localisation and contextualisation becomes important. We make space for it alongside the original need for process and consistency.

It’s still important to all meet together as a profession. It’s only feasible a couple of time a year. But it’s worth the effort to reconnect with each other. Regular meetings now happen in segments. We develop 2-3 community meetups based on geographical location. I spend the day in each location on the day of the meetup.

Our shared artefacts keep us connected between big meetups. The handbook, role description, approaches to recruitment and learning become even more important. We introduce separate Slack channels for segments of the profession. But keep our main, shared channel. All are open and accessible by all. Weekly updates give me a chance to share what I learn with everyone. People joining, people leaving, interesting reading, product updates, etc.

I reposition myself so I represent everyone. I can’t embed in the ‘original’ community as this reduces trust in me from the other locations. I give up my permanent desk and become a peripatetic* Head of Product.

*I’m allowing myself this one, obscure word. I take ‘peripatetic’ to mean someone who travels from place to place, working in each place for short periods.

The accidental community of cross-government product leaders

Head of Product meetups began with the creation of the Digital, Data and Technology Profession Capability Framework. We working together on the product manager role description, skills and career pathway through regular all-day sessions over 6-months. This gave us the space to get to know each other and build trust. We build a cross-government community of product leaders by accident. We made knowledge explicit, defined the role, agreed membership and set goals. All the stuff we were doing locally, recreated at a system-level.

This was done in a way that crossed organisational boundaries. It contributed to a similar product management identity shared across many Departments. Heads of Product also supported each other to promote product within our organisation. I’ve supported, and received support from most of the other main Departments.

Writing in the open has helped me to make links. My MOJ blog posts and personal blog have led to conversations, collaboration, speaking events, and attracted new candidates. Sometimes they’ve simply helped people in their day job. Behind the scenes, they’ve led to two side-hustles. The first is supporting new Heads of Product in Government. The second is support for people who’d like to share their experiences through blog posts of their own.

Heads of Product worked together at scale. Looking at hundreds of product managers helped us to see patterns. Most prominent to me was the need to differentiate the needs of the community as it grows. A couple of us did a retro of the cross-government product manager network. Meetups on how to roadmap for a single product remained useful for those new to the profession. But senior product managers needed a space to figure out what it means work across a group of products. Heads of Product and some Leads needed space to figure out what it means when the backlog is a portfolio and each ticket a whole product. Contexts varied too. Someone working on a greenfield public-facing product probably has a different experience from someone building a staff-facing product that has to integrate with multiple existing systems. Big meetups for everyone no longer worked as the single tool for keeping communities together.

Product management cross-sector

This same theme played-out cross-sector too. I attended Mind the Product meetups soon after they became a thing. They are great. But at a certain point they were no longer suited to the scale I was working at. Mind the Product recognised this too and introduced Product Leaders meetups (free at the time, now subscription-based). Much like Heads of Product in Government had been meeting up together, this was a space for Heads of Product. Directors of Product and Chief Product Officers from all sectors to meetup. It was a safe space for us to take about product at scale. About growing the profession. Working across many locations. And increasing the influence of product within an organisation.

For those of us who attended from Government it was also great to reduce status anxiety. Public Sector often assumes that private sector has everything figure out. They don’t. They’re human the same as us all. Government was working at a scale and in tricky spaces far in excess of most private companies. We are sector-leading when it comes to being user-focused and mission-driven. In particular, Government’s approach to Discovery and Alpha is some of the best you’ll see. This helped us be honest about what we could offer candidates. We couldn’t compete with the base salary in many of the best-funded tech companies. And couldn’t offer the chance to work on products that’d appear in Wired. We could offer genuinely user-centred ways of working. And mission-driven products that really help people. We had lots to learn from other sectors and I remember the folks at Financial Times being particularly generous with their time for which I remain grateful.

I also picked-up sporadic coaching of commercial product leaders through these meetups. In return I got to keep my insights into this sector up to date and bring lessons back to my own profession.

The folks at Mind the Product have put a huge amount of effort into supporting the product management community over the years, across all sectors and all parts of the globe. It’s hugely appreciated and they more than deserve their recent acquisition.

Distributed leadership

. . . and back in the world of the MOJ’s product management community of practice. One day I realised that a local community, just one part of the profession, had 15 members. That was larger than the whole profession when it began a few years earlier. Remember that rule of thumb about when you need a full-time Head of Product? Well, at a certain scale, it kicks-in for Lead Product Managers too. So I worked with some of my peers to introduce the role of ‘Lead’ to the organisation.

It takes time to trust in new Leadership roles. There’s understandable anxiety that they’re not ‘hands-on’ in delivery. It represents change for management teams. Until now digital specialists existed in product teams. It’s a big shift for a Lead to appear in a local management team.

But we get one Lead Product Manager. Then another. And another. And so on. My role became leading at scale. We got from 30 PMs, to 40, to 50, to 60. The nature of my role changes and I switch to working with and through a team of Lead PMs. My take is that leaders lead by going first. So anything new: it’s my job to go in whilst it’s messy and figure out what it looks like before asking anyone else to work on it. I have to provide the core, consistent principles for the profession. But I have to recognise my limits. And the limits of any principles. They need to be flexible. The Leads need space to localise them and contextualise them so they work in reality.

Shared parental leave

I took most of 2020 as Shared Parental Leave. This was a great chance to stress-test the product management profession. Had we designed a built a profession without a single point of failure?

We ran a review and retro. The profession was mature enough to continue for without an active Head of Product for a time. There were gaps. It did weaken the profession in some areas. But the profession as a whole, and the local communities led by each Lead Product Manager, were strong enough to thrive. Circling back to Emily Webber’s community maturity model: the profession as a whole was ‘mature’, with examples of being ‘self-sustaining’. Individual communities within the profession were more or less mature at any one time. Energy-levels for community of practice ran in cycles. But as a whole - we’d built a strong profession with leadership distributed across several local communities of practice.

From ‘busy’ leader to strategic leader

I’ve learned that the first years building a community of practice is hands-on, reactive people-work. It’s doing all the recruitment. And having to write the role descriptions and interview scripts first. It’s doing all the 1:1s. It’s switching from mainly contractors to mainly permanent staff. It’s personally knitting links between members of the community. Chairing meetups. Documenting knowledge and re-sharing it at the right time. It’s building trust in that professional community with other professions and with colleagues. All so the role is used in a way that’s valuable to the organisation and rewarding to the people doing it.

A few years in it switches. To building-out the career pathway. Developing, promoting and recruiting other leaders to join you and the profession. Sharing leadership activity with senior peers. Then distributing leadership with local Leads. Each success creates a little more space to be reflective, proactive and strategic.

One day I found myself with an entire afternoon of unscheduled time where, in that moment, everything was being led by others. And I had time to think.

Part 2: Ecosystems

Professions as silos

Communities of practice bridge across organisational silos. That can be from one team to another or from one division of the organisation to another. I started to notice something as I began to have time for strategic, reflective thinking. I realised that professions were on the brink of becoming new silos. Professional communities in government had defined ourselves to ourselves and for ourselves. But we’d forgotten to define how we work together in teams to get things done.

I led Service Standard at MOJ from 2018, ensuring we were taking a Lean Startup-style approach to developing and running 40-50 products. And in early 2021 I leadership across the user-centred, product and delivery professions spanning 350+ folks. Hundreds of people across dozens of products were saying the same thing. It’s hard to figure out how our specialist roles work together in multi-disciplinary product teams. We need to figure out how teams work together as well as we’ve defined individual roles.

Communities are just one part of the story

That brings us to Spring of last year. I was newly returned from a year of mostly shared parental leave and 12-months into the global pandemic. I began leading MOJ’s Heads of Profession, working with some of the most senior and experienced specialists in government. We switched our thinking from how we work separately to how we work together.

We realised that communities are just one of the features needed for us to become innovative. For me, innovation is when we solve new problems. But many organisations solve the same problems again and again, in silo after silo, in generation after generation of the workforce. How do we break out of this and start solving problems once, sharing, and then moving onto the next problem?

We realised that we had to design our organisation as well as we design our products. Each of us has brought our own inspirations. I was inspired by ‘The rise of community curated knowledge networks’ by Sari Azout. Together we’ve worked on shared designs that link our professions. We hope they’ll help us build a better understanding of how we all work together in teams. Here are the four key features I believe will improve sharing across 6 professions. Made of over 350+ amazing people. Building 40-50 fantastic products:

  1. Communities. They remain important. They’re places to find a sense of shared identity. To make implicit knowledge into something explicit and shareable. To re-find knowledge and re-share it. But communities of practice within professions are not enough. On their own they risk becoming just another silo. We need other communities that cut across professional boundaries. Like communities of interest. For example, somewhere that anyone working on a Discovery can come together, share and learn from each other. And communities of action. For example, somewhere for people to come together and improve knowledge management.
  2. Knowledge. Communities are great space to solve problems, taking implicit knowledge and make it explicit, documenting it in a way that can be shared. But it takes a lot of work to store this knowledge in a way that can actually be found and accessed. There’s work to use common tools, to have common taxonomies, to keep the information up to date and useable. The most radical act of innovation that many large organisation could make is to invest in a Content Designer and Librarian.
  3. Curation. “We consume information recreationally, not as a way to achieve our goals”, to quote Sari Azout. To quote Audree Fletcher, “shared documents are not shared understanding”. I spent years designing and updating the product management handbook for my profession. After just my first few months of shared parental leave it was already being forgotten. A few months later and some new starters to the profession had never heard of it. Knowledge needs to be curated and regularly put in front of us, discussed and explained, if we’re to actually use it. Communities, 1:1s, coaching and mentoring are all great places for knowledge to be curated and brought to life.
  4. Standards. I think standards add a ‘so what’ to this whole thing. Standards can reward us for starting from what’s already been figured out. And provide consequences for choosing to unnecessarily reinvent the wheel. They can provide a way of framing knowledge and provide the motivation to curate it. When standards truly matter, an organisation can solve problems once, for all, then move on to solving new problems.

Joining together we realised how much goes on in each profession. And realised there’s so much going on that we’ve been cancelling each other out. Each profession tries to solve similar thing in its own way year after year. But without space to work together and share we end up treading water. So Heads of Profession decided to become a true team, working together to build a shared vision and to set shared goals.

Much of our approach is about finding the awesome stuff already happening and clearing the way for it to be finished. We’ve developed some principles for how we work together which I’d summarise as:

  • Solve problems once, for all
  • Prioritise a small number of problems to solve together. And deciding what we’re not going to work on.
  • Take the invisible work needed to create great products and make it visible
  • Find, support & amplify work in progress before starting anything new
  • Prioritise most valuable work in progress that can be pushed over the finish line.

I’m pretty excited about what 2022 holds for the user-centred, delivery and product professions at MOJ.

Epilogue

I won’t help to write the next chapter in the story of professions and communities of practice at MOJ. I leave in a few weeks, moving to the public sector to work in Local Government. The Heads of Profession are running as a self-organising team. The Product management profession will have a new Head of Product. This is one of the reasons I’m excited to see what 2022 has in store for the user-centred, delivery and product professions at MOJ. It’s totally unknown to me for the first time in years.

This post isn’t the story of the product management profession at MOJ. That’d need 150+ voices to tell it. This isn’t the story of the Heads of Profession team at MOJ. That’d needs six people to tell it. But this is my story. A story about what it’s like to lead the same community of practice for a long time. It’s the story of what happens as the people in that community change, as enthusiasm ebbs and flows, and as the community grows, spreads and matures.

I’ll try and boil this whole thing down. I learned some things the hard way. If you’re in a similar role, let me share just three things with you:

  1. You can’t solve every problem. The colleagues I saw who tried doing this burned out and left. If you’re in for the long haul then you have to learn to prioritise and let things go.
  2. But you must solve the important problems. Cynicism is waiting for those who switch-off. I bargained with myself that I could let some stuff go as long as I had one important problem I was solving at all times. And that I’d see each problem through to a solution.
  3. Get yourself some support. I can leave a product failure at the door but people stuff keeps me up at night. You can’t succeed at everything. Not everyone will get on with you. You won’t get on with everyone. You’ll come under pressure to compromise your values. Sometimes you’ll have to hold the line without anyone to pat you on the back for doing so. If you keep ‘open and fair’ as your north star and ensure each year is better than the last: then you’re doing the job and doing it well. Find at least one person who you can talk about all this stuff with so you can leave it at work and enjoy your real life.