on ownership

how to make an impact as an IC

This post discusses what it means to own a project, product, service, system, process, etc. Ownership is a role taken on by everyone from time to time.

Ownership is stewardship. It's taking responsibility to achieve quality outcomes in a particular scope and timescale on behalf of the entire team through attention, craft, and care.

It takes attention and craft to turn a good idea into a great product. Grant yourself permission to create something great.

Skills required

  • Ability to leverage your own agency to get things done.
  • Ability to balance short term and long term goals to achieve high impact, sustained over an extended period of time.
  • Ability to gracefully field change requests, being open to ideas, improving ideas. Be responsive and knowledgeable about business needs.
  • Ability to shepherd larger initiatives: helping others to think through the implications of a change, break down the work, establish success criteria, and review contributions with an eye toward robustness and simplicity.
  • Ability to drive timely consensus among stakeholders, effectively communicate the plan, and execute the plan to achieve great outcomes. Includes doing pre-work to understand ahead of time where consensus will be required and front-loading it to early phases.
  • Ability to earn trust and de facto authority through clear, concise, accurate communication on technical topics and prolific design and code contributions. You set the bar for quality and speed.
  • Ability to admit mistakes. They’re inevitable! Backtrack as needed.
  • Know when to ask for backup when you’re underwater.

✅ Responsibilities of an Owner


  • Achieve clarity of purpose early. Establish and communicate end goals in a concise, compelling way.
  • Avoid or compartmentalize incidental complexity. Clarify, categorize, or abstract irreducible complexity.
  • Establish clear test/review methodology focused on verifying high level outcomes.


  • Ship good things.
  • Unix philosophy: single-purpose, composable layers.
  • Create good abstractions that make simple things easy.
  • Ensure that we don’t build leaky abstractions. If degradation is required, provide a documented escape hatch that is consistent with global behavior and concepts.


  • Core concepts up front: what is it, why do we have it, how does it work, what else does it interact with or depend on.
  • Openness to contributions, and change management. Gracefully field change requests, treat collaborators with respect.
  • Consistently and clearly communicate status, progress, and tracking to target dates through established channels. Surface blockers early.
  • Collaborate to solve problems creatively
    • E.g. adding examples to highlight existing functionality might be more helpful than adding new features or interfaces.
    • Accelerate solution exploration through clear explanations.
    • Help others to explain and frame change requests in light of long-term plans.
    • Know when it makes sense to change the plan.
    • Apply standards in service of clarity, correctness, simplicity, and consistency (in that order.)


  • Keep initiatives on the rails. Unblock and re-route quickly and effectively.
  • Don't stop until things are all-the-way done! It's often easy to leave things at 90%. Cut scope, but don't leave things half-finished. There's a big difference!