Building a team is not an easy task. In fact it is a colossal task. Extreme Ownership practitioners say there are no bad teams, there’s only bad leaders. And while there can be a lot of argumentation in there, there is a bit of uncontested truth. A good leader who knows how to set up the right balance of pressure, motivation, mentorization and cross skills in his team, will have a winning team.
When speaking about engineering teams, we have another complication. We are an immature industry (somewhere between 25 and 50 years depending on your scales, and no 5 years have been the same ever) comprised and moved by young professionals with top notch hard skills. However in many cases without time and tenure to polish their soft ones, and most importantly, where hubris is too often considered a trait and not a problem. We, engineers, are usually proud of how we build our product. Not necessary the problems it solves but how we actually solved the problem. We tend to be very focused and are in general extremely passionate with our ideas. We are so focused on the tool and the challenge, that we tend to forget the bigger picture and why we exist as engineers. To solve business / life problems by the means of code.
Disclaimer. Other types of teams are probably also complicated to create, coordinate and evolve. My experience relies on technology teams, with some stints in other areas. So yes, your team of put-your-industry-here might have similar complications as well. Please let me know if so. We may be able to learn from each other! (And yes, the software engineering industry has A LOT to learn from others)
Building code is an artisan process. It is not something you can automate or do in a mindless situation like when you are driving and suddenly realise you arrived home (even though this can be pretty dangerous). Creating software requires extreme focus and dedication in order to know exactly what you are doing, how that will affect the other parts of the system today and tomorrow, and how to do it in a professional way. Doing it solo is so complicated that requires many years of experience to get to that unattainable nirvana of the perfect developer. Managing code and building software by yourself it is very complex indeed.
However, in order to create bigger and better software you need more than 2 hands and one brain. You need specialists in different areas of the process. You need other eyes to tell you where you are screwing up. You need to divide and conquer, and somebody to support your thinking process. You need people to leverage on your capacities and somebody to prioritize. In short: somebody who not just adds, but multiplies. 2 good developers should be able to build much better products than 1 developer twice. (not necessary in half the time though!).
But creating a team is complicated. If not done properly it can cause 2 developers to do a much worse job than 1 in twice the time. When you add the communication problems, the hubris and the social factor, you start encountering diminishing returns. This is not an unknown theory: Smaller teams, “startup style” tend to be much more productive than bigger ones. The star communication factor creates so much overhead and potential problems that all the benefits go down the drain, and many companies end up using rules like the “hand rule” (You must count your team members with the fingers of your hand) or the infamous 2 pizza rule from Jeff Bezos (The team can be as big as two pizzas can feed). So how to get the right balance?
There’s plenty written on this. Big tech giants have their own theories (Apple, Amazon or Google have their own sociologist teams to enhance team performance). Perhaps one of the most celebrated methodologies is the one developed by Dr. Bruce Tuckman in 1965. “Forming, Storming, Norming and Performing”. The theory can be summarised in a short sentence: “people approach tasks differently depending on the quality of their relationships with their co-workers.”. Common sense, right? However the dynamics and the actions a leader should take in each of the stages tend to differ. Another very important point to consider is that those stages are not fixed. Each disrupting factor can move a team from one stage to another or stagnate it in one “box” for ages. There is only one common understanding in the theory: It takes a long time to reach the true performing stages.
It shouldn’t come as a surprise knowing about the M&A movements of “teamquisitions”. Where startup exits happen not necessary for the prospects of a good preforming product or exploding financial KPIs, but because the “performing” teams that tend to be created in that ecosystem (in general is either super good performing teams or completely destroyed companies, while in bigger companies it is easier to free load your way and become invisible for the team or organization, or even worse, be forever storming).
If you have a ultra performing team, that team can tackle any project and as such why would you form project oriented teams that disband after completion and lose all that organically generated glue? Indeed what companies build today are task forces that can be deployed in any situation to solve any problem. Where perhaps the team does not have yet the specific skill or knowledge, but the glue is so tight and the team members support each other so well, that they can accomplish anything.
Therefore team dynamics are complicated. Specially on the storming and norming part, mainly because that’s where problems arise. Where opposing ideas happen and where divergent opinions collide. Some think it is the cocoa effect. When mixing the cocoa on the milk you can’t just throw the powder at it and hope for the best. You need to put spoon by spoon, slowly, and stir for a while. Then you’ll get your perfect cocoa milk.
However I like better the juice analogy. I like to think of a development team as a juice (or a smoothie if you will). Each project, each company, each situation will like a different flavour. Some situations may require a healthy detox green juice with some vegetables on it, while some others might need a wake up shot full of citrics and perhaps ginger. Hell, maybe some situations might benefit from a punch of Gin! But, completely different juices, with different flavours, might have exactly the same ingredient. Apple, or cucumber could be a good base for different types of juices, orange can be used in certain situations but among several other flavours.
Teams are a bit like that. Each member is a different flavour. Individual, atomic, identifiable by itself. But when that flavour gets in touch with others is where the magic (or not) begins. And beware, because some flavours might be incompatible! Your pineapple might fit great with apple, but terrible with guava (juice lovers, mind that I’m not trying to create here a juice recipe book).
And there you have your juice, all set and ready with perhaps 3 ingredients and all is good. But alas, it is needed to add another one! Beware because that ingrediente will completely change the juice flavour. Adding one person to the team, no matter the interview process, the team fit, the role or the experience will always change the team dynamics and modify the status quo. That is a good thing, as long as you’ve done a good hiring process (and if you are lucky) but mind that your original juice will be gone forever. You won’t be able to separate again the apple from the pineapple and the grapes. Now they are one and each new ingredient changes the whole, ideally for the better.
Let me move further with the analogy. Have you ever taken a juice that has been still for a day or two? You tend to get the water on top and the sediments on the bottom. Stratification would be the right term if I was anything close to a chemist. In a way, the same thing happens with teams that are not stirred or shaken often. They tend to segregate in its parts. Each individual member will find his or her confort zone and may become individualistic, creating knowledge silos or even relationship problems. By “shaking” the team we go back to a fully mixed team that can achieve anything where what matters is the combination of all flavours and not each individual one (ey, probably you won’t enjoy that juice without shaking it before consumption!).What means “Shaking” the team you may ask? Well, anything that is not just-doing-the-job. From team building activities, to pair programming, passing through sharing tasks and projects or having “temporal internships” in other teams. The team lead role is critical here as that person is the key one to mentor and ensure this happens. Experiments and R&D sessions, hackatons, conferences and workshops and spikes to test something new. Those things not only mix and match but also create long lasting value for a passionate engineer.
Unfortunately there are no shortcuts (or none that I know of!). Teams are based on personal relations and on trust generation. Trust is generated by solving problems together, working hand on hand and watching each others back. A good leader will create situations that catalyse those behaviours and a bad leader would probably avoid them (for example by not delegating, alienating or pointing fingers). Teams must fail and make mistakes, and then must rely on each other to get back on their feet. When new members join (or leave) teams need time to adapt and reflect.
And after all that time, when each member of the team moves on with his life, will keep a bit of that juice. Will be changed forever and will retain that long lasting flavour forever.
Except durian. Avoid durian at al costs.
—
Would you like to be part of that juice? We are looking for great engineers to join our teams. Ask me! 🙂