It’s common knowledge that 9 developers won’t give birth to a baby in 9 months, but what if all of them were senior developers? They would have to, right? After all, they are Senior Developers.
It may seem that having a team full of senior developers is a Utopia. Nothing could be more wrong. Such teams have the same dysfunctions, or even worse, they can develop dysfunctions that other teams don’t face.
After working for almost 2 years in such a team, I’ve seen problems that none other teams I’ve worked in had to face. An early diagnosis can help you deal with the problem quickly and level up your team. Therefore, I’d like to share my experience of what is worth paying attention to while in a team with a lot of senior developers.
Expectations
Being a Senior Developer is not only about being a highly skilled programmer, but also about responsibility for work, decisions and other team members. Every team needs a leader and a team full of senior developers is a team full of people able to handle such a position. Maybe everyone in the team has once even held a leadership position in the past.
Choosing one person to be a leader may have an impact on team morale because others might feel that they are worse and their position has been demoted. Maybe even during the recruitment process, they might have thought they were being recruited to a leadership position. That can turn into a snowball effect where engagement in the project as well as performance and efficiency fall, people might then think of leaving the team or undermining the current leader.
To keep morale strong, it's important to remember one thing: a team is full of leaders even if only one of them is nominated to this position. Most team leaders have other responsibilities not strictly related to “coding”. Why not split these responsibilities between every team member? Going further, why not split the project so that everyone has a part they are responsible for, a part of which they are the leader. Such an approach can make everyone happy and project velocity will greatly improve.
Tasks that everyone or no one wants to do
Every project has a somewhat balanced distribution of all task types. There are always new features to implement or challenging R&Ds, tasks that everyone wants to work on because it’s a chance to do cool things or learn something new. On the other hand, some tasks don't require a lot of thinking or planning: fixing simple bugs, or other recurring chores that just need to be done.
In teams where you have developers on every level, you can assign a “changing the color of a button” task to a Junior Developer. More complex work can be done by Mids and the most challenging work can be either done or started by Seniors (or divided between the whole team, because not every piece of work requires expert knowledge). Even if it does, people won’t level up without doing tough things.
When your team is full of senior developers it doesn't mean that the distribution of the tasks is different. The number of new features or R&Ds sometimes can be bigger, sometimes can be smaller and the number of volunteers hungry to do them remains constant. The same thing with the other sets of chores. Design or business changes may cause sprints of work, work that doesn’t require experts, but when the team is full of experts no one feels happy doing the job. Of course, easy work for experienced developers is just a formality, besides this fact it’s not optimal for budget, experts don’t like to do things that aren’t challenging. Another thing is that too much super easy work can burn out or impact developer’s vigilance while working on more challenging things. It’s important to divide such work in the entire team so that no one is overwhelmed with unwanted work. On the other hand, we have to remember that no one can work all the time with challenging tasks, so repetitive work can be done over a slack week.
Code reviews
The most common downfall of the code review process is "no one reviewed my changes". When the whole team is aware from their own experience how important code reviews are, this problem should never arise, eventually, no one has an excuse that anyone in the team can do a great quality review, so no one would ever think: “I don’t want to, someone else can review it, I have that important task to finish” - once you think this way, it will come about more frequently. And when others won’t get a review of their work they won’t be willing to review the work of others and so on. That’s why, even with a team full of seniors, it’s very important to remind everyone that code reviews are relevant.
One of my team members once said: “Nothing you have in progress is more important than anything ready for the review”.
Another weakness that can appear in a team full of senior developers is an excess of ideas. Most of the problems developers solve can be solved in a few ways. These solutions are better and worse but are the differences between them so huge? Of course, there are features where every millisecond matters, but when it doesn’t matter is it worth spending time to refactor the solution? What if after the first refactor another developer has another idea, should the code be refactored once again? From my experience, developers in such a team need to put their egos aside and stop forcing their ideas because no one is always right. Using tags in every comment i.e. “suggestion” or “important” to separate things that need to be addressed and what is only nice to have is a good approach. No idea is bad and a team needs to discuss the solutions they’re implementing. Everyone needs to trust others and maintain project velocity because otherwise there is no reason to have any more than one senior developer in a team.
Most likely there is no magical remedy to make Code Review a masterpiece even with a team full of senior developers. The project will always have their ups and downs, with perfect months when work goes smoothly and months when everything drags on. Code reviews can become a real bottleneck to the project so it should be the top priority to make sure they go as well and as smoothly as possible.
Communication
Communication within a team is probably the most important thing that makes teams what they are. Good communication builds trust and when people trust each other, everything is great. On the other hand, lack of communication makes a team nothing more than a bunch of people working on the same project.
With a team full of senior developers, it often happens that everyone is so focused on working on their own domain, especially if they all work remotely, that a periodic lack of communication appears. And that’s okay. Thanks to this, work goes super fast, but it has to be under supervision so that everyone knows why they are not communicating, otherwise someone may start to think that the lack of communication is due to decreasing trust. That’s why it’s important not to resign from regular ways of communication such as stand-ups, retros, grooming, pair programming sessions, 1-on-1's, or with the whole team to chat about things not related to work as well.
Leveling Up
Programmers are people that love to level up, be better, know more, do cool things, learn about something interesting and when they can use that knowledge in a project it’s even better: it’s a win-win situation.
Sharing knowledge between senior developers usually goes smoothly, they understand things quickly, they ask good and valid questions when they have any concerns. But we shouldn’t lie to ourselves, mostly they know the same things. Most likely, none of them would have become senior developers without knowing the core knowledge of their technology. So we are talking about sharing knowledge on very specific topics. Topics that may or may not be relevant to the project. Do your senior developers share their knowledge constantly with other seniors?
Because of this, the problem of not leveling ourselves up may appear. That’s why, it’s important to provide your team with space to level up. There are many ways to do this. The easiest one is just to give them free time in the project for R&Ds. On the other hand, there are probably ideas for new and innovative features that require gaining new skills. Encouraging developers to think of such ideas can be a good balance to learn just for the sake of learning and can also be useful to the project.
Another idea could be not to have a full team of senior developers. Mentoring is a great way to improve developer skills. Junior developers usually ask questions that no one else would ask, they may seem trivial but sometimes maybe even so trivial that senior developers need to look into the documentation. This is a great way to improve core knowledge or to get a better understanding of how things work under the hood.
