WEBVTT 00:00:00.000 --> 00:00:02.540 Welcome back to The Deep Dive. Today we are jumping 00:00:02.540 --> 00:00:05.459 straight into something that really dictates 00:00:05.459 --> 00:00:08.439 success or failure in just about any tech project. 00:00:08.919 --> 00:00:11.140 We're talking about the gap between technical 00:00:11.140 --> 00:00:14.119 success and functional success. That critical 00:00:14.119 --> 00:00:16.199 difference between building something right and 00:00:16.199 --> 00:00:18.879 building the right thing. And it's a distinction 00:00:18.879 --> 00:00:22.140 that sounds so simple. but it is the invisible 00:00:22.140 --> 00:00:25.859 killer of budgets, of projects, of morale. Right. 00:00:25.960 --> 00:00:27.859 You can check off every single requirement, you 00:00:27.859 --> 00:00:30.500 can hit every deadline, and still deliver something 00:00:30.500 --> 00:00:32.679 that is, for all intents and purposes, useless. 00:00:33.140 --> 00:00:35.020 And the source we're looking at today just lays 00:00:35.020 --> 00:00:37.399 this out so clearly. It's an excerpt called, 00:00:37.799 --> 00:00:40.399 A Story About Technology Leaders in School. It's 00:00:40.399 --> 00:00:43.560 by Gary Ackerman, posted on a site called hackscience 00:00:43.560 --> 00:00:46.350 .education. And while the setting is a school, 00:00:46.869 --> 00:00:49.189 I mean, this lesson is completely universal. 00:00:49.369 --> 00:00:51.469 Absolutely. So our mission today is to really 00:00:51.469 --> 00:00:55.570 unpack this mindset, this defensive compliance 00:00:55.570 --> 00:00:58.490 -driven thinking that leads to failure. And then 00:00:58.490 --> 00:01:00.670 we need to identify the leadership skills you 00:01:00.670 --> 00:01:03.689 need to avoid it. So let's dig in. Ackerman starts 00:01:03.689 --> 00:01:05.810 with a story about a technology coordinator he 00:01:05.810 --> 00:01:08.180 was coaching. Right. And this coordinator, by 00:01:08.180 --> 00:01:10.980 all accounts, was technically brilliant. He could 00:01:10.980 --> 00:01:12.719 implement anything you put in front of him. But 00:01:12.719 --> 00:01:16.120 he had this kind of armor, a defense mechanism 00:01:16.120 --> 00:01:18.739 for when things didn't go according to the original 00:01:18.739 --> 00:01:22.620 plan. Exactly. So the scenario is he's just finished 00:01:22.620 --> 00:01:26.680 a huge tech deployment, devices, software, the 00:01:26.680 --> 00:01:29.280 whole system. And he built it based on what the 00:01:29.280 --> 00:01:32.000 educators, the users had asked for. He followed 00:01:32.000 --> 00:01:34.599 the spec sheet to the letter. To the letter. 00:01:35.119 --> 00:01:38.180 But then the moment of crisis comes, the educators 00:01:38.180 --> 00:01:40.560 actually get the system in their hands. They 00:01:40.560 --> 00:01:42.799 start using it. And they realize, oh, wait a 00:01:42.799 --> 00:01:44.939 minute. This doesn't actually fit our workflow. 00:01:45.120 --> 00:01:47.540 This isn't helping us day to day. They immediately 00:01:47.540 --> 00:01:49.920 start asking for modifications, for changes. 00:01:50.280 --> 00:01:51.799 And this is where we get the quote, the line 00:01:51.799 --> 00:01:53.939 that just sums up this entire problem. What does 00:01:53.939 --> 00:01:56.420 he say? He just says flat out, I built what they 00:01:56.420 --> 00:01:58.519 asked for. If they asked for the wrong thing, 00:01:58.700 --> 00:02:02.560 that is not my problem. Wow. That is not my problem. 00:02:03.480 --> 00:02:06.260 And you know, it's fascinating because on a surface 00:02:06.260 --> 00:02:09.539 level, that sounds almost professional. It sounds 00:02:09.539 --> 00:02:12.460 like I'm disciplined. I followed the requirements. 00:02:12.740 --> 00:02:14.840 It is the ultimate expression of a transactional 00:02:14.840 --> 00:02:17.659 mindset. You gave me a task. I completed the 00:02:17.659 --> 00:02:20.560 task. The utility, what happens next, that's 00:02:20.560 --> 00:02:23.699 on you. He's prioritizing compliance over the 00:02:23.699 --> 00:02:25.960 actual function. Precisely. And in a vacuum, 00:02:25.979 --> 00:02:28.340 you could maybe defend that. But he's not in 00:02:28.340 --> 00:02:31.479 a vacuum. He's in a school. a living, breathing 00:02:31.479 --> 00:02:33.699 environment where people are learning and adapting. 00:02:33.979 --> 00:02:36.819 The users, the teachers, they don't know exactly 00:02:36.819 --> 00:02:38.780 what they need until they can touch it and feel 00:02:38.780 --> 00:02:40.159 it. That's when they realize, you know, this 00:02:40.159 --> 00:02:42.919 report should be one click, not five. Exactly. 00:02:43.319 --> 00:02:45.419 They are refining their own understanding of 00:02:45.419 --> 00:02:48.539 the need through experience. And when the coordinator 00:02:48.539 --> 00:02:50.800 just shuts that down with, not my problem... 00:02:50.800 --> 00:02:53.259 He's not just refusing to do more work. No, he's 00:02:53.259 --> 00:02:55.740 fundamentally misunderstanding his role. And 00:02:55.740 --> 00:02:58.189 this is where the coach... Ackerman steps in 00:02:58.189 --> 00:03:01.210 and insists, no, this is your problem. And that's 00:03:01.210 --> 00:03:03.669 the pivot point, isn't it? That refusal to own 00:03:03.669 --> 00:03:06.729 the outcome leads directly to just catastrophic 00:03:06.729 --> 00:03:08.610 costs. Yeah, let's talk about the math here, 00:03:08.610 --> 00:03:11.530 because it's grim. When the IT team takes this 00:03:11.530 --> 00:03:15.469 stance, the source points out this huge dual 00:03:15.469 --> 00:03:17.409 waste of investment. OK, so the first one is 00:03:17.409 --> 00:03:20.409 the obvious one, the money. Right. The cash, 00:03:20.849 --> 00:03:23.110 the school district spent on the devices, the 00:03:23.110 --> 00:03:25.629 software licenses, all of it. If that system 00:03:25.629 --> 00:03:28.530 just sits there, unused. That investment's value 00:03:28.530 --> 00:03:31.669 goes to zero instantly. It's just a massive budget 00:03:31.669 --> 00:03:34.789 hole. But the second cost is almost worse. It's 00:03:34.789 --> 00:03:37.150 the opportunity cost. It's the waste of time. 00:03:37.389 --> 00:03:39.250 And we're not just talking about the hours the 00:03:39.250 --> 00:03:42.169 IT team spent building it. No, not at all. It's 00:03:42.169 --> 00:03:44.370 that they spent all those hours, all that brain 00:03:44.370 --> 00:03:47.090 power building the wrong thing. All of that time, 00:03:47.250 --> 00:03:49.930 the planning, the development, the testing. It 00:03:49.930 --> 00:03:51.930 could have been spent solving a real problem 00:03:51.930 --> 00:03:54.330 for the school. Instead, it was spent producing 00:03:54.330 --> 00:03:57.009 a technical artifact that was functionally flawed. 00:03:57.629 --> 00:03:59.330 And think about the ripple effects of that not 00:03:59.330 --> 00:04:01.229 -my -problem attitude. Well, the system just 00:04:01.229 --> 00:04:04.069 sits there. It's underutilized or maybe not utilized 00:04:04.069 --> 00:04:07.530 at all. So A, the problem the school wanted to 00:04:07.530 --> 00:04:12.189 solve still exists. B, a year of expensive professional 00:04:12.189 --> 00:04:16.069 effort is down the drain. And C, the credibility 00:04:16.069 --> 00:04:18.660 of the entire IT department is shot. And this 00:04:18.660 --> 00:04:21.800 brings us to what I think is the core aha moment 00:04:21.800 --> 00:04:24.879 for anyone listening. Delivering a technically 00:04:24.879 --> 00:04:27.980 perfect system that no one uses is actually worse 00:04:27.980 --> 00:04:30.740 than delivering nothing at all. It's so much 00:04:30.740 --> 00:04:32.379 worse. Because if you deliver nothing, at least 00:04:32.379 --> 00:04:34.019 you still have the budget. You still have the 00:04:34.019 --> 00:04:36.199 time. You can start over and do it right. Exactly. 00:04:36.519 --> 00:04:38.860 The tech leader's job is to deliver utility, 00:04:39.519 --> 00:04:42.120 to deliver a solution. If the teachers can't 00:04:42.120 --> 00:04:44.579 teach better, if the staff can't work more efficiently, 00:04:45.040 --> 00:04:47.139 then the project failed. It doesn't matter how 00:04:47.139 --> 00:04:49.420 clean the code is. The metric for success has 00:04:49.420 --> 00:04:52.199 to be utilization, not installation. Yes, that 00:04:52.199 --> 00:04:54.800 is the entire mindset shift. OK, so if that's 00:04:54.800 --> 00:04:57.480 the problem, how do we fix it? What are the skills 00:04:57.480 --> 00:04:59.740 that Gary Ackerman points to that move someone 00:04:59.740 --> 00:05:02.339 from being that technical order -taker to a real 00:05:02.339 --> 00:05:04.660 functional partner? He synthesizes it down to 00:05:04.660 --> 00:05:07.300 two key skills. And they really redefine what 00:05:07.300 --> 00:05:09.819 the final product even means. All right, what's 00:05:09.819 --> 00:05:12.279 skill number one? Careful listening. And this 00:05:12.279 --> 00:05:14.920 sounds so simple, right? Deceptively simple. 00:05:15.199 --> 00:05:17.139 Everyone thinks they're a good listener. Of course. 00:05:17.879 --> 00:05:21.060 But what Ackerman means by careful here is listening 00:05:21.060 --> 00:05:23.860 beyond the literal words. It's about being a 00:05:23.860 --> 00:05:27.660 translator. So if a teacher says, I need a report 00:05:27.660 --> 00:05:30.620 that tracks daily attendance, the careful listener 00:05:30.620 --> 00:05:33.680 doesn't just go and build the report. No. They 00:05:33.680 --> 00:05:36.740 stop. They ask. Why do you need that report? 00:05:36.959 --> 00:05:38.899 What decision will you make with that data? What's 00:05:38.899 --> 00:05:40.560 the real job you're trying to get done here? 00:05:40.660 --> 00:05:42.600 You're trying to get to the root need, not just 00:05:42.600 --> 00:05:45.100 the technical request. Yes. The initial request 00:05:45.100 --> 00:05:47.560 is just the user's best guess at a solution. 00:05:48.279 --> 00:05:50.500 The tech leader's job is to uncover the actual 00:05:50.500 --> 00:05:54.180 problem, that attendance report. Maybe the real 00:05:54.180 --> 00:05:56.579 need is to identify at -risk students earlier. 00:05:56.699 --> 00:05:58.939 And if you understand that... you might propose 00:05:58.939 --> 00:06:01.639 a totally different solution, like an automated 00:06:01.639 --> 00:06:04.079 alert system instead of a static manual report. 00:06:04.139 --> 00:06:06.100 Which is a much better functional solution. It 00:06:06.100 --> 00:06:08.620 actually solves the underlying problem, not just 00:06:08.620 --> 00:06:10.579 the surface level request. But here's the challenge, 00:06:10.660 --> 00:06:12.740 right? The thing that I think a lot of technical 00:06:12.740 --> 00:06:15.500 people fear, scope creep. If you start asking 00:06:15.500 --> 00:06:17.839 all these why questions, aren't you just inviting 00:06:17.839 --> 00:06:20.040 the user to keep adding more and more to the 00:06:20.040 --> 00:06:23.139 project? How do you protect your resources? And 00:06:23.139 --> 00:06:25.339 that leads us perfectly into the second essential 00:06:25.339 --> 00:06:28.470 skill, commitment. to the final product. OK, 00:06:28.470 --> 00:06:30.209 what does that mean in practice? It doesn't mean 00:06:30.209 --> 00:06:33.870 an infinite budget. No, it means you marry that 00:06:33.870 --> 00:06:36.910 careful listening to a development process that 00:06:36.910 --> 00:06:40.709 expects change. Your commitment is to the operational 00:06:40.709 --> 00:06:43.290 goal, not to the original piece of paper you 00:06:43.290 --> 00:06:46.209 both signed. So if the specs from six months 00:06:46.209 --> 00:06:49.089 ago are clearly wrong now, how does a leader 00:06:49.089 --> 00:06:51.850 handle that? Well, the commitment shows up through 00:06:51.850 --> 00:06:54.810 iterative development. You build a small functional 00:06:54.810 --> 00:06:58.149 core first. a minimum viable product, or an MVP. 00:06:58.550 --> 00:07:01.389 You get it into the user's hands as fast as possible. 00:07:01.509 --> 00:07:03.889 You get it to them fast. Knowing that their feedback 00:07:03.889 --> 00:07:06.009 is not an annoyance, it's a critical part of 00:07:06.009 --> 00:07:08.569 the design process. You force them to interact 00:07:08.569 --> 00:07:10.910 with it, and that's when you get the real requirements. 00:07:11.209 --> 00:07:12.990 So you're basically budgeting for that feedback 00:07:12.990 --> 00:07:15.569 loop. Instead of one big launch six months down 00:07:15.569 --> 00:07:19.459 the line, you do these smaller cycles. Yes. You 00:07:19.459 --> 00:07:22.120 use that inevitable feedback to correct your 00:07:22.120 --> 00:07:24.680 course early before you've spent the whole budget 00:07:24.680 --> 00:07:26.819 building the wrong ship. The coordinator in the 00:07:26.819 --> 00:07:29.699 story, he treated the initial request like a 00:07:29.699 --> 00:07:32.439 sacred text, unchangeable. A functional partner 00:07:32.439 --> 00:07:35.680 treats that initial request like a first draft. 00:07:36.480 --> 00:07:39.000 Their commitment is to the real world outcome, 00:07:39.779 --> 00:07:42.839 the school's ability to teach better. not the 00:07:42.839 --> 00:07:45.040 abstract document. That takes a lot of courage 00:07:45.040 --> 00:07:47.980 though to pause a project to push back and say 00:07:47.980 --> 00:07:50.600 this plan is wrong especially when stakeholders 00:07:50.600 --> 00:07:52.560 are just looking at a deadline on a calendar. 00:07:52.860 --> 00:07:55.800 It takes courage but it's justified by the cost 00:07:55.800 --> 00:07:58.300 of the alternative. Remember that dual waste 00:07:58.300 --> 00:08:01.410 the money and the time. It is always, always 00:08:01.410 --> 00:08:04.250 cheaper to fix the plan early than it is to deploy 00:08:04.250 --> 00:08:06.269 a useless system. It really reframes the whole 00:08:06.269 --> 00:08:08.569 idea of success. Your job isn't just to build 00:08:08.569 --> 00:08:10.730 the budget on time and on budget. It's to make 00:08:10.730 --> 00:08:12.550 sure that people are actually driving across 00:08:12.550 --> 00:08:14.290 it to get where they need to go. You're judged 00:08:14.290 --> 00:08:16.629 on the outcome, not just the output. That is 00:08:16.629 --> 00:08:19.110 the whole deep dive right there. The problem 00:08:19.110 --> 00:08:21.689 is always the tech leader's problem, if the result 00:08:21.689 --> 00:08:25.149 is waste. It requires you to own the utility 00:08:25.149 --> 00:08:27.410 of what you build. So for you, the listener, 00:08:27.529 --> 00:08:30.040 the big takeaway here is that Leadership in these 00:08:30.040 --> 00:08:33.080 environments has to be iterative. That rigid 00:08:33.080 --> 00:08:35.759 stance from the coordinator, the not my problem 00:08:35.759 --> 00:08:38.720 line. It's not professionalism. No, it's a failure 00:08:38.720 --> 00:08:41.799 to adapt to the basic truth that requirements 00:08:41.799 --> 00:08:44.980 always change once a real human touches the product. 00:08:45.379 --> 00:08:48.159 Your job is to manage that change, not resist 00:08:48.159 --> 00:08:50.240 it. Which leads to a final thought for you to 00:08:50.240 --> 00:08:53.980 chew on. If we accept that utilization is the 00:08:53.980 --> 00:08:56.980 real measure of success, and we know that initial 00:08:56.980 --> 00:09:00.100 plans are almost always flawed in some way, then 00:09:00.100 --> 00:09:02.720 how much of that initial listening phase should 00:09:02.720 --> 00:09:04.820 actually be dedicated to anticipating failure? 00:09:04.899 --> 00:09:06.879 What do you mean by that? I mean, instead of 00:09:06.879 --> 00:09:09.320 just gathering requirements, what if we dedicated 00:09:09.320 --> 00:09:12.179 time and resources to actively predicting what 00:09:12.179 --> 00:09:14.600 users will realize they don't want only after 00:09:14.600 --> 00:09:16.980 they see the first version? So using the initial 00:09:16.980 --> 00:09:19.500 plan as a tool to provoke that feedback, to find 00:09:19.500 --> 00:09:22.600 the errors early? Exactly. How can you design 00:09:22.600 --> 00:09:25.919 your process to find the flaw in the plan before 00:09:25.919 --> 00:09:28.159 you spend the entire budget building that flaw? 00:09:28.740 --> 00:09:31.879 That concept of essential anticipatory listening, 00:09:31.879 --> 00:09:34.019 it applies to way more than just tech projects. 00:09:34.240 --> 00:09:36.039 A great framework for rethinking how we start 00:09:36.039 --> 00:09:38.299 things. Thank you for joining us for this DTIVE. 00:09:38.399 --> 00:09:39.039 We'll see you next time.