Introduction
I've been pondering a while how to best work together in software teams. I'm sure there are as many ways to organize a team as there are teams, but I wanted to spend some time reflecting on my own experiences and maybe see if my conclusions actually build op towards some method that already exists. Wouldn't that be grand?
My experiences
In my decade as a software developer, I have mostly worked in 1-man teams of very small teams of just 2-3 people. I have always been the most senior developer in the team (even straight out of school), and have never been mentored by a professional from my field.
This has always scared my quite a bit, and added a tonne to my Imposter Syndrome. I need to make sure that I learn all the valuable lessons needed in order to be that mentor for the other developers in my team! So I constantly try to stay up to date with latest discussions online, and try to learn from the best in the field.
During my time at my current job, I have been the only constant in the team. I have seen a lot of people come and go, and every time fresh hires join, I need to relearn how to integrate them into the team, and this is what I wanted to reflect on here.
There is a lot of talk online about "Rockstar" developers and "10x" developers. These mythical beasts who perform 10 times the work of their peers, and should be respected and worshipped. I don't believe such people really exist. And if they do, I think it may be a sign of dysfunction, and not something to strive for.
Why can an individual do 10x more than the others? Well:
- They designed the system from their own draconian mind dreamed up
- They stuck around long enough to know all the little pitfalls they made for themselves, and how to avoid them
- They do not accept criticism and suggestions for improvements to the system, because it would slow them down
- They do not take the time to integrate the other team members and build a shared learning
This is all very critical. I understand that capable and skilled professionals exist, of course, but I don't think simply measuring the output in lines of code is a good way to measure the value of a team member over all.
Building a team
I've seen short-lived teams working together for weeks only, and long-lived teams that work closely for years. A shared challenge for both, is that individuals come with very different tools in their toolbox. Software development is a vast field, and no two people know the same things. So how to we learn from each other, and how to we settle on what is best for the project and not simply for the individual?
When peers get together to discuss, a topic may be well understood, but due to the different skill sets/toolboxes, the developers may have a different idea of what is the best solution. When they try to explain their stance, the other won't understand, because it won't track with their experiences/skill sets. so that matter cannot be settled in the room between two peers.
That is a problem! How is that addressed? So far, the way I have handled situations like this is to make sure that there is an understanding of who has the final say. A team has a "lead", and it is up to the "lead" to decide what is best for the project. In that way, we no longer have to reach an agreement. The "lead" can speak and listen and evaluate, and then finally make a decision. Decisions may mean that either the lead or the team will need to study up and fill some gaps in knowledge, but this effort brings the team's competences closer to a union.
When teams have a lead, however, it is important that the lead is humble! We don't want to empower an ego and create a rockstar situation. The lead has to put personal opinions aside and make sure that they make the decisions that are right for the project. This may mean that the lead needs to fill their own knowledge gaps.
Working with other teams
If all teams are organized this way then; where a single individual is the lead, how do we work together with other teams? How do we make sure that we are not stepping on each other's toes?
I don't think there is a singular answer here. If the leads on each team work well together and see eye to eye on problems and solutions, they can work out compromised between themselves and keep things flowing. If, however, the teams do not see eye to eye, it may be worth establishing and interface contract between the teams. Each team can make decisions for their own section of the project, and then will only need to agree on where the project scopes meet.
This is starting to smell a little like "Microservices", where each team develop their own service, and maintain contracts between services. Doesn't have to be an architecture decision though. It can simply mean that each team has a clear scope of what their responsibilities are, and where they connect to other teams' responsibilities.
Establishing documentation of team decision and processes
No matter how the teams are organized, a key point that I often see neglected is the documentation of the team's scope, responsibities, and decisions. Many teams stress that they must have a "style guide", which determines what code style the team members must adhere to. That is all well and good, but that can also mostly be automated through tools like Editorconfig files and linters.
More importantly, documentation around the project structure, software architecture, what components a team is responsible for, and what they they are NOT allowed to mess with. These are often carried mouth to mouth and never written down, and I think that contributes to a messy work environment and a lot of misunderstandings.
On the flip side, I have also seen teams that document everything. They have a wiki page for every little thing, and it is impossible to find the information you need. So there is a balance to be struck here.
Closing remarks
I'm not sure if I have any conclusion to draw on this. There are many more considerations here, and maybe I am revealing my lack of experience with various management frameworks, because I do see that many of these problems are some of what things like SCRUM and Agile are tryign to solve.
I suppose I will keep reading on the subject, and maybe I'll come back with more insights 😉