Welcome back to the deep dive. Okay, today we're
tackling something that maybe sounds a bit technical,
but honestly, it's crucial for schools. We're
talking IT, network planning and installation,
you know, the whole digital foundation, hardware,
software, all the connections that, well, Make
modern education work. Think of it like the school's
nervous system, really. And for this deep dive,
we're digging into a really insightful article
by Gary Ackerman over at hackscience .education.
It's called hashtag edtech for hashtag ed leaders,
network planning and installation. So our mission
today is basically to pull out the key takeaways,
maybe some surprising bits from this specialized
field. We want to give you, especially if you're
a school leader, a kind of shortcut to understanding
what you really need to grasp about your IT infrastructure.
It's funny how these tech topics, they often
shine a light on universal things like planning,
resources. Yeah. Absolutely. And, you know, this
isn't just about the tech specs, the cables,
and the Wi -Fi signals. It's really about getting
a handle on the practical side of things, the
decisions that need making, and how getting this
right, well, it affects everything else, day
-to -day stuff, budgets, you name it, will break
down, like, who does what, why you need certain
experts, and maybe what leaders should really
keep their eye on. OK, so let's unpack this.
The article kicks off... with a really smart
analogy. It compares a school's IT system to
a car. I thought that was brilliant, actually.
It frames the different levels of expertise needed,
building it versus just using it. It really is
a great comparison. So the idea is the know -how
needed to, say, design and build the network,
like designing and building a car, it's incredibly
specialized. and expensive. You're talking engineers,
designers, people with deep training using, you
know, often very costly specialized tools. But,
and here's the key distinction, right? Once that
system, the network or the car, is actually built,
you don't need that same level of super specialized
design expertise for the day to day. Instead,
you've got technicians who definitely need skills,
mind you, to keep it running. And then you have
the users who just need to know the basics to
operate it. So it's that split, the high -end
creation versus the ongoing management and use.
Right. And given that really specialized, probably
expensive design phase you mentioned, it totally
makes sense why the article says schools almost
always contract out for network engineers, especially
for new networks or like major upgrades. But
I could see some school leaders maybe hesitating
at that cost. Does the article get into why that
expense is actually worthwhile, why it's a good
investment. Oh, definitely. It points out that
these network engineers, they often work for
companies that don't just design, but also sell,
install, and then service the equipment. So schools
often end up in these extended contractual relationships,
as the article puts it, for service and repairs.
And yes, these services cost money, no denying
that. But leaders tend to see the value because,
well, two big reasons. First, the cost of the
network devices themselves is significant. You
want them installed right. And second, maybe
even more important are the potential liabilities
of insecure networks. Trying to save money upfront
by skimping on expert design or installation,
that can lead to way bigger costs, later security
breaches, system failures, you name it. It's
about function and security. Okay, thinking about
the actual installation, putting in a whole new
network or upgrading one, it just sounds like
a massive disruption waiting to happen in a busy
school. The article mentions they're labor intensive
and can cause network outages with technicians
needing access, you know, throughout the building.
How do schools possibly manage that without grinding
everything to a halt? Well, the approach described
is pretty straightforward, actually. Schedule
the heavy lifting when the school is mostly empty.
So think summer break, holidays, maybe even weekends
sometimes. Times when it's largely empty of students.
That way you minimize the hit to actual teaching
and learning time. It's just smart project management
really. Plus the article notes that the vendors
doing these installations usually have quite
a few technicians available. They have large
numbers of technicians, meaning projects that
need, say, hundreds of hours of labor can get
done relatively quickly because you have many
people working simultaneously. Many hands make
light work, essentially. Right. So you compress
the timeline by throwing more people at it during
off hours. Makes sense. OK. OK. So we've got
the design and installation sorted, often by
external experts. But then there's the day -to
-day running of it. The article clarifies the
different roles here, doesn't it, once the network's
actually in place? Who handles what? Yeah, it
draws some clear lines. It says, engineers, design,
and technicians build IT networks. Pretty straightforward.
Then, system administrators operate and manage
the networks once they are installed. They're
the day -to -day folks. Now, if there's a really
serious problem, something tricky, that gets
escalated back to the engineers, right? They
have that deeper system knowledge. But, and this
is important for schools, most functionality
can be sustained by individuals who've been properly
trained and who have adequate resources. So you
don't necessarily need an engineer on staff full
time. You need capable sysadmins with good training
and support. It's about matching the task to
the expertise level. That clarification is really
helpful. So thinking about the whole process,
planning, installing, managing, what's one key
thing the article highlights that maybe gets
overlooked but is super critical for school leaders
to know about? Ah, yes. This is a really interesting
point the article makes. And it gets into a kind
of unique feature of IT networks. It's mapping
and documenting them. It calls them very interesting
systems because of this inside versus outside
paradox it describes. So imagine you're inside
the network using special software like network
smiffing software. You can find a device's network
address, its unique ID on the network very accurately.
But from that software view, you can't easily
tell where that device physically is in the building,
like which classroom or closet. Now flip it.
If you're outside just physically looking at
a device, a switch on the wall, a printer, there's
no way to know with certainty its network address
or the purpose it serves just by looking. See
the disconnect. I never really thought about
it that way. You can see the digital location
or the physical location, but not easily both
at the same time without. Exactly. Without a
map. A good network map, as the article says,
bridges that gap. It identifies both the network
address and the physical location. And crucially,
the devices themselves should be physically labeled,
too, with info matching the map. The map should
also indicate the function of each device. What
does the switch connect? What's the server for?
Now, most network gear switches, routers, printers,
although they have these built -in web interfaces,
right? Assistant men can log in through a browser
to check status, change settings. And the article
stresses This interface is useful, it can supplement
a network map, but it does not replace network
documentation. That map is the master key. That
inside versus outside thing. It's more than just
a tech detail. It really tells you something
important. Real control comes from knowing both
the physical and digital reality. And for leaders,
the takeaway is huge. True control over your
IT infrastructure hinges on documentation, not
just deployment. That's how you manage it effectively,
plan for the future, budget accurately. It's
about owning it, not just having it. That makes
perfect sense. But if it's so critical, why does
this mapping and documentation often fall by
the wayside? Is it just not enough time? That's
a big part of it, yeah. The article points out
that this crucial step is often not given the
attention that it needs, precisely because IT
professionals are typically overworked. Think
about it, they spend much time addressing technology
problems that are very pressing. The printer's
down, the internet's slow, someone can't log
in, they're constantly fighting fires. So taking
the time to meticulously map and document everything,
it often feels like a nice -to -have that gets
pushed back. It's like organizing the basement
when the kitchen's on fire. But the article warns
that this focus on the urgent, this seemingly
necessary approach, well... It can lead to greater
difficulties later. It builds up technical debt.
What kind of difficulties are we talking about?
Well, think about scenarios like outside agencies
need to access the network. Maybe your main IT
person is sick or on vacation or, heaven forbid,
leaves suddenly. Or just think about planning
ahead. When the school seeks to document network
resources and budget for network replacement,
All right? If you don't have that map, if you
don't know what's plugged in where, what its
network address is, what it does, figuring all
that out from scratch is a massive time -consuming
job. The article really hits this point hard.
A good network map can save many hours of work.
Work that, if you have to hire external consultants
to figure it out later, is billed at a far greater
rate than is earned by an IT professional employed
by the school. So that upfront effort in documentation,
it pays for itself probably many times over by
avoiding those future frantic searches and expensive
rediscoveries. Wow. OK. That really drives home
the value of documentation. So recapping the
big picture here. We've seen the specialized
nature of network design why bringing in those
external experts for the big builds or upgrades
makes sense strategically the importance of smart
scheduling to minimize disruption during installation
and this really Crucial but often neglected need
for thorough mapping and documentation. It's
not just about flicking the switch to on is it?
Not at all. It's about knowing exactly what you
turned on, where it is, and how it fits together
so you can manage it effectively over its entire
life cycle. And this whole discussion raises
a broader point, doesn't it? It's relevant beyond
just school IT. How investing properly up front
in planning, in documentation, in understanding
your foundational systems, how that prevents
huge headaches and costs down the road. It's
really about enabling things to run smoothly
and efficiently long term. Flying blind without
that map, well, it's just inefficient and asking
for trouble. whatever the system is. That's a
great point. And it leads perfectly into our
final thought for you, our listeners. Think about
the unseen infrastructure in your own life, professionally
or personally. What are those critical foundational
systems that support what you do every day? And
crucially, How well are they understood? How
well are they documented? Even if just in your
own head or notes, it could be anything. Your
work project management flow, your home finances,
maybe even just how you organize your digital
files. Are you working with a clear map or are
you kind of feeling your way in the dark? It's
often the things we take for granted that cause
the biggest issues when they aren't managed well.
And if you do want to explore these ideas further
in the context of schools, remember Gary Ackerman,
the author we discussed, he's written several
books on education technology, like Technology
in Schools, isn't like this in business, Efficacious
Technology Management, A Guide for School Leaders
and Technology -Rich Teaching. Lots more to dig
into there.