A good developer can get a lot of stuff done when they work on their own. Everything is in their head and everything is under their control. There are no distractions and no-one to disagree with. Now back in the real world there are very few one man projects. To start with you have a least one customer and as the team grows that is where the trouble starts.
When you have 1 developer they have the capacity to be 100% efficient. When I say efficient, I mean there is very little waste and they are approaching the task in hand in the most optimal way. But they may not be effective. How can that be? Well the definition of effective in this context is that the developer is doing the right task and achieving all of their goals. In the 1 developer scenario being efficient helps you be effective… but it does not guarantee it. There simply might not be enough hours in the day to achieve the goals that have been set out. Hence the developer is as efficient as they can be but they are still not effective.
So the team grows. More developers join. Maybe these developers are also very efficient. Maybe they approach each task in the most optimal way. To be very efficient in team situations means that there isn’t time for debate, experimentation and challenge. This might mean your team will work as individuals with very little communication and there will be no feedback. Without feedback there can be no guarantee that the right task is being done, so even though you now have a team of efficient developers the combined team is no more effective or even less effective than the single developer working on their own.
You are looking for the team to be effective and not necessarily 100% efficient. The team has to “gel”. They need to communicate well, understand their combined strengths and weaknesses and help each other out. In this example it is important to build an effective team before that team can become more efficient. This gives you the basis to scale the team out as required. This is the basis of Tuckman’s stages of group development.
It is a lot harder to scale a team to make it more effective when it is already highly efficient but ineffective. The reason for this is the activity that is required to scale the team will negatively affect efficiency, which is the primary metric that the team value. In Tuckman’s model scaling the team is re-forming it. However, if the team is efficient or otherwise busy but are under pressure to be more effective they will be countering this by trying to be even more efficient. Their efficiency is a positive, they believe it brings results, so they want more of it. Bringing in new tooling or processes will require training which reduces efficiency. On-boarding new team members requires knowledge transfer which takes time and reduces efficiency. So for a time the team is not effective enough and you just reduced its efficiency too. If this team is under delivery pressure, which they will be if they are being asked to be more effective, then you see resistance which seems strange when the reason changes are being made are in order to reduce the pressure in the first place.
There are no easy answers to this in my experience but you should be able to recognise these situations when they occur, understand their characteristics and guide the team in the right direction.
The first important point to realise is that any drive to make a team more effective usually comes with the added context that they are probably not meeting objectives. The pressure is already on. Any change that is introduced at this point is likely to reduce effectiveness in the short term. There is not much that can be done about this so all stakeholders need to be aware of its impact. The team will be moving through Tuckman’s stages so this simply needs to be accepted. It also probably means you should not try to implement many changes incrementally over long periods of time. Each change is likely to revert the team to forming and if this keeps happening it will stop the team from reaching the performing stage.
One of the most likely changes that a team will be subjected to is new people. Therefore, care must be taken about the skillset of the people who are introduced at the start. Whilst the project team may be crying out for people with specialisms in particular areas to “help solved an urgent problem” the bigger problem is lack of effectiveness. You should not exacerbate the problem by bringing more individualists into the team. Instead you should be looking for people with the soft skills that enable them to quickly adapt, skills that allows them to coach the team whilst also having the ability to see the bigger picture. These first people need to be self-starters, stay calm and provide helpful contributions in a crisis and importantly be able to operate with very little guidance from the existing team. So when selecting candidates for these projects I’m looking for the right person not a series of skills listed on a profile.