Building High Performance Teams: Part 2 – The 3C’s
Many external factors contribute to the success of software development teams. In a previous article, I discussed some characteristics of high-performance teams (HPTs).
- Delivers continuously at a steady pace
- Displays a positive sentiment
- Is eager and willing to contribute to the success of the project and to the development of the people around them
- Values self-improvement and mentorship
I also spoke about operational features, such as team empowerment and strong leadership, which contribute to team success.
But there are other areas that have a pivotal impact on a team's success. These aspects are indicative traits and behaviors of some team members that eventually begin to rub off on other team members. Not everyone in a team needs to be a 'high flyer' or 'top developer'. Rather, a team should comprise a combination of people who want to learn and people who can teach.
The symbiotic nature of such teams leads to mutual benefit for all involved. Less experienced individuals who are eager to learn end up learning more, and improve along the way. The more experienced team members gain satisfaction from seeing those around them improve because of their teaching efforts. The overall team just gets better, works better as a cohesive unit, and delivers successful projects, regularly.
Apart from the factors noted above, there are a few other qualities that I believe stand out within high-performing teams. I call these the three C’s: Craftmanship, communication and customer centricity.
Software craftsmanship is an aspect in software development where coding skill is viewed as an alternative metaphor to engineering or science. It’s the continuous effort to create a working prototype or a system and to iterate and make slight improvements to it over time. It’s a very involved process that sees the craftsmen (i.e. the developers) invest heavily into what is being created. This includes copious amounts of energy, sheer will, determination and, above all, passion. It’s not only about the actual code that is being written but also other aspects that are necessary to ensure the success of that code.
- Understanding the domain better
- Improvement and establishing automated deployment processes
- Using the correct tool/language/library for the task at hand
- Engaging in tasks that improve the coding process
Software craftsmen are not afraid of feedback and actively seek out ways to improve themselves. They care about the result and is delivered to the customer.
In any team-based environment, and in life, communication is a primary tool that we all need to interact with others and exchange information. This seems like common sense but it’s often overlooked and not held in high regard in some team-based environments.
The above cartoon is typically used to describe common misunderstandings in a software project. It's quite poignant in that it shows how bad communication can lead to mismatched expectations at various levels of delivery. It also shows that communication gaps can occur within a single team, between teams and with the client (and other people).
To be fair, communication is difficult, especially when dealing with different people, across various skillsets, with different biases, different cultural backgrounds, varied levels of experience, and each with their own motives and objectives, languages, etc. This excludes the differences you may find when dealing with your customer!
Successful teams consider the above factors and build mutual respect. They work together towards a common goal but also all understand what the game is first. It involves upskilling people where required. Understanding and developing respect for your peers, is a group effort that everyone contributes to.
Externally though, when dealing with a customer, there is a tendency to over-communicate. I don't believe that over-communication has ever led to project failure. Over-communication should not be haphazard. There is planning and organisation and involves everyone in the team. Communication channels are established upfront, whether it is email, instant messaging or a spreadsheet. The point is that all parties involved agree on the channels of communication. Lastly, key contact people are defined as well the roles of everybody involved.
Typically, most developers create software for a paying customer: someone who is willing to commission the creation of a system or solution that will solve some business-related problem or give the customer a competitive edge. As developers, we need to keep that in mind as this plays an important part in the decisions we make and the impact of those decisions.
Firstly, customers should always get what they paid for. However, in most cases, what customers think they want and what they need can be two different things entirely. A critical part of a developer’s role is to always try and create what the customer needs. This means that we must interact and communicate with them regularly.
Customers want working software that meets their needs. They have little consideration for how it was created. Developers want to create working software that makes a difference in someone's life. There is a clear relationship between the motives of the parties involved and this can be leveraged to enhance the product delivered to a customer. Simply put, if a developer can truly understand the customer, their needs and their expectations, a developer is better positioned to create software that has a higher probability of being used and making a difference.
Mileage may vary for different teams, but there is a strong sense that craftsmanship, communication and customer centricity are basic ingredients for high-performance teams. Add some freedom, a bit of authority and autonomy and you’ll have a great team in the making.