Vox

Leitura de 18 min

Getting to Senior - Taking Ownership Without Leading Projects

Summary

Jonathan Cuttrell addresses a common misconception among engineers aiming for senior roles: the belief that ownership requires leading projects or having formal responsibility over deliverables. He explains that this misunderstanding often holds back mid-level engineers who feel they lack opportunities to demonstrate senior-level capabilities.

He describes a gradient of ownership from entry-level to principal/director levels. Entry-level engineers and interns typically operate under close supervision with well-defined, low-risk tasks. As engineers progress to mid-level, they gain more autonomy but often still wait for assigned tickets and manager intervention when stuck. The trap occurs when mid-level engineers equate ownership with formal project leadership roles.

True ownership, according to Cuttrell, is a behavior displayed through the “what now?” mindset—continuously taking responsibility for figuring out the next step, whether that means escalating to a manager, coordinating with other engineers, bringing in subject matter experts, or identifying action items from problems raised in retrospectives. Senior engineers don’t necessarily know everything but know how to get unstuck and keep things moving forward.

This ownership mindset involves translating problems into action, taking initiative on organizational improvements, and holding oneself accountable without waiting for manager follow-up. The shift from being assigned work to taking ownership represents one of the most important transitions between career levels (L2 to L3). Cuttrell emphasizes that engineers with some experience and domain knowledge can demonstrate this ownership mindset in their current work without needing formal leadership roles.

Topic Timeline

  • 00:00:00 — Introduction to the ownership misconception in engineering careers — Jonathan introduces the episode’s focus on clarifying what ownership means for engineers wanting to reach senior levels. He explains that many engineers at associate levels hear they need to “show ownership” but receive unclear definitions from managers. The concept applies across engineering tracks and even outside engineering, but particularly in engineering contexts.
  • 00:02:23 — The gradient of ownership from intern to principal level — Jonathan describes a continuum of ownership expectations. Entry-level engineers and interns work under close supervision with highly detailed, low-risk tickets. Mid-level engineers gain more autonomy but still operate within well-defined parameters. The misconception occurs when mid-level engineers think ownership requires formal project leadership roles rather than being a behavioral mindset.
  • 00:06:21 — Defining ownership as the ‘what now?’ mindset — Jonathan explains that true ownership is a behavior displayed through constantly asking “what now?” and taking responsibility for figuring out the next step. This doesn’t mean knowing everything or having perfect technical proficiency, but rather being willing to take responsibility for determining what happens next—whether that means escalating, coordinating with others, or finding solutions.
  • 00:08:27 — Measuring ownership through reduced manager intervention — Jonathan suggests engineers can measure their ownership level by how often managers or tech leads need to intervene without prompting. Senior engineers know how to get unstuck and prevent work from stalling, while junior engineers might not even realize when things have slowed down. The key distinction is taking responsibility for deciding what happens next.
  • 00:10:21 — Ownership beyond deliverables and in organizational contexts — Jonathan expands the concept of ownership beyond code delivery to include organizational initiatives and cultural improvements. He gives the example of identifying problems in retrospectives—true ownership means translating those problems into action items rather than just raising issues. Senior engineers take action and hold themselves accountable without waiting for others to follow up.
  • 00:12:54 — Applying ownership mindset without formal leadership roles — Jonathan emphasizes that engineers with some experience and domain knowledge can demonstrate ownership in their current work. Challenging situations like roadmap collisions or inter-team dependencies provide perfect opportunities to show ownership without being designated as tech leads. The mindset shift involves opting into accountability and organizing work proactively.
  • 00:14:06 — Ownership as critical mindset shift from L2 to L3 — Jonathan concludes that ownership represents one of the most important transitions between career levels—moving from being assigned work to taking ownership and mastery. He hopes this clarification helps engineers realize they don’t need formal project leadership opportunities to demonstrate senior-level ownership capabilities in their current roles.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2025-11-18T08:00:00Z
  • Duration: 00:15:56

References

Podcast Info

Transcript

[00:00:00] hey folks and welcome to today’s episode of developer team my name is jonathan cuttrell

[00:00:14] my goal on the show is to help driven developers like you find clarity perspective and purpose in

[00:00:19] their careers today’s episode is going to be a pretty short episode i’m going to focus

[00:00:23] on a misconception a misconception that a lot of senior uh sorry uh people who want to become

[00:00:30] senior engineers um they are at that level below whatever your your company calls this the kind of

[00:00:37] associate engineer level and you want to move into a more senior role um and this is true also for

[00:00:44] managers by the way this this principle applies uh regardless of uh you know uh what what track

[00:00:50] you’re on it probably applies outside of engineering as well

[00:00:53] it especially applies in engineering um in in some particular ways we’re going to talk about

[00:00:58] that but uh the the concept is ownership if you if you’re my report if you uh that’s not many of

[00:01:07] you probably um if you uh uh you know have worked in engineering for very long if you’re an associate

[00:01:14] engineer if you talk to your boss and hopefully you have about what it takes to get to a senior

[00:01:19] role if that’s something you care about you have

[00:01:22] probably

[00:01:23] heard this term right you’ve probably heard that it requires you to show ownership and unfortunately

[00:01:32] the industry has not done a great job of standardizing across roles but this does tend

[00:01:38] to be one of the kind of aspects of moving along your career track um the the higher up you go the

[00:01:48] more senior you become the more ownership is expected from you

[00:01:53] but uh although that part has made its way into most conversations most performance conversations

[00:02:01] about uh how to move up in in the organization it very often is not well defined what do we mean

[00:02:09] by ownership what exactly uh you know do i need to do in order to show ownership um and this is

[00:02:16] where most managers have not provided a lot of clarity so let’s take a step back and think about

[00:02:23] think about what this transition is. And really, I want to talk about a gradient, a gradient from

[00:02:30] the most entry-level engineer all the way up to principal or up to a director level, a VP level.

[00:02:38] I want to talk about this gradient of ownership. So let’s say you’re an intern, like a very,

[00:02:46] very early entry-level engineer. You’re still kind of learning the basics of the various stacks

[00:02:56] you might be working on as an intern. You may barely know the language that you’re coding in,

[00:03:02] right? And so you can still show a bit of ownership, but the amount of ownership that

[00:03:08] you’re able to show is going to be limited by your experience pretty heavily at this point,

[00:03:14] right? And so most,

[00:03:16] most of the time, an intern or an entry-level engineer is likely going to do exactly the work

[00:03:23] that’s handed to them to do, right? This is, you know, very highly, you know, high level of detail

[00:03:31] and the tickets that you pick up, maybe a very low risk kind of work is going to be handed to

[00:03:37] these, to these engineers. If you’re working at a startup, you may have a little more risk

[00:03:43] tolerance. So you may get exposed to, you know, production environment, you may get exposed to

[00:03:46] production environment, you may get exposed to, you know, production environment, you may get

[00:03:46] exposed to, you know, production environment, you may get exposed to more complicated things a little

[00:03:49] bit earlier, but overall the, the kind of one end of the gradient of ownership is at this entry

[00:03:57] level where most of what you are doing, you are not necessarily owning. You are kind of operating

[00:04:04] under the patronage, you could say, of your manager or of another senior engineer or tech

[00:04:11] lead. And they’re likely to be very hands-on with you, right? They’re likely to,

[00:04:16] um, you know, to review your code. They’re likely to pair with you very closely. Um, you know,

[00:04:23] they’re, they’re trying to, as much as they are trying to get that ticket done with you,

[00:04:26] they’re also trying to help you learn how to get your feet under you, how to move towards

[00:04:32] more autonomous operation. And this is usually not just because they like you or because they

[00:04:38] want to, um, you know, uh, uh, you know, to, to provide some kind of charity. That’s not the goal

[00:04:45] in most cases. Um, you know, uh, uh, uh, you know, to, to provide some kind of charity.

[00:04:46] This is because they want to create an environment where you are more autonomous,

[00:04:51] where you’re able to take on work and they can work in parallel and you all get a little bit

[00:04:56] more done. All right. So that is kind of the next step, right? Uh, as you begin to become

[00:05:01] more autonomous, the work may still be fairly well, uh, defined. Um, you know, it’s, it’s likely

[00:05:08] that your tickets are well refined by the time they make it to you. Maybe they’re still fairly

[00:05:12] low risk. Uh, but overall you’re, you’re starting to have, you know,

[00:05:16] sessions of two or three hours where you’re just focused heads down and you’re actually able to

[00:05:21] produce code. So this is kind of a mid-level engineer. Um, you know, if you get stuck, uh,

[00:05:26] usually you can kind of just say, Hey, I’m stuck. And then somebody will come over to you and help

[00:05:30] you out, right. Um, virtually or in person. And this is where the trap that I’m talking about

[00:05:38] tends to happen is you’re, you’re kind of in this mid-level engineer and, uh, you’re handed tickets

[00:05:45] to do.

[00:05:46] You carry them through to completion. And this is as much as you can, uh, you know, currently

[00:05:51] kind of the limits that you see on your ownership. And the truth is that, uh, most of the time we

[00:05:59] mistake ownership for being assigned a tech lead role or being given a full project to do.

[00:06:06] We mistake ownership for, uh, some kind of scope of responsibility matching,

[00:06:12] right? Uh, you have to own a project.

[00:06:16] You have to own a deliverable. Um, you know, you have to own some particular outcome.

[00:06:21] And the truth is ownership is a behavior that engineers, especially senior engineers

[00:06:28] are displaying throughout almost every action that they take. I’m going to explain kind of

[00:06:35] how this works or what I look for, um, as, as a manager, as a leader of other, of other engineers.

[00:06:41] So, um, most of the time,

[00:06:46] what I’m looking for is someone who is always thinking about what now, if you remember nothing

[00:06:54] else from this, from this episode would you remember that phrase? What now? What next?

[00:07:00] What do we do as a result of what I know as a result of the thing that just happened is

[00:07:06] the result of the way that I just got stuck. What do I do next? All right and to always kind of have

[00:07:15] Okay.

[00:07:15] that mindset of moving on, moving forward, figuring out what the next step is. Now,

[00:07:23] you should pay really close attention to this little nuance. I want to call your attention to

[00:07:27] it. I am not saying that you should know what to do next every time. I’m not saying that you should

[00:07:38] always be able to learn all of the nuances, the technical detail. I’m not saying

[00:07:44] that you necessarily should inherently understand the work that you’re doing

[00:07:51] to a degree of ownership in terms of executing every step in the process.

[00:07:58] What I am saying is that you are willing to take responsibility for figuring out what happens next.

[00:08:06] All right. This is a subtle distinction. You are willing to take responsibility. This means that

[00:08:11] you are willing to raise your hand and say,

[00:08:14] and say, I will take care of this. What this really looks like in practice, you can kind of

[00:08:20] measure yourself. How often is your manager, is a tech lead, how often are they having to intervene

[00:08:27] in your situation? All right. In particular, without your prompting. Okay. So there’s this

[00:08:37] interesting kind of little nuance here where we said ownership is knowing that you need to figure

[00:08:48] out what to do next. So that might mean escalating to your manager. That might mean bringing in

[00:08:54] another engineer. It might mean bringing in product, some subject matter expert, somebody

[00:08:59] with a skillset you don’t have. All of those things are things that I do. They’re things that

[00:09:05] the highest level engineer does.

[00:09:07] Okay. So don’t get too hung up on, oh, a senior engineer, they know everything. They know how to

[00:09:15] do everything. They know how to operate every system. They know how to write, you know, any

[00:09:19] algorithm it’s put in front of them. That’s just simply not true. Okay. Instead, what they do know

[00:09:25] how to do is they know how to figure out who to coordinate. They know how to figure out what to do

[00:09:34] next. How do I get unstuck?

[00:09:37] How do I make sure that this doesn’t stall out? Now, a junior engineer may allow something to stall

[00:09:46] out without even knowing it. They don’t even realize that things have slowed down or, you know,

[00:09:54] a junior engineer may not know that it is theirs to decide what to do next. That is ultimately my

[00:10:03] definition here of ownership.

[00:10:07] Right. So, and this doesn’t always have to do with deliverables, by the way. Right. This doesn’t

[00:10:21] always have to do with, you know, pushing code through. This might be something like an

[00:10:25] organizational initiative to improve the culture. It might be something that you’ve identified. You

[00:10:32] identify a problem. Let’s say you identify a problem in retro, for example. Right. What is the

[00:10:37] ownership look like in this scenario? If you identify a problem and then you just kind of like

[00:10:42] let it sit. Right. If you just let that problem sit, then it’s unlikely that some other person is

[00:10:51] going to take the initiative to pick it up. And so there’s a hypothesis, a kind of an implied

[00:10:58] hypothesis that just by bringing this problem up, you have done your due diligence in order to solve

[00:11:05] it. That somebody else,

[00:11:07] of course, the, you know, the manager or another lead or somebody is going to pick it up. And this

[00:11:11] so often is not the case. And so what a, generally speaking, what a more senior engineer does

[00:11:19] is they try to translate, okay, these to translate these problems into action or a decision.

[00:11:28] Right. What that looks like is, okay, we’re going to bring something up at retro.

[00:11:33] What do we want to do about it? That’s, that’s the question.

[00:11:37] That a manager should be asking. That’s a question that you as an, as a mid-level engineer

[00:11:43] wanting to become a senior, that is the question that you ask. What are the action items? Can I

[00:11:48] take an action item? Can I go and act on this thing? A lot of times people kind of tend to

[00:11:54] accidentally avoid action items because they don’t want to load their plate up, but this is what it

[00:11:59] means to have ownership, right? To, to show ownership over, over a problem is to take

[00:12:06] action on that problem and do it in a way that you’re holding yourself accountable. You’re not

[00:12:11] waiting for someone else to hold you accountable, right? You’re not waiting for your manager to come

[00:12:15] and ask you what the status of something is. Go tell them what the status of that thing is, right?

[00:12:21] So hopefully the theme here is that you are taking over your work, right? There’s, there’s a lot of

[00:12:29] agency involved here. Hopefully I’ve dispelled the idea that you have to know everything in

[00:12:35] order to do this, that you have to have,

[00:12:36] the highest technical proficiency in order to do this. It’s not the case. It’s not the case.

[00:12:41] It’s helpful to have some, right? Which is why this advice doesn’t apply well to an intern.

[00:12:47] It doesn’t apply well to an entry level engineer. It applies excellently to an engineer that has a

[00:12:54] few reps, right? That, that you’ve shipped code to production. You kind of understand the domain,

[00:12:59] but you’re being challenged with new work, with expanding scope, with harder things to solve.

[00:13:05] Maybe you’re being challenged,

[00:13:06] uh, you know, roadmap collisions, or you have some, uh, some inter-team, uh, dependency stuff

[00:13:13] that you need to figure out. These are the perfect opportunities, even though you’re not

[00:13:17] designated as a tech lead. These are the perfect opportunities for you to step up and show

[00:13:23] ownership for you to step up and show that you are going to choose, right? You’re going to opt,

[00:13:30] opt in to being held accountable for the outcomes of some situation,

[00:13:36] of some set of work, of some, you know, uh, solving some problem. Um, so as you,

[00:13:43] as you progress through your career, you’ll realize that the more and more senior you become,

[00:13:49] the more this becomes really kind of all of your job, right? Is, is the ability to own something

[00:13:57] and to organize yourself and organize others around the things that you own.

[00:14:02] Um, this isn’t the only skill, right? There’s just to be clear,

[00:14:06] it’s not like this is a magic skill that you’re going to acquire and suddenly everything,

[00:14:10] you know, you get the promotion and, uh, confetti falls from the sky. That’s not the case, but

[00:14:16] it is a critical mindset shift and possibly one of the most important mindset shifts

[00:14:21] between an L2 and an L3. You move from being assigned work, right? Being pointed in a direction,

[00:14:29] uh, uh, and being deployed, you know, by a manager and by a tech lead, move away from that.

[00:14:36] And you move towards mastery of the craft and towards ownership. Hopefully this is a clarifying

[00:14:44] discussion and you can start to think about, um, my, my, my, uh, hope here that the best outcome

[00:14:50] is if you’re looking at your career right now, and you’ve been given this advice,

[00:14:55] so you have to own things and you said, well, there’s no projects coming up. There’s no way

[00:14:59] for me to show ownership because I’m not given any opportunities to lead anything.

[00:15:03] Hopefully this dispels all of that.

[00:15:06] Um, I hope you walk away feeling like, well, I don’t have any more excuses left.

[00:15:10] And now is the time to show ownership. Thank you so much for listening to today’s episode

[00:15:16] of developer tea. Um, sorry for the, uh, potential interruption, uh, with this episode

[00:15:22] and other episodes being on YouTube versus not being on YouTube. Uh, this is largely because

[00:15:28] we have some, uh, it’s a little bit harder to get interviews up on YouTube. Sometimes we’re

[00:15:33] going to be recording things that do, uh, get up to you.

[00:15:36] There is a feed that goes to YouTube of every episode. Um, that’s pulling off of our normal

[00:15:42] RSS, our normal podcast, RSS feed. And then sometimes we have these video episodes.

[00:15:47] Thank you so much for listening until next time. Enjoy your tea.

Visão de gráfico