Emilio Carrión
Ownership: The Invisible Superpower
"It worked on my machine." Ownership is what separates just another developer from someone who actually builds product.
You know what? This week I've been thinking a lot about those phrases we've all heard (or worse, said) at some point:
- "It worked on my machine"
- "I just did what the ticket said"
- "That's not my problem"
And I've realized they all have something in common: they reflect a lack of ownership. That invisible superpower that makes the difference between being just another developer and being someone who truly builds product.
Why am I telling you this?
Because ownership is probably the skill I look for most when evaluating teams. It's not the most technical, nor the flashiest, but it is the most important.
As Simon Sinek said: "Hire for attitude, because skills can be taught." And it's completely true. You can have technical gaps, you might not know the latest trendy framework, but if you have the right attitude, if you genuinely care about what you do, the rest follows.
What does having ownership really mean?
It's not about doing more work. It's about working with more impact. It's going from being a cook who follows recipes to being a chef who cares that every dish reaches the customer perfectly.
Day-to-day example: Your job doesn't start when you open a ticket and end when you commit. It starts with understanding why we're building something, continues through development, testing, deployment, and extends all the way to seeing how your users interact with it in production.
Three things you can do today
1. Understand the "why"
Before writing a single line of code, ask yourself: What problem does this solve? For whom? How will we measure if it works? When you understand the context, you make better decisions and can even propose better solutions.
2. Follow your feature to production (and beyond)
Don't wash your hands after the merge. Test it yourself in production, check the metrics, make sure there are no errors. Be the first to know if something goes wrong.
Enjoying what you read?
Join other engineers who receive reflections on career, leadership, and technology every week.
3. Apply the Boy Scout Rule
Leave the code better than you found it. Always. If you see something you can improve in 5 minutes, do it. The next developer (who might be you in 6 months) will thank you.
Having ownership also means knowing when not to add unnecessary complexity to the system. To help you decide when to abstract and when to keep it simple, here's my volatility scoring system:
The uncomfortable truth
If something takes 5 minutes to fix, don't say "that's not my problem." Fix it. The ownership mindset doesn't just make you a better professional -- it makes you more valuable to any team.
And the best part: it makes your work more satisfying. Because ultimately, the most rewarding thing about our craft is seeing how what we create impacts people's lives.
Insight: Ownership isn't given, it's taken. Don't wait for someone to give you permission to care about the product.
What do you think?
I'd love to know: have you been in situations where ownership (or the lack of it) made the difference? Share it on social media -- I read every message and love hearing your stories.
PS: I've published the second part of this on YouTube, but applied to code. We'll look at concrete examples of how ownership shows up in practice. Don't miss it.
This content was first sent to my newsletter
Every week I send exclusive reflections, resources, and deep analysis on software engineering, technical leadership, and career development. Don't miss the next one.
Join over 5,000 engineers who already receive exclusive content every week
Related articles
The Selfish Senior
When a senior hoards knowledge in their head, the team is left without a safety net. With AI accelerating code creation, sharing context is no longer a nice-to-have -- it's a critical responsibility.
AI Won't Replace the Software Engineer. It Will Replace the One Who Only Wrote Code.
Dario Amodei says AI will replace engineers in 6-12 months. Jensen Huang says we shouldn't learn to code. I've been thinking about this for months. I don't have all the answers, but I do have a stance.
The Senior Engineer Is Dead. Long Live the Expert Generalist
The classic senior engineer -- extreme depth in one stack, focused on implementation -- is becoming obsolete. The natural evolution is becoming an expert generalist: real technical depth with the breadth of judgment to connect technology with business.