Saturday, January 06, 2024

Be humble, no Rockstars allowed

Continuous delivery is based on the hypothesis that when facing uncertainty and complex problems (see Cynefin), the appropriate strategy is to assume that we do not know the solution and must continuously learn about the problem and the best possible solution. Additionally, continuous delivery forces us to put in place means to manage errors, which we are sure to make with minimal impact.

If we assume that we know the solution or the problem is sufficiently simple (or just complicated in Cynefin terms), continuous delivery and learning are not the most efficient strategies. In these cases, a direct approach is better, made by some team that has already done it before. However, do not expect to learn anything or improve anything. On the other hand, if it has been done before, doing it again would simply be a waste that we should try to avoid.

"The only way it's all going to go according to plan is if you don't learn anything." - Kent Beck

My experience and context

In my case:

  • I assume that what I come up with is not the best solution.
  • I assume that I have (we have many faults) in developing (I can't even do the 'hello world' right the first time).
  • I assume that we still have a lot to learn about everything (domain, business, tools, needs, etc).

And I have never been in complicated or simple contexts where a better solution had already been made. And if I came across one, I would try by all means not to build a new solution (to avoid waste).

In this context, the discipline of lean product development, with continuous delivery (focused on continuous flow), continuous learning, and sustainable quality, is the best option I know.

For Self-Sufficient Experts

If you consider yourself an expert in everything, who rarely makes mistakes and feels like a 'rockstar' in their field, you might think that you don't need continuous delivery. I suspect that humility and recognizing that EVERYONE (including yourself) makes mistakes are lacking in this case. Maybe I am wrong, and you are some mythological being who does not make mistakes and does not need to learn continuously. If that is the case, my apologies… :)

However, I won’t be able to work with you since I do make mistakes and need to be in a team that uses techniques that allow us to develop products despite errors without living in constant stress.

In summary

I believe that the general trick of this profession is to do teamwork in the best way we know how, with the best techniques we know, and still assume that we are going to make mistakes, that we have to keep learning, that we need to improve, and that we need a quality that allows us to be sustainable. The discipline of continuous delivery (CD, TBD, TDD, etc.) provides me with all of that...


  • Be a great team player. Collaborate and get involved.
  • Create a safe learning environment for your team.
  • Program as best you can but assume that you will fail, so create an environment where failing is manageable and has a low impact on customers.
  • Make the best architectural decisions you can, but assume that you will have to continuously improve it (evolve it).
  • Seek continuous delivery (as a goal that helps us generate the right discipline and a safe work environment).
  • Be humble and accept failure, uncertainty, and lack of knowledge.

I don't want to work with RockStars, nor with x10 developers… I want to work in x10 teams and environments, where learning is constant, questioning is accepted, errors are accepted (since they are low cost) and improvement is continuous.


We need professionals, not heroes.

“I’m Not a Great Programmer, I’m Just a Good Programmer With Great Habits.” — Kent Beck

No comments: