Feedback and continuous improvement
The third way
Sharing, feedback and continuous improvement are the learning half of DevOps. The second way amplifies feedback from right to left - from production, customers and monitoring back to development - so problems are found and fixed quickly. The third way builds a culture of continual experimentation, where taking risks and learning from failure is expected, and where knowledge is deliberately pushed into the organisation.
Concepts a candidate must know
- Feedback loops: automated test results, monitoring and alerting, user telemetry, incident reviews, customer feedback, and short release cycles that make feedback cheap.
- Blameless postmortems and incident reviews that produce actionable, owned improvements rather than a search for a culprit.
- Retrospectives with tracked action items; improvement is only real when it changes how work is done.
- Sharing mechanisms: internal communities of practice, guilds, internal conferences, dojos and kata, pairing and mobbing, shared documentation, chat-ops transparency, open dashboards, and rotation between teams.
- Knowledge as a public asset: documentation, runbooks and design records in version control, discoverable by the people who need it, with appropriate access controls for sensitive operational information.
- Continuous improvement frameworks: PDCA (plan-do-check-act), kaizen, and experimentation with hypotheses and measured outcomes.
- Error budgets and SLOs as a structured way to decide when to invest in reliability versus new features.
Traps in questions
- "The retrospective was held and everyone agreed it went well" with no actions or owners - a classic non-answer.
- Feedback only at the end of a project, or only from managers, rather than continuously from users and systems.
- Rewarding individual knowledge hoarding as "being indispensable"; sharing is the desired behaviour.
- Treating failure as something to hide, which suppresses the information feedback depends on.
- Assuming a tool (wiki, chat channel) creates sharing culture by itself.
Rule of thumb
Every improvement cycle should leave behind two artefacts: an owned action with a date, and something learned that others can find. If neither exists, the loop did not close.