One of the most surprising things I’ve learned in my time as a software developer is that most hard problems are people problems instead of technical ones. Strangely, people problems rarely get discussed in the context of software development. This is especially surprising given that one of the original values of the agile movement was “individuals and interactions over processes and tools”. As almost everyone is agile these days (at least on paper) we should be talking about how to solve people problems every day. But we don’t. Instead, the focus is either on technical issues or on processes. Continuous improvement is explicitly aimed at processes not on proactively solving people problems or on helping people improve. People problems are also ignored by frameworks like Scrum: Not only are they not mentioned in the Scrum guide, Scrum also likes to pretend that all developers have the same skill set - which is false - and likes to pretend that all developers harmonize with each other. One example for these assumptions in Scrum is the idea that all team members work on the same feature together. This only works in a company where features can be divided infinitely and everybody gets along. There are not many such companies out there.

Because people problems are so rarely discussed, we often mistakenly assume that a problem is caused by a broken process and try to address this by changing the process. For example, if we have quality problems and frequently break existing features when shipping a new software version, it is tempting to just add more bureaucracy to the development process to fix the issue. However, this rarely works because the root cause is most likely a people problem and we cannot solve people problems via process changes! Instead of thinking about processes, we need to think about people. If we struggle with code quality issues, then we need to identify how the bugs are distributed. We will probably find that some teams perform worse than others. We need to look at these hotspots and identify why the developers in these teams perform so poorly. Only this way will we actually solve the problem. If we just make our processes more elaborate, we will slow down all developers including our stars who we want to develop as much code as possible.

If we cannot solve people problems via process changes then how do we solve them? Sometimes, we’re lucky and there is an easy solution which we can take. Maybe a team is unproductive because two headstrong developers argue about everything. Then it can be a good solution to move one of them in a different team which is still missing a leader. In other cases, the solution is not so clear. Imagine a product owner who is in over his head: He just isn’t good at refining requirements which leads to a lot of frustration from the development team. If additional training isn’t enough to fix the problem, then we need to find him a different role. In some cases, even a forced reassignment or a termination are necessary and these are painful and difficult to do. Solving people problems is often unpleasant which is why it is so tempting to just ignore them. However, these problems rarely go away on their own. Ignoring them turns them into a time bomb which can go off at any point in time. Managers need to find the courage to deal with any people problems in their team if they want to be good leaders.

But how do we know that it is actually a people problem? Isn’t it more likely that it is actually a process problem given that the company’s processes form our environment? In fact, some people argue that everything is a process problem. They have a point: Incentives are very powerful and humans react to them. If the established processes set the wrong incentives, then this will produce harmful results. For example, if managers only have a certain time frame to fill an open position, they will rush to fill it even if it means hiring a substandard candidate when the deadline is near. This is clearly a poor process which creates bad incentives. However, processes affect everyone in the organization the same. So, we can conclude that it’s a process issue if we see the same problems in roughly the same severity in all parts of the organization. If we have a high level of variance between different teams then we probably have a people problem. My recommendation is to always assume that it’s a people problem unless proven otherwise. Even if this assumption is wrong and it actually is a process problem, sufficiently skilled and motivated people can compensate for almost all process problems. Compensating for people problems is much more difficult. So, there is a good chance that we improve the situation by actively searching for and solving people problems. If it turns out that we’re wrong, that’s great news as process problems are much easier to solve.

Conclusion

Most hard problems in software development are people problems. We need to assume that a problem is a people problem by default and actively try to handle it. Trying to solve a people problem with a process change doesn’t work.

If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.