Data for Improvement or Evaluation?

Growing up, I don't remember caring much about grades. I wanted to do well, but papers and tests were less an examination and more a challenge to take on—something like a puzzle. The grade was a data point on how well I figured out the puzzle, but I didn't think of it as a judgment.

My father didn't seem to sweat grades much either. We rarely talked about school, and the only reason I even thought to show him my report card was to collect the rewards of the $5-per-A incentive system. He'd look at the report card, review it for fifteen seconds, and hand it right back. Of course, because my grades were good, there wasn't much to discuss. But the low-stakes interaction reinforced the notion that grades were just data—a neutral concept.

I was thinking about that dynamic at work. Over the last few weeks, I've been building an app and dashboard for our operations team. Technically, the app is straightforward—it takes existing checklists and turns them into forms that capture data in formats we can easily analyze to identify opportunities for improvement. For example, our facilities team walks the buildings to check whether things are clean and working. The app lets them log the observations in real time, so we can track patterns.

Here's where it got complicated. As I previewed the app with team leaders, one person asked whether we could use the tool to monitor staff performance. My goal was simply to generate more data we could use to improve—it had never even occurred to me that it might be used to evaluate team members. Quite naive.

Of course data isn’t neutral. When our “grade” is 95%, we choose whether to focus on the 95% that went well or the 5% that didn’t. And we choose whether to interpret the data in a neutral way (e.g., “The custodial team completes 95% of the daily tasks on average”) or to attach judgments to them (e.g., “The custodial team is awesome because…” or “The custodial team is bad because…”).

Those choices—and how people experience them—are driven more by context and team dynamics rather than by the existence of data itself. It was the same lesson I learned when I got to college and met classmates who got the exact same grades as I did in high school but had very different experiences with them, depending on their personalities, how competitive their school cultures were, and how their parents handled the report card moments.

My team leader's question about using the app data for performance management made me realize that if I wanted people to generate unbiased data and use it effectively, I had to pay more attention to team dynamics. First, I’d have to set clear intentions with the team about how we want to use the data. At minimum, we need to pay attention to where things are going well, not just use the tools to identify what's going poorly. We can only make good decisions about where to improve with a full accounting.

Second, I realized that the app experience itself had to set up conversations, rather than evaluations. For example, rather than making “problems” the primary aspect of the dashboards, the reports can reframe the data as “areas to investigate” or “what to discuss with the custodial vendor.”

Finally, getting the team dynamics right means ensuring that everyone has access to both inputs and outputs. Participating on both ends of the process is what makes it a tool for joint exploration and improvement. On the other hand, if the system only reported data upward to the boss, it would become a tool for judgment, a cumbersome task for everyone else that they get no benefit from.

Ultimately, this is about the leadership task of building a culture that’s psychologically safe enough for data to become neutral, where reviewing the data is a low-stakes check on how well we’ve solved the puzzle, rather than a high-stakes evaluation of the person doing it.