Aim for perfection in self-organising teams with Mastery (Part III of IV)
The urge to learn and become better
Welcome to part three of my series about Autonomy, Mastery and Purpose and how each of these principles help with creating a self-organising team. This article will focus on creating an environment that allows the team as a whole to perform at their absolute best. In other words, we will be exploring a setup that fosters Mastery.
The Context
For the full background, please have a read of part one. I will only repeat some core information here to give context for the rest of the article.
Everybody dreams of working in a high-performing team. Contrary to what we think, individual talent or intelligence is in most cases not the deciding factor. It is how well the team can work together.
When a team is set up to be self-organising, a large part of the foundation is put in place for it to run like a well-oiled machine. Which, in turn, yields a higher volume and better quality output.
The concepts of Autonomy, Mastery and Purpose provide the structure for a self-organising team, which enables it to be highly productive.
The never-ending quest for Mastery
The challenge for any team is to have impact. In other words, a team exists to create value through a product — be that online or elsewhere. A team can therefore only be classified as high-performing if it delivers value to the customer consistently. If a team is delivering at an amazing pace but without any impact, all of the hard work is wasted. On the other hand, if the team is delivering a great product at a slow cadence, it is missing lots of opportunities.
For a team to be high-performing, it needs to become great at delivering a valuable product.
In order to get the team to become an expert in delivering value, we need to create the perfect environment for them. It is not about getting the ten most talented engineers in the room, as mentioned in the first part of this series. It is not about working 80 hours a week for a quick win. The challenge is to maximise the performance of the team as a whole by introducing the right processes.
Combined with Autonomy — which creates a culture of independence and freedom — you get a team that wants to do great things and has all the tools to achieve it.
Become experts at delivering
The first task in order to be able to build a valuable product is to be able to deliver. And a solid, proven way is to adopt some form of Agile, Scrum, Kanban or the likes. Finding the right processes can be tricky though. It is certainly not about copying everything out of a book — that would be anything but agile.
Problem number one is finding the right processes. Problem number two is to be able to introduce them without scaring the team with yet another thing that keeps them doing real work. The approach that works well for me is to make clear that we are changing the process on an experimental basis: Try it a few weeks, measure the impact, gather feedback, then iterate.
Following are a few examples that can be used as a starting point for your own team. But remember, because it works for one team does not mean it will for another. Always treat it as an experiment.
Short Iterations
My opinion: The shorter the better. We are currently running with a one week cycle (we have not tried anything shorter though). It dramatically minimises the time to feedback, both within the team and for the product. It also forces the team to aim for a release every week. In other words, we have to figure out how to break up the project and deliver iteratively.
Iteration Planning and Retrospective
Every form of team organisation comes with process overhead. When looking at iterations, most times you will need some form of planning and retro. A planning session should align and make it clear to everybody what the goal is for the iteration. Regular retrospectives give the team a time to reflect and learn. Ideally, both are done for each iteration. The more often you do them (e.g. weekly), the shorter they can be.
This is the bare minimum I would consider necessary for most teams. Some might wonder if a daily stand-up should be part of the list. It can be useful in some situations. However, I personally believe that as soon as a team reaches a level of efficiency, it will be a waste of time.
Become experts at creating value
While an agile process puts the team in a position to deliver, the other important part is to make sure you are building the right thing. There is nothing worse than spending a huge amount of time on something that is not having any impact.
I am a big believer in the Lean Startup way of product development. At its core is the principle of eliminating process waste and focusing on a streamlined way to get a valuable product in the hands of customers as quickly and often as possible. For all the insights (and a good read), consider buying The Lean Startup. I will only cover some of the core concepts here.
Build, Measure, Learn
At the heart of the Lean Startup way of working are three stages of development:
- Build. The first step of the cycle is to create a product that can be put in front of customers, often called a Minimum Viable Product (MVP). (More on that in the following section.)
- Measure. Once a product can be put in front of customers, it should be measured against the expected impact. What metric are we trying to move? How can we collect qualitative feedback?
- Learn. As soon we have collected data about how our feature performs, we can analyse the results. All the learning in this step will then be used to build the next version of our product and a new cycle is started.
This process is incredibly useful for building the right thing. The focus on small releases, measuring the impact and deciding about the next steps based on the new information allows a team to pivot incredibly fast and ensures value is created as often as possible.
Minimum Valuable Product
As mentioned before, the result of every build iteration can be thought of as a MVP. Traditionally, it stands for Minimum Viable Product. However, viable does not put the customer first. The concept of a Minimum Valuable Product attempts to solve this problem.
For a contrived example, imagine that you are tasked to build something that is able to get people from A to B. Your stakeholder is quick to suggest a solution: How about a car? Logically, the first viable deliverable could then be a tyre. Not bad. It is definitely needed for a car.
However, it does not add any value for the customer until the car is completed. What about if you would deliver a skateboard first? Or a bike? Or even a set of rollerblades?
Keeping the customer front and centre of product development is key to delivering value incrementally. In addition, new insights will be available during development and incorporated into the final product. As a result the end product might be better for the customer than the originally imagined solution.
Measure on multiple dimensions
Between the three steps in Lean — Build, Measure, Learn — being able to evaluate what impact the product has in every cycle can become very complicated. The team will have to figure out not only what to measure, but also how. Here a few tips that have worked for me in the past:
- Define your assumption before building. This can be considered a pre-building step, which will make life easier throughout the three normal stages. If you know what you want to achieve before you build the next iteration of the product, you will also have a decent idea on how to evaluate the impact.
- Qualitative and Quantitative user testing. Most agile teams do some form of experimentation. Most of the time, this is giving great insight into the quantitative results. It is however extremely valuable to add a qualitative dimension, for example through interviews or surveys.
- Document everything. There will come a time, be that in 2 weeks, a year or 5 years, when someone — most likely you — is looking for information about the product you are developing right now. Any context you are able to capture now is going to pay back twice in the future, so attempt to document everything you can: What you are building. Why. How it is tested. The results. Next steps.
Master your team’s cross-functionality
So far I have covered ideas and tools that can be used to streamline the process in order to deliver a valuable product. Some areas I have not covered yet include team composition and values.
Involve all the disciplines you need
The most common cross-functional team in a technical company consists of engineers, designers and product managers. In most cases though, the product you are building has to get input from other parts of the business, for example data analysis or marketing.
Based on my experience, you want to include everybody that is needed to build the right product, and build the product right. Cross-functionality works wonders for this, because a high degree of diversity creates healthy tension and yields a better outcome.
Create a culture set up for success
Imagine you have formed a team, started to set up processes, picked up some traction and are starting to deliver a product. Congratulations! However, this is just the start of the journey. Every team will go through four stages of development: Storming, Norming, Forming, Performing.
One of the initial issues you will encounter, is the need for trust between the team members. As Patrick Lencioni puts it in The Five Dysfunctions of a Team: The first challenge any team will encounter is the Absence of Trust. Put another way, your group of people is unable “to be vulnerable and open with one another”. The standard approach is to assume that friendships need to be formed between each other, for example through lunches together, off-sites, bowling sessions or similar. That’s a decent start, but might not help a lot when facing an obstacle at work. Following are a couple of ideas that will make sure the team builds trust on a personal and professional level:
- Sharing of personal goals. It might sound scary to some folks on your team, but it allows everybody to be more aware of where each member of the team is heading with their personal development. In the best case, people can come together and help each other.
- 5 minute 1:1’s. Every fortnight, the whole team gathers to have 1:1’s with each other. Five minutes per pair. This breaks the traditional reporting lines and provides an opportunity to give personal feedback.
Next up: Purpose
The next part of my series will cover Purpose in the context of self-organising teams and how it builds a culture of engagement and excitement.
Previously published stories as part of this series:
The art of self-organising teams: Create amazing teams by applying Autonomy, Mastery & Purpose
Build the foundation for self-organising teams with Autonomy: Our desire to be self directed
If you want to make sure you are not missing the story, please follow me on Medium or connect with me on linkedin.
