Why your team might be holding you back
About a week ago, my wife and I went to our first escape room in the Netherlands. We’ve been in about 12-15 escape rooms before, and were always able to escape as a team of two. Not this time, however. This escape room was the first where we failed to escape.
Poisoned by the corporate world I decided to do a postmortem of what went wrong, and what we could have done better in order to increase our chances to escape. We both came to a conclusion that adding two more people would have increased our chances to escape, as the room relied a lot on multitasking in its first phase. When we tried to think who we would like to take with us, if we could, we came to a conclusion that most of our friends would not be helpful.
Some, we don’t know well enough. Others are as competitive as us, and a team of 4 leaders can lead to only one outcome: failure due to inability to follow rather than lead. This recent experience, together with some past thought about software engineering as a team sport, made me reconsider the accepted norm of software engineering teams.
Why your team might be holding you back
It’s pretty common to accept the fact that software is developed in teams. Solo developers are an exception, and any successful MVPs that are built by 2 people, are going to grow into a big development team eventually. However, developing software in teams is not the be-all end-all solution. In fact, there are some issues that arise strictly from the fact that we have a team. Let’s look at these issues.
There are two ways to define a team on a given project. A team can be a combination of multiple disciplines like backend developer, frontend developer, QA engineer, designer and DevOps. But a team can also be 7 backend engineers. The former are less prone to team issues, however some issues also applies to multidiscipline teams.
The first issue I would like to discuss is the obvious concept on stepping of each other toes. When a team is too big, people start to work on overlapping functionalities. We try to pretend that we can solve it with feature branches and occasional rebase—in reality we can’t. The bigger the team, the more they step on each other toes.
Another issue with team work is the fact that not all team members are on the same page. You see, in reality, if we look at software companies, we assume they have one goal—build product for their customers and make money. As an engineer who joined such company, ideally you should inherit this goal. In reality, however, this is not true. Due to corporate BS and things like career ladders, every team member has a hidden agenda. It’s like these board games when you all work as a team towards common goal, but the actual winner of the game is the one who fulfills his/her hidden agenda. One such game is “The Resistance”, where everybody claims to be member of the resistance who tries to overthrow the government, but at least two people (depending on the size of the group) are secret spies who try to sabotage the resistance.
I’m not saying that in a corporate world, members of a team try to sabotage the entire team, but I am claiming that people have hidden agendas. It’s even part the growth plan. So members of the team might get tasks like “lead the design of a complex feature” in order to score points in their leadership qualities so that they can get promoted in the next promotion cycle. This creates a weird dynamic inside the team because team members would focus on reaching their personal goals while putting the company goal on a second place.
Composition of the team also affects its success. If we look at job requirements, we can agree that everyone wants the best of the best. They want the top performers, and A-players, rock stars, and ninjas. And while in theory it sounds great, in reality it’s a recipe for disaster.
If we look back at my escape room example, my wife and I wouldn’t take any of our friends with us. Maybe to have fun together, but not if our goal is to escape. We both have successful friends who are motivated and posses leadership qualities. Smart and successful people, usually, don’t like authority. In order to be a leader you need to be able to question the norm, and you don’t like to follow orders.
The same can be said for top performing software engineers. They are top performers, or A-players, because they question authority and dare to change what’s accepted. Gather a team of such people together, try to appoint one to be the lead, and you will get into constant refactoring sessions as nobody will be satisfied with the code quality of his peers. But companies seem to ignore it.
Lastly, team size correlates with growth. The other day I was watching an interview with Pavel Durov, the creator of VK and Telegram messenger. Telegram is a messenger that is on a path to reach 1 billion monthly active users, while having only about 30 engineers according to Pavel. When asked by interviewer why other companies have so much engineers, Pavel shared an interesting insight. It’s his words, so take it as you wish. He said that he met with Jake Dorsey at a time and told him that Twitter does not need that many engineers in order to run. Dorsey agreed with Pavel, and in reply said that he can’t downsize the teams as it will signal that something is wrong with the company.
And while I can’t attest to the existence of such conversation between the two, I can agree with a clear fact that team size equals growth. The moment the project is deemed as important, higher management will allocate monetary resources primary for one use-case: hiring. It becomes the number one priority of the team lead—to grow his team. And it creates a double-edged sword. From inside the company, team growth correlates with success of the product. From outside, candidates don’t want to work in small teams as they might see the project not as important as project that has a bigger team.
The lone-wolf
People who like or want to work alone, are not viewed well in the eyes of the corporate world. Every job requirement wants people who can work alone if needed, usually because companies don’t want to babysit you or save cost to avoid investing in proper documentation and/or trainings; but you also need to be able to work in a team and be a great team player, which usually means that you need to play the corporate rules of pointless meetings and other rituals around development cycles.
Derek Sivers wrote a nice paragraph about it:
Nobody gives a novelist shit for writing alone. But an entrepreneur, programmer, or musician is expected to collaborate. I disagree, for me. I prefer the life of a novelist, whether I’m writing code, music, or systems.
And I’d like to agree with Derek here. The moment I switched to a small team (we are two people), I must say that I find it way more effective compared to 5+ people teams I had before. There are no hidden agendas as we don’t participate in the ladders games. Nor we step on each other toes, as the product scope is huge. While infrastructure related code affects both of us, individual feature development is diverse enough that we can operate each by himself.
I believe that modern software development practices were inherited from wrong disciplines. Software development viewed more as a factory assembly line where more people equals higher output, but it’s far from the truth. A lot of the modern team dynamics are flawed, and they tend to harm productivity of each individual, thus sabotaging the entire team. I think that software engineering would benefit more if we would focus on one-man-teams or small, less than 3–4 people, teams. This configuration provides higher development velocity, and reduces knowledge fragmentation.
Development velocity is improved because nobody has hidden agendas, people don’t step on each other toes, and there is less overhead in managing the team, thus you are able to get rid of rituals such as stand-ups, plannings, retrospectives, etc. Knowledge fragmentation is reduces because each individual has bigger knowledge of the system. With bigger teams, in order to avoid stepping on each other toes, each engineer is given a smaller subset of the system, thus known as “a cog in the machine”.
Consider the above the next time you want to join a big team or scale your own team.