Amplification - Make Signals Loud and Clear
Amplification - Make Signals Loud and Clear
Leading a Change With Slowification, Simplification and Amplification, part 5
For engineering leaders, leading change is not a one-time event but an ongoing initiative. As I discussed in my previous articles, we must continuously strive to improve and amplify the outcomes of our work.
This is the last in a series of five articles where I explore three critical aspects of the transformation process:
Slowification: Making the problem-solving process easier.
Simplification: Making the problems themselves easier.
Amplification: Bringing problems to the forefront, loud and clear.
These concepts were introduced in the book, Wiring Winning Organizations, which I highly recommend as a comprehensive source of knowledge.
In this article, I’ll focus on the third process from the list—Amplification—and supplement it with examples from my own experience.
Here, you can find a PDF cheat sheet summarizing this article.
Links to the other articles in the series:
Amplification (this article)
Westrum's Generative Culture
No two companies have identical cultures, but certain patterns help classify them in more general groups. If you’ve read Accelerate or follow DORA reports, you may already know Westrum's Typology of Organizational Culture.
Dr. Ron Westrum, in his research, categorizes companies into three types of cultures:
Pathological – power-oriented, marked by secrecy and fear, where problems are hidden, and messengers of bad news are punished. Issues are ignored or neglected, leading to systemic failures.
Bureaucratic – rule-oriented, where processes are rigid, and information flows slowly through the hierarchy. Problems are acknowledged but resolved slowly, with little urgency or innovation.
Generative – performance-oriented, where information flows freely, and messengers are encouraged to share problems. Failures are seen as learning opportunities, and problems are amplified early to ensure swift resolution and continuous improvement.
Here's a more concise table from the linked PDF with Westrum’s research:
In my personal experience, I went through a few transformations from pathological to bureaucratic to generative culture. All I can say is that a CEO doesn't have to be a violent and ruthless person to lead an organization with pathological signs.
I worked in a culture where there was a fear of discussing failures and incidents, and only good news was shared - all under an easy-going and charismatic person. The opposite - a harsh, self-confident, and sometimes scary leader built a culture where each mistake was deeply reviewed so we could learn from it and improve.
The difference? For me (not an experienced individual contributor back then), the easy-going CEO was still in a position of power. It's simply tough to share bad news with someone who could fire you with the snap of his fingers.
On the other hand, I had a chance to work with senior leaders who were the opposite personalities. But even though they weren't as pleasant, they had clear expectations - "Bring me data, explain clearly what was the anomaly here, and tell what we learned from it and what we did to not make it happen again,”
Generative Culture and Organizational Performance
Before diving deeper into how to build a generative culture and its connection to the amplification process, here’s an important fact confirmed repeatedly by DORA research:
"Teams with generative cultures have 30% higher organizational performance than those without."
According to DORA, building a culture where risks are shared, bridging between teams is encouraged, and failures lead to inquiry helps improve all aspects of the tech organization: teams, operational, SDLC, and organizational performance.
The Generative Culture acknowledges this - in the complex and dynamic world, problems are inevitable. What distinguishes high-performing organizations is not the absence of problems but how quickly and effectively they identify, communicate, and resolve them.
And this is where Amplification comes to light.
Amplification
Amplification is a powerful concept introduced by Gene Kim in Wiring Winning Organizations. It emphasizes the need to make problems visible early and consistently, allowing organizations to swarm, contain, and resolve issues before they escalate into larger, systemic failures.
While Slowification changes our approach to solving problems, and Simplification makes the problems themselves easier to address, Amplification ensures that problems are clearly identified, communicated, and resolved.
Swarming
Why is this so important? According to the DevOps Handbook, processes should be designed so that defects are swarmed and fixed immediately rather than passed down the value stream. Like Toyota’s Andon cord, where workers stop the production line when something goes wrong, our SDLC should enable issues to be fixed during development rather than after they reach customers.
It has been measured that the cost of fixing a problem grows exponentially if left unaddressed until it reaches production and is discovered by customers.
You can read more about swarming and catching issues early in my articles:
Stripe's Observability Practices
A powerful example of Amplification in action comes from Stripe, known for its high standards of reliability and availability. According to their 2023 annual letter, Stripe’s infrastructure achieved 99.999% availability last year.
However, they acknowledge that even with this level of uptime, there is still a small percentage (0.001%) where things can go wrong. This is where their Amplification practices come into play.
Stripe’s approach to Amplification includes:
Automated Testing Practices and Rollout Process: Stripes says its changes can be tested using more than 1.4 million automation tests. It also uses gradual rollout practices, which check tens of thousands of different metrics at each stage (0.5%, 1%, 20%, 20% of production traffic).
Automated Monitoring and Detection: Stripe employs automated monitoring systems that detect incidents as early as possible. These systems can automatically remediate many issues by invoking redundant paths or enabling emergency fallback capabilities.
Manual Inspection and Continuous Human Oversight: Despite their reliance on automation, Stripe does not solely depend on machines to manage incidents. Every incident is manually inspected by dedicated operations staff, who are on call 24/7.
Thorough Post-Incident Analysis: After an incident is resolved, Stripe conducts a detailed post-incident analysis to understand the root causes and to identify systematic changes that need to be made. This process involves not just fixing the immediate issue but also addressing any contributing factors to prevent recurrence.
Stripe’s approach to Amplification isn’t only about setting up alerting. It’s a system where problems are detected early, responses are swift and comprehensive, and lessons are extracted to prevent recurrence.
Check Stripe’s letter for more details and their case study. To read more about Stripe’s culture, you can also check:
My article about What Engineering Leaders Can Learn from Stripe's BFCM Product Dashboard
- ’s article about Stripe’s engineering culture.
The Startup Reality and Culture of Feedback
Not every company operates at Stripe’s scale. In early-stage startups, resources may be more limited, but Amplification is still essential—and it goes beyond just monitoring and testing. It’s about how feedback is handled throughout the organization. Amplification means paying attention to all signals, not just from your monitoring tools but also your team.
Here are a few signs of a pathological culture that can be dangerous for your organization:
Perpetually Failing Tests: There is a difference between flaky tests, which fail from time to time due to random events (e.g., testing infrastructure failure), and tests that never pass. They often exist in legacy systems, developed in “old times” where there was no time to maintain both - code and tests, so developers left that for better times. These tests are worthless. The longer they fail, the bigger the chance they will never be brought to life. They give no feedback; they don’t follow the changes in the code. Your job is to either get rid of them or get them fixed as soon as possible.
Unchecked Monitoring and Noisy Alerts: This is a common story when a company implements observability practices for the first time. There are tens, hundreds, or thousands of active issues and alerts triggered every few minutes. Most are just noise - logs, minor errors not affecting customers, warnings. Not addressed, they slowly become invisible to us. Once we get hit by something serious, most likely, we’ll ignore that or even won’t notice. Here, we must constantly maintain the health of our alerts by grouping issues, reducing noise, or finding the balance in alerts’ thresholds.
Unaddressed Feedback: Leaders often claim they value feedback, but failing to act on it can make team members reluctant to speak up in the future. If feedback isn’t addressed—or even acknowledged—people may stop offering it. Lack of feedback doesn’t mean everything is fine; it usually means you’re not hearing about the problems. As a leader, it’s essential to demonstrate that you’re listening and taking action.
These are just a few examples I’ve encountered over my career. Even though these issues exist on different levels, they share a common trait: when problems (whether technical bugs, feedback, or incidents) are ignored, people start accepting them as normal. This normalization of problems can lead to a snowball effect where small issues grow into cultural norms that become increasingly difficult to reverse. If you don’t address these issues early, the consequences can be catastrophic.
For more on building a culture of feedback, check out Mastering the Feedback.
The Principles of Amplification
In "Wiring Winning Organizations," six steps of amplification are outlined, inspired by Control Theory:
Sender generates a signal.
Sender transmits the signal.
Receiver gets the signal.
Corrective action begins.
Corrective action is completed.
Sender confirms the problem is solved—or repeats the signal.
— Kim, Gene; Spear, Steven J. Wiring the Winning Organization
Here’s how I interpret these steps as an engineering leader:
Sender generates signal: A problem or issue is identified and turned into a signal that can be communicated. This is the first step in ensuring problems don’t go unnoticed. Signals can come from various sources: monitoring data, alerting systems, or feedback from employees who bring up issues. It’s important to recognize all forms of signals, whether they’re technical or interpersonal.
Sender transmits signal: The signal is shared with the appropriate parties. Without effective transmission, critical information might remain siloed, and opportunities for timely intervention could be missed. If you check it once every 24 hours, in the worst case, you will learn about the problem after a day. Regarding feedback, it must be clear to people that once they experience any problems, they can report it to their leader or HR department via direct conversation or anonymous survey.
Receiver receives signal: The signal must reach the right person or team who can act on it. If it’s missed, delayed, or misunderstood, the problem won’t be addressed. In the case of technical alerts, this could mean ensuring the alert reaches the correct on-call team. For feedback, it could mean that leaders or HR receive the report and are able to take appropriate action. Failing to route signals to the right people can lead to a dangerous normalization of issues.
Corrective reaction is started: Action is taken to fix the problem. Swift responses are crucial to prevent the issue from growing or spreading. This involves both immediate technical fixes and appropriate responses to feedback or organizational issues. From a cultural perspective, leaders must demonstrate that they prioritize timely responses. For instance, addressing technical alerts early prevents costly downstream failures, while responding to employee feedback in a timely manner fosters trust and openness.
Corrective reaction is completed: The problem is fully resolved. Partial solutions or temporary patches may leave vulnerabilities in the system or cause issues to recur. In a technical context, this means not only hot-fixing an incident but also conducting a root cause analysis and making system improvements to prevent future occurrences. When it comes to feedback, this means not just addressing immediate concerns but also identifying and rectifying deeper cultural or structural issues. Hint: you cannot always act on the feedback you get, but at least you can let people know that you acknowledged it and either plan to do something with it or not.
Sender confirms that the problem is solved, or sends another signal: The resolution is validated, ensuring that the problem is truly fixed. If it isn’t, further action is triggered, closing the feedback loop. This step also has cultural implications. Engineering teams should communicate not only that problems have been fixed but also explain the root causes, the steps taken to resolve them, and how future issues will be prevented. Post-mortem sessions and clear communication with stakeholders ensure that everyone is on the same page and that lessons are learned.
Closing Thoughts
Amplification is a powerful approach for making problems visible early in software engineering organizations. By amplifying issues and addressing them swiftly, leaders can create a culture of continuous improvement, where problems are tackled before they escalate, and teams are empowered to learn from their mistakes. This process not only reduces the risk of systemic failures but also drives faster decision-making and better collaboration across teams.
In this article, I explored Amplification and its role in improving organizational performance by ensuring that issues are identified, communicated, and resolved effectively. By fostering a culture of openness, accountability, and swift action, Amplification helps engineering teams become more proactive, resilient, and adaptable.
This was the final article that wrapped the series on transformation via Slowification, Simplification, and Amplification, as described in the book “Wiring Winning Organization.”
Thank you for reading, and I welcome your thoughts and feedback on today's topic.