WEBVTT 00:00:00.000 --> 00:00:04.379 Okay, imagine this. It's 8 Lir AM Tuesday, you 00:00:04.379 --> 00:00:06.960 walk into a school, the bell rings, and for the 00:00:06.960 --> 00:00:10.419 next, I don't know, seven hours, thousands, and 00:00:10.419 --> 00:00:13.060 I mean literally thousands of tiny, invisible 00:00:13.060 --> 00:00:15.599 digital things have to happen perfectly. Right. 00:00:15.820 --> 00:00:18.399 Teachers logging in, the cafeteria system scanning 00:00:18.399 --> 00:00:20.800 lunch cards, a student in the library clicking 00:00:20.800 --> 00:00:23.579 a research link. And if it works, it's just... 00:00:24.129 --> 00:00:26.589 It's magic. It feels completely seamless. It's 00:00:26.589 --> 00:00:28.629 invisible. But we all know that's not always 00:00:28.629 --> 00:00:31.129 the reality, right? When that invisible machinery 00:00:31.129 --> 00:00:33.450 breaks, you know, the Wi -Fi drops in the middle 00:00:33.450 --> 00:00:35.130 of state testing or the smart board just won't 00:00:35.130 --> 00:00:37.950 connect, it stops being invisible. Oh, it becomes 00:00:37.950 --> 00:00:40.609 a crisis. A big one. A very loud, very panicked 00:00:40.609 --> 00:00:43.390 crisis. Exactly. And suddenly the IT director 00:00:43.390 --> 00:00:45.750 isn't some wizard behind the curtain. They're 00:00:45.750 --> 00:00:47.369 the ones standing in the principal's office trying 00:00:47.369 --> 00:00:49.329 to explain why calculus isn't happening today. 00:00:49.429 --> 00:00:51.689 And that explanation, it usually sounds like 00:00:51.689 --> 00:00:55.450 complete gibberish to the administration, which 00:00:55.450 --> 00:00:57.509 is I think the core tension we're getting into 00:00:57.509 --> 00:00:59.560 today. That's exactly where we're going. We're 00:00:59.560 --> 00:01:02.079 doing a deep dive into this really fascinating 00:01:02.079 --> 00:01:05.159 article called Key Performance Indicators and 00:01:05.159 --> 00:01:08.420 IT. It's by Gary Ackerman, published on hackscience 00:01:08.420 --> 00:01:13.319 .education back in January of 2026. And I'll 00:01:13.319 --> 00:01:15.420 be honest, when I first saw the title Key Performance 00:01:15.420 --> 00:01:17.579 Indicators, KPIs, I almost just scrolled right 00:01:17.579 --> 00:01:20.319 past it. It sounds like the driest, most corporate 00:01:20.319 --> 00:01:22.200 thing you could imagine. It really does. It sounds 00:01:22.200 --> 00:01:24.900 like a spreadsheet that absolutely nobody wants 00:01:24.900 --> 00:01:27.959 to open. The more I read Ackerman's piece, the 00:01:27.959 --> 00:01:29.780 more I realized this isn't about spreadsheets. 00:01:30.239 --> 00:01:33.019 It's about survival. It's about how IT leaders 00:01:33.019 --> 00:01:36.359 can use these numbers as like a defensive shield 00:01:36.359 --> 00:01:38.760 and a translation tool. That's the perfect way 00:01:38.760 --> 00:01:41.579 to put it. It's a power move that's just disguised 00:01:41.579 --> 00:01:43.950 as boring paperwork. So our mission for this 00:01:43.950 --> 00:01:46.370 deep dive is to unpack all of this. We're going 00:01:46.370 --> 00:01:48.329 to look at why schools even need these metrics, 00:01:48.450 --> 00:01:50.549 what numbers actually matter, you know, beyond 00:01:50.549 --> 00:01:54.090 just is the internet on. And this is the important 00:01:54.090 --> 00:01:56.230 part, how those same numbers can be used to hide 00:01:56.230 --> 00:01:59.450 a total disaster. The dark side of data. Exactly. 00:01:59.969 --> 00:02:03.310 So let's start with the big picture, the strategic 00:02:03.310 --> 00:02:07.170 need. Why does Ackerman say a school IT director 00:02:07.170 --> 00:02:09.849 needs to even bother with KPIs? Can't they just, 00:02:09.849 --> 00:02:12.550 you know, fix computers and call it a day? You 00:02:12.550 --> 00:02:15.210 think so, right? But Ackerman points to this 00:02:15.210 --> 00:02:18.050 fundamental translation problem inside schools. 00:02:18.430 --> 00:02:19.770 I mean, think about who's running a school district. 00:02:19.849 --> 00:02:22.150 You've got superintendents, principals, the school 00:02:22.150 --> 00:02:24.530 board. What's their background? It's usually 00:02:24.530 --> 00:02:27.789 education, you know, curriculum, pedagogy, maybe 00:02:27.789 --> 00:02:30.629 some finance or policy. They are not network 00:02:30.629 --> 00:02:32.370 engineers. They have no idea what the difference 00:02:32.370 --> 00:02:36.090 is between a DDoS attack. and you know a cheap 00:02:36.090 --> 00:02:38.729 router that just failed so when something breaks 00:02:38.729 --> 00:02:41.030 and the IT person starts talking about packet 00:02:41.030 --> 00:02:44.169 loss or server load the administration just hears 00:02:44.169 --> 00:02:46.710 noise they hear excuses they hear computers broken 00:02:46.710 --> 00:02:50.210 and you don't know why precisely so the KPI the 00:02:50.210 --> 00:02:52.669 key performance indicator becomes the translator 00:02:52.669 --> 00:02:55.289 it takes all that complex technical stuff and 00:02:55.289 --> 00:02:57.469 turns it into a simple metric that a non -technical 00:02:57.469 --> 00:02:59.800 leader can actually understand Okay, but here's 00:02:59.800 --> 00:03:01.860 the part from the source I found really interesting. 00:03:02.460 --> 00:03:04.919 Ackerman says IT leaders have to define their 00:03:04.919 --> 00:03:08.379 own KPIs. Doesn't that seem a little, I don't 00:03:08.379 --> 00:03:11.099 know, convenient, like grading your own homework? 00:03:11.460 --> 00:03:13.539 It does sound a bit suspicious, but it's really 00:03:13.539 --> 00:03:16.460 a defensive move. It's a necessity. Because if 00:03:16.460 --> 00:03:18.400 the IT department doesn't define what success 00:03:18.400 --> 00:03:20.620 looks like, then the administration's going to 00:03:20.620 --> 00:03:22.419 define it for them. And their definition might 00:03:22.419 --> 00:03:25.439 be totally unrealistic. Afford just. completely 00:03:25.439 --> 00:03:28.060 irrelevant. An administrator might say, success 00:03:28.060 --> 00:03:30.139 is zero complaints. Well, that's impossible. 00:03:30.780 --> 00:03:34.240 Or success is we spend zero dollars. Also impossible. 00:03:34.719 --> 00:03:37.939 So by setting the KPIs themselves, the IT leader 00:03:37.939 --> 00:03:39.879 is really setting the terms of the conversation. 00:03:39.979 --> 00:03:41.840 They get to control the narrative. So instead 00:03:41.840 --> 00:03:43.860 of the story being the Wi -Fi is always broken, 00:03:44.219 --> 00:03:48.419 the story is we achieved 99 .9 % network uptime 00:03:48.419 --> 00:03:50.819 this month, which actually exceeds our goal. 00:03:51.199 --> 00:03:53.520 Exactly. It moves the conversation away from 00:03:53.520 --> 00:03:55.520 just feelings like I feel like the Internet is 00:03:55.520 --> 00:03:58.610 slow and into facts. Well, the data shows our 00:03:58.610 --> 00:04:01.310 latency is under 20 milliseconds. It stops what 00:04:01.310 --> 00:04:03.990 Ackerman calls distraction. It keeps the bosses 00:04:03.990 --> 00:04:06.669 from obsessing over a tiny glitch when you can 00:04:06.669 --> 00:04:08.810 prove the whole system is healthy. I love that 00:04:08.810 --> 00:04:12.650 phrase, data as self -defense. OK, let's get 00:04:12.650 --> 00:04:15.330 into the weeds then. If I'm an IT director, or 00:04:15.330 --> 00:04:17.550 maybe I'm a principal trying to figure out what 00:04:17.550 --> 00:04:20.589 my IT team is doing, what should I actually be 00:04:20.589 --> 00:04:22.769 measuring? Ackerman breaks this down pretty neatly. 00:04:22.990 --> 00:04:25.149 He does. And the first category is what I kind 00:04:25.149 --> 00:04:27.639 of think of as the plumbing. you know, speed 00:04:27.639 --> 00:04:30.139 and reliability. The absolute basics. Right. 00:04:30.379 --> 00:04:33.540 Most obvious one is system uptime. It's just 00:04:33.540 --> 00:04:35.819 the percentage of time that your critical systems 00:04:35.819 --> 00:04:38.079 are actually working. That's the classic five 00:04:38.079 --> 00:04:40.220 nines thing we always hear about, right? Like 00:04:40.220 --> 00:04:43.680 99 .999 percent uptime. That's the gold standard, 00:04:43.699 --> 00:04:46.939 yeah. And in the school, if the student information 00:04:46.939 --> 00:04:49.579 system goes down, you can't take attendance, 00:04:49.620 --> 00:04:51.620 you can't see a kid's medical records, you can't 00:04:51.620 --> 00:04:54.180 call a parent. The school is basically paralyzed. 00:04:54.240 --> 00:04:56.860 So tracking uptime is step one. But, and this 00:04:56.860 --> 00:04:59.680 is a really big, but uptime can be super deceiving. 00:04:59.899 --> 00:05:03.379 How so? I mean, if it's on, it's on. Not really. 00:05:03.980 --> 00:05:06.339 And that brings us to the second metric he mentions, 00:05:07.259 --> 00:05:10.660 network performance. The lights can be on in 00:05:10.660 --> 00:05:14.540 the house. but it's how it's usable. This is 00:05:14.540 --> 00:05:16.939 where you measure bandwidth, latency, packet 00:05:16.939 --> 00:05:19.139 loss. OK, hold on. Can we define those? Because 00:05:19.139 --> 00:05:21.800 I feel like latency is a word I only hear when 00:05:21.800 --> 00:05:23.779 my video game is lagging. What does it mean in 00:05:23.779 --> 00:05:26.180 a classroom? So think of it this way. Bandwidth 00:05:26.180 --> 00:05:28.839 is how wide the highway is. Latency is how long 00:05:28.839 --> 00:05:30.680 it takes to actually drive from one end to the 00:05:30.680 --> 00:05:33.120 other. You'd have a 10 -lane highway. That's 00:05:33.120 --> 00:05:35.259 huge bandwidth. But if there's a traffic jam 00:05:35.259 --> 00:05:37.339 and you're moving an inch a minute, your latency 00:05:37.339 --> 00:05:40.240 is terrible. So for a student, high latency would 00:05:40.240 --> 00:05:43.149 be? The spinning wheel of death. You click a 00:05:43.149 --> 00:05:46.430 link, and you wait. And you wait. The video keeps 00:05:46.430 --> 00:05:49.569 buffering. A Zoom call freezes. So technically 00:05:49.569 --> 00:05:52.529 the system is up. The server is working. But 00:05:52.529 --> 00:05:55.970 for all practical purposes, the lesson is completely 00:05:55.970 --> 00:05:59.029 ruined. That is a huge distinction. So uptime 00:05:59.029 --> 00:06:01.529 just means the machine is running, but performance 00:06:01.529 --> 00:06:04.089 means a human can actually get their work done. 00:06:04.350 --> 00:06:06.709 Exactly. And if you're only measuring uptime, 00:06:06.889 --> 00:06:08.509 You could be sitting there patting yourself on 00:06:08.509 --> 00:06:10.850 the back, while every single teacher in the building 00:06:10.850 --> 00:06:13.050 absolutely hates your guts. Which is a perfect 00:06:13.050 --> 00:06:16.350 lead -in to his second category, the support 00:06:16.350 --> 00:06:18.810 experience. Because, you know, things do break, 00:06:18.829 --> 00:06:20.790 and people have to call someone. Yeah, this is 00:06:20.790 --> 00:06:24.269 where IT gets very, very human. Ackerman points 00:06:24.269 --> 00:06:27.170 to two really important metrics here, help desk 00:06:27.170 --> 00:06:30.970 response time and ticket resolution time. And 00:06:30.970 --> 00:06:32.769 you have to be so careful not to mix those two 00:06:32.769 --> 00:06:34.810 up. Response versus resolution, OK. Response 00:06:34.810 --> 00:06:36.779 time is just, hey, we got your ticket. It's just 00:06:36.779 --> 00:06:38.819 acknowledging the problem exists. Does an automated 00:06:38.819 --> 00:06:41.000 email count for that? In a bad organization, 00:06:41.220 --> 00:06:44.199 yes. In a good one, it means a real person has 00:06:44.199 --> 00:06:46.319 looked at it and figured out how urgent it is. 00:06:46.839 --> 00:06:49.920 A fast response time lowers anxiety. It tells 00:06:49.920 --> 00:06:52.139 that teacher, okay, help is on the way. But it 00:06:52.139 --> 00:06:54.240 doesn't mean the problem is actually fixed. Not 00:06:54.240 --> 00:06:57.399 at all. That's resolution time. How long did 00:06:57.399 --> 00:06:59.779 it take from that first frantic email until the 00:06:59.779 --> 00:07:01.699 printer is actually printing again? I can already 00:07:01.699 --> 00:07:03.579 see a problem there. If I'm the tech, I want 00:07:03.579 --> 00:07:05.959 to close tickets as fast as possible, so my resolution 00:07:05.959 --> 00:07:08.899 time looks great. But some problems are really 00:07:08.899 --> 00:07:12.120 hard. That's the tension. And we'll get to manipulation 00:07:12.120 --> 00:07:15.579 later. But yeah, if you only reward speed, you'll 00:07:15.579 --> 00:07:18.759 get technicians putting a digital Band -Aid on 00:07:18.759 --> 00:07:21.279 everything just to close the ticket, which is 00:07:21.279 --> 00:07:23.560 why Ackerman says you also have to measure user 00:07:23.560 --> 00:07:25.959 satisfaction. The survey data. Right. You have 00:07:25.959 --> 00:07:27.939 to go ask the humans, are you actually happy? 00:07:28.040 --> 00:07:30.579 Because you can have Amazing metrics on paper, 00:07:30.720 --> 00:07:33.639 fast response, great uptime. But if your IT staff 00:07:33.639 --> 00:07:37.060 is rude or condescending, or if the fix doesn't 00:07:37.060 --> 00:07:39.720 actually help the teacher teach, your satisfaction 00:07:39.720 --> 00:07:41.500 score is going to be in the basement. It's like 00:07:41.500 --> 00:07:43.500 taking the emotional temperature of the building. 00:07:45.879 --> 00:07:47.519 OK, so we have plumbing and support. What's the 00:07:47.519 --> 00:07:50.779 third bucket? Security and maintenance. This 00:07:50.779 --> 00:07:53.860 is all the stuff that, if you do it right, keeps 00:07:53.860 --> 00:07:56.139 you out of the headlines. Scary stuff. The biggest 00:07:56.139 --> 00:07:59.920 one here is security incidents. You are literally 00:07:59.920 --> 00:08:03.240 just counting the bad things that happened. Malware 00:08:03.240 --> 00:08:06.139 infections, successful phishing attacks, data 00:08:06.139 --> 00:08:08.379 breaches. And the goal is zero, I'm guessing. 00:08:08.540 --> 00:08:11.889 The goal is always zero. But the reality is looking 00:08:11.889 --> 00:08:14.089 at the trends. Are we seeing more attacks? Are 00:08:14.089 --> 00:08:17.009 we catching them faster? But what's really tied 00:08:17.009 --> 00:08:19.370 to this is device management. Just counting all 00:08:19.370 --> 00:08:21.829 the laptops. It's way more than counting. It's 00:08:21.829 --> 00:08:24.230 about their health. How many devices out there 00:08:24.230 --> 00:08:26.250 haven't been updated in six months? How many 00:08:26.250 --> 00:08:28.129 iPads haven't checked in with the main server? 00:08:28.610 --> 00:08:31.089 In the security world, we call these zombie devices. 00:08:31.490 --> 00:08:33.289 Zombie device, I like that. Because if they're 00:08:33.289 --> 00:08:35.450 not getting updates, they've got like holes in 00:08:35.450 --> 00:08:38.870 their armor. Exactly. An unpatched laptop from 00:08:38.870 --> 00:08:42.299 last year. connecting to your network today is 00:08:42.299 --> 00:08:45.120 just, it's a ticking time bomb. It's an open 00:08:45.120 --> 00:08:47.799 door for an attacker. So a high percentage of 00:08:47.799 --> 00:08:50.639 managed and updated devices is a massive security 00:08:50.639 --> 00:08:53.080 win. And the source mentions software deployment 00:08:53.080 --> 00:08:55.740 time in this section too. Why is that a KPI? 00:08:56.139 --> 00:08:58.940 Okay, so imagine a huge security flaw is found 00:08:58.940 --> 00:09:01.340 in Windows. You've got 5 ,000 laptops spread 00:09:01.340 --> 00:09:04.019 across 10 different buildings. How long does 00:09:04.019 --> 00:09:06.179 it take you to push that critical patch to every 00:09:06.179 --> 00:09:09.570 single one of them a day? a week, that deployment 00:09:09.570 --> 00:09:12.149 time is your window of vulnerability. So the 00:09:12.149 --> 00:09:15.309 speed is literally about safety? It is. Plus, 00:09:15.669 --> 00:09:17.210 deploying things efficiently means you're not 00:09:17.210 --> 00:09:19.409 disrupting class. You don't want an update to 00:09:19.409 --> 00:09:21.230 start installing when a kid is halfway through 00:09:21.230 --> 00:09:22.950 a standardized test. Oh, that's the nightmare 00:09:22.950 --> 00:09:24.950 scenario. Please weigh while Windows updates 00:09:24.950 --> 00:09:27.889 10 % complete. And the student is failing the 00:09:27.889 --> 00:09:31.049 exam, just watching that progress bar. That is 00:09:31.049 --> 00:09:33.230 how an IT director gets fired. OK, so that's 00:09:33.230 --> 00:09:35.769 all defense. Is there a more strategic side to 00:09:35.769 --> 00:09:37.909 these metrics? Yeah, that's the last category 00:09:37.909 --> 00:09:41.169 he calls future proofing in finance. This has 00:09:41.169 --> 00:09:43.750 things like cost management, staying on budget. 00:09:44.230 --> 00:09:46.710 But the really interesting one to me is training 00:09:46.710 --> 00:09:48.990 and professional development. So just tracking 00:09:48.990 --> 00:09:50.990 how many training sessions you run for teachers. 00:09:51.190 --> 00:09:53.669 Yes. And this is what's called a leading indicator. 00:09:54.379 --> 00:09:56.879 Most of the KPIs we've talked about are lagging 00:09:56.879 --> 00:09:58.820 indicators. They tell you what already happened, 00:09:59.120 --> 00:10:01.460 the server went down, the ticket was closed. 00:10:01.600 --> 00:10:04.679 But training, that predicts the future. In a 00:10:04.679 --> 00:10:08.080 way, yes. If you see high engagement in professional 00:10:08.080 --> 00:10:09.860 development, teachers are learning how to use 00:10:09.860 --> 00:10:12.480 the new software, staff are learning how to spot 00:10:12.480 --> 00:10:15.399 phishing emails, you can actually predict that 00:10:15.399 --> 00:10:18.470 your help desk tickets will go down. and your 00:10:18.470 --> 00:10:20.789 security incidents will drop in the future. That's 00:10:20.789 --> 00:10:23.710 a great point. You're investing in the brainware, 00:10:23.789 --> 00:10:26.009 not just the hardware. It shifts the IT department 00:10:26.009 --> 00:10:29.710 from being just fixers to being educators. So 00:10:29.710 --> 00:10:32.009 this all sounds incredibly logical. You know, 00:10:32.009 --> 00:10:34.250 you build this dashboard, you track your uptime, 00:10:34.389 --> 00:10:36.429 your tickets, security, training, you show it 00:10:36.429 --> 00:10:39.909 to the school board, everyone's happy. But it's 00:10:39.909 --> 00:10:42.450 never that simple. And Ackerman spends a lot 00:10:42.450 --> 00:10:44.830 of time in the article on this. He warns that 00:10:44.830 --> 00:10:47.620 metrics can lie. Or, as he puts it, They can 00:10:47.620 --> 00:10:51.419 be myopic, nearsighted. This is maybe the most 00:10:51.419 --> 00:10:54.639 dangerous trap of all. Myopia is when you focus 00:10:54.639 --> 00:10:57.759 so hard on hitting a specific number that you 00:10:57.759 --> 00:11:00.419 completely miss the big picture. You hit the 00:11:00.419 --> 00:11:02.759 target, but you miss the entire point. He gives 00:11:02.759 --> 00:11:05.019 this amazing example for this, the Chromebook 00:11:05.019 --> 00:11:07.120 paradox. Can we break that one down? Yeah, this 00:11:07.120 --> 00:11:09.580 is such a classic scenario. So let's say a school 00:11:09.580 --> 00:11:11.759 bird has a goal. We want more devices for students, 00:11:11.820 --> 00:11:14.220 more digital equity. So the IT director makes 00:11:14.220 --> 00:11:16.960 a KPI for it. total number of student devices. 00:11:17.340 --> 00:11:19.899 Seems reasonable. More computers, better access. 00:11:20.379 --> 00:11:22.620 Right. So to hit that number, the IT director 00:11:22.620 --> 00:11:24.620 goes out and buys 2 ,000 of the cheapest, most 00:11:24.620 --> 00:11:26.659 basic Chromebooks they can find. The numbers 00:11:26.659 --> 00:11:28.980 on the chart go through the roof. The dashboard 00:11:28.980 --> 00:11:32.120 is bright green. Look, we increased devices by 00:11:32.120 --> 00:11:35.720 300%. But what if that school has a really strong 00:11:35.720 --> 00:11:38.419 program in, say, graphic design or video editing 00:11:38.419 --> 00:11:41.600 or engineering? You can't run AutoCAD or Adobe 00:11:41.600 --> 00:11:44.879 Premiere on a $150 Chromebook. So the students 00:11:44.879 --> 00:11:47.100 have a device, but they can't actually do their 00:11:47.100 --> 00:11:50.000 schoolwork on it. Exactly. The quantity metric 00:11:50.000 --> 00:11:53.120 was met, but the capacity need was totally ignored. 00:11:53.759 --> 00:11:56.399 The educational value of that spending is basically 00:11:56.399 --> 00:11:59.179 zero. You could even argue it's negative because 00:11:59.179 --> 00:12:01.879 you just blew the whole budget on useless hardware. 00:12:02.159 --> 00:12:05.460 That's a failure completely disguised as a success. 00:12:05.879 --> 00:12:08.059 And the dashboard would never tell you that. 00:12:08.320 --> 00:12:10.720 The dashboard would say, mission accomplished. 00:12:11.000 --> 00:12:13.500 That's the danger of myopia. It's why Ackerman 00:12:13.500 --> 00:12:17.000 warns so much about focusing on counts over capabilities. 00:12:17.379 --> 00:12:19.279 And this kind of bleeds into the darker side 00:12:19.279 --> 00:12:22.059 of things, doesn't it? Just outright manipulation. 00:12:22.519 --> 00:12:23.919 There's something called Campbell's Law, which 00:12:23.919 --> 00:12:26.440 basically says that the more you use a number 00:12:26.440 --> 00:12:28.799 to make important decisions, the more likely 00:12:28.799 --> 00:12:31.059 people are to start corrupting that number. In 00:12:31.059 --> 00:12:33.860 plain English? If my bonus depends on a number... 00:12:33.789 --> 00:12:35.470 I'm going to do whatever it takes to make that 00:12:35.470 --> 00:12:37.269 number look good, even if it hurts the whole 00:12:37.269 --> 00:12:39.850 organization. OK, give me an IT example. Let's 00:12:39.850 --> 00:12:41.909 go back to that ticket resolution time metric. 00:12:42.029 --> 00:12:45.309 Yeah. The boss says all tickets have to be resolved 00:12:45.309 --> 00:12:49.850 in 24 hours. Right. And I get a really hard problem. 00:12:49.990 --> 00:12:52.690 I know I can't fix it in 24 hours. So what do 00:12:52.690 --> 00:12:55.629 you do? You mark the ticket resolved, then send 00:12:55.629 --> 00:12:57.450 an email saying, hey, I think this is fixed. 00:12:57.490 --> 00:13:01.090 Let me know if it happens again. Or. Even worse, 00:13:01.629 --> 00:13:04.710 you close the ticket and then immediately open 00:13:04.710 --> 00:13:06.730 a new ticket for the exact same problem. You 00:13:06.730 --> 00:13:08.710 reset the clock. You reset the clock. Your stats 00:13:08.710 --> 00:13:11.730 look fantastic. Wow. Our average resolution time 00:13:11.730 --> 00:13:14.889 is only four hours. But the teacher is absolutely 00:13:14.889 --> 00:13:17.570 losing their mind because they have to keep reporting 00:13:17.570 --> 00:13:20.450 the same issue over and over. This is sometimes 00:13:20.450 --> 00:13:22.850 called a watermelon effect. Oh, watermelon. Green 00:13:22.850 --> 00:13:25.169 on the outside on the dashboard, but bright red 00:13:25.169 --> 00:13:27.659 on the inside. which is the reality. That is 00:13:27.659 --> 00:13:29.919 a very vivid image, and I guess this makes user 00:13:29.919 --> 00:13:32.659 satisfaction really tricky too. If I send a teacher 00:13:32.659 --> 00:13:34.919 a survey that says, are you happy, and it just 00:13:34.919 --> 00:13:36.940 had a terrible class, they might say no just 00:13:36.940 --> 00:13:39.059 because they're in a bad mood. And Ackerman points 00:13:39.059 --> 00:13:42.120 that out. Satisfaction is subjective. You can't 00:13:42.120 --> 00:13:44.659 just have a smiley face button on an email. You 00:13:44.659 --> 00:13:47.659 need to use proper instruments, validated surveys 00:13:47.659 --> 00:13:50.460 that measure technology acceptance, and ask questions 00:13:50.460 --> 00:13:52.940 like, did this tech actually help you teach better? 00:13:53.139 --> 00:13:57.090 Not just, do you like us today? So we're really 00:13:57.090 --> 00:13:59.370 walking a tightrope here. We need the data to 00:13:59.370 --> 00:14:01.889 defend our work and to get funding. But if we 00:14:01.889 --> 00:14:04.470 trust it blindly, we could be driving the entire 00:14:04.470 --> 00:14:07.590 school right off a cliff. So what's the solution? 00:14:07.809 --> 00:14:10.429 How do we use these tools without, you know, 00:14:10.669 --> 00:14:13.350 getting hurt by them? Ackerman really boils it 00:14:13.350 --> 00:14:16.269 all down to one word. Alignment. Alignment. Your 00:14:16.269 --> 00:14:18.870 KPIs can't just exist in some IT bubble. They 00:14:18.870 --> 00:14:20.730 have to be directly aligned with the overarching 00:14:20.730 --> 00:14:23.450 goals of the school itself. So before you even 00:14:23.450 --> 00:14:25.309 decide to start counting Chromebooks, you have 00:14:25.309 --> 00:14:27.649 to ask a much bigger question. You have to ask, 00:14:27.970 --> 00:14:29.850 what are we actually trying to teach here? If 00:14:29.850 --> 00:14:32.250 the school's big mission is excellence in the 00:14:32.250 --> 00:14:35.450 digital arts, then your KPI isn't number of devices. 00:14:35.909 --> 00:14:38.470 It's number of workstations capable of rendering 00:14:38.470 --> 00:14:42.000 4K video. That's such a subtle change, but it 00:14:42.000 --> 00:14:44.279 changes absolutely everything. It forces the 00:14:44.279 --> 00:14:46.759 IT goals to be in service of the educational 00:14:46.759 --> 00:14:50.000 goals. Exactly. Ackerman says KPI should be seen 00:14:50.000 --> 00:14:53.340 as stepping stones, not the final destination. 00:14:53.559 --> 00:14:56.399 They're just markers on the path. And crucially, 00:14:56.590 --> 00:14:59.029 You have to be willing to change them. Adaptability. 00:14:59.210 --> 00:15:02.610 I mean, tech changes so fast. A KPI that was 00:15:02.610 --> 00:15:06.049 brilliant in 2024 might be totally useless by 00:15:06.049 --> 00:15:09.789 2026. If you're still measuring DVD player uptime, 00:15:10.210 --> 00:15:12.629 you're fighting the wrong war. You have to constantly 00:15:12.629 --> 00:15:14.929 look at your metrics and ask, does this number 00:15:14.929 --> 00:15:17.269 still matter? It sounds like the job of an IT 00:15:17.269 --> 00:15:19.330 director has changed. It's less about being a 00:15:19.330 --> 00:15:22.000 mechanic and more about being a strategist. That's 00:15:22.000 --> 00:15:24.379 the ultimate takeaway from the piece. In a modern 00:15:24.379 --> 00:15:27.139 school, the IT leader has to be a strategic partner. 00:15:28.019 --> 00:15:29.559 They're not just the person you call when the 00:15:29.559 --> 00:15:31.679 printer is jammed. They're the person who makes 00:15:31.679 --> 00:15:33.860 sure the entire infrastructure can support the 00:15:33.860 --> 00:15:35.919 way you want to teach. and keep you eyes on the 00:15:35.919 --> 00:15:37.419 language they use to prove they're doing it. 00:15:37.519 --> 00:15:39.460 You know, I think there's a lesson in here for 00:15:39.460 --> 00:15:41.659 everybody, not just people in IT. Maybe you're 00:15:41.659 --> 00:15:45.179 in marketing or HR or even just, I don't know, 00:15:45.379 --> 00:15:47.820 managing your own household budget. What's the 00:15:47.820 --> 00:15:49.960 parallel you're seeing? It's this idea of defining 00:15:49.960 --> 00:15:52.379 your own success before somebody else does it 00:15:52.379 --> 00:15:54.679 for you. If you don't set the metrics for your 00:15:54.679 --> 00:15:57.159 own job, if you don't articulate, this is what 00:15:57.159 --> 00:15:59.919 value looks like for my role, then you're just 00:15:59.919 --> 00:16:02.940 leaving yourself vulnerable to being judged by 00:16:02.940 --> 00:16:04.639 someone who might have no clue. what you actually 00:16:04.639 --> 00:16:07.519 do. It's profound, yeah. Controlling the definition 00:16:07.519 --> 00:16:10.600 of success gives you all the leverage. If you 00:16:10.600 --> 00:16:12.980 point to the data you chose, you get to justify 00:16:12.980 --> 00:16:15.789 your own existence. So before we wrap this deep 00:16:15.789 --> 00:16:17.370 dive up, I want to leave you with one last thing 00:16:17.370 --> 00:16:19.629 to think about. We talked about that watermelon 00:16:19.629 --> 00:16:21.990 effect. We talked about how a dashboard can be 00:16:21.990 --> 00:16:24.250 all green while the building is on fire. The 00:16:24.250 --> 00:16:27.429 illusion of control. So if we know that KPIs 00:16:27.429 --> 00:16:30.230 can be manipulated, if we know a clever person 00:16:30.230 --> 00:16:32.970 can game the system to make a disaster look like 00:16:32.970 --> 00:16:36.330 a victory, how do you measure the integrity of 00:16:36.330 --> 00:16:38.669 the data itself? Now that is the provocative 00:16:38.669 --> 00:16:42.250 question. In a system as complex as a school, 00:16:42.490 --> 00:16:44.750 Nothing is ever perfect. There's always friction. 00:16:44.870 --> 00:16:46.789 There's always some broken projector somewhere. 00:16:47.750 --> 00:16:50.549 So if I see a dashboard, and it's 100 % green, 00:16:51.029 --> 00:16:53.610 across the board, I actually get suspicious. 00:16:53.789 --> 00:16:56.899 You think perfection is the red flag. I do. Is 00:16:56.899 --> 00:16:59.720 it possible that the greenest, most perfect dashboard 00:16:59.720 --> 00:17:01.740 is actually the one that's hiding the biggest 00:17:01.740 --> 00:17:04.900 systemic problems? Because a healthy system has 00:17:04.900 --> 00:17:07.779 noise. A healthy system reports its failures 00:17:07.779 --> 00:17:10.420 so it can learn from them. If all your data says 00:17:10.420 --> 00:17:12.920 everything is perfect, maybe the data is the 00:17:12.920 --> 00:17:15.259 biggest lie of all. A little healthy paranoia 00:17:15.259 --> 00:17:17.960 to end on. Don't trust the perfect spreadsheet. 00:17:18.099 --> 00:17:20.599 Never. That's our deep dive on the invisible 00:17:20.599 --> 00:17:23.200 machinery of school IT. Thanks for listening, 00:17:23.220 --> 00:17:25.119 and we'll catch you on the next one. Stay curious.