Error culture refers to a team’s open approach to software errors and defects: errors are not hidden or sanctioned, but recognized as a normal part of the development process. This is successful when teams clarify together at the start of the project what an error means and how it is dealt with. Processes alone are not enough; the interpersonal level is crucial.
Key Takeaways
- Error culture is not reflected in glossy documents, but in how a team deals with a found defect in a specific moment of conflict.
- If you clarify together at the beginning of the project what finding defects means for the team, you lay the foundation for testers to be able to communicate defects without friction.
- Quality management gains weight when defect metrics flow into formal quality gates and influence decisions in the project instead of disappearing in reports that nobody reads.
- Learning from mistakes does not usually fail because of a lack of will, but because no time is planned for it; those who do take the time to learn will avoid the same mistakes in the next section.
- Criticism is more constructive if you adapt the message to the person without distorting the content, which requires knowledge of the person and does not work from day one.
Error culture shows how successful a project is
How an organization deals with errors is a reliable early indicator of a project’s chances of success. Observing how a team reacts to software defects or mishaps in the process gives you an idea of how the collaboration is working.
Katja Radom has been working on IT transformation projects for a long time, from several perspectives: testing, test management, quality assurance, IT service management and project management. A pattern emerges from these roles. The way in which errors are handled gives an indication of the culture. And this culture can be improved.
Processes and tools remain important. But they are not enough. If the culture is not right, established processes do not work as they could. Culture is not everything, but it is the lever with the greatest impact.
Why a good error culture starts on the first day
A sustainable error culture is created when a team clarifies early on what happens when errors occur. This tone can be set at the beginning of a project, before the first defect causes friction.
The concrete start is a discussion with everyone involved: Is it bad for you to find or make a mistake? If so, how do we change this? If a team knows right from the start that 30 errors found or made are not a drama because everyone is working in the same direction, the pressure is reduced in individual cases.
This brings error culture closer to people change management. It’s not about writing a promise in the project manual, but about creating a shared expectation before things get serious.
Openness on the vision board is not enough
A declared openness fizzles out as soon as the first real error occurs. A test strategy or project manual can state that errors are dealt with openly: if something then happens, this sentence is quickly forgotten.
The difference lies in repetition. In an agile environment, the retrospective is a good way to regularly address the topic. In non-agile contexts, a fixed rhythm in which the team sits down together and asks how things went helps.
This only becomes effective when it is anchored in the project management and stakeholders. Then it is also possible to say: We have too much friction at the moment because something is not working at a certain level. Pausing and looking at what can be changed is part of the culture.
Put yourself in the other person’s shoes
Conflicts between roles are easier to resolve if you understand what the other person’s role is. Managers are often part of the problem, but behind their behavior lie their own goals and constraints.
The useful question is: What is the manager’s job, what are their goals and what are my goals? Sometimes it is simply unavoidable that these goals clash. If you know this, you can deal with it in a more relaxed way than if you expect the other person to be just like you.
This applies not only to different countries, but also to different roles and responsibilities. When in doubt, it helps to ask. Especially if there is already a crisis, you have little to lose. You are not guaranteed an answer, but without question you are guaranteed none.
Stereotypes about cultures are only good as a starting point
National stereotypes about how to deal with mistakes are partly authorized and partly lazy. The Americans who celebrate mistakes, the serious North Germans: these stereotypes come from somewhere, but they don’t apply to everyone.
The productive approach is curiosity instead of pigeonholing. You compare your specific counterpart against the stereotype and see what is actually there. This applies to international teams just as much as to colleagues from your own cultural area.
How to make mistakes in the project visible enough
Error prevention gains weight if it is integrated into the overall quality management system instead of being relegated to the engine room. In larger projects, this means that finding and avoiding errors flows into a quality gate.
As soon as this weight is incorporated into project decisions, a different dynamic is created. Whoever tests and whoever completes things so that they can be tested works differently than if the end result is just a report that nobody reads.
Smaller projects rarely have a formal quality gate process. Parts of this idea can also be adopted there. There is no one size fits all here, but there are building blocks.
Learning from mistakes takes time, which must be planned for
Learning from mistakes does not usually fail because of a lack of will, but because of a lack of time. In many projects, a bug is closed and never looked at again; nothing happens after the project.
The analysis of defects and mishaps in the team needs its own slot. This is rarely at a crucial moment, such as when a go-live date that has been set in stone is approaching and there is suddenly less testing time left. Then it doesn’t always work.
It doesn’t have to be a three-day off-site. Even on a small scale, the evaluation is worthwhile if the findings are incorporated into the next sprint or project phase. You save time afterwards because the same mistakes don’t happen again. The reflex to immediate success often stands in the way of this.
Staying honest is part of it: This doesn’t work every time either. But every now and then it works, and if you don’t try at all, it will never work.
Criticism needs the relationship first, then the content
Difficult messages are better received if you already know the other person. On the first day of a project, people meet who are not yet able to assess each other. The big criticism does not belong on day one.
The same content can be conveyed in different ways. The more forms of expression you know for your message and the better you assess the person, the better you can adapt the form without distorting the content. A bang can never be completely avoided.
The social impression that criticism is hardly possible is not reflected one-to-one in everyday project work. Openness is the prerequisite for this approach to work at all.
How do you accept criticism yourself without defending yourself
The first impulse after criticism rarely leads to a good reaction. It is more helpful to listen first and suppress the impulse. After a few minutes, sometimes not until the next day, you look at the same thing with different eyes.
A simple question can help: What relevance will the thing I’m currently annoyed about still have tomorrow? In a week’s time? In a month’s time? By the month at the latest, the answer is often: totally irrelevant. This distance makes the view more neutral.
It’s also worth separating: what do I have in my own hands and can I change, and what is actually a problem for the other person? A message often says more about the inner life of the sender than about the person to whom it is addressed.
If you have run someone over in the heat of the moment, it helps to say afterwards: I’m sorry that I ran you over like that, let’s talk about it again. Many people find it difficult to apologize, but it works.
How to start an error culture in your team without forcing it
The easiest starting point is the beginning of a project or a newly formed team. You don’t always have this luxury situation, which is why starting in the middle of an ongoing project requires a sure instinct.
Rushing ahead head-on can backfire. If a tester brings the idea of a better error culture to the team via the project manager and everyone looks at the initiator, it is easily received badly. It works better in the group and via the opportunities for exchange that the respective setting provides.
A viable approach looks like this:
- Start by making friends with someone you are well connected with.
- Ideally, find several people to join you.
- Try it out together: What are we doing today? Does it work for us? If not, what do we change?
- Never change everything at once.
Agile, hybrid and waterfall teams need different settings. Trying to change everything at once is doomed to failure.
