Developing a continuous feedback culture means looking beyond metrics and the DevOps toolchain
A core component of successful CI/CD pipeline management is enabling continuous improvement. The ‘continuous’ nature of DevOps is key to its success because it eliminates the bottlenecks and silos that often extended deployment timelines and made software harder to maintain or update. Often, teams look to tooling to provide the feedback they need to identify what improvements are required. However, it is important to not limit your understanding of continuous feedback to just the information tools can provide.
Instead of a singular focus on data and metrics, leaders need to match output produced with an understanding of how it connects to individual and team performance and the implications for the project, product, or service. Practicing DevOps isn’t simply about a set of tools or a method of structuring planning, deployment, and operations processes. It also requires a cultural shift in the way teams approach each other and their work that facilitates a shared responsibility amongst developers and operators for the software they deploy and maintain. A culture optimized for continuous improvement, and therefore feedback, requires teams to look beyond tools and toward their teammates. Feedback can and should be found within incident retrospectives, meetings, and customer interactions.
So, what characteristics define a continuous feedback culture?
As our VP of Product Ryan Taylor says, “feedback shouldn’t fail quietly, it should fail thoughtfully.” Not only should there be ample opportunities to share feedback, there should also be clear processes around ensuring each piece of feedback receives consideration and a response. Not all feedback will be implemented, but closing the “loop” is important — there’s a reason it's not called a feedback line! Not only will circling back ensure feedback continues to be shared (it's human nature to stop sharing when we don’t receive responses), but it also empowers individuals as part of the process and helps them get on board with whatever direction may have been decided upon.
If the feedback loop is operating correctly, then each person should feel like their voice and opinions are viewed as valuable contributions to the team and their collective goals. Level or role should not determine who is able to share feedback, the response time, whether the feedback is implemented, or its prioritization. Feedback should be considered solely on its own merits, without regard for whom the feedback came from.
How feedback is shared or received is just as important as the feedback itself. While sharing positive feedback may be straightforward to many, expressing shortcomings or sharing critical feedback can be much more difficult, especially in a group setting. Statements should not be steeped in judgment or negativity. Instead, each should be focused on a specific behavior or outcome, and should include context on why feedback is being presented along with a suggestion on how to achieve a more ideal result in the future. It should never be a personal attack. Body language and tone should also convey support and optimism, not anger or frustration.
Unconstructive feedback: “Every document you’ve written is completely useless and illegible and a waste of time.”
Constructive feedback: “I have had trouble using some of the documentation provided here because of the large blocks of text. I recommend breaking these long paragraphs of actions into shorter sentences for increased clarity, and using bullets or numbers to outline next steps or important information. I believe these changes will make it much easier to follow in the future.”
If conveyed in the right way and within a supportive environment, feedback will be viewed as a gift shared for the betterment of either an individual or the team as a whole. Ultimately, personal wins become team wins.
Just because they may not be physically in the room with you or sending messages in your war room slack channel doesn’t mean that you haven’t received feedback from your end user, whether internal or external. Some ways to achieve this include adding A/B testing or canary deployments into your processes to gain user feedback quickly. Successful DevOps teams include the voice of the customer and the larger business goals in the feedback they share as well as within the vetting, response, and implementation processes.
As with most things, practice makes perfect! It's better to lean toward feedback than away from it, even if it seems inconsequential. The more opportunities your team has to discuss small pieces of feedback or improvements, the better off you will be. Not only will this help prevent larger incidents through smaller, quicker fixes, but it will also give you ample opportunity to hold blame-free retrospectives, close the loop on feedback, and stress test your processes. Equally important, don’t put off conversations or let retrospectives linger. You’ll receive higher quality, more actionable feedback and direction by reviewing incidents or events quickly after they occur.
Leaders must play a critical role in orchestrating a healthy feedback environment. They should make a point to be open and transparent about their own shortcomings or missteps, step in when feedback is not being delivered in an appropriate or constructive manner, and ensure the feedback “loop” operates as it is supposed to. Most importantly, they should always tie decisions back to the larger business objectives and the needs of the customer. Regular 1:1 meetings with the members of their team will enable that important context to be shared and provide an opportunity to gain a pulse on team needs or anything that needs attention.
Having the right tools will always provide pivotal support for deploying and maintaining software and gaining actionable insights. However, the culture built within your team and organization will have a critical impact on how quickly or effectively you meet your goals. Successful DevOps practices require the right tools and the right environment for the people who use them — one without the other means neither will work as intended, and both will end up falling short.