The day they asked you for the evidence

2015. We were still a small startup, but we'd reached the point where "everyone does things their own way" stopped being an agile virtue and became a risk. We needed to define processes. We needed what we did to be repeatable, no matter who was behind the keyboard that day.

We were fortunate to have a lead auditor with a very deep understanding of processes, who walked us through constantly questioning whether what we were defining actually made sense. And there I ran straight into a resistance very typical of the SaaS entrepreneurial spirit in Latin America: the idea that defining processes automatically means becoming bureaucratic and slow.

A process framework doesn't tell you how to do that definition. Each process owner builds their own custom suit with the Lego pieces available. And there I saw everything: processes described down to the semicolon, with such granular detail they left no room for the natural exceptions of daily operations. And at the other extreme, completely flat processes that only described the happy path, as if nothing could ever go differently than expected.

And then comes the moment that truly terrifies: your first audit. The process you defined yourself, alongside your leader, now asks you to show evidence that it's actually being followed. And there, though no one says it explicitly, you get nervous. You approach that request completely wrong: you feel like you're in danger, like your job is at risk.

When in reality, an audit isn't about people. It's about the processes, and about the activities people perform within them.

For a process operator to truly adopt a process, they need to have participated in defining it. A process imposed from above, without that participation, never generates the same level of ownership. And over time, with new tools and new role scopes, the version-one definition of any process stops being 100% functional. For the process —and the whole system— to reach maturity, people must own it, and non-conforming outputs, instead of being hidden or punished, must become input for the system to mature.

The experience gained over time showed something even more uncomfortable: one of the biggest pains in operations was gaining real efficiency when implementing systems and delivering tasks on time and with quality. The technical result —reaching production— was achieved. But with high deviations, and in some cases, low quality. What set apart a project that started stable from one that didn't was not just the seniority of the manager in charge, but the correct management of scope, risks, and deviations, and truly understanding the value that implementation added to the client.

A quality management system doesn't exist to scare anyone on audit day. It exists so the knowledge of how to do things well stops living only in the heads of those who do them, and becomes something the whole organization can repeat, improve, and, when something goes wrong, correct without pointing at a person. The fear of showing evidence is, almost always, the clearest sign that this message hasn't reached the whole team yet.

Does your team fear audits, or do they use them to mature? If you're not sure of the answer, that doubt is already telling you something about the real maturity level of your management system.