Very recently I came across this post by D Spinellis. It listed notes from Grady Booch keynote on the future in Software Engineering. I wasn’t at all surprised that there was a reference in teamwork. As it appears nowadays, with the Agile principles growing in acceptance and popularity, we shouldn’t just invest on the talent or the knowledge but also in the ability of individuals to work in teams.
I have been a very active supporter of teamwork. I do believe that strong teams will always achieve a lot more than individuals. That being said however, I have to acknowledge the fact that in the modern societies, the individual effort is praised a lot more than collective effort and this is something that inhibits teamwork to a great extent.
In his speech, Gary Booch – the founder of UML – has identified the assistance of teams as one of the biggest challenges in the future of Software Development. In other words he wonders, what can we do to assist the work of teams?
I have been fortunate enough, during my career in software development, to work in a variety of teams and projects. I have never worked on my own and have always been part of a team from the very first job I took, until now. Furthermore, the team size I have participated in varies from 2 to 100 people. The purpose of this post is to attempt an answer to Gary Booch’ question.
But prior to every similar discussion one must wonder what makes up a good team? Is there such a definition? Let me try and define this from my personal experience.
Firstly, I believe a good team, has members who communicate very well with each other. The basis of good communication is primarily to listen first and then talk, and secondly to be as concise as possible. On top of this, a positive attitude in communicating plays a very important role in gaining the trust of your fellow team members. Being positive not only means that each team member maintains the ‘can-do’ attitude, but also that you are happy to come to work in this team because of both the people and the project! It also helps if someone enjoys talking with his team mates about other matters besides work.
A good team has enough talent to deal with the various problems that may occur in a project. It’s the responsibility of the manager to acquire all the talent carefully and create this versatility. However one must be careful not to rely on the talent or just the knowledge. As I have previously described, the personality plays a very important role. Enthusiastic individuals that show excitement about the role and the project can be a good start when you are assessing the personality aspect. One of the nicest feelings is where your fellow teammate offers to help you with a problem, or when you offer a second pair of eyes on this piece of code that ‘refuses’ to do what your teammate wants.
There is, of course the situation of denial and several times you will find that someone may not be in a mood to pair-programming, for example. This is where the spirit and the mentality matters most. A polite request / reply can never inhibit the relationship with a teammate. As for your manager? He should be observing all behavior and all interactions without interference. He should encourage direct communication between team members instead of emails / chats / phones (except if you are remotely working.
– How can someone create a good team?
The selection of the team members is the basis of a good team. It is very rare that a manager can choose all his team members from scratch though. In this scenario one must choose carefully and once he decides on 1-2 people he definitely can work with, he should involve them in the screening process and ask their opinion about the rest of the candidates. This should happen in a discrete manner and everyone should be clear that the manager decides. There are many situations in life where the team manager, finds himself placed in a role where he has to manage an existing team of individuals. He / She, who hired him will of course say they back him up and believe in him, but the truth is that if he fails to lead the team, it is he who will be shown the door. This is the real life situation. Most of the time he has to adapt and win each member with his vision and his attitude. Winning each member’s trust can be a very difficult task sometimes leading to tensions and altering the team dynamics in a drastic manner. There have been many cases in real IT life, that projects have failed due to poor team relationships. I believe however in the following principles for creating a good team which should be followed by both team managers and members.
- Be open and honest in all comms
No information should be hidden in a software project between the manager and the team members. Not even between the team members themselves. Budgets should be shared, deadlines too so that everyone has a clear picture. All team members should participate in the meetings and have their say in the matter of discussion. Transparency in communications is vital for the success and the bonding of a team. It will generate meaningful dialogues and can engage all team members in participating.
- Get rid of the hierarchical model
If the team is following an agile structure (tech leads, scrum masters / product owners) it should be clear that there is no hierarchy. Each member has its role in the team and it shouldn’t mean that you are reporting to the next most senior person. This kind of team has a manager (product owner or scrum master) and it should be he who deals with the team dynamics (roles, pay, budget, deadlines etc)
There are still many teams in the world though, that do not follow the agile model. There is still a hierarchy of people often generating more trouble than value. This is normally the case with large teams (my latest project had 100 developers and about 50 managers!!!) and should be avoided at all costs. It doesn’t bring any value and over-complicates communications.
- Always keep the motives high and provide recognition
Two different things combined in one but equally important individually as well. Motivation is what will keep the team running. Many teams have been formed with the only motivation being money. This is a total suicide. It has to go beyond the money and if you work for a large project, beyond the outcome that a big company expects. It doesn’t have to be the same for each team member, and its the job of the team manager to provide this for his team.
Recognition or reward for an achievement is also vital for keeping the team spirit high. When you recognize someone’s efforts this should be done publicly and the respective reward should be equivalent of the effort and agreed with the member himself (preferably prior to joining the team).
But if you have formed the team and followed the principles, how does your team feel empowered?
Teams are truly empowered when their members feel valued within the team itself. If you are a manager consider asking your team all the team about the next deadline and whether its realistic or not. Discuss your budget and ways to distribute it. Leave the choice of technology for your technical people to decide and take their side when an important fight comes up. By being there for the team instead for yourself you will achieve trust and your team will enjoy working for you and your project. Also as mentioned before, achieving true transparency is vital.
One very important aspect of managing the team, is the ownership. In a true team, the team manager should not be hesitating to take ownership of the team’s mistakes. Each member should feel that his manager is his safety net. Exposing individuals mistakes, is a disastrous decision that will not save the manager’s job at the end of the day. In a similar manner, keeping the team isolated from irrelevant comms and people could prove really useful.
Finally, your team should be getting enough challenges to keep them on their toes. It is true that many people lose interest in their job if it becomes ordinary and they don’t have to think in order to produce. Giving them interesting challenges to resolve not only will keep your team motivated but will also keep them from thinking about moving around.
Having mentioned some ideas about empowering teams, I would like to strengthen the point of forming a good team before considering empowerment. I have experienced many cases where, challenges were given to badly formed teams and the gap between team members knowledge would expand instead of shrink. Team dynamics in IT projects will gain a lot of focus in the coming years and hopefully the IT community will realise that it is in desperate need for team players rather than for great and in depth knowledge of one technology.