Three attempts. Three different ways in. One lesson about how work actually gets done.

The first attempt#

A few years ago I became obsessed with a problem nobody had officially asked me to solve: we had no reliable way to know who owned what service. Ownership was scattered — in people’s heads, in Slack threads, in documentation that was already outdated the moment it was written.

So I started collecting it. Built a Notion database, mapped services to teams, planned to migrate it into our own system eventually. The vision was clear to me: you can’t build an internal developer platform without knowing what you’re building it on top of.

The SREs across every team got it immediately. Bottom-up, the buy-in was there. We brought it to a broader meeting — the engineering managers, the people with actual authority to make it official.

It got shot down. The reasoning was fair: this adds coordination overhead for teams already underwater, and Datadog can surface service lists anyway. Not a perfect answer, but a valid one from where they were sitting. The initiative died in that room.

I was disappointed. But I couldn’t argue with the logic.

What rejection teaches you#

The easy response to getting shot down is to conclude the idea was wrong. The harder thing — and the more useful thing — is to separate the idea from the entry point.

The idea wasn’t wrong. The SREs knew it. The way in was wrong.

Technical consensus is not the same as organizational will. You can have every engineer in the room nodding and still lose the meeting, because the people with authority are optimizing for something different — coordination cost, team bandwidth, political timing. They’re not wrong either. They’re just looking from a different altitude.

Coming in frontal — here is the problem, here is the solution, here is what we need to build — puts the cost on the table immediately. In an org where everyone is already underwater, a new initiative that requires buy-in and coordination across teams is a very easy no from the top, even when the bottom is ready.

The cost of saying yes has to be invisible. Or better — it has to look like something else entirely.

The trojan horse#

A while later we were migrating repos into a monorepo. The existing tooling was a mess of Makefiles and composite actions — functional, but unreadable. Even I had to squint to follow what some of them were doing.

We had Mason, an internal CLI that could build and test. I saw an opening. While helping with the migration, I extended Mason to handle secret generation and deployments too. The alibi was simple: might as well clean this up while we’re in here. Make it readable. Consolidate the Makefiles.

Nobody pushed back. Why would they? It looked like housekeeping.

But underneath the cleanup I was laying plumbing. Every Makefile we converted was one less artifact from a previous era, and one more thing Mason owned. I wasn’t asking for a project. I was just making things tidier — and quietly building toward something I’d believed in for a long time.

Today Mason is how everything gets built, tested, packaged, and deployed across the monorepo. It’s not a side project anymore. It’s infrastructure. Nobody remembers it started as a cleanup task.

The third way#

CI Insights came differently again. This time I didn’t sneak in through cleanup — I waited for the moment when the org’s pain and our existing work finally intersected.

We’d been building the data layer for months. Originally just to track runner SLA, because GitHub ARC gave us nothing usable. Once we held the data, cost attribution became possible. Per-team visibility became possible. But none of it mattered politically until transaction volume started falling and CI showed up as 25 to 30 percent of our entire cloud spend.

That’s when the tool became relevant to people above us. Not because it changed. Because their context did.

We demoed it. The response was real — this could anchor an internal developer platform, finally answer questions with data. But the wind wasn’t going that direction yet. So the tool exists, the data exists, and we wait.

The floor, not the ceiling#

Three attempts. Three different ways in. One rejection, one trojan horse, one that’s still waiting for its full moment.

What I learned across all three isn’t a hack or a framework. It’s simpler: your assigned work is the floor. The minimum. The thing you’re expected to do. Most people treat it as the definition of their job. But the ceiling — what you can actually build, what you can move, what you can quietly make real — that’s yours to decide.

The constraint isn’t the org. The constraint is how you enter. Come in frontal with a new initiative and you’re asking people to take on cost. Come in sideways through something they already want done and the cost disappears. Wait for the moment when what you’ve already built becomes exactly what they need, and you don’t have to ask at all.

I’m not sneaking around the system. I’m learning to read it — and move within it without waiting for permission that was never going to come.

And sometimes — if you’re patient enough — the thing that got rejected comes back on its own.

The service catalog I pitched years ago and lost: it exists now. Not because anyone approved it. But because CI Insights collects every test module across the monorepo, gh-etl pulls ownership data from GitHub, and when you put those two together, the catalog just appears. Package names, owners, team attribution — all of it, without a single meeting about whether we should build it.

Nobody rejected it this time. Nobody approved it either. The data made it inevitable.

That’s the thing about conviction — you don’t always need to win the argument. Sometimes you just need to keep building until the argument becomes irrelevant.

Assigned work is where you start. The rest is up to you.