The Hardest Thing About Work Isn't the Work

Early in my career, a mentor gave me a simple system for success:

Tell people what you're going to do, do it, then tell people you did it.

I remember that lesson clearly because it was practical. No theory. No fluff. Just a simple way to build trust and momentum.

At the time, I thought it was a communication tip. Over time, I realized it was the start of something much bigger.

I started out as an engineer

When I was an engineer, I thought my job was to produce more code.

That was the whole model in my head. Ship more features. Close more tickets. Fix more bugs. Build more stuff. If I just wrote enough good code fast enough, everything else — the recognition, the trust, the next opportunity — would take care of itself. The work was the output, and the output was the code.

And there's nothing wrong with that instinct. Execution matters. Craft matters. Being able to produce high-quality work, consistently, is table stakes — it always will be.

But it took me an embarrassingly long time to notice that the engineers who got ahead weren't always the ones writing the most or the best code. They were the ones you knew what to expect from. They wrote things down. They surfaced risks early. They explained the tradeoffs. They kept track of decisions. Their work didn't disappear into a black box you had to go spelunking in — you could see it coming, count on it, and build around it.

They made everyone else's job easier. And that, it turned out, was the job.

The altitude kept changing, the lesson didn't

Then I became a consultant, and the lesson got clearer.

The work still mattered, but clients almost never judged us on the output alone. They judged whether we actually understood the problem. Whether we kept them informed. Whether we could turn ambiguity into a plan and bring a room full of stakeholders along with us. That was when it clicked that communication isn't a soft skill sitting next to the work. It is the work.

Then I was leading teams — eventually across different functions, locations, and time zones. And the question changed shape again. It was no longer whether I could produce good work. It was whether a group of people could move together without constantly losing context.

That meant priorities had to be clear. Decisions had to be written down. Status had to be legible — what mattered, what changed, what was blocked, what came next. Project management stopped being a layer of process on top of the work. It became the way the work became real.

Then founder, and now CEO — first JupiterOne, now Ariso. The altitude changed one more time. At this level almost none of my day is "the work" the way engineer-me would have defined it; there's no ticket queue. It's setting direction. Communicating goals and priorities until they actually stick. Getting alignment across people who don't report to each other. Tracking progress, validating the assumptions we bet on, and pivoting fast when they turn out to be wrong — where failing fast isn't an excuse for sloppiness, but a discipline for learning.

(You can see the full arc on my LinkedIn — engineer, consultant, security and infrastructure, founder.) Every step of it, the same truth got a little louder:

The hardest thing about work is not the work.

The work around the work

There is the work itself, of course. But there is also the work around the work. That's the biggest lesson I've learned throughout my career. It's the part that empowered my growth — and the part almost everyone underestimates.

Here's the tell. Almost never is it the strongest engineer, or the one who works the hardest, who gets promoted. It's the person who has mastered the tracking and the reporting, the communication and alignment, the follow-through, the measurement and improvement.

That's not politics, and it's not "playing the game." It's the job getting bigger than the artifact you produce. The higher you go, the more of your impact comes from the work around the work — and the less of it comes from the work itself.

I've started thinking about that system as TRAM:

• Track what's happening. Write lots and lots of notes. Journal what happened every day, and use it to always be prepared.
• Report so the right people know what happened, what changed, and what needs attention — and not just your manager. Your team, your peers, your cross-functional partners.
• Align people and priorities by getting everyone on the same page, whether it's between you and your manager, your peers, your reports, or colleagues across a different function.
• Measure whether it worked through honest self-reflection, and turn that into a loop of continuous improvement.

That's the loop. Track, report, align, measure — and around again.

Better management. Better decisions. Better outcomes.

What this looks like on a Tuesday

If this sounds abstract, it isn't. It's the least glamorous part of your calendar.

If you're an individual contributor or a manager, the work around the work is: managing your tasks and todos, and prioritizing them when everything feels urgent. Taking notes so the important thing doesn't evaporate the moment the meeting ends. Running the project. Writing the status update nobody explicitly asked for but everybody needed. Keeping your teammates in the loop before they have to wonder where things stand.

If you're an executive, it scales up — but it's the exact same shape. Setting strategic direction. Communicating goals and priorities clearly enough that they survive contact with reality. Getting alignment across functions that each have their own gravity. Tracking progress against the plan. Validating the assumptions you bet the quarter on. And being willing to pivot — to fail fast — the moment the evidence says you were wrong.

None of that is "the work." All of it is what makes the work, work.

When I look back honestly, almost everything that helped me grow — from engineer to consultant to manager to founder to CEO — wasn't the work itself. It was the other stuff: the tracking, the reporting, the aligning, the measuring, the reflecting, the improving.

Why this is so hard — and where AI comes in

Here's the cruel part. The work around the work is the work we're worst at, precisely because it's invisible and it competes with the "real" work for the same hours.

Nobody feels productive writing a status update. Nobody gets a hit of dopamine from journaling what happened today or double-checking that a decision actually reached the three people it affects. So it slips. The notes don't get written. The update goes out late, or not at all. Alignment quietly decays. The plan and reality drift a few more degrees apart. And then one day you're re-having a conversation you already had, wondering why everything feels busy but nothing feels like it's moving.

This is the part I think AI can actually change — and not by writing more code or generating more content. By carrying the load of the work around the work.

Tracking what happened without you having to hand-journal it. Turning that into a report the right people see, automatically. Surfacing the places where you and your team have quietly drifted out of alignment. Closing the loop so you can measure whether it actually worked, and get better next time.

Track. Report. Align. Measure — carried for you, so you have the attention left over for the judgment only you can bring.

That's the real promise of AI in the workplace, if we get it right. Not doing the work for us. Doing the work around the work — so the work can finally work.

That's the whole reason we're building Ari.

---

Want to run this loop yourself? I wrote it up two ways: a field guide to run it today as a folder of markdown in Claude Code, and a full product spec if you'd rather build the whole app. And if you'd rather not maintain any of it — that's exactly what we built Ari to do, and it's free to start.