What's in a good team?

About a month ago, I left my position as a Senior Software Engineer / Architect. I held that position for about three years. I think these three years were some of the most productive years, in terms of learning, productivity itself, communication skills... While it is true I ultimately said I want to leave, the story is a bit longer and deeper. I do not want to go into full details here, those who know me are fully aware of the reasons, as are my former co-workers who I still hold to the highest regard. What I do want to point out however, is that the final decision was a culmination of various things done wrong (by me, and by others) and clashes in the way I feel (certain) things should have been handled. And these are exactly why I wanted to write this blog post. I feel that the suggestions I have can be useful to team leaders & managers to motivate their team members and encourage them to stay and contribute to the company, while also feeling welcomed and rewarded.

Things I want, looking forward...

Like I said, I have learnt several things during this time and I will be forever thankful to the whole team for this opportunity. I hope I also taught them some things and gave them some inspiration on how to solve problems. The list under this paragraph is a composition of thoughts I had after I left the office and spent some time at home, just thinking. It's a composition of what I feel are best practices for small teams, and it's a list of things I would do if I were starting my own company today. You may not like all of them. I never said they're the only ones. I know I would be happy in a team that implemented them, and I know a lot of people who would be happy in such a team as well.

• Having an open team turns out to be a huge motivation. A team that works together is connected, understands each other, and more importantly, covers each other's backs when something goes wrong. I was fortunate enough to work in a team where this was true. We had each other's backs and, I think, we each delivered at the end of the day. As projects come and go, teams change, shuffle, as do priorities. I feel it is crucial the team stays together, and that teams that work on projects are kept as large as possible. I also feel, and have come to see, that communication is vital - people, even across teams, need to be able to see what others are facing & ****** solving** and be able to contribute ideas and suggestions. If it was up to me, for teams of up to 10 people, I would keep daily meetings spanning the whole team, and try and partition my key people to work not on a per-project basis, but as much as possible on a problem-solving basis as possible. If someone is good at the middle-tier, try having them build middle tiers as much as possible, but at the same time allow him to learn other things by giving him the option. Never force them!

• Being technologically open - I learnt, soon in my career, that good developers are technology agnostic, and I stand by this today. If a company is focused solely on one technology it will almost always end badly. We tried introducing Technology Fridays during which a team member can get 15 minutes to introduce a new technology. Following this is a Q&A session where other developers can ask questions and have them answered quickly without having to invest a lot of time on finding the right answer. This also means that as projects arrive, teams will always find the best solution, not simply adopt the only one they know.

• Having tech-agnostic management - this, for me, was the key pain point. I think it is vital that project managers, CEOs et al stay away from the technology side of solutions. That's why engineers are on your team, no? That's why they get paid... To think of the best technology solutions to a given problem. That means leaving space for team members to try things, prototype things, figure out the best way to solve something. Granted, time doesn't always allow for these things, nor does pricing. But if you want to have a competitive team in these times, I think this is crucial. It also builds trust between management and the team members. Engineers will know that they are responsible for things working, and product owners/PMs are responsible for defining how they work. A good combination is what makes the end result perfect.

• Good project managers are notdime a dozen, but the difference between a good PM and a bad one is the product being finished on time or not. I've learnt team members are not good project managers, or SCRUM masters, or whatever you want to call them. Although Agile approached advocate certain self-management it is crazy to expect a horde of developers to be able to efficiently plan their own time. That's where a good PM comes in. I consider a good PM someone who focuses on people, guiding each team member to select the problems they want to solve. A good PM also sees if there is a problem within a team and tries to solve it. Problems include team members not getting along well (guess what, it happens! And yes, it happens everywhere!), deadlines being missed and CEOs spending their time with the team instead of selling products/services.

• Money is always tight when there isn't a big "cash cow" project in sight. But there are things teams just need to work more efficiently. That may involve hardware (mice, keyboards, chairs), control toolkits, licences (I can't imagine living without a ReSharper licence) and even education material. The overall cost of these tools per year equals to a monthly cost of a developer if not less. If I were running a company today, I would have this budget set and be it well known from the start of  the year. It's up to each developer to think what they need and convey the need - and up to the CTO to figure out what the whole team needs (e.g. ReSharper licences).

• People have personal issues and that's normal. Team members will deal with their own issues, like loved ones leaving, death in the family or whatever. During these times, they might not be the happy team member, fun for everyone, they usually are, but they will probably still produce quality code. Learn to give them space. Make it clear they can come to you for help, guidance, talks, but give them space, get out of their way. There are complete thesis written on how to deal with this sort of behaviour, but personally, I feel that the best solution is letting them know it's OK and that they can come in for a talk. I know for a fact, the worst solution is poking them constantly, asking what is the problem etc. As a side point, if you have an open team (see point 1), team members will already know what's going on and will be willing to help!

• Host regular (at least yearly) reviews allowing team members to answer:

  • What are my goals in the following time frame? (e.g. I want to write a book, I want to work on front-ends more than back-ends, I want to design databases...)
  • What problems do you feel, are currently present in the team that can be solved, and how would you solve them?
  • What are we, as a team, doing properly and do you think we're advocating it enough?
  • How would you rate yourself at (1) knowledge level, (2) communication, (3) satisfaction and where would you like these ratings to be the next time we ask these questions?
  • What do you feel, you have most improved since the last round of questioning?
  • What do you feel, has your team improved mostly since the last round of questioning?
  • What can you, as a single person do, to improve this team?
  • What can I, as your manager do, to improve this team?
  • Whan can your team members do, to improve this team?
  • What are the types of project you would like to work on? How do the projects you recently worked on relate? Do they fit into those categories, if not, why not?

• Limit the time developers spend with clients. There's a special breed of people that knows how to talk to clients and not over-commit, they're called product/project managers. They know when to let the client near a developer and when to keep them back. Even if the client is internal (e.g. the CEO needs an application developed), there has to be someone standing between the always frantic ideas generated by clients, CEOs etc., and filter them according to priority and relevance. Let developers focus on what they do best - developing applications.

• Keep it quiet. Open-floor office plans are interesting, for sure, and they allow a much better team communication. But they are also the ultimate productivity killer. There are people whistling, singing, talking on the phone, gossiping and overall disturbing this process. If you absolutely want an open office space try to at least separate people who have a lot of interactions (management) from the people who need quite (developers). If possible, try and group developers into smaller offices. From my experience, 3 people in an office is perfect. You can rotate the offices as you rotate teams, but not too quickly. This provides a quiet environment for the team to work, but also for an open enough environment each team member to be accessible. Also, please, never, ever, ever, ever, shout across the office.

• Challenge us! Developers love solving a good challenge. We're prepared to solve these challenges during coffee times, lunch breaks, at home, even during the weekend (at the same time, do not expect us to be constantly available. When someone is out of the office, consider them not available). Try and make these challenges not relate to any client project currently going on, and you, as a manager, will benefit extensively. The team will be motivated to solve new problems and will be learning at the same time. If at all possible, give them some time, during regular working hours, like Google's 20%, to work on interesting stuff. You will thank me later. You can even agree to spin-off successful projects that come out of this... But that is a whole new blog post.

• Be open. Have a Twitter account, use it to converse, not market yourself. Have a blog. Yes, it takes a significant effort to write a quality blog post, but it's worth it. If your teams knows something, make sure people know you know! Sharing knowledge will not mean less money for you, probably quite the opposite. Let team members take some time to write articles, posts, contribute to Stack Overflow...

Whoo... that was a long post. If you read through that, I salute you! I would really welcome any comments you have, even if your views are different from mine.