The skill that transfers isn't the manual, it's the mindset
People assume the hard part of moving from a trade into IT is the technical knowledge, the protocols, the command line, the acronyms. It isn't. That stuff is learnable, and frankly a lot of it is simpler than wiring a board to code. The part that doesn't come from a textbook, the part you either learned on a job site or you didn't, is the discipline of finishing. On the tools, a job isn't done when it more-or-less works. It's done when it's tidy, it's labelled, it'll pass an inspection, and the person who paid for it is happy. Nobody hands you a participation trophy for "mostly".
Carry that into IT and it changes everything about how you work. A network you've built to a trade standard is labelled, documented and laid out so the next person, or you in two years, can understand it at a glance. A server rack done properly is the same: cabled clean, sized for the room, nothing hanging by a thread. That's not vanity. It's the difference between a three-minute fix at 2am and a two-hour archaeology dig because nobody could be bothered writing on a cable.
Outcomes over jargon
On a trade, nobody asks what brand of saw you used. They ask if the thing works and whether you left the site clean. The work speaks; the patter doesn't. IT has the opposite problem, it's drowning in patter. There's a whole industry habit of using jargon as a shield: bamboozle the customer, make the simple sound complicated, and the invoice writes itself. I came up the other way, where the only thing that counted was the result, so I've got no patience for it.
What that means for you, if you ever hire me or read anything I write: I'll tell you in plain English what's actually wrong, what I'd do about it, and what it costs. Then I'll do that thing and show you it's fixed. If I can't explain a problem without hiding behind acronyms, I don't understand it well enough yet, and I'll say so rather than dress it up. The measure of the job is whether your problem is gone, not how impressive the explanation sounded. That's a builder's standard applied to a field that badly needs more of it.
No double-handling, ever
If there's one phrase from the tools that I've dragged into everything I do, it's this: no double-handling. On a job, double-handling is when you touch the same load twice, lift it, set it down in the wrong spot, then lift it again. It's wasted effort, it's how you hurt your back, and it's the fastest way to lose money and the customer's respect. The good operators design it out. They lift it, place it, and get it done.
IT is riddled with double-handling, the industry just doesn't call it that. The patch that fixes one thing and breaks another. The "fix" that gets reopened a week later because it treated the symptom, not the cause. The migration that has to be half-redone because nobody scoped it properly the first time. Every one of those is a load picked up twice. The builder's instinct is to kill it: understand the real problem before you touch anything, plan the change, do it once, do it right, and walk away. It costs less, it's faster in the end, and it's how you earn the kind of trust where a client stops getting quotes from anyone else.
Sequencing: you can't render before the wiring's in
Here's a bit of trade logic that took me straight into systems thinking without me noticing. On a build, order is everything. You can't render a wall before the wiring and the plumbing are in, or you'll be smashing it open next week. You can't lay the floor before the messy work above it is done. Get the sequence wrong and you create rework for yourself and everyone after you. So you learn, fast, to think a whole job through before you start, to see how each step boxes in or frees up the next one.
That is, almost exactly, how you think about infrastructure. You don't bolt security on at the end, the same way you don't run power after the plaster's up. You don't migrate the data before you've proven the new system holds. You don't automate a process you haven't first understood and fixed. The dependency graph of a decent IT project and the sequence of a build site are the same shape: do the foundational, hard-to-change things first, in the right order, and the rest goes in clean. Most IT disasters I've been called in to untangle weren't a lack of skill. They were a job done out of order.
Why I'd rather own the thing I'm responsible for
The deepest thing the tools left me with is a discomfort with hand-waving. If my name's on the work, I want my hands on it, I want to understand it to the bones, and I want to be the one accountable when it runs at 3am. That's not control for its own sake. It's the only way I know to actually stand behind something.
It's also why I made a choice a lot of people in this field find strange: I run my own data centre instead of renting a slice of someone else's and hoping their SLA holds. If I'm going to be responsible for the systems a business depends on, I want to own the floor they run on, not cross my fingers behind a logo. That's the same instinct as wanting to see the wiring before you sign off the wall. I've written about why I run my own data centre instead of renting the cloud and the broader case for owning your stack rather than renting your dependence if you want the long version, because it's the same builder logic playing out at a bigger scale.
What "low budget" and the tools have in common
A trade also teaches you the value of a dollar and a minute, because on a job you're spending both out of your own pocket. You don't over-engineer to look clever, and you don't cheap out where it'll cost you later, you make the right call for the actual situation. That same discipline is what separates good engineering from showing off, and it's something I've leaned on hard running a business on a tight budget, the same instinct behind building to the actual need instead of selling the biggest box. Constraint isn't the enemy of quality. It's what forces you to decide what actually matters.
The Australian angle: we still respect someone who can do the job
There's a cultural fit here too. Australia still has genuine respect for someone who can actually do the thing, the operator who turns up, sorts it, and doesn't carry on, and we can smell wankery from across the carpark. A trade background lands well here because it signals exactly that: less talk, more done. Small businesses and people in the regions, especially, would far rather deal with someone who'll get on a plane and fix it than a slick city outfit that talks big and routes them to a ticket queue. The trade ethos and the Australian small-business expectation are the same thing in different clothes: be straight, be useful, finish the job.
What "enough" actually looks like
Bringing a trade background into IT isn't about pretending the technical side doesn't matter, it absolutely does, and I've put eighteen years into it. It's about which standard you hold the work to. Done right, it looks like this: the problem understood before anything's touched, the change planned and sequenced, the job done once and left clean, documented so the next person isn't cursing your name, and someone real standing behind it. No jargon to hide behind, no double-handling, no black box. Just the thing, working, the way it should. That's the whole ethos, and it started on the tools long before it reached the rack. If you want the longer version of how I got here, it's all in my story and the principles I run on.
FAQ
Is a trade background in IT a disadvantage?
No, it's an edge. A trade teaches you to plan a job, sequence it, get it right the first time and stand behind the result, because if you don't, you're back on site fixing it for free. That habit maps straight onto good IT: design the change, do it once, document it, own the outcome. The certificates and the theory you can pick up. The standard of finish you learn on the tools, and most people in IT never get taught it at all.
What does a trade actually teach you that helps in IT?
Three things that matter more than any cert. First, sequencing: you can't render before the wiring's in, so you learn to do things in the right order and not create rework. Second, finish: a job isn't done until it's tidy, labelled and the customer's happy, which is exactly how a server rack or a network should be left. Third, accountability: your name's on the work and you're the one who comes back if it fails, so you build it to last the first time.
Outcomes over jargon, what does that mean in practice?
It means the measure of the job is whether your problem is gone, not how clever the explanation sounded. On a trade, nobody cares about the brand of the tool, they care that the thing works and the site's left clean. IT should be the same: I'll tell you in plain English what's wrong, what I'd do, and what it costs, then I'll do that thing and prove it's fixed. If I can't explain it without jargon, I don't understand it well enough yet.
What is double-handling and why does it matter in IT?
Double-handling is touching the same work twice because it wasn't done properly the first time, lifting a load, putting it down, then lifting it again. On a trade it's the fastest way to lose money and respect. In IT it shows up as the patch that breaks something else, the fix that needs re-fixing, the ticket that gets reopened. The builder's instinct is to kill double-handling: plan it, do it once, do it right, walk away. That's cheaper for the client and it's how trust gets built.
Can you really go from the tools to running IT infrastructure?
You can, and the path is more natural than it looks. The skill that transfers is the mindset, not the manual: understand the system to the bones, build it so it holds, and be the person who's accountable when it runs. I'd rather understand something fully and run it myself than resell a black box and hope. That's why I operate my own data centre rather than renting space and crossing my fingers. The tools taught me to want my hands on the thing I'm responsible for.
If that's the way you'd rather be dealt with, straight answers, the job done once, and someone who actually stands behind it, that's how I work. Whether you've got a problem you're stuck on or you just want to know if I'm the right person to help, tell me what you're trying to sort out and I'll give you a straight read on it, no jargon and no upsell.