Welcome back to The Deep Dive. Today we are jumping
straight into something that really dictates
success or failure in just about any tech project.
We're talking about the gap between technical
success and functional success. That critical
difference between building something right and
building the right thing. And it's a distinction
that sounds so simple. but it is the invisible
killer of budgets, of projects, of morale. Right.
You can check off every single requirement, you
can hit every deadline, and still deliver something
that is, for all intents and purposes, useless.
And the source we're looking at today just lays
this out so clearly. It's an excerpt called,
A Story About Technology Leaders in School. It's
by Gary Ackerman, posted on a site called hackscience
.education. And while the setting is a school,
I mean, this lesson is completely universal.
Absolutely. So our mission today is to really
unpack this mindset, this defensive compliance
-driven thinking that leads to failure. And then
we need to identify the leadership skills you
need to avoid it. So let's dig in. Ackerman starts
with a story about a technology coordinator he
was coaching. Right. And this coordinator, by
all accounts, was technically brilliant. He could
implement anything you put in front of him. But
he had this kind of armor, a defense mechanism
for when things didn't go according to the original
plan. Exactly. So the scenario is he's just finished
a huge tech deployment, devices, software, the
whole system. And he built it based on what the
educators, the users had asked for. He followed
the spec sheet to the letter. To the letter.
But then the moment of crisis comes, the educators
actually get the system in their hands. They
start using it. And they realize, oh, wait a
minute. This doesn't actually fit our workflow.
This isn't helping us day to day. They immediately
start asking for modifications, for changes.
And this is where we get the quote, the line
that just sums up this entire problem. What does
he say? He just says flat out, I built what they
asked for. If they asked for the wrong thing,
that is not my problem. Wow. That is not my problem.
And you know, it's fascinating because on a surface
level, that sounds almost professional. It sounds
like I'm disciplined. I followed the requirements.
It is the ultimate expression of a transactional
mindset. You gave me a task. I completed the
task. The utility, what happens next, that's
on you. He's prioritizing compliance over the
actual function. Precisely. And in a vacuum,
you could maybe defend that. But he's not in
a vacuum. He's in a school. a living, breathing
environment where people are learning and adapting.
The users, the teachers, they don't know exactly
what they need until they can touch it and feel
it. That's when they realize, you know, this
report should be one click, not five. Exactly.
They are refining their own understanding of
the need through experience. And when the coordinator
just shuts that down with, not my problem...
He's not just refusing to do more work. No, he's
fundamentally misunderstanding his role. And
this is where the coach... Ackerman steps in
and insists, no, this is your problem. And that's
the pivot point, isn't it? That refusal to own
the outcome leads directly to just catastrophic
costs. Yeah, let's talk about the math here,
because it's grim. When the IT team takes this
stance, the source points out this huge dual
waste of investment. OK, so the first one is
the obvious one, the money. Right. The cash,
the school district spent on the devices, the
software licenses, all of it. If that system
just sits there, unused. That investment's value
goes to zero instantly. It's just a massive budget
hole. But the second cost is almost worse. It's
the opportunity cost. It's the waste of time.
And we're not just talking about the hours the
IT team spent building it. No, not at all. It's
that they spent all those hours, all that brain
power building the wrong thing. All of that time,
the planning, the development, the testing. It
could have been spent solving a real problem
for the school. Instead, it was spent producing
a technical artifact that was functionally flawed.
And think about the ripple effects of that not
-my -problem attitude. Well, the system just
sits there. It's underutilized or maybe not utilized
at all. So A, the problem the school wanted to
solve still exists. B, a year of expensive professional
effort is down the drain. And C, the credibility
of the entire IT department is shot. And this
brings us to what I think is the core aha moment
for anyone listening. Delivering a technically
perfect system that no one uses is actually worse
than delivering nothing at all. It's so much
worse. Because if you deliver nothing, at least
you still have the budget. You still have the
time. You can start over and do it right. Exactly.
The tech leader's job is to deliver utility,
to deliver a solution. If the teachers can't
teach better, if the staff can't work more efficiently,
then the project failed. It doesn't matter how
clean the code is. The metric for success has
to be utilization, not installation. Yes, that
is the entire mindset shift. OK, so if that's
the problem, how do we fix it? What are the skills
that Gary Ackerman points to that move someone
from being that technical order -taker to a real
functional partner? He synthesizes it down to
two key skills. And they really redefine what
the final product even means. All right, what's
skill number one? Careful listening. And this
sounds so simple, right? Deceptively simple.
Everyone thinks they're a good listener. Of course.
But what Ackerman means by careful here is listening
beyond the literal words. It's about being a
translator. So if a teacher says, I need a report
that tracks daily attendance, the careful listener
doesn't just go and build the report. No. They
stop. They ask. Why do you need that report?
What decision will you make with that data? What's
the real job you're trying to get done here?
You're trying to get to the root need, not just
the technical request. Yes. The initial request
is just the user's best guess at a solution.
The tech leader's job is to uncover the actual
problem, that attendance report. Maybe the real
need is to identify at -risk students earlier.
And if you understand that... you might propose
a totally different solution, like an automated
alert system instead of a static manual report.
Which is a much better functional solution. It
actually solves the underlying problem, not just
the surface level request. But here's the challenge,
right? The thing that I think a lot of technical
people fear, scope creep. If you start asking
all these why questions, aren't you just inviting
the user to keep adding more and more to the
project? How do you protect your resources? And
that leads us perfectly into the second essential
skill, commitment. to the final product. OK,
what does that mean in practice? It doesn't mean
an infinite budget. No, it means you marry that
careful listening to a development process that
expects change. Your commitment is to the operational
goal, not to the original piece of paper you
both signed. So if the specs from six months
ago are clearly wrong now, how does a leader
handle that? Well, the commitment shows up through
iterative development. You build a small functional
core first. a minimum viable product, or an MVP.
You get it into the user's hands as fast as possible.
You get it to them fast. Knowing that their feedback
is not an annoyance, it's a critical part of
the design process. You force them to interact
with it, and that's when you get the real requirements.
So you're basically budgeting for that feedback
loop. Instead of one big launch six months down
the line, you do these smaller cycles. Yes. You
use that inevitable feedback to correct your
course early before you've spent the whole budget
building the wrong ship. The coordinator in the
story, he treated the initial request like a
sacred text, unchangeable. A functional partner
treats that initial request like a first draft.
Their commitment is to the real world outcome,
the school's ability to teach better. not the
abstract document. That takes a lot of courage
though to pause a project to push back and say
this plan is wrong especially when stakeholders
are just looking at a deadline on a calendar.
It takes courage but it's justified by the cost
of the alternative. Remember that dual waste
the money and the time. It is always, always
cheaper to fix the plan early than it is to deploy
a useless system. It really reframes the whole
idea of success. Your job isn't just to build
the budget on time and on budget. It's to make
sure that people are actually driving across
it to get where they need to go. You're judged
on the outcome, not just the output. That is
the whole deep dive right there. The problem
is always the tech leader's problem, if the result
is waste. It requires you to own the utility
of what you build. So for you, the listener,
the big takeaway here is that Leadership in these
environments has to be iterative. That rigid
stance from the coordinator, the not my problem
line. It's not professionalism. No, it's a failure
to adapt to the basic truth that requirements
always change once a real human touches the product.
Your job is to manage that change, not resist
it. Which leads to a final thought for you to
chew on. If we accept that utilization is the
real measure of success, and we know that initial
plans are almost always flawed in some way, then
how much of that initial listening phase should
actually be dedicated to anticipating failure?
What do you mean by that? I mean, instead of
just gathering requirements, what if we dedicated
time and resources to actively predicting what
users will realize they don't want only after
they see the first version? So using the initial
plan as a tool to provoke that feedback, to find
the errors early? Exactly. How can you design
your process to find the flaw in the plan before
you spend the entire budget building that flaw?
That concept of essential anticipatory listening,
it applies to way more than just tech projects.
A great framework for rethinking how we start
things. Thank you for joining us for this DTIVE.
We'll see you next time.