In software development we always again speak about the team, the team that meets together for planning and realizing a project, a common goal. But so many times I have the feeling that “team” is just used as a synonym for a couple of people mixed together because they have to. But that’s not a team as it should be. So often I miss the spirit, the cohesion…

The Team

According to Wikipedia a team

[…] comprises a group of people or animals linked in a common purpose.

The common purpose is the key aspect here. Take a football team. They have a clear, common objective: to win the game. Still, inside the team there are quite different figures

• a goalkeeper which is responsible to make sure the other team does hit a goal
• the defense player which supports the goal keeper, making the life of the adversary as hard as possible to even reach the goal
• the attackers which have to hit as many goals possible
• the midfeld player which connects the defense and attackers
• the lead player or skipper which is responsible for leading the team

Different roles with different very concrete responsibilities. But no one is more or less important than the other, right?? Not even the lead player. Each single player has its own unique value and capabilities. There might be those superstars, but in the end only the team that works best together will be able to succeed in the long run.

“Team Geek - A Software Developer’s Guide to Working Well with Others” by Brian W. Fitzpatrick and Ben Collins-Sussman (O’Reilly)

This is the title of the last book I received from O’Reilly.

Brian Fitzpatrick and Ben Collins-Sussman, both lead developers at Google, describe their experiences and lessons learned during their career as developers and team leads at Google.

Software development is a team sport.

The book treats exactly these kind of interpersonal relationships that take place in every serious development team. “Team Geek” starts by demistifying the “Myth of the Genius Programmer”, detailing why working in isolation is considered harmful as well as explaining what’s the “bus factor” of a team. A very interesting part is the chapter about building a successful team culture. It talks about the enourmous importance of communication in the software development process, presenting a couple of communication patterns. But it doesn’t finish there, it also treats the question about why every boat needs a captain. Basically speaking about what the role of an ideal leader should be, highlighting several antipatterns such as ignoring human issues or to treat your team like children. For sure one of the most impressing quotes in that chapter is that

“People are like plants” - Different engineers need different things to grow.

So to speak, we cannot just treat all of them as being the same. People are individuals. It always again becomes interesting as Fitz and Ben always again reference to real life examples they personally experienced when working on SVN. They don’t only include the pros but also - for instance - on how to deal with poisonous people, how to treat them and when its really time to abandon them.

The book is amazing and contains lots of useful information. But in the end it all boils down to HRT.

HRT

There is a key ingredient for these different team stakeholders to play together in a well manner and it is called “HRT”, pronounced “heart”.

HRT stands for

Humility

You are not the center of the universe. You’re neither omniscient nor infallible. You’re open to self-improvement.

Respect

You genuinely care about others you work with. You treat them as human beings, and appreciate their abilities and accomplishments.

Trust

You believe others are competent and will do the right thing, and you’re OK with letting them drive when appropriate.

These simple pillars should be the core of every team. They’re simple and do not need any further clarifications.

So…

…stop ranting and become a team player. Trust in the fact that everyone in the team does his best, respect the work created by others, accept criticism and propose improvements. That’s the only way to become a better software developer (and not only) after all.

Reflect about HRT the next time your in a team. Are you following these principals? Do you treat others with respect? Are you a team player or a lone wolf? In the end, these don’t just apply to software development…