PRODUCTHEAD: Component teams, feature teams and centralised skill teams
PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
morning product
tl;dr
A component team’s focus on a specific technology can result in being less user-centric
Feature teams are better suited to deal with innovation, uncertainty, and change
Centralised skill teams should aim to make themselves redundant by disseminating knowledge
a favour: please share this with other product people
every PRODUCTHEAD edition is online for you to refer back to
hello
When thinking about dividing up a complex product or service across multiple delivery teams, it’s often presented as a stark choice between ‘feature teams’ (focused on helping a user achieve a goal, such as ‘publishing and sharing a blog post’) and ‘component teams’ (focused on delivering technologies such as ‘the visual text editor’).
You’ve probably come across these concepts if your organisation has adopted some kind of scaled agile approach in the last few years. In reality, this debate is not new, predating even the Agile Manifesto (2001). You can read a description of feature teams in Microsoft Secrets (1988, by Cusumano and Selby) and be surprised by its familiarity.
Out of necessity, some organisations also adopt what I’m calling ‘centralised skill teams’. These are teams intended to provide a service to the other delivery teams, when a particular skill set is in demand, but in short supply.
There’s no one right answer as it always depends on your own particular context (your organisation, market, product, team and available skill sets). For the same reason, copying the approach of other organisations, even if superficially similar to yours, probably won’t work because their context differs from yours.
Component teams #
Component teams often arise from the need for specialists on a particular technology. They can become overly fixated with the technology itself and lose sight of the context. If you’ve ever worked in an organisation where a particular technology or process dictated the constraints on what you could and couldn’t do, then you’ll know what I mean.
For me, it was the ongoing battle to adopt pricing models in my products that could not be represented in the underlying CRM (customer relationship management) system, which had been bastardised over several years from its original use case into a product cataloguing system.
The component team only sees requirements (what, not why) coming in without context and duly customises the component over and over. They tend not to disseminate know-how outside of the team — they’re the specialists, after all, and want to stay that way. Team members come and go, often taking with them the ‘tribal’ knowledge of why certain critical customisations exist and how they work.
Over time the component team becomes increasingly siloed, and the component it looks after becomes both inextricably embedded and completely unmaintainable, a source of drag to the product teams that are obliged to work with it.
Feature teams #
Feature teams are about empowerment, accountability, identity, consensus and balance …
Empowerment — While it would be difficult to entrust one functional group or a single functional hierarchy, such as Development, for instance, with virtually absolute control over a particular technology area, it’s a good idea to do that with a balanced multi-disciplinary team. The frontline experts are the people who know more than anyone else about their area, and it seems dumb not to find a way to let them have control over their area.
Accountability — … If a balanced group of people are mutually accountable for all the aspects of design, development, debugging, QA, shipping, and so on, they will devise ways to share critical observations with one another. Because they are accountable, if they perceive it, they own it. They must pass the perception to the rest of the team.
Identity — … With cross-functional feature teams, individuals gradually begin to identify with a part of the product rather than with a narrow specialized skill.
Consensus — Consensus is the atmosphere of a feature team. Since the point of identification is the feature rather than the function, and since the accountability for the feature is mutual, a certain degree of openness is safe, even necessary. I have observed teams reorganizing themselves, creating visions, reallocating resources, changing schedules, all without sticky conflict.
Balance — Balance on a feature team is about diverse skill sets, diverse assignments, and diverse points of view.
Microsoft Secrets by Michael A. Cusumano and Richard W. Selby
In contrast to component teams, feature teams are cross-functional. Their role is to support a particular customer journey, which entails understanding what users are trying to achieve, as well as the context of related customer journeys. Feature teams are not immune to becoming siloed, but they at least have a vested interest in understanding how (and how well) their product workflow fits into the bigger picture.
They research, design and build everything up and down the tech stack from the user interface to the data layer, even to the underlying server infrastructure. Populating these teams can therefore be tricky. Not every company has the luxury of ready access to all the different skill sets needed. And not all of the skills are needed 100 percent of the time, making it more difficult to manage the ebb and flow of work for individuals with particular niche skills — making a good case for team members to be multi-skilled.
Centralised skill teams #
One approach to this particular problem of niche skills can be to have a centralised skill team to begin with, whose purpose is to facilitate the other teams. An example might be a centralised devops team tasked with taking away the effort the creation of development, staging and production environments from delivery teams.
This may sound a bit like a component team again, but the difference lies in their goal and perspective. In my example, the devops team’s users are the delivery teams. The team is outward-looking so they can serve the needs of their users. Their goal is to make themselves redundant by upskilling the delivery teams.
Because (in this example) their work is mostly repetitive, with variations to take into account individual delivery teams’ specific needs, the devops team creates tooling to make the process more efficient. The tooling is built in the open (00:15:56 in the video) and designed for people outside of the devops team to use. They collaborate with the delivery teams to share know-how and tooling.
Eventually the centralised team disbands and its members are absorbed by the multi-disciplinary delivery teams. Devops has become just another skill set held by multiple people on each delivery team. The delivery teams have levelled up, if you like, removing the need for the centralised team of specialists.
Final thoughts #
Do you recognise any of these team patterns in your own organisation?
How does your organisation justify its chosen way of working?
How could your teams become more user-centric, transparent, and better at sharing their knowledge and experience with their peers?
Speak to you soon,
Jock
what to think about this week
Are feature teams or component teams right for your product?
Whenever you require more than a single development team to progress your product, you have choice: You can organise the teams around features or components. This article explains why this decision matters for product people, and it shares my advice on when feature teams are right for your product and when component teams are better suited.
[Pro tip: the comments to the article linked are worth reading also]
Be clear on the team setup that benefits your product most
[ROMAN PICHLER / PICHLER CONSULTING]
Platforms, postcodes and pushing services live: a year in the life of our platforms team
How our platforms team created a postcode lookup service, developed a toolkit for live services and slashed hosting costs, all before its 1st birthday.
We formed a platforms team almost a year ago on not much more than a gut feeling that there was a better way of doing things.
A platform has to be used, or it may as well not exist
[AL DAVIDSON / MINISTRY OF JUSTICE DIGITAL AND TECHNOLOGY]
5 tips for successful internal platforms
Large organisations often have internal platforms. My first assignment at the Ministry of Justice in 2015 was an internal platform to help development teams run and change their software. I got to pair with colleagues at GDS who were developing ‘Government as a Platform’. There was a lot of mutual learning and sharing in those early days, and I got to assess the early versions of a couple of their products.
[SCOTT COLFER]
recent posts
Whatever this is, this web3 product manager role is not a product manager
Jason Shah wrote a guest post recently for Lenny Rachitsky’s newsletter, “A Product Manager’s Guide to web3”, which describes how product management differs in web3 companies. He notes that joining a web3 company can be “an opaque process and a risky decision”. I’d add “ethically challenging and morally grey” to that description.
“You keep using that word. I do not think it means what you think it means.”
[I MANAGE PRODUCTS]
Sorting the signal from the noise — a guide to fact-checking
One of the most important, and arguably hardest jobs we have as product managers is to work with our team to sift through information, read between the lines, and verify what is fact and what is merely opinion.
[I MANAGE PRODUCTS]
Start building a community of practice with the 3 minute challenge
When you start out as a head of product (or product director or VP product), you’ll probably need to create a community of product people. In this latest entry for my series of 100 things I’ve learned about product management, I share my advice to help you get the ball rolling with your own community of practice.
[I MANAGE PRODUCTS]
upcoming talks and events
15th June 2022
Chief Product Officer Summit
The Chief Product Officer Summit returns on June 15.
Dedicated solely for senior product leaders, our panel-focused agenda will discuss leadership challenges without losing a whole day.
Get ready for insights from:
💥 Amazon – Head of Amazon Prime Europe | Product | CPO
💥 Politico – Director of Product
💥 Aklamio – CPO
💥 Proximie – CPTO
💥 Wefox – CPO
💥 Jit – CPO & Co-Founder
💥 Plagood – CPO
💥 Concentrix – Vice President of Product
💥 Just Eat Takeaway – Global Head of Product
💥 Royal Mail – Chief Digital product Officer
💥 Citi – VP/Head of Product, NLP & AI
Our geo-specific sessions are back, so whether you’re in Europe or the US, you can tune in wherever, whenever.
can we help you?
Product People is a product management services company. We can help you through consultancy, training and coaching. Just contact us if you need our help!
Helping people build better products, more successfully, since 2012.
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from delayed onset muscle soreness.
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“This is a great book for Product Managers or those considering a career in Product Management.”
— Lyndsay Denton
Jock Busuttil is a product management and leadership coach, product leader and author. He has spent over two decades working with technology companies to improve their product management practices, from startups to multinationals. In 2012 Jock founded Product People Limited, which provides product management consultancy, coaching and training. Its clients include BBC, University of Cambridge, Ometria, Prolific and the UK’s Ministry of Justice and Government Digital Service (GDS). Jock holds a master’s degree in Classics from the University of Cambridge. He is the author of the popular book The Practitioner’s Guide To Product Management, which was published in January 2015 by Grand Central Publishing in the US and Piatkus in the UK. He writes the blog I Manage Products and weekly product management newsletter PRODUCTHEAD. You can find him on Mastodon, Twitter and LinkedIn.
Leave a Reply