We're on the same side

If you read my job title, you'd learn what I'm responsible for. You wouldn't learn what I actually do, or why I love doing it.

What I've really been doing my whole career is looking at how teams work. Other teams, my own team, the wider IT org, and the lines between every org in the companies I've worked at. Where does the work get stuck? Where are people doing the same thing three different ways? What's slowing them down that has nothing to do with the job they were hired to do? Where are the lines of communication failing?

Then I take that friction out, so they can get to the real work.

I love making the lives of the people around me better. At work, that looks like removing bottlenecks. At home, it looks like building an app that tells me when the water filter is due. Same instinct, different address.

The work behind the work

Most teams don't struggle with the work itself. They struggle with everything around it: the hand-off nobody owns, the approval that waits on one person, the manual step everyone forgot was manual, the process that made sense three reorgs ago.

None of it is dramatic. It's a few minutes here and an hour there. But it adds up, and it's the part that wears people out. Nobody joined a team to fight the tooling, and nobody likes a process that doesn't make sense.

So when I look at a team's workflow, I'm not asking "are they doing their job?" I'm asking "what's in the way of them doing it?"

We're on the same side

Here's the part I care about most: the whole company is one team.

When one team is lagging in the way it works, it doesn't stay that team's problem. It affects everyone who depends on them, and it makes every project that needs both teams harder than it has to be. You can't work well together on a shared problem if you don't share a way of working.

That doesn't mean every team has to work identically. Each team has its own nuances, and those are often there for good reasons. But when the foundations are shared (similar processes, similar methods, and real communication between them), nobody has to reinvent the wheel, and everyone starts on a level playing field.

And when something needs attention, we lean in. We help each other. We're not competing teams that happen to share a company name on our résumés. We're on the same side.

From digging to watching

Here's one example of what that looks like in practice.

Audits like SOX used to mean digging. After the fact, someone had to work out which changes were in scope, then search through tickets, release notes and deployment history to confirm when each change happened and whether it followed the controls. Half of it meant ruling things out, based on history nobody remembered anymore.

At the time, that digging fell to me. I was the only one doing the auditing, so I knew the constraints well.

So we flipped it. Before our team onsite, I gave the team homework: the intro courses for our integration platform, MuleSoft. Then at the onsite, I challenged them to build automation that watches for in-scope changes as they happen and flags them right away. Now the digging happens while the change is fresh, and the people who made it still remember why.

The win wasn't only automating a manual task. Only one person on the team knew that platform. This took away two bottlenecks at once, me as the only auditor and them as the only MuleSoft expert, and it brought the team together to solve a real problem, learn together, and grow together.

It's the same work. It just moved from reactive to proactive, and that one shift took a painful, backward-looking job and made it part of the everyday flow.

That's the pattern I keep coming back to, in every system I touch: stop finding out after the fact.

I'm the cleaner

I've been the cleaner of a lot of orgs and systems. I love cutting out the fat.

The unused fields still being filled in by some automation that does things nobody needs anymore. The three tools that each do half of one job. The workaround that became permanent because nobody had time to fix the real thing. The pile of logic on one object that sets off circles of updates behind the scenes and slows down every page load.

Tech debt is real. It isn't a someday list or a nice-to-have. It's the reason the simple change takes a week, the reason the new person takes a month to get up to speed, and the reason the team is tired. It slows down every project that sits on top of it.

A lot can be said about preventing tech debt, and honestly, even with the best processes and intentions, it will always be a byproduct of the work. Something stops being needed. Something new comes along. The vision changes. Or we just tried a thing and it didn't work the way we thought it would. When that happens, whatever was replaced needs to be removed, updated, or at the very least turned off. If it isn't, that's tech debt.

Left alone, it makes the foundation we build on unstable, muddied with excess. Over time it becomes a hoard that takes more and more work to dig out of. And worse, when you finally go looking for something stable underneath it all, the core pillars of logic have often been eaten away or lost. I've seen it.

Tech debt needs a seat at the priority table, right next to the shiny new features, because it's the thing that decides how fast every one of those features gets built.

The same instinct, at home

This is why I build what I build on the side.

Saasy Logs exists because reading a Salesforce debug log shouldn't be a chore that eats your afternoon. DwelLogs exists because keeping a house running is almost always reactive: the pump quits, the filter is a year overdue, and you find out when something breaks. I wanted it to be proactive instead.

One of my mottos is see a need, fill a need. Most of the needs I see are friction: in a team, in a process, in a system, in my own laundry room. I can't help noticing it, and I can't help wanting to solve a good problem.

Once I've noticed it, my mind starts working. I want to understand it, and I want to make it better. For me, and for the people around me.

Because we're on the same side.