I’m going to tell you about an engineer I worked with. Call him Mark. Mark was talented, well-liked, and utterly ineffective. Here’s what I learned from watching him.
What Mark did
Mark’s technical skills were real. He wrote good code. He gave thoughtful design review comments. He spoke well in meetings.
Mark’s problem: he didn’t own anything.
He worked on whatever was in front of him. He fixed bugs in code he didn’t write. He helped other engineers with their services. He never said ‘this is mine.’ Everything was ‘we should figure out who handles that.’
Why this was a problem
When something broke in production, Mark would help debug — for a few minutes. Then he’d disengage because it ‘wasn’t really his area.’ Nobody ever held him accountable because the code wasn’t explicitly assigned to him.
When planning happened, Mark didn’t propose projects. He waited for projects to be assigned to him. Assigned projects rarely came because leaders couldn’t predict what he’d actually commit to.
When reliability work needed doing — alerts to tune, dashboards to fix, runbooks to write — Mark agreed it was important and waited for someone else to do it.
Mark got good performance reviews for the first two years. He was technically capable, pleasant, and unobjectionable.
What happened
At year three, the company hit hard times. Leadership started asking: ‘what has this person done? what do they own?’ Mark had no answer.
He got laid off. It wasn’t a performance issue in the normal sense — he hadn’t done anything wrong. He just hadn’t owned anything.
The lesson for SREs
SRE is especially vulnerable to this trap. Everything is shared infrastructure. It’s tempting to be the person who ‘helps out everywhere’ without ever claiming a specific service.
Don’t. Claim something.
- Own an SLO
- Own a runbook library
- Own the post-mortem process
- Own the alerting hygiene for a service
- Own the capacity planning model
It doesn’t have to be big. But it has to be explicitly yours, with consequences if it fails and credit if it succeeds.
The meta-lesson
Ownership isn’t the same as being busy. You can be in a million meetings and own nothing. You can write 10,000 lines of code and own nothing. Ownership means: when something in your area breaks, you are the first person called, and you are the person who gets credit when it works.
Pick something this week. Ask your manager: ‘can I explicitly own X?’ Write it down. Defend it.
Don’t be Mark.
Written by Dr. Samson Tanimawo
BSc · MSc · MBA · PhD
Founder & CEO, Nova AI Ops. https://novaaiops.com
답글 남기기