“Dionysus creates opportunity, Apollo gets results.” — Me, Myself and I (Alec)
Why read this you may ask? Well, I reckon that anyone in software has had to work with a team that doesn’t just consist of ‘Me myself and I’. So from this diary / instructional article, you will learn from my mistakes and misery.
We were a team of four that aimed to create an automatic music genre recognition system (A.K.A. MGR ). We decided to adopt Agile and use Azure DevOps service to facilitate that. This comes with Azure boards and all the other gizmos like Azure Repos, Azure pipelines, and so on.
Azure fell out of favour quickly…
Azure DevOps is not friendly at all for a beginner let alone a team full of them. It is also not prevalent in academia, so you will end up having to convince people to learn something new that is not necessarily related to the project. I wish it had different tiers on how many features are visible or are needed to make Azure boards work smoothly, like Agile for Dummies. It is also not easily accessible from Github since now you can sync it up! We haven’t used it once! Lastly, what is really weird is that it is quite difficult to access your project via the internet. I had to bookmark my project’s page so I didn’t end go looking for my project with a candle in a dungeon. Catch my drift?
Discord for the Rescue with a twist
Discord quickly filled in the void and has been keeping our ship tight and on track with our timeline. However, it is only so because we also signed a semi-official contract on how we would communicate with each other and what our roles are. We shared all contact details and set up very deliberate and clear channels of communication. Each channel is designated for sharing data only or tutorials, etc. We even created a system on how we will handle crises from small to big. This is something that you must ingrain when embarking on a project. Crises are inevitable, it is a guarantee. Consider a new perspective that the darker vices of humans such as power, greed, sex, and revenge play a bigger role in any organization of 1 to 1,000’s on their performance and outcomes. Greed, sex, and revenge will probably not manifest as quickly and obviously, so we shall look at power.
Power dancing with Harmony
We are inclined to approach project decisions as a team (due to the indoctrination of democracy), however deep down we quickly can notice who sways the team decisions the most. The decision-swayer can come into power in various ways: through network, merit, or dominance. Upon team formation, there might be prior bonds, he/she might have demonstrated superior knowledge and adept skills in the domain, or he/she is able to exert his/her influence more easily onto others on the get-go. These are things to watch for so you can better navigate or lead!
There are other roles that consistently manifest upon team formations time and time again as well though. There are those who are criticizers, diplomats, bystanders, followers, challengers and etc. Some of these roles are filled more readily while others not so but are unduly always filled to some degree.
It is paramount to clearly define the possible roles in your new team and create checks and balances when relations are amicable and untainted by inevitable conflicts/tensions.
I admit I am pushing for a more cynical approach when dealing with people. Yet this is what some will call what it means to be a team player. You must strive for harmony and inspire but you must know what and how to deal with the “beneath.” Your goal is to position yourself in such a way that you can rig the team to find its center of harmony. Once this peace is found will your team begin to achieve fantastic results all the while bonding fruitfully.
Here are some tools that helped our team immensely!
So using the RACI matrix for designating roles here is a template. I hyperlinked the RACI matrix to a google doc.
Urgently research how your project’s lifecycle shall evolve (in our case our ML project followed CRISP-DM) this will greatly help with guesstimating your timeline and sprints.
Conclusion
I know this is not like my other very technical and dry articles but these soft skills I believe are too often overlooked. The health of the team determines if your project takes off or nose dives just as much on the technical competence of the members. I hope you took something away from this. In addition, I think this article should kickstart an open forum down below on this continually evolving debate on how to make a team work!
How do you approach team formation?
Code slowly and surely, stay slothy — Slothy
