How to lose your developers - Mindmap around software development, what not to do to lose developers

Last updated Oct 23, 2021

This post is random thoughts around software development from a developer point of view (strong opinions on the way!). The content covered is mainly based on my career, and the opinions expressed might not fit all scenarios. Do not take the text as a saint grail or a tutorial, it is more like a conversation on what I think about software development, soft skills, hard skills and management.

On top of that, I was inspired by the book Mind Map Mastery from Tony Buzan [1] and also by The software craftsman: professionalism, Pragmatism, Pride by Sandro Mancuso [2], which I share the same opinions as he expressed in the book.

Mind mapping - how to loose your developers

The depicted mind map above is the result of my dive into mind mapping, the subject approach is what this post came to be.

The well known path

Developers usually start picking up a programming language and playing around it. The “standard” is to have a computer science (or any related) degree and then start working for a company.

Usually the shift from study only mode to working mode brings more responsibilities. For example, dealing with deadlines, struggling with bugs, writing documentation, talking with business and trying out new technologies, build prototypes, research, etc (just to name a few).

it is easy

The first way to start a not fruitful discussion in the middle of a meeting with developers is to say the phrase: “its easy”. It is a bonus point if followed by “it’s just a button”. This phrase of impact can be taken as two-sided coin, if it comes from another developer, it will be more likely to be accepted, therefore, if it comes from a business or someone that is not part of the daily coding task of developers, it can be interpreted as an “insult”.

I see no problem with those phrases, but, in a given context where developers are working under pressure, having to deal with meetings, support for clients and many other tasks besides coding, it can be a starter for the developer to lose confidence and start the search for another job.

If we were to do a comparison, would we go to the dentist and say that we have is “easy” to treat?

Lack of documentation

Since the agile manifesto documentation has been a subject of a second matter. Even though, being secondary doesn’t mean to not have it. Teams struggle with outdated documentation (when it exists). I personally think that people misinterpreted the manifesto and uses that as a shield to jump the documentation step. To achieve technical excellence, documentation is needed, as it can be used as a way to share knowledge among the team. The following list enumerates the benefits of having documentation:

  1. Reinforcing what has been done
  2. Share what has been done across the team
  3. Allows improvement, as it is written, it can be analyzed and improved.

The “down” side is to keep it up to date. Documentation should be a commitment to avoid such situations.

You have until Friday to finish up

Imposing deadlines on developers can lead to friction. Developers are not a “code machine”, writing code takes time, creation and problem-solving. Sometimes the step to actually write the code is the last of a chain that starts with the problem to solve.

Building software is not an assembly line, that each stage is well-defined and workers have to do simple moves to accomplish a task. Building software is a solving problem and creative process.

Imposing deadlines on developers uncovers illness under the hood of the team or even the organization. Imagine you going to your dentist and having the following conversation:

  • Dentist: it will take 2 days to finish up your treatment.
  • You: 2 days? I can’t wait, can you do in 1?

This dialog is weird, as you that have no idea is trying to impose how long the dentist’s work is going to take. Did you find this weird? This is the feeling that developers have when managers or business start to pressure for sooner deliveries.

Don’t worry we will test it later

Developers deliver value through tasks, be it in a staging environment or in production, the final word should be from the users, or the ones that are responsible for the feature. It also applies for bug fixes, the one who wrote the bug ticket, should be the one to double-check it and give a positive feedback.

There is a long journey to fix something or implement something. It requires communication both with the business and also code wise, then understanding the code that is in place, modifying it and often, add something on top of it.

It gets worse when the code base is not focused on technical excellence, thus, making the previous steps even harder. [3] Highlights the importance of such technical skills to delivery as fast as possible to the business.

Let’s say that all the steps have been finished up and the bug or feature has been deployed to staging, on the developer side, it is a lot of expectation because it is the time when the user will see the change and have the chance to play with it. This loop should be as short as possible, and not testing practicing test continuously, can potentially leads to:

  • Frustration
  • Lack of confidence with the team

Longer feedback circles can also lead to the feature or bug to be reworked and change too may time, as the cycle is long, often it is difficult to keep track of all the changes and make decisions.

Tackling the engineering culture

Pack Kua, in his talk [4] enumerates a few ideas that I would like to share here as they are engineering oriented. Those ideas are based on his experience working across different projects and companies.

The part I enjoyed the most is the distinction between the enterprise scenario and the startup, on his talk those are totally different things and he uses that to contrast those two worlds.


  1. [1]T. Buzan, Mind map mastery: The complete guide to learning and using the most powerful thinking tool in the universe. Watkins Media Limited, 2018.
  2. [2]S. Mancuso, The software craftsman: professionalism, Pragmatism, Pride. Pearson Education, 2014.
  3. [3]N. Forsgren, J. Humble, and G. Kim, Accelerate—building and scaling high performing technology organizations (The science of lean software and DevOps). IT Revolution Press Portland, 2018.
  4. [4]P. Kua, “Secrets of a Strong Engineering Culture,” 2020 [Online]. Available at: [Accessed: 11-Apr-2021]