Nobody assigned it: notes on taking the initiative
On finding the problem a company has learned to live with, proving a fix before asking permission, and staying with it long after it stops being new.
Every company has a few problems it has quietly agreed to live with. A vendor that costs too much and does too little. A manual process that eats someone’s Friday. A feature customers keep asking for that has no owner. They aren’t on the roadmap because they’ve become part of the furniture.
Some of the best work I’ve done started by noticing the furniture.
The clearest example is the one I wrote about in part one of my scaling series. We were paying a third-party provider every month for crypto infrastructure, and the provider’s limits had become our product’s limits. Nobody had asked anyone to fix that. It just felt like the way things were.
Look at what you keep saying no to
If you want to find the problems worth taking on, don’t start with the roadmap. Start with the requests the team keeps turning down, the costs nobody questions any more, and the work people do by hand because it was urgent once and then never got fixed.
You don’t need permission to look. You only need permission to spend other people’s time, and that comes later.
Prove it before you propose it
A proposal asks people to imagine something. A working build asks them to look at it. I’ve found the second changes minds far faster.
Keep the proof small and honest. Days, not months. Real data, not a mock. And be clear about what it doesn’t do yet, because the goal isn’t to ship. The goal is to change the conversation from “should we?” to “how quickly can this carry real load?”
The mandate is a debt
This is the part people skip. Once someone backs your idea, you owe them a working system. That includes everything that isn’t exciting: monitoring, reconciliation, documentation, the support question at an awkward hour.
Prototypes are fun. Operations aren’t. Most initiatives die in the gap between the two, and taking the initiative really means being willing to keep owning the thing after it stops being new.
Pick hard problems on purpose
Easy problems get staffed. The ones that change a company’s position usually don’t, because they’re risky, badly defined and cut across teams. That’s exactly why one person can move them.
I look for problems where the value is obvious once solved, where I can take the first step on my own, and where failure is survivable because the old and new can run side by side for a while.
Let the problem pick the tools
When you own a problem instead of a codebase, the stack stops being part of your identity. I’ve shipped TypeScript and Python, Swift and Solidity, servers, phones and smart contracts, because that’s what the problems needed.
Being stack agnostic doesn’t mean knowing a little of everything. It means learning a new tool well enough to be responsible for it in production, and doing it quickly, because the problem won’t wait.
Bring people with you
Initiative without communication looks like going rogue. Say what you’re trying and why. Share the proof early and ask people to break it. Give credit away freely, because the people who adopt your work are the ones who make it matter.
And sometimes the honest result is “we looked, and buying is still right.” That counts too.
None of this needs a title. It needs the habit of treating the business as if it were yours. In my experience, the surest way to be handed responsibility is to have already taken it.