Simon Colmer (at the time of this talk, the Head of Development at Access NFP Websites) spoke to ProductTank London about a developer’s perspective on what it takes to build a successful product development team. As product people, team alignment is table-stakes, and it’s crucial that we factor in multiple perspectives to create diverse, empowered teams, so Simon’s talk is a great reframing of something many of us wrestle with.
Simon starts by describing some common antipatterns in product team structures and processes – the better for us to recognise where we might be slipping into pitfalls! After that, he walks us through some better ways of working, and creating dynamic, high-impact teams.
Things that may demotivate product development teams
As a huge advocate of continuous delivery and agile, empowered teams, Simon’s got a keen eye for patterns of work that are counter-productive, and ripe for improvement.
Scrumerfall
This is where a lot of teams end up in their journey towards becoming agile. Everyone wants to get “better”, and they adopt several agile rituals, but only the development team at the end of the actual product development process are really “agile”. When the only really agile part of the process is right at the end, when code is actually being written, then the development team is disempowered, and treated as a delivery resource.
- This effectively splits your teams,
- It creates lots of opportunities for context and insight to leak out of the process
- It creates indistinct accountability
- And it ultimately leads to a breakdown of trust in the team.
Product Managers are not Project Managers
Product teams are often asked questions about “velocity”, and have their performance tracked according to the story points on their burn-down charts. The challenge with this is that story points – taken in isolation – are simply a measure of team utilisation. They measure how busy the team has been, and how effective the team has been at maximising output… but they measure nothing about direction, or impact, or whether the team has been working on the right thing.
Many of these measures are also based on estimates that are made in advance, without full knowledge of the challenge ahead. The start of a piece of work is literally when we know the least about it, so any estimates we make at this point will be the least accurate. Product teams that are tyrannically held to these estimates are incentivised towards the wrong thing (namely, heavily padded estimates!)
Avoid Toxic language
Communication matters immensely to humans – even more so when we’re either working remotely, or in situations that have the potential for high stress or anxiety. No matter what your role is in the team, but especially if you’re in a leadership role, it’s really important to be precise with your language, and to consider the impact of what you say. For example:
- People are not a resource, so don’t refer to them as such.
- Avoid using “them” when talking about other parts of the organisation or team. Be inclusive or descriptive – preferably both!
- When we’re told we’re “accountable”, it’s often interpreted as “our job is in danger if we fail”. The reality is (or should be) that we are “responsible”, rather than positioned for punishment.
The Traits of a Well-Integrated Product Development Team
Okay, so what does a high-performing, well integrated product development team look like? There are a few key patterns to aim for. This is not an exhaustive list, and it’s not to say that you can’t be a great team without these, but they certainly help! A lot of this starts with having a product owner who…
- … is not assigning or managing work – they are just responsible for ensuring that the most important problem is being tackled.
- …is setting scope, not schedules, in response to external forces that the team needs to respond to (E.g. legislation changes).
- … understand the needs of the customer, and keeps the team focused around them..
- … can answer questions about product context and insights, or find those insights if they don’t have them to hand.
- … works across teams and functions to facilitate the bigger picture.
Start with trust
The common thread here is that trust is critical to a well-integrated team. Amongst other things, trust is built on a set of common core values and beliefs, and it builds a willingness to experiment with new ideas by making the “failure” of experiments (really, learning) a safe idea. But trust isn’t free, it must be built and earned. Simon walks us through a few key practices to develop, framed as questions to ask yourself, to better build trust with your team:
- Are you regularly having 1-2-1 conversations with the people on your product development team?
- Do you participate in team rituals as a member of the team, not a manager?
- Are you and the product development team “co-located”? (when remote, this might be built around regular shared video calls, or being available to quickly jump into product development conversations)
- Does the team have space and permission to experiment?
Ultimately, it’s important to remember that you are all working with each other, not for each other, and you are all aiming towards creating the same valuable outcomes for your customers.
Enjoy more from ProductTank
ProductTanks are informal meetups, created by Mind the Product, to bring local product people together and to enable speakers to share amazing product insights. Today we have ProductTanks in more than 200 cities across the globe and there’s probably one near you.
Learn more about ProductTank – find your local meetup, explore more ProductTank content, see the latest ProductTank news, and discover ways to get involved!
