dagblog.
← Archive

Notes on Team Geek


Archive image in Notes on Team Geek, figure 1
Image could not be loaded. Archive image in Notes on Team Geek, figure 1
↗ Medium

A programmer's favorite interface for communicating with the outside world is the compiler, even if its output is sometimes a little incompatible and not much use when talking to other people. Most geeks mistakenly take the technical side of software to be the only measure of success. Often, to their great annoyance, what decides the outcome is the human side of development: how well people understand and respect each other, how they communicate within the team and how they communicate outside it with management and customers. The human factor and its effect on software development are the subject of Team Geek, subtitled A Software Developer’s Guide to Working Well with Others. I'll share a few observations from the book that caught my attention.

Humility, respect and trust

Almost every social conflict can ultimately be traced back to a lack of humility, respect, or trust.

The central idea of the book is to put three principles into practice: humility, respect and trust.

Humility
I am not the center of the universe, and I'm certainly not infallible. I'm always open to learning new things and improving myself.
Respect
I respect the individual abilities and capabilities of the people I work with.
Trust
I trust that others are capable of doing the right things and making the right decisions at the right time.

The importance of putting your own ego aside runs through the whole book. It's understandable, because as the authors rightly point out, software development is a team sport. Individuals set aside their egos for the good of the team, and the only ego you build up is the team's.

Culture

Building a team stands or falls on a culture that defines the formal and informal rules by which the team operates. The culture and the people you choose to hire shape each other.

A strong culture gives you focus, efficiency, and strength, and these things make for a happier team.

A strong culture is focused above all on delivering quality software. A weak culture is focused elsewhere. To me, a sign of a weak culture is trolling or constantly having meetings. If you pour all your energy into heated debates on the immortality of the beetle, you'll earn the admiration of the local entomology club and do absolutely nothing to deliver better software. In short, you lose your drive to score, and that's the only thing that counts here.

If your team’s primary focus is anything other than that (e.g., partying, attending meetings, practicing one- upmanship) your team may bond tightly, but you won’t get very much software written.

What makes a culture strong

  • Mission statement — If you want everybody pulling on the same rope, preferably in the same direction, define it. Knowing it matters in everyday decisions as well as strategic ones.
  • Effective meetings
  • Team ego, which I mentioned earlier
  • Communication — Set up appropriate channels, such as discussion groups, online chat and design documents. This matters if your team is spread out geographically and also if you need to look back at why a decision was made.

The way you make decisions is another story for both strong and weak cultures. Strong cultures tend to make decisions by consensus, weak ones from the top down. Consensus fits the principles of humility, respect and trust better and is attractive because it gives people freedom and autonomy. If you want to hire the best engineers, you can hardly expect them to accept decisions someone else makes for them. They'll prefer a culture that lets them take part in deciding.

Who you choose has a big effect on the culture that takes shape. If you hire people who don't fit, for example because they won't put their egos aside for the team, it will fall apart. No individual is so brilliant that they're worth changing the culture for. Remember, software development is a team sport. One thing any culture does is attract people who think similarly. The culture then goes on to shape them.

Organizations

Every organization you work in has its own rules and processes. If you understand them, you can bend them so they work in your favor. A few techniques can help. In my experience, including a few years in a corporation, some of them are very effective.

Ask forgiveness, not permission
It's easy to shift responsibility to someone else by asking whether you can do something. Your back is covered, but you're also more likely to hear no, and you'll never get anywhere. Sometimes it's worth simply trying it, then apologizing and asking forgiveness if it doesn't work out.
If you can’t make it happen from the top, make it happen from the bottom
If you can't convince your bosses of something, such as the need for agile development, start from the bottom. Get enough support from your colleagues, start doing it guerrilla-style, and if it catches on, your bosses will have little choice but to accept it.
The gray economy
My favorite. Every company has cooperation outside its official processes. Team A built a tool, and I need some advice about it, so I go see them and they help. When they need something from my team, they can be pretty sure we'll help them too. A service or favor with no demand for something in return.

Leading people

After a while you'll usually move from a purely technical role where you're responsible only for yourself into one where you lead others. There are plenty of ways to screw it up and a few tips that can help. Every leader should realize that their ultimate goal is to protect the team and clear away the obstacles it runs into during development. Besides the technical side, which may no longer play such an important role, you'll have to deal above all with the human side, surprising as that may sound. A good leader uses humility, respect and trust as the basis for the kind of culture we've already discussed.

  • Fear of failure. People who are afraid of failing take no risks. People who take no risks can only achieve so much. Foster a culture where failure is an opportunity to learn rather than cause for punishment. Encourage failing fast as well. If something doesn't work, you want to know quickly. You'll get better results because people won't be afraid to take a risk. If you don't fail at least once a year, you aren't taking much risk.
  • Ignoring people's difficulties. Everybody occasionally finds themselves unable to meet the formal obligations set by company rules. You have a great employee who commutes two hours every day and has to leave at four, even though the official rule is that nobody may leave before five. Let them do it or find a way around the rule. They'll repay you many times over.
  • Treating people like schoolchildren. If you treat the people who report to you like little brats, expect them to start acting like it. This is mainly about micromanagement. Follow the HRT principles and show people respect and trust.
  • Hiring weaker people. You try to hire people less capable than you are because you fear for your job and want people you can manipulate. Do the opposite. Hire people who are better and more capable than you are. Apart from letting you go on vacation without worrying, it will force you to keep improving.
  • Ignoring people whose performance is slipping. Sticking your head in the sand will cause more problems than it solves. Either you'll have to do more work to cover for them or someone else on the team will. That isn't sustainable. Sit down with them, agree on clear tasks and goals, and check progress regularly. If it still doesn't work out, let them go.
  • Compromising on hiring. You have an open position, get ten résumés, invite five people to interview and take the best of them, even though you wouldn't have hired that person under other circumstances. Over time the team deteriorates. It's better to leave a position open than to hire just because you can. Focus on quality.

Motivation

The chapter on what motivates people caught my attention. There's intrinsic and extrinsic motivation. Extrinsic motivation comes from outside incentives such as money. Intrinsic motivation comes from within, such as feeling satisfied or seeing meaning in what you do. Intrinsic motivation has a greater effect on overall productivity. The strongest drivers of it are autonomy, purpose and mastery. In other words, if you want to motivate people, give them a worthwhile goal to commit to and the freedom to work toward it, then let them do the work and get better at it.

Of course the book contains more than fits in one article. I'd recommend reading it. It isn't long, and with a little effort you can finish it in a few days. I've also made a mind map of my notes available. And I found a shorter review on the SW Samurai blog.

Medium version

Related articles

Related CZ Podcast episodes