4 Software team strategies that work
/Flat hierarchy
It's important for the team to feel that they are not bogged down with management. We try to build this into the system by having very flat hierarchy in the teams. Usually a team a has a team lead and everyone reports to her. The team lead can decide pretty much everything as much as day to day operations of the team is concerned. This empowering of the teams help increase both our ingredients. Empowered teams feel more gelled because they feel their actions navigate the whole team and they feel more responsible for the whole group. Less hierarchy makes it easier for the team members to speak out and voice their concerns - increasing openness.
Small Teams
Lines of communications as the team size increases (source: Lines of COMMUNICATION)
Small group sizes are natural. If members of the team cannot know each other on a level where they consider each other friends the team’s ability to cooperate drops. The more people you have in a team the less a single team member contributes to the project - this was known as far back as 1913 when Maximilian Ringelmann discovered that the more people who pulled on a rope, the less effort each individual contributed.
Smaller teams lead to more social cohesion, that leads to more individual responsibility and more productive work done per capita.
There is another strong reason for smaller teams: less time spent on communication. There’s a formula for this, the number of ways conversations can flow between person to person is:
n(n – 1) / 2
where n = the number of people in a team
So this builds up very fast as n becomes larger and larger. The graphic here shows this - things get messy quite fast. And the messier it is the more noise there is to get information across the team and thus more time spent in getting things done.
What’s the ideal team size?
It depends of course on the nature of the project. Jeff Bezos has the famous Two Pizza rule that goes - “If you can’t feed a team with two pizzas, it’s too large.” You’ll have to find out your own rule, but as long as you keep the team small you should win.
A great read when you are thinking about the optimal team size is: Productivity and Team Size: Less is More
Culture of openness
Software is all about discussions and debate. No single person, no matter how many years he has been “doing software” or how many fancy places she has worked in, will always have the correct plan. Yes experience helps but sometimes experience leads to “this is how I did it in 1997” type sentences that usually lead to badly designed software. The only way to solve this is to have discussions and debates (we call them “fights”) where everyone has a chance to voice their concerns. Now this only works if everyone has a say, or rather feels free voice their ideas. If the culture of openness is not there in a team, junior members of the team will always stay silent, or people with louder voice will always be the only people speaking. This gets you nowhere. So cultivate the culture of openness in the team. Take steps that make the team members feel free and relaxed. Our strategies are always to take them out of work environment say in a fun party or in one of trips or adventures and break the ice particularly between junior and senior members of team.
Culture of excellence
Cultivating a culture of excellence is very important for the performance of the team. This is why elite commando forces have “we are the best” motto. A culture of excellence builds a bond between team members that is commitment towards keeping the standard up. This is a basic tribal need of humans - we don’t want to let our tribe down. And when the tribe’s culture is being the best at what they do - that is what everyone strives to do. HBR had a great article about the culture of excellence in companies that’s a good read: Creating a purpose driven organization.
And here’s the customary stolen Dilbert…
