The Career I Built on Work Nobody Wanted

TL;DR: The filter was never tedium. It’s blast radius: does this force me to understand everything downstream of it? I built Lavender’s security program from zero to SOC 2 Type II — evidence collection, control mapping, IAM, MDM, vulnerability management, incident response — and it taught me more about that company than any feature I shipped there. The same shape repeats across thirteen years: the Cognito-to-Auth0 migration covering 225K+ users and $400M+ in assets, consolidating InsideTrack’s ten services down to six, the GCP-to-Azure move that saved $350K in six months, twelve offshore engineers across timezones at Qualaroo. Nobody was fighting to own any of it. All of it touched more of the system than the interesting work did. The cost is real — years of low-visibility work with nothing to show a promo committee — and I’m not going to pretend it’s a hack instead of a trade.

The part of the job nobody puts on a slide

Lavender had no security program when I got there. Not a bad one — none. So the first months of building it to SOC 2 Type II looked like this: reading every control in the framework and mapping it to something real in the company, or admitting nothing real existed yet and building it from a blank page. Writing the access-review policy, then actually running the access review, cycle after cycle, until it was routine instead of a fire drill. Inventorying every device that touched company data so MDM had something concrete to enforce against. Standing up incident response as a process with defined roles and a runbook, rather than a Slack channel improvised during the incident it was supposed to prevent. Chasing evidence for auditors — screenshots, logs, signed-off tickets, the exact artifact a specific control required — for controls that felt, in the moment, like pure paperwork.

Why a company signs up for all of that in the first place is a separate argument, and I’ve made it in SOC 2 is a revenue tool, not a security tool. This essay is about what building it did to me.

None of that is a demo. Nobody in a standup says “excited to show you the evidence folder this week.” I’m not telling the story to complain about it. I picked work like this on purpose, at every company on my resume, for reasons that had nothing to do with liking audits. I don’t like audits. I like what building one teaches you about a company that nothing else does.

The engine: unwanted work is the fastest map of a system

The work nobody wanted was the work that touched every system.

Building a security program from zero doesn’t let you scope yourself to one service. To map IAM you have to know every system that authenticates. To do vulnerability management you have to know every dependency in every repo — including the repos nobody’s touched since the person who wrote them left. To write incident response you have to know what actually breaks in production at 2 a.m., who has to be woken up, and which system’s failure cascades into which other system’s failure. Nobody assigns that work because it’s fun. It sits there unassigned until someone takes it, because it’s diffuse and slow to show results. Those are exactly the properties that make it the fastest way to learn an unfamiliar org from the inside, rather than from an architecture diagram someone drew eighteen months ago and never updated.

Compare it to the interesting work: a new feature, a clean greenfield service, the model integration everyone wants to demo at the all-hands. That work teaches you one slice, deeply, and it teaches it well. The unwanted work teaches you the seams, because the seams are where the unwanted work always ends up living. Nobody owns a seam. Everybody owns a slice.

The receipts

At Lavender, past the security program itself, the same shape shows up in the infrastructure work. Moving production off GCP and onto Azure isn’t a feature anyone campaigns for. It’s a six-month slog of dependency mapping, cost modeling, and staged cutover, with zero user-visible upside if it goes well and a very visible outage if it doesn’t. I’ve written up the cloud migration in full — the short version is that it saved $350K over six months, and the reason I could scope it at all is that the security work had already forced me through every system that touched cost and every system that touched risk. It still cost $50K in mistakes along the way. Those are in the post too.

At BlockFi, the identity migration off AWS Cognito onto Auth0 covered 225K+ users holding $400M+ in assets, and it had to happen without forcing a mass logout — meaning every edge case in the auth flow had to be understood and handled, not just the happy path that demos cleanly. The full migration writeup is here; the mechanics are all in that post. What’s relevant here is what the project actually was. Nobody wants to own an auth migration, because auth migrations are where careers get quietly ended by a wrong assumption about token expiry. I owned it because it was the fastest way to understand exactly how identity flowed through a fintech company handling nine figures of customer assets. The same instinct showed up smaller-scale in the internal tooling I built for identity repair and account support — unglamorous by definition, since its whole job is fixing other people’s mistakes — which cut manual support burden by 65%.

At InsideTrack, the unglamorous version was consolidation — taking the microservice footprint from ten services down to six during a Ruby-to-Elixir migration. Consolidation produces almost no visible feature output for months. It also requires understanding every one of those ten services well enough to know which ones could actually be absorbed and which were only redundant on paper. That’s a map of the whole platform, and most engineers on the team never had reason to build it, because their job was one service.

At AAMP Global, it was ingestion pipelines processing telemetry from 40K+ telematics devices across commercial fleets, running on Kubernetes, while migrating legacy Ruby services alongside new Elixir feature work. Infrastructure plumbing that has to be correct at volume and gets noticed only when it’s wrong.

And at Qualaroo, the unwanted work wasn’t even technical. It was managing twelve offshore engineers across multiple countries and timezones while rebuilding growthhackers.com in Rails. Coordinating a distributed team and absorbing the timezone math nobody local wants to own is thankless, and it gets handed to whoever says yes first. Saying yes meant learning how the whole delivery pipeline worked, end to end.

What I look for now, on the other side of the hire

I’ve written about why the outcome-owner is the hire you want, not the specialist with the cleanest scope, and I won’t re-run that argument here. This is narrower. The question worth asking a staff-level candidate is what unglamorous thing they picked up voluntarily in their last role, then listening for whether the answer maps to a system boundary or to a single task. The staff-engineer loop I’d run doesn’t name this signal explicitly, but it’s what the judgment round is fishing for. Either a candidate can describe how the unwanted thing connected to three other systems, or they can’t, and the difference shows up immediately in conversation.

It’s also what I look for a candidate to have avoided. Someone who’s only ever taken interesting work isn’t disqualified by that alone, but it’s a gap worth probing, because it usually means they’ve never built the cross-system map the unwanted work forces on you. That gap shows up later as slow ramp time on an unfamiliar codebase, at the point when ramp is expensive instead of free.

The discriminator: does it touch the whole system, or just sit there being annoying

Not all unwanted work is equal, and this is the part that’s easy to get wrong. There’s a trap version of “take the unglamorous work” that just means volunteering for tedium: cleaning up a stale spreadsheet, renaming a batch of variables in one file, sitting through a meeting nobody wants to attend because the agenda is boring. That work is genuinely low-value. It’s tedious and isolated, and doing a lot of it teaches you how to tolerate tedium, which is not a skill worth building a career around.

The filter I actually apply: before you take on unwanted work, ask how many other systems it forces you to understand to do it well. A vulnerability backlog forces you through every service’s dependency graph, because you can’t triage a CVE without knowing what imports the vulnerable package and what breaks if you patch it. An identity migration forces you through every auth-dependent flow in the product. A cloud migration forces you through every cost center and every network boundary the company has. Those are diffuse. The work is unwanted precisely because it’s cross-cutting, and the cross-cutting is the payoff. A spreadsheet cleanup is unwanted because it’s boring, full stop, and boring-but-isolated work stays boring however long you do it. Pick the unwanted work that widens your map. Skip the unwanted work that’s just a chore in a box.

If you’re not sure which one is in front of you, ask what you’d have to learn to do it well, not just to do it at all. If the honest answer is “nothing new,” it’s a chore. If the honest answer is a list of three or four systems you don’t currently understand, it’s the kind worth taking, even though nobody’s asking you to spend the time there.

The honest cost

I’m not going to dress this up as a growth hack. Building a security program from scratch, running infrastructure migrations, managing offshore coordination — none of it produces a demo, a launch tweet, or a line item that reads well on a promotion packet next to “shipped feature X, drove Y% growth.” It’s low-visibility by construction. Nobody invites the person who wrote the incident-response runbook to speak at a conference about it. The evidence-collection months at Lavender didn’t make anyone’s highlight reel, including mine, and I wasn’t expecting them to.

Years of this mean years where the visible artifact of your quarter is a checklist, a migration nobody notices because it went right, or a policy document instead of a feature people can click on. If you’re optimizing purely for the fastest path to a promo packet full of shippable wins with clean before-and-after metrics, this is not that path, and I’d rather say so plainly. I made this trade repeatedly and would make it again. Eyes open, every time.

Where it actually leads

What it compounds into is narrower and less dramatic than a victory lap: the ability to walk into a system you’ve never seen and get oriented fast, because you’ve done exactly that involuntarily, over and over, as the price of taking the job nobody else wanted. I’ve written about doing it deliberately in how I triage an unfamiliar codebase in ninety minutes. That skill isn’t innate. It’s the residue of a decade of being handed the audit, the migration, and the offshore coordination. You get fast at reading an unfamiliar system by being forced through enough of them, at the times nobody else wanted to go first, until the pattern-matching stops feeling like effort.

What to do this week

1. Name the diffuse work nobody’s covering. Look for the thing that’s unowned because it cuts across three or more systems, not the thing that’s unowned because it’s boring in one place.
2. Take it before it’s assigned to you. Volunteering changes what you learn from it. You scope it, so you decide how wide the map gets.
3. Skip the isolated chores. If the payoff caps at “this one thing got cleaner,” let someone else have it.
4. Write down what it taught you about the system, not just what it fixed. The map is the asset. The completed task is the receipt that you built it.
5. Say the cost out loud before you commit to a multi-quarter version of this. Know what you’re trading in visibility, and decide on purpose, before you’re two years into low-visibility work you never chose.

If you’re a founder or an engineering leader trying to figure out who on your team is quietly building this kind of map — or trying to build it yourself before your next raise or audit — that’s a conversation I have often. Let’s talk.