Four (and a half) Frames for Thinking About Ownership

It's hard to write a guide to being good at ownership. I guess this shouldn’t be surprising, given the extent to which ownership is about not needing guides and being able to figure stuff out for yourself. Despite this, I thought it was still worth trying to articulate what really strong ownership looks like - both because it's so valuable and because I think it is possible to improve with focus and practice.

Ownership means taking responsibility for your work – both for its overall quality, but also for whether it's the right work to be doing at all. It's a key factor in career progression, and explicitly one of Open Phil’s operating values, but when I look at internal guidance on those values or career progression, the descriptions I find don’t feel action guiding.

I've ended up with a few different ways of thinking about ownership that overlap with each other. I'll describe these frames in turn, and hopefully that will provide some useful nudges, or at least provoke interesting reactions.

1. Ownership as manager leverage

As a first approximation, you can think of ownership as: Output / Manager Effort

Taking this seriously doesn't mean checking in less – you’re dividing by manager effort, not manager time. It does, however, probably mean making check-ins more efficient. The main thing to aim at is making it easy for your manager to engage with you – providing the context they need in order to understand an update or answer a question, making clear what you're asking of them, and generally thinking about how to get the most value out of the interactions you have.

The right attitude towards manager interactions here looks something like treating manager time as a valuable resource that you have a fixed amount of each week, and that doesn't roll over. The finite resource bit drives the idea of using the time as best you can, but importantly, you shouldn’t try to ‘save it up’. Batching small questions that share context is often a good idea. But if you're stuck or think the project might be going in the wrong direction, not saying anything because "I didn't want to bother you" is not the way out.

A second aspect of this is about making yourself and your work legible to your manager. Both of you should have a shared understanding of what you're doing, such that you are both confident that if your manager disappeared for a bit, nothing would immediately blow up. You're trying to, in some sense, ‘make your manager unnecessary’ by creating your own systems, and plans, making it much easier for them to input only on the stuff that's most needed.

2. Ownership as default intellectual labour

Lots of communication in a work context follows this pattern: someone makes an observation, some reasoning happens, and then action points are assigned. Ownership can be viewed as defaulting to taking on more of the cognitive work in the middle stages.

Consider giving or receiving feedback. The easiest feedback to act on contains:

• An observation about your work or behaviour

• A value judgment (this worked well, or this was less than ideal)

• An explanation of that judgment

• A suggested next action

That kind of feedback takes effort to produce, but it's very easy to understand and act on. In contrast, feedback that's just "this piece of work was good/bad" is much easier to give, but harder to (usefully) act on.

For feedback to actually lead to improvement, someone needs to do the work of going from observation to value judgment to explanation to suggested next actions. That intellectual labour can in principle be done by either person. While it's typically best done by the person giving feedback, it's valuable (and shows ownership) to be able to take feedback where most of the labour hasn't been done, and either do it yourself or ask the feedback giver to do it.

This also applies when bringing problems to others. Instead of just saying "I'm worried about whether we're going to complete this on time," good ownership looks like saying "I'm worried about completing on time. Here are three potential bottlenecks I've identified, and here's how I plan to address each one. I'm confident in the first two approaches, but less sure about the third."

The same idea applies to structuring questions. Saying "I think I should do X for these reasons. I also considered Y and Z, but think X is best. What do you think?" is much easier to engage with than just asking "what should I do?"

Importantly, as well as being easy to respond to, this kind of question makes it easy for others to get a sense of what would have happened without their input.

Good ownership also means providing necessary context. Almost always, you know far more about your work than anyone else you're speaking to about it. It's on you to determine which bits of context are relevant and communicate them clearly. This often includes telling people what kinds of response you want. If you're asking for feedback, give specifics about what kind of feedback you're looking for.

What might it look like if you’re doing this well?

• You typically get answers without people needing to ask for clarification

• You reliably turn up to meetings with an agenda, and meetings follow that agenda

• It's rare that people get something from you and wonder "what am I meant to do with this?"

3. Ownership as justified autonomy & trust

Good judgment is crucial for ownership but hard to teach. However, good calibration on when to take risks versus when to check in is easier to sync up on and often more useful to improve.

Knowing what you don't know is core to the judgment that's important for ownership. Even at high levels, ownership isn't about having every answer – it's about recognising gaps in your knowledge before they become problems and knowing when you need help.

Consider delegating to someone who makes 90% of high-stakes decisions correctly and asks for help on 90% of the remaining ones, versus someone who gets 95% right but only asks for help on 50% of the rest. In the first case, we end up with a 1% unchecked error rate; in the second, 2.5% – even though the second person makes better initial judgments.

To improve at knowing when to double-check your judgment, make concrete predictions. When unsure whether to check in, predict whether your manager would have thought it was a mistake to proceed without checking.

How high that probability is isn't the only factor. You also need to assess the downside risk. What we care about is the expected disvalue of not checking in. For things with very high downside, even a 1-2% chance of error might warrant checking. But most "mistakes" don't have huge downsides, and aiming for error rates in the single digits in these cases would be overkill.

What does being well-calibrated on check-ins look like? You'll likely use a mixture of:

• FYIs ("I've done/am doing this thing")

• Objection windows ("I plan to do X unless I hear from you by [time]")

• Explicit requests for sign-off

It's a good sign if both you and your manager are clear about the "stakes" of the decision. The detail you provide should correlate with the risk. For low-risk activities, a light-touch FYI (or none) is fine. For high-downside decisions, you should clearly explain your reasoning.

Good reasoning transparency – clearly expressing what you think and why you think it – helps build justified trust and puts you in position to improve your judgment. When you disagree with your manager, you can focus on the crux of the disagreement rather than first needing to establish context.

4. Ownership as project managing poorly-scoped work

A core part of this frame is identifying the right end-state for a piece of work and then appropriate success criteria – knowing how you'll know if things are on track.

Ownership isn't just taking delegated work; it's making sure that's the right work to do. If you aren't bought in, push back. This is important because if you don't agree on why you're aiming at what you're aiming for, it's hard to know when to re-scope, change tack, or abandon the project. It's also harder to backchain from that end state to concrete actions. The more you can take a fuzzy, unscoped project and turn it into something that looks more like a to-do list with people and deadlines attached, the better.

Owning something poorly scoped means taking responsibility for rescoping it as the situation changes. That's why you need to understand the "why" behind the initial end state. You also need systems that give you visibility of the project's progress, because if something needs to change, you need to notice.

As you juggle more projects or tackle bigger ones with multiple stakeholders, systemising your tracking becomes even more important. You'll need to think ahead about which things are on the critical path and which will take the most time. You’re not going to be able to hold all of the relevant information in your head while doing this. Use your systems as additional working memory.

What does good ownership in this frame look like?

• It’s rare for you to feel surprised by a deadline, or need to rush because you’re blocking someone else

• Work is rarely duplicated by accident

• It's rare for no one to be left holding the ball on a particular action.

• It’s easy for new people to get up to speed – good visibility systems for yourself are typically also good for others

• When something inevitably slips off track, it’s you who notices – escalating, re-scoping, or just jumping in and fixing the broken thing yourself.

Good systems also ideally serve as a ‘historical record’ so that future projects can learn not just what was done, but why decisions were made that way.

The half: a note on LLMs

Currently, LLMs kind of suck at ownership. If you tell them to do something, they'll do it – even if it's a bad idea or the approach you asked for doesn't make sense.

They can structure and present information clearly, making them useful when providing context. They don't need context to be neatly presented (but they absolutely need it and are terrible at asking for more).

Using LLMs well looks a lot like demonstrating high ownership in how you interact with them. It's on you to determine:

• Whether this is the right question to ask

• Whether to trust the answer

• What needs to happen next

• What context is needed

• How the task should be done

But, what’s stopping you trying to answer those questions in all your work?