Core Leadership Principle #2
It was 2 AM. Production was down. The team was scrambling in Slack trying to figure out what broke.
Someone deployed a feature that afternoon. Everything looked fine in staging. But in production, it was causing a cascade of failures across our integrations.
The developer who wrote it? Offline. Asleep. Had no monitoring set up. No alerts configured. No documentation about how the feature worked or what could go wrong.
We spent four hours debugging someone else's code, in the dark, with real users unable to process data.
That's when I learned what ownership actually means.
What Ownership Looks Like
Ownership isn't just writing code. It's owning that code from the moment you have the idea until it's retired from production.
That means:
- You understand the problem you're solving
- You design the solution
- You write the code
- You test it
- You deploy it
- You monitor it
- You fix it when it breaks
- You improve it over time
If you write code and throw it over the wall for someone else to deal with, you're not owning anything. You're just coding.
The Two-Hour Rule
Here's a pattern I see all the time:
Developer hits a bug. Stares at it for six hours. Finally asks for help at 5 PM: "Hey, this isn't working, can you take a look?"
Six hours of being stuck. Zero communication.
Better approach: If you're blocked for more than 2 hours, raise it.
But here's the key - don't just say "it's broken, help me." Show what you tried:
"I'm stuck on this auth bug. I've tried:
- Checking JWT token expiration - tokens are valid
- Validating signature algorithm - matches what we configured
- Using Claude to review the middleware - found nothing
- Here are my logs [paste]
I think it's in the token refresh flow, but I need another set of eyes."
See the difference? You did the work. You exhausted your options. You documented what you tried. You have a theory about where the problem is.
Now when someone helps you, they can actually help - not spend an hour reproducing what you should have already done.
Before You Ask for Help
Use everything available to you first:
- Read the documentation
- Use AI tools (Claude, ChatGPT, Gemini, Cursor)
- Write failing tests that show exactly what's broken
- Check similar issues in the codebase
- Google the error message
If you've done all this and you're still stuck after 2 hours - perfect. Ask for help. Just show what you tried.
"Can you help?" without context is not taking ownership. It's asking someone else to own your problem.
When Things Break in Production
This is where ownership really shows.
Bad ownership:
"The deployment failed. Someone should look at it."
Good ownership:
"The deployment failed. I own it. Root cause: database migration timed out because I didn't account for the table size. I'm rolling back now. Fix: breaking the migration into smaller batches. Should be ready to redeploy in 30 minutes. Here's how we prevent this next time..."
Notice:
- Takes responsibility immediately
- Explains what went wrong
- Has a fix plan
- Knows how to prevent it
- Gives timeline
That's ownership.
Setting Up for Success
When you ship a feature, you should have:
Monitoring:
- Metrics tracking the important stuff (latency, errors, throughput)
- Dashboards showing health at a glance
- Logs that actually help you debug
Alerts:
- Configured before you ship
- With context - not just "something broke"
- Routed to the right people
Documentation:
- How does this work?
- What can go wrong?
- How do you fix common issues?
- Who built this and how do you reach them?
If your feature goes down at 3 AM and someone else is on-call, they should be able to:
- Understand what broke from the alert
- Find your runbook
- Fix it or know how to reach you
If they can't, you didn't finish shipping.
The Deployment That Failed
A dev once deployed a payment refactor. It tested thoroughly. Everything worked in staging. It pushed to production Friday afternoon.
Saturday morning: alerts firing. Payment processing slowed to a crawl. Users couldn't complete transactions.
The old dev might have said "worked fine in staging" and waited for someone else to investigate.
Instead:
- It jumped on immediately
- It found the issue: hadn't tested with production data volume
- It rolled back in 10 minutes
- It wrote a post-mortem
- It fixed the actual issue
- It added load testing to our CI/CD
- It redeployed Monday with confidence
That's ownership. Not "it worked on my machine." Not "not my problem on weekends." Just: I own this, I'll fix it, here's how we prevent it.
Ownership Makes You Better
Here's what surprised me: taking full ownership made me a better engineer faster.
Why? Because when you know you're responsible for something in production, you:
- Think through edge cases
- Write better tests
- Set up proper monitoring
- Document your decisions
- Care about performance
- Plan for failure
You can't just write code and move on. You have to think about the whole lifecycle.
This makes you better at every part of engineering.
The Junior Developer Who Got It
I had a junior developer on my team. First significant feature. He was nervous about deploying.
But he did everything right:
- Wrote comprehensive tests
- Set up monitoring and alerts
- Created a runbook
- Deployed behind a feature flag
- Watched metrics for the first hour
- Posted an update in Slack
The feature worked perfectly. But more importantly, he owned it completely. When a question came up two weeks later, he knew exactly how it worked and why we built it that way.
That's the mindset. Not "I wrote some code." But "I own this feature."
Start Small
Pick one thing you're working on right now. Before you ship it:
- Set up basic monitoring
- Add one alert for the most critical failure mode
- Write a simple runbook: "If X breaks, here's how to fix it"
- Document your reasoning: "Why we built it this way"
- Tell your team: "I'm shipping X, here's what to watch for"
That's ownership.
Do this consistently, and you'll notice: people trust your work more. You grow faster. Your code gets better.
Not because you're perfect. Because you own the whole thing, not just the code.
The Real Test
Next time something you built has an issue, watch your first reaction.
Is it: "Well, it worked in my environment"?
Or is it: "I'll look into that right now"?
Is it: "Someone should probably fix that"?
Or is it: "I'm on it, here's my plan"?
The difference between those reactions is the difference between a code writer and an engineer who ships.
Choose the second one. Every time.
That's ownership.
This is part 2 of a 14-part series on Core Leadership Principles. Next week: Ship Every Day - why making progress daily beats bursts of heroic effort.
How do you practice ownership in your work? What's helped you take full responsibility for your code in production?
Follow me on Twitter
If you like and want to support my work check my patreon
See more in https://linktr.ee/daniloab.
Photo by Miguel A Amutio on Unsplash
Top comments (0)