Are your developers happy and performing well?
(Merci à Jason Tan pour sa révision de mon anglais qui n’est pas prod ready)
This is a topic that has already been well covered, so everything has probably been written about it. But here is my (very opinionated) take, based on my personal observations.
Over the past 10 years, I have seen many organizational changes, department restructuring, team reorganizing, new directors, new VPs and new developers’ arrival (and others quitting). All this in the same company. Over all those years, an overall goal remains: increasing department velocity while keeping a certain level of quality, all while addressing technical debt. This is a complex and hard-to-achieve objective involving many roles in a business, not only developers. But I am pretty sure that this same objective is the target for all companies.
There are multiple requirements for making a team successful (high velocity / high code quality / low number of bugs). In my opinion, the developer’s ownership and happiness are the most critical. There are probably as many criteria for making developers motivated as there are developers, but here are mine.
By mixing people together in a single team, you may or may not obtain a successful recipe. In general, people work well together. But on very rare occasions, people who have issues working together land in the same team. When this happens, it is usually so obvious that actions will be taken rapidly.
But sometimes, it is the reverse situation. Some people (or group of people) have great unmatched chemistry. And such a situation is not quite as easy to spot for managers. Those people are more effective together and deliver better and quicker results. That must be preserved as much as possible. When you are breaking those kinds of relationships, it is simply impossible to see the impact because there is no way to have metrics about the individual performance of people depending on the people that they are working with. It is not obvious like people struggling to work together.
Ever heard of a developer quitting a job and bringing colleagues with them? This is happiness, when you are willing to switch jobs to continue to work with some people. All that seems trivial, but I have seen people moved to other teams just to fill a seat, without taking into consideration that chemistry. Of course, managers have their own objectives and their own challenges in managing a large group of people, along with the need to respect a roadmap. But when that serves as justification, this can lead to counter-productive effects, undermining that same initial overall objective of having productive and performing teams they are trying to achieve! Managers are aware of their key players, but rarely of those invisible (and rare) relationships.
Having a good fit between people is not a silver bullet. Of course, it is only part of the equation. That can help to make developers happy, but it is not enough. However, I am 100% convinced it is a mandatory requirement.
A couple months ago, I had the opportunity to build a 20-hour DDD training split across a couple of sessions. At the time of writing, I have trained about 5 groups for a total of 25 developers. I know some of them very well, either because I have been in their team in the past, or because we are currently in the same team. And there are some others that I know a little bit because I worked with them during short periods of time during multiteam initiatives. I do not pretend to have a lot of experience as a trainer, but while training these people, I observed something striking. People’s enthusiasm and desire to produce something good was unpaired compared to what I observed on a daily basis during our regular work. I saw much unused potential in some developers. Why is that?
Over the last few years, even with the multiple structural changes, something remained consistent. I observed two things over the years, related to business requirements and architectural requirements.
Business requirements can be decided before developers are even aware of a new project or feature. The business problem analysis and resolution (problem distillation) is done upstream. Sometimes, developers are exposed to the “why” (the reasons and motivations behind a project), but a lot of the times, they only receive the “what” and “how” (what to implement and how to implement it). Usually in the form of a list of requirements that have been preapproved by other people. Developers are then involved at the very last (and ironically, the longest!) part of the project, which is the solution implementation that has already been decided and settled on. When developers find a problem in the solution that they received, or when an unanticipated problem emerges (and guess what, it happens all the time), a feedback loop is then created with the people who initially prepared the plan.
Architectural requirements are very similar. Either they come alongside the business requirements, or they are the central point of a refactoring initiative. In both cases, the thinking and preparation is done before the team is involved.
Many reasons can be used to explain those situations. It can be related to developers’ maturity or confidence toward them. But sometimes, it is at the foundation of how responsibilities are given and split across multiple role layers in a business. That is a cultural thing that is very hard to address because having those big roles and responsibilities at some critical point in a project can simplify project management and makes people comfortable along the way. All this assuming that better decisions would be taken that way. And breaking news, that is not always the case.
All that leads to a situation where developers become unengaged over time, impacting the ownership, the care, the motivation and finally, the productivity of the team. This is something that is subtle, happening over a long period of time. And that is again a paradox because the strategy leading to this situation was supposed to help the productivity of the business by having clear and better solutions defined at first.
Back to my DDD training. Why are those developers behaving a different way in those training sessions compared to their typical day-to-day work? Why are they engaged so much? Why are they asking so many questions? Why are they so willing to receive tips? Why are they so motivated to produce the best solution possible?
The answer is quite easy. They do not feel the pressure to fail, even if the training schedule is tight. But most importantly, they have a purpose, they have ownership. They are involved from the very beginning, they can learn and understand the problem, they question the needs, they can suggest different options, they can experiment with different solutions and they can model the problem the way they want. They have control over their destiny, they are free, they can be creative, and they can learn new things. And this is a far cry from their typical day-to-day work.
Don’t get me wrong, I believe in people having some responsibilities that others don’t. I believe in the architect role for example. I also believe there is a need for some people to have insight about overall business problems, allowing solutions to converge in a way. There is a need to orchestrate the work of multiple teams. I just do not believe that people having those responsibilities should do their work without implicating the people that will transform their idea into a real-life solution or system. Developers can have a huge and positive impact on business problem solving, on global architecture design, on UX choices and in many other fields, not just on solution implementation and support.
You are probably thinking that all this is not new. You are right, it is all related to the concept of multidisciplinary teams and to the agile movement, that were established a couple of decades ago. Software development is still a new and constantly changing discipline. Many people need to unlearn old skills and habits and adapt their practices to reflect today’s reality. The problem is when those old skills and habits were those that make people successful in the past. Resistance to change is hard, and people typically hire people with the same kind of mentality, which makes everything harder to change. But sometimes, and this is what I have been observing for a couple of months, new ideas embracing agility and team ownership emerge. And when this happens, people who care about those ideas rally together to carry on their shoulders this transition. Even if no transition is perfect, moving toward a target goal is always good. All this gives hope. And this is even truer when developers are trusted and involved in the reorganization process, which is the situation for us now.
Involved and trusted developers are developers that will do the extra mile. They will be more productive, and they will care a lot more about what they are doing. And this is contagious, they will carry and prop up others during difficult times.
How are your developers going?
