The Technician vs. The Architect

There is a tell.

When I walk into a business and want to understand how the technology was built, I do not start with the server room or the firewall or the network diagram. I look under the desks.

If I find a single cable drop at every workstation – just one cable running from the wall to the computer – I already know what I am dealing with. And somewhere in that office, probably zip-tied to a desk leg or stuffed behind a filing cabinet, there is a small unmanaged switch with five or six ports that somebody put there because they ran out of connections.

That switch is not malicious. The person who installed it was solving a real problem and they solved it. The computer works. The internet works. Job done.

Except the port on that switch is capped at 100 megabits per second. And the cable in the wall is gigabit. And the user has been running at a tenth of their available speed for two years and nobody knows why. And that little unmanaged switch is also a security gap, sitting outside the managed network, invisible to monitoring tools, accessible to anyone who walks up to the desk.

That is the difference between a Technician and an Architect. Not skill. Not effort. Not even intention. It is the question they were asking when they did the work.

The Technician Gets You Online

Let me be clear about something before we go any further: the Technician is not the problem. The Technician is essential.

The Technician is the person who shows up, gets things done, and gets you back online. They are fast, they are capable, and they are the reason most businesses are running at all. When something breaks at 8am and you have customers waiting, you do not want an Architect standing at a whiteboard drawing diagrams. You want a Technician with a cable in their hand who can fix it in twenty minutes.

The Technician asks: how do I make this work right now?

That is the right question in the right moment. The Technician is the execution layer. They are the hands that build what the plan calls for and the people who keep things running day to day.

The problem is not having a Technician. The problem is having only a Technician – and no one who was ever asking the other question.

The Architect Asks What Happens When It Breaks

The Architect is not smarter than the Technician. They are asking a different question.

What happens when this fails?

Before I ever ran cable on a project, I had a whiteboard meeting. Sometimes more than one. The whole team would gather and we would draw the entire project out – every connection, every device, every dependency. And then we would start erasing lines.

Not randomly. Deliberately. We would pick a cable, a switch, a connection, and erase it from the board. Gone. Now what? How does that failure affect the rest of the system? What breaks downstream? Is that failure acceptable or is it catastrophic? What do we need to put in place so that when this fails – and it will fail, eventually – the business keeps running?

We erased lines until we had tested every single point of failure we could imagine. And by the time we walked out of that room, every person on the team understood not just how the project was going to be built, but why every decision was made the way it was. They understood the logic. They could defend it. They could troubleshoot it. They could explain it to the client.

That is Architectural thinking. It is not about being smarter. It is about asking the question the Technician is not paid to ask and making sure the answer is built into the work before the first cable goes in the wall.

Why You Always Run Two Cables

Here is the most practical version of this distinction I can give you.

When I run cable to a workstation I always run two. Sometimes four. Not one. Never one.

Yes it costs more. Yes it takes longer. Yes the client sometimes pushes back on the budget.

And every single time I explain why.

Because the day you need that second cable – the day someone needs a dedicated connection for a VoIP phone, or a second monitor with network access, or a device you did not anticipate when the office was built – that cable is already in the wall. You do not need a service call. You do not need a switch under the desk. You do not need to explain to a frustrated user why their connection is running at a fraction of what it should be.

The Technician runs one cable because one cable solves the problem in front of them.

The Architect runs two because they have already thought about the problem that does not exist yet.

The Relationship Between the Two

Here is the thing that most people get wrong about this framework: the Technician and the Architect are not opposites. They are a team. And neither one works without the other.

An Architect without Technicians is just a whiteboard full of ideas that never gets built. The vision is useless without the execution. The plan means nothing without the people who can carry it out with precision and speed.

A Technician without an Architect is a very capable person solving the wrong problems very efficiently. They get things done. They keep things running. But nobody is asking what happens when it breaks, and nobody is building toward something that will still make sense in five years.

The Architect’s job is not to replace the Technician. It is to train them, educate them, and give them the context to do the work the right way from the start. When a Technician understands why you always run two cables – not just that you do, but why – they make better decisions on every job from that day forward. They start asking the failure question themselves. They start seeing the long-term challenges instead of just the immediate ones.

That is how you build a team that produces infrastructure that lasts.

Which One Is Running Your Technology?

Here is the question worth sitting with.

The technology in your business was built by someone. Maybe an internal employee. Maybe a managed service provider. Maybe the person who was good with computers and got handed the responsibility one afternoon and never handed it back.

Were they asking the Technician question or the Architect question when they built it?

Not because one is better than the other as people – but because the question you ask determines what you build. And what you build today determines what you are dealing with three years from now when the business has grown and the infrastructure underneath it has not.

Look under the desks. Count the cables. Check for the switch zip-tied to the desk leg.

It will tell you everything you need to know.

—

Kelly Hansen is the author of The IT Dilemma: Why Good Businesses Fail During Cyberattacks, Outages, and Technology Disasters – and How to Prevent It. Have a question about your own environment? Reach out: Contact, or connect with me on LinkedIn.