A DevOps approach to feedback

Javier Cardenete Morales -
The absence of feedback buys you comfort. Too much comfort in the workplace is a slippery slope towards mediocrity.

Yearly performance reviews are to personal development what any non-agile model (i.e., Waterfall) is to product development. Tech companies strive to adopt a DevOps approach to building systems, but why not have a similar DevOps approach to growing people? People systems are certainly more complex than software systems, both in their internal interfaces (emotions, traumas, egos, etc.) and also in their external interfaces (relationships, environment, etc.)

With a non-agile approach to feedback, companies are incurring “human potential debt.” That’s a terrible type of debt because it only buys you comfort. Too much comfort in the workplace is a slippery slope towards mediocrity. Then mediocrity will for sure affect the quality of your products. So basically, you are incurring a debt that buys you a depreciating asset. Do not do that.

Organizations will massively benefit from adopting a DevOps approach to feedback: a little bit of feedback every time, as opposed to just a big chunk of feedback once a year.

But how?

  • Make it explicit that giving feedback is a responsibility that individuals have with the organization. Tie it to performance within any category that has to do with accountability.
  • Make it a habit that 1:1s are a trusted and safe space to give and to seek feedback.
  • Embrace a culture where folks proactively seek feedback. This is crucial, especially for people in any leadership position. By default, their teams see a 20ft wall between them and their leader, and they will default to not give direct feedback unless leaders build the necessary trust and space to do so. Leaders can never work enough on removing their power differential.

And also, train your people in how to give, seek and receive feedback. Feedback cadence is not the only variable of a great feedback culture, it’s just the one variable that gets most neglected. A complete effective feedback formula looks like this:

+ trust
+ rigorous facts
+ precise language
+ shared purpose
- emotional clutter
- time delay

Before you go and start trying a DevOps approach to feedback, be aware that things can go wrong very quickly if any of the other variables are neglected. Lack of trust will make feedback dishonest, ambiguous feedback will create confusion, and the absence of a shared purpose is the beginning of toxicity. I may write a bit more about those in a different post, but for now, I just wanted to focus on the feedback cadence.

Folks aren’t naturally wired to give or receive feedback; it feels uncomfortable. The trap of “ah, it’s not a big deal” and keeping it for ourselves is real. And in some sense, it’s true that it’s not a big deal “right now,” but it will very likely become a bigger deal in months—a bigger deal for you and a bigger deal for the organization. Remember that giving feedback is a responsibility that individuals should have within the organization. Every single thing we do (or don’t do) contributes to the culture we create. In the realm of feedback, people tend to over-index in either one of two problems: a problem of inaction (not enough feedback flying) or a problem of mean action (evil feedback flying).