Drew Barontini | Continuous Ownership

I was talking to a colleague. They pinged me before our call to ask about a configuration value for the email provider we’re moving to for product emails. Since I didn’t know, I told them, while on the call, to ask the question in a channel where I think someone may know.

They said (paraphrased with brevity):

I already changed it. I don’t wait for people to move something forward.

I shared my similar philosophy for moving work forward, and we both lamented how most people actually like it when work stalls, because it means it’s not on them anymore. If it’s in someone else’s hands, they can move to the next thing and defer responsibility.

The most effective people take ownership of work from start to finish, even when the work requires dependencies.

The best salesperson doesn’t send an email and leave it. They follow up and try different channels. The best engineers don’t open a Pull Request and hope someone approves it whenever they can. They write detailed instructions and follow up to express urgency.

Taking ownership means seeing the work through until it is fully complete.

When I changed our code review process to assign one reviewer instead of a group, the speed and quality of reviews went up. Why? Because a directly responsible individual (DRI) was given ownership for their part instead of deferring to the group.

Think about a strategy document. Any strategy document. The one you’ve shared and asked for feedback on. It sits. You get a few people in there right after sharing, and maybe they even add a few comments. You respond. Then it sits again. You wonder how to move it forward. It’s top of mind for you, but not anyone else. It’s your responsibility to move it forward. Set a date and ask for a decision. Or, if you have enough authority, make the decision. I’ll often say I’m accepting feedback until X date, and then I’m going to close it and move it forward. A document that lives in perpetuity collects dust unless there’s a steward who keeps it fresh and continually nurtures the information.

Continuous Ownership means maintaining responsibility of progress toward an intended outcome, even when the next action passes to someone else. Reaching a desired outcome requires understanding and judgement to intervene when the work needs to move.

Ownership extends beyond individual actions

When I’m responsible for any work, I start by getting clear about the outcome. What do I need to accomplish to call this done? This is often referred to as the “definition of done,” but I like to imagine the outcome as what impact (or change) I want to see.

Writing code? It’s not the expected behavior, but the improved user value that delivers better metrics for the business.

Pursuing a lead? It’s not the email response, but the booked meeting and established relational trust to convert a new customer.

Visualizing the end state helps you make better decisions during the process. Getting anything to done requires trade-offs. Knowing which trade-offs to make requires a clear understanding of the desired outcome.

But a lot of work involves multiple people coordinating, like a relay race where batons are handed off from one runner to the next. If you don’t want the track littered with dropped batons, you need continuous ownership to maintain the thread of continuity and coherence.

Work in complex systems requires strong relationships to thrive. When my team needs a PR reviewed or a demo for a customer, I help support their efforts. It builds trust. It also creates a culture of collaboration and collective responsibility to make progress.

But remember: your priorities are your priorities. Nobody will care as much as you do about advancing your work. If it’s assigned to you, then you have the responsibility of continuous ownership. To reach the outcome, you need more than the right mindset. You also have to exercise good judgement.

Effective ownership requires understanding and judgment

Knowing the outcome is important, but so does meeting reality. Anything before that point is a simulation. It’s what you believe will happen and what you should do. Each step the work progresses is an opportunity to improve your understanding and adapt.

Smart people update their understanding when information changes.

A member of sales submitted questions from a new customer lead they were in the process of qualifying. They made incorrect assumptions about the product in their draft response. I have Linear Asks connected to an internal email, so we get tickets that are automatically triaged, with a thread directly to the person who emailed, and any internal comments private to Linear. I pinged my boss and we chatted briefly, but it was late in the day and he said he’d review in the morning. The next day, I stared at the ticket in my queue and responded to the salesperson. I corrected their assumption and told them to have the discovery call to learn more before we make any additional decisions. When I met with my boss, he asked if we needed to discuss the response, and I told him I already responded.

I knew what we should say. I knew the risk of the decision was low. It wasn’t worth the time, and I wanted to clear my queue to make sure work is moving. Sales shouldn’t sit on the response. They should connect with them to move the opportunity forward.

I leveraged my understanding of the work and exercised judgement to make a decision. It didn’t need to wait, so I didn’t let it.

Decision Practice

Let’s put this inside a decision practice you can use to exercise appropriate judgement.

Understand → Evaluate → Act

Understand

Outcome → what are we trying to achieve?
Context → what do I need to know?
Constraints → what are the boundaries?

I had enough understanding of the sales request and situation to move forward.

Evaluate

Impact → what are the consequences?
Reversibility → can this be undone?
Confidence → do I know enough to proceed?

I realized waiting or expending more energy wasn’t going to net a better decision, so I felt confident in moving to a decision.

Act

Decide → make the call
Test → reduce uncertainty through action
Involve → seek expertise or approval

I made the call. It didn’t need a test or additional involvement to resolve it.

Ownership is demonstrated through sustained follow-through

When it comes to moving work forward, I’m not very patient. And I think impatience is a positive attribute in this context because it forces movement. Default to movement. Do something: bump the ticket with a comment, send an email, or consider a smaller step you can take to move closer to the outcome.

You have to care more than anyone else about moving your work forward. Letting work sit is how you lose momentum and progress toward achieving outcomes.

I like to refer to work that’s idling as “ghosts” because it sits and loses any of the energy required to move it fully to completion. If you own the work, you’re a Ghostbuster. Keep an internal clock for what’s sitting too long. I even have a Linear automation run every Monday to find the ghosts in the system and add relevant comments to bump the work.

But when it comes to your own work, you need a mental model formed around what the work is, the current status, and the completion clock.

I redesigned our system for managing B2B licenses. The status and dates for each license required manual updates, which meant they were often wrong. So I collated the data to update and sent a request out to sales leaders to review the changes. One sales leader added more people to the thread, someone pinged me directly, and complexity ensued. The surface area of the problem was clear, but the surface area of the solution expanded, making it difficult to move forward with that many people involved in the decisions. It was important work for me, but “another thing” for everyone else. Adding more people to a thread is an easy way to defer responsibility, and it happens all the time. It’s also why so many big projects stall and fail.

But remember how I’m impatient?

I made the decision (with approval) to handle it on my own. I reduced the complexity being created with too many people and resolved it in a way that provided visibility into the changes without unnecessary handoffs.

When some of the changes had unintended consequences, I acted on the feedback and improved the system. Sustained follow-through necessitates iteration speed. You can’t sit on the feedback. Create a tight feedback loop and continuously iterate. Doing so builds your intuition for sensing when it’s ready. And knowing the outcome makes you certain.

Ownership Board

I shared this before, but I stopped keeping a traditional to-do list. I used to swear by one, but then I just stopped. I keep a weekly list of what I’ve completed, but now I focus on what I call my Ownership Board. This is the “My issues” Kanban board in Linear, which shows cards in a set of five columns:

Backlog for things I’m tracking.
Queue for things I’m about to do.
In Progress for what I’m working on.
In Review for work I’m finishing.
Done for completed work.

This is specific to the software development lifecycle work moves through, but I also track regular tasks in my board. This is a public and accountable list of everything I’m responsible for, not a private list of things to do.

I love a Kanban-style board to track work because it’s visual. There’s weight to it. I can easily see imbalances, like when there is too much work I’m focused on; or trying to finish; or when there’s too in my backlog; or not enough ready to work on next.

Thinking about this more abstractly, there are essentially five components:

The visual board.
The five columns as stages.
The cards for each work item.
The flow for moving the cards through.
The limits to maintain balance in the work.

And although I use standard naming for the team, I like these names for the columns:

Radar → Queue → Focus → Finish → Done

And in the interconnected AI and MCP world, I can open a Claude Code session and talk about my board in Linear. I like to close my Fridays by reviewing my board and all the product analytics to find signals. I built a few skills in Claude to do this. One reviews all the data and finds three strategic signals and adds them as issues to my board.

Constraints

A key part of this process is constraints.

I like to end my week with empty Focus (In Progress) and Finish (In Review) columns. I also like to make sure my Radar and Queue aren’t overloaded. They should consider the upcoming week and how much time I have to dedicate to the workload. To make it easy, I suggest applying basic constraints to each of the working columns.

My default constraints:

No more than 10 cards in Radar.
No more than 5 cards in Queue.
No more than 3 cards in Focus.
No more than 3 cards in Finish.

Done is a cumulative column, so it doesn’t need a constraint.

The skill can then assess the work and I can talk it out to make sure work is constrained to the limits I set. And throughout the week it’s easy to see the imbalances since Linear shows the aggregate count of each column. If I have too much work in Finish, I shift my energy toward getting work to Done.

Interventions

There are five key evaluations I make when I’m trying to work within the constraints:

Complete the work.
Defer the work to another stage.
Split the work into smaller pieces.
Transfer the work to someone else.
Cancel to remove work that’s not relevant.

I built this into the skill, which makes it easy to triage the work and create an accurate representation of my priorities each week. And anyone else on the team can see it. Because ownership shouldn’t be a private affair. You need to surface the work, make it visible, and take responsibility to bring it to completion.

Don’t sit around and wait for someone else to help you make progress. And never ask for permission to make something better. Take ownership and deliver meaningful change.

Be an owner.