There have been endless books, courses and models created about team maturity, what it means and how to assess it. Each model revolves around a specific framework or way of working, often as marketing material for a consultancy (e.g Agile maturity matrix). It’s likely everyone agrees, at least they would do if asked, that teams go through different levels of maturity. What new, or ineffective, managers can be slow to realise is that their role needs to change dramatically depending on the team they are managing’s maturity.
When first stepping into the a manager role you likely hear of terms like ‘servant leadership’, ‘self organising teams’ and ‘micro-management’. The first two being the ideals to strive for and the latter being a universal evil. What people often don’t understand is that without a proper understanding of what a team needs from you, it’s stage of maturity, blindly following the first two concepts are equally as damaging as the latter.
Throughout my experience as an engineering leader, most recently while scaling the engineering team at Omnipresent, I have either led or been heavily involved with the forming and continued maturing of over 10 engineering teams. The main reason I have seen for a team’s success or failure, beyond developer capability, is their manager’s ability to assess the team's level of maturity, adapt their role accordingly and provide the support needed for the team's current stage.
In his book, High output management, Andy Grove talks about a concept he calls task based maturity. The basic idea is that you have to assess the ability of someone you manage to complete a task and then provide a specific level of support based on their ability. If someone has never completed a certain task before they will need constant support and guidance while they learn how to carry out the task effectively. On the opposite end, if someone has completed a task many times and is fully proficient, they will need very little input from their manager and the manager can take a step back. When someone is learning to ride a bike for the first time the teacher holds them up and gives them very detailed advice but once the person can successfully ride a bike they need no support or guidance and can be left alone.
In a professional environment, a manager’s job is two fold. First they need to recognise where on the maturity scale their employee is and then they need figure out the level of support or guidance the employee needs for their specific level of maturity for their task. If you misjudge the first aspect then you either micromanage your employee or set them up for failure. Neither are desirable outcomes.
The same is true for teams as it is for individuals. When you are leading a team you need to constantly be altering your approach to your leadership based on the maturity of the team. While the maturity of a team for a specific task often correlates with the length of time a team has been working together it isn’t necessarily a direct correlation and a team may be mature working with one type of task while immature with another.
Almost every manager will have heard of Tuckman’s stages of team formation (forming, storming etc) and understand the general concept of a team moving through distinct stages as it forms and matures. What I am talking about is subtly different from Tuckman’s model. It has some overlap but i’m talking less about team dynamics and am focused more on team output, the ability of a team to complete certain tasks. It seems that most managers have heard about this model and can parrot the meaning of the different stages but remain unable to effectively diagnose where a team is, what they need from them at that stage and how to progress the team to the next stage.
To a lot of people the above is self explanatory. When teaching someone a skill outside of a professional environment you naturally rely on such task based maturity assessments to make sure you are guiding them efficiently. So why do some managers struggle with this?
In the software development industry there has been a large push towards self organising teams without a defined leader, at least what is traditionally considered a leader. Servant leadership is the new buzzword, leaders are supposed to facilitate and enable teams to come to decisions and let them lead themselves. When misunderstood and taken to mean that they aren’t supposed to make decisions themselves and not supposed to interfere with the autonomy of the team or individual team members. While in theory this makes sense as an eventual goal, the developers in a team are the people closest to the problems and with the best knowledge on how to solve them, in reality it isn’t effective (and often damaging) until a team reaches a certain, late, stage of maturity.
The issue is that a lot of managers don’t fully understand what servant leadership and decentralised command really mean. They feel that they shouldn’t be making decisions, take micromanaging to be a mortal sin and run off in the opposite direction. They are reluctant to ever make a decision or to ever be seen to ‘tell’ the team or individual developer what to do even if the team or developer in question is failing. How is an individual or team supposed to learn what good looks like if there is no one there to show them?
The other reason why a manager may not be willing to guide someone through maturing their task based maturity is because the manager themselves doesn’t know how to carry out the task. This can often happen if the manager either doesnt have experience of the task in question or if they do but weren’t far enough along the task relevant maturity scale themselves. If this is the case then it is the manager’s managers job to help guide their report along the task based maturity scale of teaching the task or to find someone else who can.
There is also a reluctance to accept that there are proven good and bad ways of working. There are existing toolboxes of proven techniques which teams can choose from. Things will need to be tweaked on a team by team basis but a good starting point would be what is generally accepted in the industry as best practice or what other teams in your organisation have success with. Letting a team start from complete scratch in deciding their ways of working will just lead to going round in circles and ineffectiveness, especially when noone is making any decisions. This is compounded if the team isn’t particularly experienced in good ways of working.
The managers job here, for immature and new teams, is to step in and put in place ways of working which either have been proven to work in the industry or they have seen work successfully in their previous experience. Once an initial way of working is in place then the team can continually revisit if it’s working and make changes. Once again though it is the manager’s job to make sure that changes made are in the right direction and will actually improve things. If the team suggests to move away from the core of the best practice it is for the manager to step in and guide them back in the right direction.
A common refrain is that if you step in and guide/direct a team then you are depriving them of key learning opportunities. An immature team will take a while to work successfully together, along the way they may be unproductive and make mistakes. Some managers see this as a necessary step to the team forming and organising itself. While this is largely true, making mistakes and learning from them together is a key element of team formation, it needs to do this in a way that isn’t at the expense of their customers or the rest of the business. It is the managers job to act as a safety barrier and step in before any serious errors are made or if progress is too slow. Ideally the manager will be the one to catch the failure and help the team learn from their error in thinking before the mistake has actually been made or any customers have been impacted.
Similarly, a team that is self organising and learning to work together will likely be unproductive and slow to begin with. Again, this is an understandable, and necessary, stage in team development. The manager shouldn’t just sit back and accept this though, their job is to speed the team along in this process, stepping in where needed to guide or direct the team. Once again we can’t have team formation unduly affect the customer or the rest of the business.
A manager’s job here is to guide a team through higher and higher levels of task based maturity. Closely supporting them through completing harder and more complex tasks with less and less input and hands on support from the manager. How can this be achieved?
First you need to form a rough assessment of where the team currently sits for the upcoming task. Is everyone speaking up with their point of view (and are they good ideas?), are they generally experienced with the area they are working in and solving similar problems, what is the track record of the team. At this point all you need is a very rough assessment to see how to start i.e do you need to tell them exactly what to do at every stage or are they comfortable with some ambiguity?
Once you have a rough idea of where the team is currently at you should identify some initial tasks for the team that are just at the threshold of their current capability. Say there is a new, fairly simple, bit of work coming up that needs scoping and planning. Maybe the team is able to scope small chunks of work together so you split the overarching work into small chunks that you then walk through with the team one by one in a planning meeting. You may need to actively ask each person what they think at this point and challenge any estimates you don’t agree with. They may be sailing through with little difficulty, providing accurate estimates and progressing through each ticket with little involvement from you. They may be struggling, no one speaking up, not understanding the work to be done and when they do speak providing wildly inaccurate estimates. Or they may be somewhere inbetween.
Using the information gathered above you can then see what to do next. If they succeeded and everything was great then next time you can push more responsibility on to them, maybe give the team the big bit of work and get them to split it up into smaller chunks by themselves. If they struggled then maybe you need to get even more involved, perhaps even providing some of the estimates/scoping yourself to show them what you are expecting. If they are somewhere in between then you can repeat the exercise in the same way in future until they move into being comfortable with it.
This process then repeats with every task your team faces. The end state of this process is to get the team to full self organisation for as many of their tasks as possible. After a few goes through the loop for a specific task it’s very likely that the required support of the manager is minimal and the team can self organise around solving this specific task in future. At this point the manager shouldn’t disengage completely as they need to be making sure that things don’t slip back and be on hand to act as a guardrail if things go wrong.
It’s worth noting that your team might be far along the maturity scale for a certain type of task, e.g scoping work, and able to carry it out with little to no input from you and quite early on in the maturity of a different type of task, e.g releasing their work. A manager’s job is to constantly be assessing the level of support a team needs for their given task and then providing it.
While self organisation and servant leadership are great ideals to aim for, they require an intentional and guided journey to get there. A team can’t be formed and immediately self organise. At early stages of maturity the team needs a guiding force which has the knowledge and capability to help the team learn what good looks like and support them while they get there. This means that someone is there who has the knowledge, willingness and ability to make key decisions on behalf of the team.
It’s worth mentioning that this guiding force doesn’t need to be a manager and depending on how your team is set up could be a tech lead or other senior member of the team. What is important is that there is someone in the team to support and guide the team on this journey.
A good mental framework to help you guide a team on this journey is task relevant maturity. For each task a team tackles they will be at a certain maturity level for completing it. It is the manager’s job to assess this level, decide the support level needed and then provide that support or guidance.
Back to writing