While reading Atomic Habits I stumbled on a phrase that got me thinking on my goals as a team leader: “Suffering is the source of progress.”

I’ve worked on several projects where the suffering was seen as usual. It was so usual that the developers didn’t even question it at all. I still see it happening to this day even on healthy teams and projects. There’s this thing that happens that causes suffering somehow, but we’re all so used to it that we just take it as is without questioning.

We may have times where we have more bugs than usual, we may have build times that are troublesome, and we may even have flaky tests that force us to rerun those builds. We may have a process that fosters merge conflicts on sizable features that take some days to overcome. We may have lots of meetings that we don’t feel that bring enough value. We may need to save two days per sprint for demos and planing and we don’t see value in it. We may have parts of the code that are untested and with bad quality and everyone’s afraid of touching that.

The list goes on and on. Each team will have their specific issues on that list. Sometimes we have people that complain. Sometimes we just feel that it’s the way it is and that we can’t do much.

Looking back, I do see how the suffering I had from some practices contributed for my progress as a developer. There are several practices that I vouch for that are a direct result of this suffering: unit tests, functional programming, RFCs, zero bug policy, etc.

I accept that failure happens but I always push for it not to happen again. I try to change my habits when I do something wrong and I’m an advocate for a postmortem culture.

I’d say that my main process is actually to make sure that we remove most suffering from the team. This means more focus on productivity and satisfaction and being proactive today to prevent suffering tomorrow. So I believe that with enough time and the right mindset, a team can will reach a sweet spot where most suffering is minimized.

But if we reach that sweet spot, does that mean that we will stop progressing as a team and individuals? Because we’ve lost the thing that motivated us to be better?

Maybe this is an utopia. Maybe we’ll never reach that sweet spot. There’s always code that needs to be improved, even if we just did it 6 months ago. There’s always people joining and leaving the team and that always changes the personality of the team and the way we tackle problems. There’s always some deadlines that will put our processes to the test. Even if things are going great, we may have that production issue that brings up performance issues and force us to reconsider our application and our ways of working. And even if we have a team that is healthy, scaling it has its own set of problems.

And even if we did achieve a team that had zero problems and suffering, there’s also the part of making sure we keep the discipline and motivation to stay at that level. And that by itself can be a source of new problems that will cause their own levels of suffering that will motivate us to make new progress.

My conclusion from all this is that we do need some suffering, and that it’s healthy to have it in healthy doses. It will force us to leave our comfort zone. This is something that I actually do to my mentees. I may see them going on a wrong path and let them pursuit it. But when the problems arise I’ll expect them to properly handle the problems and consider what led them to those issues and how to prevent them in the future.