That's Not My Job
How I got promoted twice by ignoring my job description
“Isn’t that a product manager’s job?”
One of my new collegues asked me that the other day. He’d stopped by my desk and caught me drafting a product proposal, a feature idea I wanted to pitch to our leads for next half. Technically, he was right. Writing proposals isn’t what I was hired to do. But over the years it’s become second nature, and I didn’t think twice about it.
His question stuck with me though and got me reflecting on my engineering journey.
Waiting For Permission
Early in my career, I kept asking senior engineers the same questions. What should I work on? How can I add more value?
I was waiting for someone to hand me the right project, for permission to contribute beyond my assigned tasks, for the path forward to be obvious. That’s not how it works.
At some point, something shifted. I started noticing inefficiencies on my own. Missing features. Problems that had been sitting there forever with nobody fixing them. So instead of waiting, I just started writing proposals.
Some made it onto roadmaps. Most didn’t. And the ones that got rejected? I ended up building them myself on the side when it made sense. That’s actually how my biggest early career moment happened.
What Nobody Asked Me To Build
At my first software engineering job at Capital One, we didn’t have a feature toggle system. For whatever reason, this just wasn’t a thing, and it made managing releases a nightmare.
One of my projects got stuck with this massive feature branch that went unmerged for months. We were rebasing constantly, and it felt terrifying to ship this giant feature all at once. One bad deploy and everything breaks.
I knew how to fix it, so I built a feature toggle service. Nobody asked me to. It wasn’t in my job description. I just did it.
That side project didn’t just solve my problem. I turned it into a full API service for our internal developer portal, and soon other teams across the org started using it. Teams I’d never even talked to were building their own integrations on top of it.
What started as fixing my own frustration became one of the largest APIs in our org by QPS. I got promoted twice that same year, not because someone handed me an opportunity, but because I built something nobody asked for.
Real Job Description
That experience taught me something I’ve carried ever since: companies don’t hire you to check boxes. They hire you for your expertise and your ideas. Sometimes that means doing work that isn’t technically yours.
At Meta, I’ve worn a lot of hats. I’ve been a data analyst when we needed someone to dig into experiment regressions. A TPM when projects needed coordination across teams. A mentor when junior engineers needed help leveling up. Sometimes even a crappy designer when I needed a better way to showcase what I was trying to build to leads.
None of this fits neatly into “software engineer.” But all of it helped me solve real problems that needed solving.
Am I a product manager? Sometimes. A data scientist? When I need to be. A designer? A terrible one. But I stopped thinking about job titles a long time ago. I just see problems and fix them.
What If You Just Fixed It
Next time you see a problem at work and catch yourself thinking “that’s not my job,” stop for a second.
What if you just fixed it?
The best opportunities I’ve had weren’t assigned to me. They were problems I decided to own when nobody was asking me to. That’s where the real growth happens.
What are you walking past?
Thanks for sharing, insightful.
Sounds like my mother. She kept taking on projects that were no part of her job description, and kept on getting promoted. She was inspiring