Short notes from the route.

Jul 6, 2026

How I’d approach a helpdesk-to-manager jump today

The jump usually isn’t blocked by skill — it’s blocked by visibility. The technical gap between the people who get promoted off the helpdesk and the people who don’t is small. What separates them is who raises a hand for the messy, cross-team problem nobody owns: the printer VLAN, the onboarding process three departments quietly hate, the queue that backs up every Monday. It’s the only way a manager sees you operate on something bigger than your ticket count.

Fixing the problem isn’t the whole job — writing it down is. A two-paragraph recap (what broke, what you tried, what worked, what you’d change) sent where your manager’s manager might see it does more for your case than the fix itself.

And before you have the title, manage your own work like someone already trusts you with other people’s. None of it guarantees a timeline — but it’s the difference between “not yet” and “not sure they’re ready,” and those are very different conversations to be having about you.

Jun 1, 2026

The one skill that got me from network engineer to program manager

It wasn’t a certification. It was learning to write a status update an executive could read in fifteen seconds and still know what was actually at risk. Technical people write updates the way they debug — details first, then context, then the conclusion. That’s exactly backward for the audience deciding whether you get pulled into program management. Bury the risk in paragraph three and you may as well not have mentioned it.

The habit that changed things: write every update as three lines first — current state, the one thing that could go wrong, what you need from the reader. If a program won’t compress into those three lines, that’s a sign you don’t understand it as well as you thought. The writing is diagnostic, not cosmetic.

If you’re technical and eyeing TPM work, this is the first thing I ask about. It’s rarely your technical background that’s the gap.

May 4, 2026

What actually matters managing a data center team for the first time

Resist the urge to change anything in week one. New managers arrive with a list — the naming convention, the stale runbooks, the on-call rotation. All of it might be true. None of it should be touched until you’ve asked the two or three people who already know where the real problems are what they’d fix first.

Spend the early weeks in a listening posture: sit in on incident calls without running them, ask why the deployment has that extra manual step (there’s a scar-tissue reason, not a laziness reason), learn who the informal escalation path actually runs through.

When you do make a change, it should feel almost anticlimactic — the thing they told you was broken, fixed the way they believed it should be, with public credit to whoever flagged it. That converts “the new manager” into “our manager” faster than any all-hands speech.

Jan 5, 2026

What I wish I knew before starting my own company

Technical skill gets you your first customer. It has almost nothing to do with getting your fiftieth. I ran a digital-forensics and data-recovery firm for six years — profitable in year one — and an honest accounting of my hours shows more invoicing, scheduling, collections and marketing than forensic work. The craft is why you start the company; operations is why it survives.

The customers who got us to fifty weren’t won on better technical work. They were won by same-day callbacks, clear quotes, met deadlines, and findings explained in language a lawyer could actually use. In a specialized field, clients can’t judge your technical quality — they judge whether you behave like a professional operation, so that’s what they buy.

The question isn’t “am I good enough at the work?” If you’re seriously considering the jump, you probably are. It’s whether you’ll still like the business when the work is a third of your week — and running the machine around it is the rest.