Full-stack Teams and Moving Fast
There’s plenty to take out from this post by VC and former product lead Sarah Tavel on lessons from scaling Pinterest and working in full-stack teams. She has a good take on the dangers of vanity metrics, and why at Pinterest they shifted from growth in MAUs as a guiding metric to growth in the number of weekly active pinners:
‘They aren’t just misleading to the outside world — they can start a vicious-cycle. You use a metric because it makes your company (or team) look good, and because you start tracking it, you want it to continue to increase, so you start optimizing for it. This will take you down the wrong path.’
And on the tricky balance of knowing when to listen to your users, and when to ignore them. Listening to power users can lead to biases which prevent you from making significant changes to key features or lead you into a development path that favours a small group:
‘Your loudest users…are a blessing and a curse…(they) don’t represent all your users, and they definitely don’t represent your future users.’
And then there’s the importance of building a bank of trust with your users which can help you when the inevitable glitches occur, and how important it is to stick to your first principles during moments of organisational self-doubt.
But I really liked her point about how flat hierarchies can act as a brake on moving fast, and the ‘night and day’ difference between when they worked as a matrixed organisation, and when they shifted to work instead in full-stack teams bringing together all the key functional expertise and skills needed to build and ship great products:
‘Org changes are often painful and distracting but they’re absolutely necessary as a company scales. When an org structure doesn’t reflect your strategy or is overly matrixed, it acts as a tax on your company’s ability to execute.’
In our book on organisational agility, we describe not only the need for greater fluidity in resourcing but how concurrent working in small teams enables businesses the capability for rapid progress. The point about full-stack teams is that they are naturally built for concurrent working, quick decision-making and moving fast. Large, traditional hierarchies work well for optimising efficiency in execution of existing propositions or processes but are far less well-equipped for building the new. For that you don’t need silos or complicated reporting structures. You need all the key disciplines needed to produce an output working concurrently in a seamless, borderless way. As one team. And that team needs to be kept small if it is retain any kind of semblance of agility. The two structural forms are very different, but if you’re looking to progress a new initiative at pace and get to outputs quickly, you have to set the team up in the right way.
You can order your copy of Building the Agile Business Through Digital Transformation here, or you can join our community to access exclusive content related to the book
Image source
Originally published at Building The Agile Business.
