Job titles in software can be pretty crazy! I genuinely think they cause more problems than they solve, and we’d all may as well just choose a nickname for ourselves and use that instead. The reality is that everyone has their own skills and strengths, and it’s the combinations of these in a team who value cooperation, collaboration and results over individual agendas that makes the real magic happen. I see weird and wonderful things like “Senior (level 2) programmer” and even “senior director” titles (bonus crazy points because on closer inspection this is not a board member, i.e. not a director) – what do these even mean? Why can’t we just stop trying to score points off each other and climb over people as if we’re in some kind of zero-sum nonsense competition, and work together like grown-ups rather than fighting over the shiniest badge!
Anyway, I was in a project kick-off meeting with a client recently where the question of resourcing came up, phrased in terms of “how many senior and how many junior developers should I hire”. I smiled, and politely suggested that a better question might be “what traits should I look for”? This particular client, like many that I work with, were about to start a project that I think it is fair to say is different from their core competency, and different from projects they have undertaken before. In this kind of situation, one really dangerous thing to do is to keep thinking in the same way – while another really dangerous thing to do would be to change everything in an uncontrolled way, with no anchor. Specifically, this project was expected to take on a microservices style architecture, representing a vastly different paradigm to building a conventional “monolith” system.
When you’re about to try an approach that is unfamiliar, you want 2 main things. The first is someone who’s seen it before; someone with battle experience who knows some combination of things that did work for them and more importantly some of the dead ends and pitfalls. Having these people on a project can save an absolute fortune, because their prior experience will allow them to recognize and prevent problems. You don’t necessarily need a team made exclusively of people in this category; it would normally be quite expensive to build such a team. The second are people who are keen to learn. These might be people who are at early stages in their career, who have relatively little experience, but who will go above and beyond in researching and learning new things naturally. Sometimes it is better for this category go have people with less experience, especially if the experience would be misleading. In this case, the architectural style is significantly different, and so too much experience with a different style might mean people drift back to other paradigms. If someone’s background is a blank canvas, you get to train people without having to un-teach them old habits first.
Projects of any significant size generally benefit from having someone in the team who has an eye on the big picture – an “architect” if you like, but without the pomp and ceremony that often comes with this. This should be someone who has relevant prior experience, and someone who is mature enough to make decisions, but not be attached emotionally to them. At the start of a project, you have to move, and so a direction gets set; a good architect will be aware that this direction can and probably should change as the team uncover more information about the project. An issue that is often encountered when working with people who proudly sport a “senior” job title is that they can be proud and stubborn, and unable to change their thinking, however much evidence there is that a change may be beneficial. Just because someone has prior experience definitely should not mean that they are not open to further learning!
So long as at least one person is aware of the big picture, there is no need to limit how many people are thinking this way. Ideally the role of leaders within the team is to encourage more people in the team to become leaders – by their actions, rather than by title. Having a good core of strong leader characters in a team should mean that there are always plenty of “go-to” people, who are always ready to help others. It’s really important to understand that leadership is absolutely not about asserting yourself above others; sadly there are still many organizational cultures that encourage this. Things like code reviews where “the senior is always right” are a classic sign that the culture in the team is broken and there is a lack of true leadership. A true leader is someone who others will naturally look to for guidance, and as such will not usually need to assert their position. It falls to the people in these positions to act responsibly, by providing guidance and leadership by example, setting a tone of working together as equals with different and complementary strengths.
For all members of the team, the most important traits are not necessarily specific skills or technologies, but more in the way people think about a problem. This can’t be measured by a tick-box, but is something more subtle that can be teased out as part of interviews and other parts of the selection process. Look for clarity of thought; for reasoned and rational explanations; for enthusiasm and genuine interest in their chosen field; for a collaborative rather than competitive nature. If these traits are there, the rest will come in good time.