Malba Tahan, in "The Man Who Counted," tells a story that should be required reading at every corporate results meeting. Three brothers inherit thirty-five camels from their father, with the following stipulation: the eldest would receive half, the middle one a third, and the youngest a ninth. The dispute begins immediately, as none of these divisions yields whole numbers. Half of thirty-five is seventeen and a half. A third is eleven point sixty-six. A ninth is three point eighty-nine. Camels cannot be divided into fractions.
The brothers tried to solve the problem in the most intuitive way: rounding. The eldest claimed eighteen, since seventeen and a half should round up. The middle one wanted twelve, by the same reasoning. The youngest demanded four. Added together, thirty-four. One camel was left over and no one would yield. The fight was not about greed; it was about the inability to see that the original equation simply did not add up. They were trying to solve a problem that had no solution in the terms it was proposed.
Beremiz, the calculator, observes the dispute and offers an ingenious solution. He lends his own camel, making the total thirty-six. He then distributes eighteen to the first, twelve to the second, and four to the third. The brothers check: eighteen is more than seventeen and a half, twelve is more than eleven point sixty-six, four is more than three point eighty-nine. Everyone received more than the original fraction promised. Satisfied, they thank him and depart. Beremiz recovers the two remaining camels: his own and one as profit.
The elegance of the solution conceals an uncomfortable truth: the original equation was impossible. One half plus one third plus one ninth equals seventeen eighteenths, not a whole. One eighteenth was missing to complete the inheritance. The brothers were fighting over something that, mathematically, did not exist as proposed. Each one thought he gained more because he compared against the impossible fraction, not against the actual total. Beremiz did not deceive them; he was simply the only one who understood what the numbers truly said. The difference between him and the brothers was not moral. It was epistemological.
This parable traverses centuries and arrives intact in contemporary boardrooms. How many decisions are made based on fractions that do not add up to a whole? How many indicators are presented as absolute truths by people who do not understand their fragmentary nature? The mathematical ignorance of the three brothers did not make them dishonest. It made them vulnerable. And vulnerability, when exposed to the fear of appearing incompetent, frequently disguises itself as certainty.
The Truth That Lies Without Lying
In 1988, the Brazilian agency W/Brasil created a commercial for the newspaper Folha de S.Paulo that would become a worldwide reference in advertising. The text began narrating the achievements of a political leader. This man, said the narrator, took a destroyed nation and recovered its economy. He restored pride to his people. He reduced inflation from one million percent to twenty-five percent per year. He created one of the largest automobile manufacturers in the world. He built highways that would become engineering models. He reduced unemployment from six million people to two hundred thousand.
The viewer followed the narrative with growing admiration. What an extraordinary leader. What impressive achievements. The numbers were precise, verifiable, historically documented. No piece of information was false. The conclusion seemed inevitable: this man deserved recognition, perhaps even reverence. The ad built, fact after fact, the image of a competent and visionary statesman.
Then came the reveal. The leader was Adolf Hitler. And the commercial's conclusion was cutting: it is possible to tell a mountain of lies by speaking only the truth. That is why one must be very careful with information. The commercial, written by Nizan Guanaes under the direction of Washington Olivetto, won the Golden Lion at the Cannes Festival and in 2000 was elected one of the one hundred best commercials of all time.
Every fact presented was verifiable. No number was fabricated. The lie resided in what was not said: the context, the consequences, the human cost. Wittgenstein argued that language is a picture of reality, but every picture presupposes a frame. What remains outside the frame does not cease to exist; it merely ceases to be seen. And whoever controls the framing controls the narrative.
This phenomenon does not require malice to thrive. Fear is enough. Insecurity is enough. The pressure to appear competent in an environment that punishes imperfection is enough. When error is treated as a sentence rather than data, people naturally begin to edit reality. Not because they are evil, but because they are human. And humans under threat tend to protect their own image before protecting the truth. The problem is not in the person; it is in the system that trained them to fear transparency.
The Transparency That Reveals
There is an irony that experience teaches and intuition frequently resists: a bad KPI is more valuable than a good KPI. The positive indicator confirms what is already known; the negative one reveals what has not yet been learned. A system that presents only healthy metrics is a system that hides its fragilities, or worse, one that does not know where they are. True transparency is not the proud display of successes; it is the courageous exposure of failures.
Consider a common scenario in development teams: the average response time of an API is within the established SLO. The dashboards are green, the reports are positive, everyone celebrates. But no one looked at the ninety-ninth percentile. No one noticed that one in every hundred users waits fifteen seconds for a response. The average masks the suffering of the tail. The good KPI hid the real problem. If there had been a red indicator, someone would have investigated. Since it was green, no one asked.
The same happens with availability metrics that ignore partial degradation. The system is technically up, so the uptime SLI is green. But half the features return errors. The metric says everything is fine; the user experience says it is not. This disconnect between what we measure and what matters is a symptom of poorly designed metrics, not poorly operated systems. The problem is not the team that monitors; it is the indicator that does not capture the relevant reality.
Donald Knuth, one of the fathers of computer science, warned that premature optimization is the root of all evil. But there is an even more insidious evil: the optimization of appearances. When the metric becomes the objective instead of being the symptom, the system begins to optimize for looking good instead of being good. This is Goodhart's Law in action: when a measure becomes a target, it ceases to be a good measure. The weak metric is a gift. It points exactly where knowledge is lacking, where the process fails, where behavior needs to change. Treating the weak metric as a threat and trying to eliminate it, instead of eliminating the problem it reveals, is confusing the thermometer with the fever.
The Doctor's Method
A doctor does not cure. This statement sounds counterintuitive, but it expresses a fundamental truth about complex systems. The doctor observes parameters, formulates hypotheses, administers interventions, and monitors results. He does not directly control the cure; he controls the conditions that allow the body to heal itself. The difference is crucial. The doctor works with indicators: temperature, blood pressure, heart rate, test results. He uses technical knowledge to interpret what those numbers mean and which behaviors of the system need to be modified.
When a patient presents persistent fever, the doctor does not declare personal failure. He investigates. Tests hypotheses. Adjusts medication. Observes again. The fever that does not subside is not evidence of medical incompetence; it is diagnostic information. It says that the current intervention is not working and that another approach is necessary. The competent doctor does not hide the fever from the medical record to appear competent. He records it, analyzes it, and uses it as a guide for the next decision.
Software systems operate under the same logic. An elevated latency SLI is not failure by the engineering team; it is information about the state of the system. But here begin the nuances that haste frequently ignores. Sometimes the problem is the code. Sometimes it is undersized infrastructure. Sometimes it is the architecture that was designed for a different scenario than the current one. Many systems are born as projects to solve a specific task and are later forced to behave as platforms that need to evolve. The point solution becomes a critical system without having been designed for it.
This conception debt manifests in the indicators. Latency rises because caching mechanisms were not anticipated. Availability drops because there is no redundancy. Recovery time is high because there is no failover automation. None of these problems is the fault of the developer who is on call when the incident happens. They are consequences of decisions made before, frequently under deadline pressure, when someone decided that resilience mechanisms could wait. Today's bad metric is the echo of yesterday's rushed decision.
The mature response is to investigate: is the problem in the code, the infrastructure, the network, the database, the original architecture? What behaviors do we need to modify? What knowledge is missing? The inadequate response is to hide, justify, or redefine the indicator so that the problem disappears from the report while continuing to exist in the system. The engineer who acts this way is like the doctor who erases the fever from the medical record and declares the patient cured.
DORA Metrics and the Temptation of the Shortcut
The DORA program, conducted by Google Cloud, spent over a decade researching what differentiates high-performing teams in software engineering. The result is four metrics that have become a reference: deployment frequency, lead time for changes, change failure rate, and service recovery time. The first two measure speed; the last two measure stability. Elite teams manage to be fast and stable simultaneously. They do not sacrifice one for the other.
The research shows that teams excelling in these metrics are twice as likely to meet or exceed organizational objectives. The immediate temptation is to turn DORA metrics into targets. If elite teams deploy multiple times a day, let us demand that our team deploy multiple times a day. If elite teams have a failure rate below fifteen percent, let us set fifteen percent as the target. The problem is that this inverts the causality.
Elite teams are not elite because they have good DORA metrics. They have good DORA metrics because they developed practices, knowledge, and behaviors that naturally produce those results. Frequent deployments are a consequence of automated pipelines, reliable tests, decoupled architecture, and a culture of small incremental changes. Demanding the metric without building the conditions is like demanding that someone run a marathon without training. The person may try, but the result will be injury, not performance.
When an organization examines its DORA metrics and discovers it is at the low or medium level, the productive question is not "how do we raise these numbers?" It is "what knowledge and behaviors do we need to develop so that these numbers rise naturally?" The difference seems subtle, but it is fundamental. The first question leads to shortcuts: forced deployments that increase frequency but also increase failure rate, tests removed to reduce lead time, incidents underreported to improve recovery time. The second question leads to learning: investment in automation, training in testing, architecture refactoring, observability improvement.
The 2022 DORA report stopped identifying "elite" teams because the statistical analysis showed only three distinct clusters. But the lesson remains: metrics are symptoms of capabilities. Improving the symptom without developing the capability is cosmetic. Developing the capability improves the symptom as a side effect.
The Error Budget: License to Learn
The concept of error budget, popularized by Google's Site Reliability Engineering team, represents one of the most elegant inversions in thinking about reliability. The traditional logic says: maximize availability, minimize errors, pursue perfection. The error budget logic says: define how much error is acceptable and use that margin to innovate. If the SLO establishes ninety-nine point nine percent availability, that means there is zero point one percent of permitted unavailability. And permitted unavailability is synonymous with room to experiment.
The book "Site Reliability Engineering," published by Google in 2016, documents this philosophy with clarity. The authors explain that the error budget is the tool that SRE uses to balance service reliability with the pace of innovation. Changes are the largest source of instability, representing approximately seventy percent of outages, and development work for new features competes with development work for stability. The error budget removes politics from these negotiations. If there is budget available, you can ship. If the budget is exhausted, you stop and fix. The objective metric replaces the subjective dispute. It is not punishment; it is information.
This approach fundamentally transforms the relationship with failure. In a traditional environment, any error is evidence of incompetence. In an environment with error budget, error is the cost of learning, as long as it stays within budget. John Boyd, a military strategist whose ideas profoundly influenced agile methods, argued that victory belongs to whoever learns fastest. The OODA loop: observe, orient, decide, act: presupposes that the speed of learning surpasses the speed of execution. The error budget operationalizes this philosophy: fail fast, learn fast, fix fast, within agreed limits.
The organizational implication is profound. If the team has error budget available and is not using it, it may be being too conservative. It may be failing to experiment, to innovate, to learn. Excessive availability is not a virtue; it is a waste of opportunity. This inversion of perspective only makes sense in environments where failure is not punished. If using the error budget means risking one's career, no one will use it. The budget will exist on paper and die in practice.
The Conflict of Contradictory Goals
One of the clearest symptoms of organizational dysfunction is the proliferation of goals that contradict each other. Maximize delivery speed. Maximize code quality. Minimize operational cost. Maximize customer satisfaction. Each of these goals, in isolation, seems reasonable. Together, they form an impossible incentive system. The team that tries to meet all of them simultaneously ends up meeting none, or worse, optimizes for the one that will be demanded most loudly, regardless of whether it is the most important.
Consider a concrete example. An organization sets a goal to reduce deployment lead time from two weeks to two days. Simultaneously, it sets a goal to reduce production incident rates by fifty percent. And it adds a goal to reduce infrastructure costs by thirty percent. Each goal makes sense individually. But how do they interact?
Reducing lead time requires test and pipeline automation. Automation requires initial investment, which increases cost in the short term. More frequent deployments mean more changes in production, which increase the probability of incidents, at least until the automation is mature. Reducing infrastructure costs may mean fewer test environments, which reduces the ability to validate changes before production. The speed goal competes with the stability goal, which competes with the cost goal. The team is in checkmate.
Physics teaches that systems with contradictory constraints enter states of tension. Software engineering is no different. When the speed KPI competes with the quality KPI, the developer must choose which to sacrifice. If the environment punishes the wrong choice but offers no criteria for the right one, the result is paralysis or randomness. Setting contradictory goals without making priorities explicit is not challenging the team; it is confusing them. And confusion does not produce high performance.
The problem worsens when goals are defined by people who do not understand their technical interdependencies. Reducing deployment time without increasing test automation is a recipe for incidents. Increasing code coverage without quality criteria for tests is a recipe for false security. Demanding zero downtime without investing in redundancy is a recipe for unsustainable heroism. Each metric exists in relation to others. Ignoring these relationships is like adjusting blood pressure without considering heart rate: you may kill the patient trying to cure a symptom.
The solution is not to have fewer goals; it is to have conscious goals. This means understanding the trade-offs, making priorities explicit, and accepting that optimizing one dimension frequently means de-optimizing another. It also means revising goals when conditions change, instead of maintaining them through inertia. A goal that made sense last quarter may be counterproductive today. The rigidity that looks like discipline is frequently just lack of attention.
Looking Good Versus Being Good
There is a fundamental difference between looking good and being good that environments of fear systematically obscure. Looking good is optimizing the presentation. Being good is optimizing the system. Looking good is choosing the favorable angle of the photograph. Being good is improving what the photograph reveals. Being good is also being transparent about problems, admitting unmet targets, and working consistently on the system for long-term results. The distinction seems obvious, but the pressure for short-term results dissolves it with remarkable efficiency.
Jeff Bezos built Amazon on this distinction. In his 1997 letter to shareholders, he declared that decisions would be made with a focus on the long term and market leadership, not short-term profitability or Wall Street reactions. In 2000, when Amazon's stock dropped eighty percent, he did not change the strategy to look better the following quarter. He maintained the investment in infrastructure because he believed that fifteen percent of commerce would eventually be online, at a time when it was less than one percent. In 2012, after the company's largest loss in a decade, he wrote to shareholders that in the long run the interests of customers and shareholders align. Anyone who wanted immediate returns should invest elsewhere.
Now consider the test coverage metric. A team under pressure can raise coverage from sixty to ninety percent in a single sprint. The dashboards turn green, the reports impress, everyone celebrates. But if those tests were written merely to cover lines, without testing relevant behaviors, coverage went up and quality did not. The system appears safer and is not. The metric improved and the product did not. This is looking good.
Being good would be different. It would mean recognizing that test coverage is not added by force, but cultivated through practices. Teams that develop in a test-driven manner naturally produce testable code and meaningful tests. Coverage is a consequence, not an objective. Forcing the metric without changing the practice is like forcing a harvest without preparing the soil.
A healthier approach than aggressive coverage targets is the boy scout rule applied to code: leave the campground cleaner than you found it. Every time a developer touches a piece of code, they add a layer of testing to what they modified. It is not an arbitrary target of ninety percent by the end of the quarter. It is an incremental practice that gradually improves the codebase where it is actually being worked on. The most-touched code becomes the most-tested. Forgotten code remains as is until it is touched. Coverage rises as a side effect of a sustainable behavior.
The trap closes when the environment does not distinguish between the two. If the metric is the only evaluation criterion, optimizing the metric is rational, even if it does not optimize the system. Goodhart's Law is not an academic curiosity; it is an organizational force. When test coverage becomes a target, coverage stops measuring quality. When the number of deployments becomes a target, the number stops measuring speed. When any indicator becomes a target, it captures attention and loses meaning.
The Tyranny of Failure
In environments where fear reigns, not meeting a target means personal failure. There is no room to ask why. There is no interest in investigating what was missing. The unmet target is evidence of incompetence, and incompetence is punished. This cycle closes quickly into a system where no one admits difficulty, no one asks for help, no one reveals the real metric. Everyone looks fine. No one is fine.
The problem with this approach is that it confuses result with capability. An unmet target can mean the team is incapable. It can also mean the target was unrealistic, that conditions changed, that dependencies failed, that the necessary knowledge did not exist, that the tools were inadequate, that the deadline was insufficient. Each of these causes requires a different response. Punishing all of them uniformly as "failure" is like prescribing the same medicine for every disease: it occasionally works, generally does not, and sometimes kills.
The alternative is to treat the unmet target as data, not as a sentence. To ask: what does this result reveal about the system? What knowledge was missing? What behavior needs to change? What external condition interfered? What dependency failed? These questions do not absolve anyone of responsibility; they direct responsibility to where it can produce change. Blaming without diagnosing is emotionally satisfying and practically useless. Diagnosing without blaming is emotionally uncomfortable and practically productive.
The difference between these two approaches is the difference between organizations that learn and organizations that repeat. The organization that punishes failure teaches people to hide problems. The organization that investigates failure teaches people to reveal problems. And you can only solve what you can see.
The Difference of Seconds
High performance lives in narrow margins. The difference between the medal-winning sprinter and the one eliminated in the semifinals is hundredths of a second. The difference between the system that withstands the Black Friday peak and the one that crashes is milliseconds of latency. The difference between the deployment that passes and the one that fails is a single line of code. This proximity between success and failure means that incremental improvements require exponential effort.
Reducing latency from two hundred to one hundred milliseconds may be a matter of well-implemented caching. Reducing from one hundred to fifty requires rethinking architecture. Reducing from fifty to twenty-five may require a change in programming language, dedicated infrastructure, specialized algorithms. Each marginal gain costs more than the previous one. Those who do not understand this dynamic set linear targets for nonlinear systems, and then look for someone to blame when physical reality does not cooperate.
Gene Amdahl formalized this in the law that bears his name: the maximum optimization gain is limited by the non-optimizable fraction. If ninety percent of the time is parallelizable and ten percent is not, no amount of processors will reduce the total time below that ten percent. The implication for metrics is direct: there are physical, mathematical, and architectural limits for any indicator. Targets that ignore these limits are not ambitious; they are fantastical. And pursuing fantasy is not ambition; it is a waste of energy on something that cannot exist.
This does not mean that aggressive targets are bad. It means that aggressive targets need to be informed by the limits of the system. Demanding one-millisecond latency from an architecture that makes ten synchronous network calls is not a challenge; it is an impossibility. Demanding zero incidents from a system that processes millions of transactions is not excellence; it is a denial of statistics. The ambitious and possible target energizes. The ambitious and impossible target demoralizes. Distinguishing between the two requires technical knowledge that is not always present where targets are defined.
The Missing Knowledge
Aristotle distinguished between vincible and invincible ignorance. The first can be overcome through study; the second is an intrinsic limitation. The problem with metrics in organizations is rarely invincible ignorance. It is epistemological laziness disguised as pragmatism. No one is born knowing how to interpret a ninety-ninth percentile latency graph or calculate a quarter's error budget. But anyone can learn, provided they recognize that they do not know.
The drama begins when the acknowledgment of ignorance is punished. When admitting "I did not understand this indicator" means being seen as incompetent, people stop asking. When questioning the methodology of a KPI is interpreted as insubordination, people stop questioning. Deming, the father of statistical quality control, warned that fear is the greatest enemy of improvement. He was not speaking of individual cowardice; he was speaking of environments that turn curiosity into risk.
The consequence is predictable: people who do not understand what they measure begin to measure what they understand. Or worse: they begin to present what is convenient. Not out of innate dishonesty, but out of institutional survival. An environment that demands certainties from those who should be learning creates a perverse incentive for the simulation of competence. And simulation of competence is merely another name for sustained incompetence.
The Fear That Corrupts
There is a crucial difference between acting in bad faith and acting under environmental coercion. Bad faith presupposes a deliberate intention to deceive. Environmental coercion produces the same result through distorted incentives. When the environment punishes inconvenient truth, the convenient lie becomes a survival strategy. One does not need to be a villain to edit reports. One only needs to be in a place where honest reports end careers.
Hannah Arendt coined the term "banality of evil" to describe how ordinary people can perpetrate terrible acts when embedded in systems that normalize the unacceptable. With due proportions, organizations that institutionalize fear produce their own banality: the banality of the lie. Adulterated indicators, omitted contexts, narratives constructed to protect reputations. None of these acts necessarily springs from individual perversity. They can spring from a system that made truth dangerous.
The hardest thing to identify is that many people do not even realize what they are doing. They have convinced themselves that optimizing the presentation is part of the job. That highlighting the positive and minimizing the negative is "strategic communication." That omitting context is "being objective." The rationalization is so complete that distortion disguises itself as professionalism. Kierkegaard observed that the most dangerous form of despair is the one in which the person does not even know they are in despair. Analogously, the most dangerous form of organizational distortion is the one in which not even those distorting realize they are distorting.
Environments That Use Failures to Grow
Toyota built one of the most admired production systems in the world on a counterintuitive principle: having no problems is a problem. If no one is reporting failures, either people do not understand the process, or they do not feel safe enough to reveal the truth. Toyota's leaders actively work to create sufficient psychological safety so that problems and errors surface. Only then can they be resolved.
A concrete example is the minivan story. Toyota's first attempt in the American market, the 1991 Previa, failed. Among other problems, it had only two cup holders, insufficient for the American consumer. Instead of abandoning the segment or blaming the team, Toyota investigated, learned, and adjusted. The second generation, the Sienna, came with fourteen cup holders. The company continued iterating and, in 2019, surpassed Honda as the best-selling minivan in the United States.
The mechanism that sustains this behavior is cultural, not procedural. Any employee on Toyota's production line has the authority to stop the entire line if they identify a quality problem. This would be unthinkable in environments where stopping production means punishment. At Toyota, it means responsibility. The principle, called jidoka, places quality above speed. And it works because the environment makes it safe to exercise it.
The numbers confirm the culture. Toyota employees generate more than one million process improvement ideas per year. The most impressive data point is that ninety percent of these ideas are implemented. This does not happen by accident. It happens because the organization created an environment where suggesting improvement is not risky, but expected. Where revealing a problem is a contribution, not insubordination.
The Courage of the Complete Truth
In the end, metrics are just numbers. They neither lie nor tell the truth. The people who interpret and present them do that. And those people are embedded in contexts that shape them. An environment that punishes error produces people who hide errors. An environment that rewards appearance produces people who tend to appearance. An environment that values learning produces people who learn.
A team is a unit. When a developer forgets to handle an edge case and this causes a production incident, it was not the developer alone who erred. The code review process should have caught it. The automated tests should have captured it. The staging environment should have revealed it. Every validation layer that failed is as responsible as the original code. And above all those layers is the leadership that designed, or failed to design, that process.
Peter Drucker said that most of what we call management consists of making it difficult for people to do their work. The statement is provocative, but it carries a truth. When the leader chooses a scapegoat, he solves the problem of the day and perpetuates the problem of the system. When he investigates the process, empowers the team, and strengthens the validation layers, he solves the system and prevents tomorrow's problem. Choosing the scapegoat is easy. Empowering the team is the real work of leadership.
Courage and responsibility go together. The courage to show the ugly number must be accompanied by the responsibility to do something about it. Transparency without action is mere confession. But transparency with action is the foundation of trust. In a safe environment, revealing a problem is not admitting weakness; it is asking for support. And support can only be given to those who ask. The team that hides its problems remains alone with them.
Responsibility also implies distinguishing between what is trainable and what is not. Lack of technical knowledge is solved with training. Lack of experience is solved with mentorship and practice. Lack of skill is solved with time and exercise. These are trainable deficiencies. What is not trainable is character: the willingness to learn, the honesty to admit error, the humility to ask for help. When someone with knowledge and capability chooses to distort, omit, or manipulate, the problem is not one of training. It is one of fit.
The complete truth requires more than good intention. It requires a safe environment, technical knowledge, emotional maturity, and courage. Courage to admit not knowing. Courage to show the ugly number. Courage to ask what needs to change. Bertrand Russell said that the problem with the world is that fools are full of certainties and the intelligent are full of doubts. Organizational maturity begins when doubt ceases to be weakness and becomes method.
The Photograph That Matters
The three brothers in Malba Tahan's story were not dishonest. They were ignorant. And their ignorance made them fight over something that did not exist in the terms it was proposed. Beremiz did not deceive them; he revealed that they were already deceived. The difference between him and the brothers was not moral. It was epistemological. He knew how to read the numbers. They only knew how to fight over them.
Organizations are full of thirty-five camels. Targets that add up to more than one hundred percent of available time. KPIs that measure the same thing in contradictory ways. Indicators that capture the convenient and ignore the relevant. Partial truths presented as complete portraits. And many people of good faith, genuinely trying to do the right thing, perpetuating errors because no one taught them how to do the math.
The central point is not that there are bad people manipulating numbers. It is that numbers without comprehension of their nature are dangerous. A metric is an abstraction of reality, not reality itself. It captures some dimensions and ignores others. It reflects the choices of whoever designed it. Using it well requires understanding those choices and their implications. Using it poorly requires only copying it from a template and demanding results.
A culture of continuous learning uses metrics to its advantage. Not as a tribunal that judges, but as a mirror that reveals. The bad metric is not an enemy; it is a teacher. It says where knowledge is lacking, where behavior needs to change, where the process needs to evolve. Transformation does not happen by decree. It happens when people develop new behaviors, and new behaviors require energy: energy to learn, to practice, to fail, to correct, to try again.
The poetic metric collects its due. The adulterated photograph reveals its filter. The incomplete truth finds its context. And when that happens, and it always happens, no PowerPoint presentation will save you. What saves you is having learned beforehand. Having asked beforehand. Having faced the ugly photograph and understood that it was not there to judge, but to teach.
The maturity of truth is not a destination; it is a practice. Daily, uncomfortable, and irreplaceable. As Popper would say, we may not know if we are right, but we can always find out if we are wrong. The only condition is wanting to know.
References
- Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media.
- Tahan, M. (1949). O Homem que Calculava. Record.
- Deming, W. E. (1986). Out of the Crisis. MIT Press.
- Popper, K. (1959). The Logic of Scientific Discovery. Routledge.
- Arendt, H. (1963). Eichmann in Jerusalem: A Report on the Banality of Evil. Viking Press.
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- Liker, J. K. (2004). The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. McGraw-Hill.
- Bezos, J. (1997-2020). Cartas aos Acionistas da Amazon. Amazon.
- Google SRE. (n.d.). Error Budget Policy. https://sre.google/workbook/error-budget-policy/
- DORA. (2022). State of DevOps Report. Google Cloud.
