Nobody hands technical people a time management curriculum. You either got formal training somewhere, had a good mentor, or learned it the hard way when your job was on the line. Nothing teaches time management like the fear of unemployment.
A disclaimer up front: I’m not a time management guru and I haven’t written a book on the subject. There are excellent ones out there and I’d encourage you to read them. But this article is an application of the Pareto Principle to time management itself. Put in twenty percent of the effort and you’ll capture eighty percent of the value. Get these basics right first. They pay major dividends.
The problem is worst for your best people
I know this struggle personally. I’m hyper-focused by nature. When I lock onto something, time melts away and I get incredible things done.
As an engineer, I got away with it by working eighty-hour weeks. Running my own business, that same hyper-focus became a liability. I had to learn to ship an eighty percent solution to keep a customer moving and circle back later for the permanent fix. That does not come naturally to people wired the way I am. It’s also the Pareto Principle in action.
Here’s the part managers miss: this hits the ambitious people hardest, not the ones coasting. Once you move past desktop support into infrastructure, engineering, and security, time management stops being optional. It becomes the difference between a career that grows and one that stalls, and the difference between job satisfaction and quietly becoming disgruntled, unappreciated, and checked out.
First: take time to manage time
Most technicians believe an open schedule is best so they can fit things in as time allows. That’s backwards. Work expands to fill whatever time you give it.
You need boundaries. Budget a set period for a task and work within it. I know how painful that is for a hyper-focuser, breaking concentration feels almost physically wrong, but unless your entire job is hyper-focusing on one thing forever, failing to budget your time will stunt your growth. You may be performing well. Your employer won’t see it that way.
In practice, this means scoping projects fully. If someone asks you to build a server cluster, write out every task: procurement, configuration, installation, patching, networking, all of it. Estimate each piece and work within the estimate.
You’ll get remarkably good at this over time, and accurate estimation is a genuinely valuable skill. If you bill for projects, it’s the difference between pricing with confidence and guessing.
Second: you only have so many hours
Don’t schedule yourself edge to edge. It will break you no matter how capable you are.
Structure work into large blocks for complex tasks, or smaller blocks that flow naturally across days. Always leave gap time for admin work, interruptions, and reopened tickets. If the gap goes unused, pull project work forward into it. But when something urgent lands, you need room to absorb it.
We track this internally as project hours per week. If an engineer can realistically deliver thirty hours of project work in a week and a project is budgeted at one hundred twenty hours, that’s four weeks. Once you know that number, you can forecast workload instead of guessing at it.
Everything you plan to do belongs on your calendar, every task inside a project, not just the project itself. And yes, sometimes that means staying late to hit a commitment. That’s an uncomfortable truth for salaried technical staff, but it’s the truth.
Third: managers have to hold up their end
This one is for managers as much as technicians. Your employer has to actually value scoped, scheduled work rather than handing out a deadline and walking away.
Think of a toddler near a ledge. You don’t just hope they don’t fall, you put up guardrails. Deadlines work the same way. Hand someone a due date with no scoped hours and no checkpoints and you haven’t set a goal, you’ve set a trap.
If you didn’t scope the project and put the work on the calendar, a missed deadline is on you, not the technician. I’ve lost my temper in meetings over blown deadlines, and I wasn’t proud of it. The real failure was mine for never setting the guardrails.
That cuts both ways. Once the guardrails exist, a technician who sees they’re falling behind and stays silent until it’s a crisis owns that outcome. Which is why you need a regular checkpoint; a weekly meeting where at-risk work gets flagged while there’s still time to act.
Track activity and results together
To know whether any of this is working, you have to watch two things at once.
Results alone tell you what’s finished but not whether trouble is brewing. Activity alone tells you people are busy but not whether the busy work matters. Together, they tell you honestly whether a project is on track, early enough that you can still do something about it.
The takeaway
It comes down to budgeting time honestly, setting clear expectations, and keeping both sides aligned before things go sideways rather than after.
It’s a rare skill in this industry. Master it early and you’ll spend the rest of your career teaching everyone else how to do it.
Brian Largent
Father to five, husband to one, founder, CEO, and all around swell fella (or so I'm told)
