The Email That Never Got Sent
Last Tuesday I spent three hours writing documentation for a tool that processes customer feedback data. Nobody asked me to do this. My manager doesn’t even know the documentation exists. The tool itself was something I built six months ago to solve a problem that was driving me crazy, but officially it doesn’t exist either.
This is the contradiction of caring about your work: the projects that actually matter to you are rarely the ones that matter to anyone else. They’re the side quests that come from genuine frustration or curiosity, not from quarterly planning sessions. They’re what you work on when you’re supposed to be doing something else.
Why Official Projects Feel Like Performance Art
Here’s what I’ve noticed about most official work projects: they’re designed by committee to solve problems that sound important in meetings but feel abstract when you’re actually doing the work. Take the “customer experience optimization initiative” I’m technically leading right now. It involves a lot of spreadsheets and stakeholder alignment calls, but zero interaction with actual customers.
Meanwhile, the feedback tool I mentioned earlier came from reading hundreds of support tickets and realizing our categorization system was completely broken. Customers were telling us they were confused, but we were categorizing their complaints as “technical issues” when they were really saying “your interface makes no sense.” That discrepancy kept me up at night.
The difference is obvious once you see it. Official projects optimize for meetings and metrics. Unofficial projects optimize for actually fixing things.
The Rebellion of Small Improvements
I’ve started keeping a list of these shadow projects, partly because I forget about them otherwise. There’s the automated email I set up to remind the sales team about feature requests that have been sitting in our backlog for over six months. There’s the simple dashboard I built to track which bugs actually affect real users versus the ones that only show up in our testing environment. Last month I spent my lunch breaks redesigning our internal status page because the current one requires three clicks to find out if our API is working.
None of these appear on my performance review. Most of them took less time to build than a single planning meeting for our official projects. But they solve real problems for real people who have to deal with broken processes every day.
The best part is that when you’re working on something you actually care about, the solution tends to be simpler. You’re not trying to accommodate every possible edge case or political consideration. You just want to fix the annoying thing.
When Caring Becomes Risky
There’s a trap here, though. I’ve watched colleagues burn out by caring too much about projects that their organization fundamentally doesn’t value. They build beautiful solutions to important problems, then get frustrated when nobody adopts them or gives them credit. The passion that makes these projects meaningful can also make their failure feel personal.
I learned this lesson with a data visualization tool I built two years ago. I was convinced it would change how our team understood user behavior. I spent weeks perfecting it, adding features nobody requested. When it launched to zero fanfare and minimal adoption, I took it as a personal rejection rather than what it actually was: a mismatch between what I thought was important and what the organization was ready to prioritize.
The trick is learning to care without attachment to outcomes. Build the thing because it needs to exist, not because you need recognition for building it.
Finding Your Real Work
The projects I actually care about share a few characteristics: they solve problems I run into personally, they make someone’s daily work noticeably easier, and they feel like craftsmanship rather than performance. They’re small enough to build without permission but meaningful enough to matter.
Sometimes these projects do get noticed and become official initiatives. The feedback categorization tool eventually caught the attention of our product team, and now it’s being integrated into our main platform. But that’s not why I built it, and it wasn’t any less valuable when it was just a script running on my laptop.
I think the real work happens in the margins between what we’re supposed to be doing and what we see that needs to be done. It’s the difference between following a job description and actually solving problems. Most organizations struggle to create space for this kind of work, but that doesn’t mean it isn’t happening. It just means it’s happening quietly, in documentation nobody asked for and tools that don’t appear on any roadmap.
What are you working on that nobody knows about? What small rebellion against broken processes are you quietly nurturing? Those projects might matter more than anything in your official workload.
