After completing more than dozen number of contracts over the course of years, some public, some private sector, I wanted to share my insights on how important team chemistry is for development teams and success within project delivery.
Years ago, during my final year at university, our professor set an assignment, which I thought had little or no impact on Computer Engineering at the time. It was around working with people from different cultural and work backgrounds and how we can overcome difficulties in communication and work ethics. However over the years and after working with a number of clients, I cannot stress how important this assignment was. In this article, I want to talk about difficulties I've faced, the good, bad and ugly experiences working with widely separated teams and how product owners can prevent such issues. I will not name any clients as this is against my point within this article, which is roughly a guideline in improving team chemistry and overcoming difficulties.
Let's start with the ugly one first. During the autumn of 2016, I've taken on a project assisting in development of stock and product control for a major Dutch client based in Rotterdam. The team consisted of two Dutch software engineers, a German development tech lead and a junior developers of Greek background. Every standup we had a tradition of listening to production issues raised by clients from the product owner, potential solutions to bugs raised from the mid-level developers and progress developer of the past day. Every pull request from our junior developer received over 20 non-constructive and sometimes insulting comments from the Lead Developer. Although he was a brilliant developer, he was NOT a team leader. Instead of utilising pull requests to share his experience with others, he simply used it to mark it as not following his vision of the software state he desired. The CTO was too late to intervene and needless to say, we've lost the junior developer after three months, followed by the other mid-level developers. The company had to hire three more contractors to cover the mess and brought back the other developers who resigned after laying off the tech lead.
❌ Team player - Not all good developers are good team players. Those who don't fall into this category is likely to create their own teams and cause friction amongst the team. When hiring, this was my top #1 metric, even before problem solving skills.
The bad experience was actually from a public UK contract which I've worked for more than 8 months. The team spirit and collaboration was all fine. However the product owner measured team success on the number of tickets points covered in each sprint without taking into the account of production bug fixes, architecture enhancements and number of meetings involved. Invitations to three hour long meetings per day and expecting eight hour progress is each team member is simply unrealistic.
❌ Unrealistic Product Owners - Unnoticed team achievements and a simple JIRA ticket number aggregation isn't a metric for success. Protect your team at all costs, voice the pressures being raised on you and your responses of protection of the team. Your team will be grateful. This will create an attachment with your team!
And finally the good experience. On one of my more recent contracts, I've had the pleasure of working with Benny, who has not not just been a good tech lead but an excellent team player, open to ideas, collaboration and suggestions. Software can have a number of solutions, listening to your team and getting their input is the best way in creating a team feeling. Not each ticket will require collaboration but big ones which affect the team will and should require input from all the team, whether junior, mid level or senior, its the perfect test bed of transferring knowledge about the system and covering edge cases which one might've missed.
✅ Good team players will create the perfect atmosphere for success.
Latest comments (0)