Proactive ownership

Reactive ownership closes assigned loops. Proactive ownership finds problems before they are tickets: a metric that looks wrong, a support complaint that matches a code path you know, tech debt with a business case, a missing runbook found while ramping up or during a near-miss.

The skill is packaging. "This code is messy" gets shrugged. "This code adds ~200ms p99 on checkout and we have two weeks of headroom before a launch" gets scheduled. Write the cost in product or risk language.

Edmond Lau's leverage framing — effort that compounds — is the right mental model. Proactive fixes to shared tooling, tests, and alerts often beat another feature slice.

Walking through healthy vs over-ownership

Ownership is not martyrdom. Over-ownership looks like being the only person who can deploy or understand a system; taking every page personally and never delegating; blocking the team because all decisions route through you; doing the PM's prioritization so hard that your engineering impact collapses.

Healthy owners make themselves replaceable on purpose: docs, pairing, rotating on-call, teaching. Delegation is not dumping. It is transferring outcome ownership with support. As you approach senior scope — scope growth, SDE3 path — multiplying others becomes part of the job. You cannot scale by clutching every loop.

If you are repeatedly the single point of failure for a service, your next owned project is not another feature. It is reducing bus factor: runbook, diagram, backup owner, simpler design.

Incidents amplify the same habit. Owners join the channel when their service might be involved, write hypotheses and actions, volunteer for action items that match their expertise — and complete them. They do not disappear when the fire is out and the dull follow-ups remain. In review, they care whether the change is operable, not only whether their taste was adopted. You can disagree and commit. You cannot shrug at a missing alert on a payment path because "not my PR."

Common mistakes

• Complaining in taste language. "Messy" does not get scheduled. Risk and user cost do.
• Heroics as identity. Bus-factor ownership does not scale and fails when you take leave.
• Doing everyone else's job. Prioritization and project management can swallow engineering impact.

Check yourself

You notice a table scan that will break at 10× traffic. You are at 4×. How do you raise it?

With the cost: "breaks at 10×; we are at 4×; launch is in two weeks" — not "this query is ugly."

You are the only person who can deploy a service. What is the next owned project?

Reduce bus factor: runbook, diagram, backup owner — not another feature.

Key takeaways

• Proactive owners surface problems with business or risk framing.
• Avoid bus-factor heroics. Delegate and document so ownership scales.
• Incidents and reviews still need closed follow-ups, not only clever diagnosis.
• Leverage compounds: shared tooling and alerts often beat another slice.

Further learning

Edmond Lau at Google on choosing work that compounds:

Back to the map: ownership.