Empathy and Kindness

I keep thinking this blog is truly focused on quality (it sure ain’t focused on grammar and spelling).

Quality is so nebulous when you try to talk to people about what you do. Day to day as a site quality head or a director I am not on the line seeing what is going on (1).

I explain quality as all of the attributes that give you the certainty/belief that the product is going to work without any negative effects. High quality means that you don’t even think about it not working the way it is intended to. That it is safe and reliable.

These attributes are built into systems by smart, well intentioned people. They attend to their jobs seriously. Even when life has them by the neck, they do what is right.

So if the regulated community is reliant on people, as it will be for a very very long time, I keep coming back to what centers us as humans. And from there what quality should be so as to make it easier to administer and to see as managers and site quality heads.

Quality culture is the measure, but what is then the criteria that we should measure the quality culture. I posit that it is Empathy and Kindness. Not just in day to day, but in the development of these systems. We need to be honest about how we use the system and the data out of the system.

The honesty that we have with ourselves helps us engineer quality in our systems. When we design a system, are we looking at it with the endpoint and mind AND by who it will be implemented and then used by?

Do we take the empathy and kindness in the type of training needed to use the system; cutting down the BS out of it and simplifying as much as practical?

Do we as managers write in or even know when we should be checking in on the users and administrators of the system? Do we advocate for personnel prior to implementation?

So yes, everything I am talking about is derivative of managing/implementing complex change (google away). But I am trying to go a bit deeper on the human aspect. Engineering simple is incredibly hard. It takes lots of trial and error and understanding about people. The most amazing user interfaces evolved from the dashboard of dials, indicators and sliders that took a doctorate to manage. But that is not quality, even if it gets us the result we are looking for. We want scale, we want person independent from a results perspective, we want person focused in its usage and consistency. The best systems are easy to use and you get what your expectations are out, every single time. You believe the outputs and understand the maintenance of the system (in fact you do it responsibly and lovingly).

How we get there is by leaning into the human aspect. Human factors are not just for devices or user interfaces. It comes from talking to people across the usage life cycle of the process. To think with them and where needed to help think for them through thoughtful questions. We get there through recognizing the empathy and kindness needed in their daily jobs. What complexities they have already? What complexities will this process introduce? What are the obstacles to success and implementation? (2)

Do you know what the end of the process actually is?

I am not saying a disertation for each process, but I am asking that you talk with users, implementers, etc.

  • Do a literature search.

  • Read the existing procedures, be honest about their function and quality

  • Look at the quality and resolution of the data in place

  • Look at the constraints that they have in time, training, data integrity (reliability of data)

  • How quick does upstream data change?

  • How long does it take to process all variables to the appropriate degree?

  • Are all the right people being asked and involved?

  • Are you listening to the wrong people? Or how do you know the team is large enough?

  • Is it the right time for this process?

In short, I suggest you question your certainties and your understanding. Be willing to change your perspective based on data and input from people. Have empathy and kindness for the users and consumers of this system.

I have heard people use the phrase “do it with them, not for them” albeit without much power behind it, but the sentiment is sound. Your northstar needs to be that in building the tool, process, report, how do you intend it to be used and any unintended consequences. What is the load the process will create, and is the “juice worth the squeeze” for all involved?

Footnotes:

(1) I certainly make it out weekly but not on a daily basis. Also, as a note, going out at a managerial level gives great familiarity but you have to understand their may be a bit of a heisenberg effect of watching. Trust any of your quality associates (especially quality on the floor) to give you the intelligence that you need. Do not over react or cause them to lose credibility with their peers/colleagues.

(2) Look at the people involved and see if there is an agenda to implementation as sometimes loss of control is terrifying.