Engineering ownership in the age of AI: the DRP (7 min read)

Over the years I have worked with many engineers, and I noticed that many of them did what was on the ticket, did it well, and waited for the next one. Some were very good, technically better than the people around them, but their impact (and careers) stopped moving forward early.

It was rarely about technical skill. They were missing ownership and engagement: being the person who is responsible for the result, not only for their part of it. The engineers who advanced fastest and furthest were the ones who asked "is this actually solving the problem, and what can I do about it?" and then made sure it happened.

I wrote down a simple framework to help managers and engineers. I call it the DRP: Directly Responsible Person. The idea fits in one sentence: a DRP is one person who is accountable for a deliverable.

This framework is inspired by Apple's DRI (Directly Responsible Individual). I added a more practical guide with concrete guidelines for what the person responsible actually does. I gave it a different name, DRP, only to avoid confusion.

I wrote the first versions of the DRP years ago, long before AI became essential to software engineering, and its principles still stand. In fact, the more I use AI tools in my own work, the more I think the DRP is one of the most important habits an engineer can have today. With AI, writing code is no longer the bottleneck, so the skills a DRP needs count for much more on a career.

This is not only for engineers. Product managers and leaders already work this way. Testers, designers and other roles can too. Anyone can be a DRP.

What a DRP is (and isn't)

Is it just "project management"? They share some aspects: planning, tracking progress, communication with stakeholders. The difference is what they are. Project management is a process and usually a role, with budgets, resources and timelines. The DRP is a rule about ownership: one deliverable, one named person who is accountable for the result. You don't need a title or a team to be one, and it works for small deliverables as well as large projects.

If you are an engineer who likes well-defined tickets, with everything you need to do served on a plate, you likely won't enjoy the DRP. If you want autonomy and like to take care of a goal, then DRP is for you. The main benefit is clarity of ownership, so a project doesn't stall because everybody assumed somebody else was on it.

People can ask for a status at any moment, and the DRP always knows what's going on, or whom to ask. One more thing matters to me. A DRP doesn't just connect people and tell them to figure it out. A DRP makes sure it happened, and checks.

I deliberately kept the guidelines short and didn't elaborate on each point. They are a reminder of what to think about when you are a DRP, not a checklist of chores. When you prescribe every step, you get a false sense of progress and less room for ideas and engagement. I'd rather give the principles and let engineers choose and work out how to use them.

What a DRP does

These are the guidelines, in short:

• Agree on the success criteria with stakeholders and write them down. This is your best protection against scope creep. "Why are we doing this, and how will we know that it is successfully done?" should always have a clear answer, and the closer the answer is to customer experience and the business, the better.
• Agree on the priority and communicate it, so everyone knows what comes first. Know how your project ranks against other company priorities.
• Find and involve all relevant stakeholders early, in planning, for example: platform, operations, testing, security, legal, product, finance, UX. The later you involve a stakeholder, the more risk you create.
• One shared place for communication, one place for documentation. Don't segment communication. You never know which colleague you'll need in the conversation next. Keep it easy to follow. The best setup uses company-public Slack or Teams channels (avoid "secret channels").
• Plan and drive the breakdown of the work across dependent teams, and map the dependencies. On a big project you can't do it all yourself, but the plan is on you (involve people), and the quality of the plan often decides how the project ends.
• Track progress, and keep it simple and transparent. I recommend only two statuses: green (on track) and red (not going well). The goal is to detect delays and obstacles as early as possible. Some people add yellow for at risk. That works too, but green and red force a clear call.
• Inform people proactively when scope, priority or obstacles change, and keep reporting predictable. Don't count on others to notice a message. If your stakeholders haven't heard from you in a while, or if they always ask you for updates, that is a bad sign.
• Ask for help early, and escalate early. Don't wait for problems to grow, and have the courage to raise them.
• Give credit. Mention the people who contributed. Be fair. That is how you build enthusiasm and allies for your next project.
• Name the risks early. Ask what could go wrong, write it down, and say who owns each risk.

None of this is rocket science. The hard part is that somebody has to do it, consistently. That is what a clear owner is for.

Do you need authority to be a DRP?

No, you don't need to be a manager. If a decision is outside your scope, involve and ask the decision makers. Your job is to bring clarity and people together around the same goal. Some of the best DRPs I've seen were junior engineers, with more impact than their senior colleagues.

Coding is no longer the bottleneck

For a long time, the scarce skill in software engineering was writing working code. We organized teams, hired and promoted around it.

AI is changing that quickly. I use Claude and other AI tools every day. Boilerplate, tests, scripts and first drafts are cheap, understanding parts of an unfamiliar codebase takes much less time than before, and the distance between "I have an idea" and "I have something running" has collapsed.

What's left is everything around the code, and that is exactly what the DRP guidelines above cover. If AI helps you write the code and the tests, then "I only do the coding part" is no longer a reason to stop where your task ends.

That doesn't mean engineering has become non-technical. To use AI well, you need technical skills, architectural knowledge and engineering experience. Without them you can't guide AI properly, and the work it produces is unlikely to be good.

For some people this shift is frustrating, because the fun of writing code by hand is fading. But that is the future, and it is already happening in many teams. Orchestrating agents, gathering insights, working with stakeholders and making decisions in the company's best interest are the new engineering.

What stays human

AI doesn't own anything. It can't be held accountable, and it doesn't know what is never written down: who really decides, when priorities shift and why, what people want from their careers. That context comes from people. Someone has to define "done", check the result, and stay with it after it ships. That someone is the DRP.

What this means for juniors and managers

Juniors used to learn slowly, one small task at a time, but AI now answers most "I'm not expected to know this yet" questions in seconds. Being new is no longer a reason not to own at least a small outcome.

Managers can use the DRP for upskilling and as a signal of engagement, and letting someone be the DRP of a small but real deliverable is probably the best way to grow them. In another article on engineer's seniority I listed "delivery and ownership" as the first pillar of seniority, and today it is the entry ticket.

How to start

If you are an engineer who wants to try being a DRP, or a manager who wants to grow your reports, you can start immediately. You don't need a big process change.

If you want to be a DRP:

• Pick one small piece of work and put one name next to it. If you can't name anyone, that's already useful information.
• If the name is yours, write down in a few sentences what success means, who needs to be involved, and what could go wrong.
• Use AI to widen your reach, not to shrink your accountability. Let it help with the unfamiliar parts, and keep yourself responsible for the whole.

If you lead a team:

• Say it out loud. Don't assume engineers know they're expected to own the outcome. Tell them which outcomes each of them owns, and give them the room and authority to do it.
• Pick one person and make them the DRP of a small but real deliverable. Then watch how they grow.

Being good at DRP is a matter of practice. Starting small and growing is normal. Stagnation is a reason for alarm. There is no less engineering work in the age of AI. There is more, and the impact per engineer is bigger.

Closing thought

The old days of engineers who just write code are ending quickly. Historically, our profession was always about finding our way in new contexts, changes and unknowns. That is the job we are paid for.

Tools will keep getting better at the "how". That makes the "who" more important. The engineers who matter most will be the ones who can say "this is mine" and then make sure it happens, end to end. If you are an engineer who likes well-defined tickets, with everything you need to do served on a plate, you likely won't enjoy the DRP. If you want autonomy and like to take care of a goal, then DRP is for you. The main benefit is clarity of ownership, so a project doesn't stall because everybody assumed somebody else was on it.

People can ask for a status at any moment, and the DRP always knows what's going on, or whom to ask. One more thing matters to me. A DRP doesn't just connect people and tell them to figure it out. A DRP makes sure it happened, and checks.

I deliberately kept the guidelines short and didn't elaborate on each point. They are a reminder of what to think about when you are a DRP, not a checklist of chores. When you prescribe every step, you get a false sense of progress and less room for ideas and engagement. I'd rather give the principles and let engineers choose and work out how to use them.

What a DRP does

These are the guidelines, in short:

• Agree on the success criteria with stakeholders and write them down. This is your best protection against scope creep. "Why are we doing this, and how will we know that it is successfully done?" should always have a clear answer, and the closer the answer is to customer experience and the business, the better.
• Agree on the priority and communicate it, so everyone knows what comes first. Know how your project ranks against other company priorities.
• Find and involve all relevant stakeholders early, in planning, for example: platform, operations, testing, security, legal, product, finance, UX. The later you involve a stakeholder, the more risk you create.
• One shared place for communication, one place for documentation. Don't segment communication. You never know which colleague you'll need in the conversation next. Keep it easy to follow. The best setup uses company-public Slack or Teams channels (avoid "secret channels").
• Plan and drive the breakdown of the work across dependent teams, and map the dependencies. On a big project you can't do it all yourself, but the plan is on you (involve people), and the quality of the plan often decides how the project ends.
• Track progress, and keep it simple and transparent. I recommend only two statuses: green (on track) and red (not going well). The goal is to detect delays and obstacles as early as possible. Some people add yellow for at risk. That works too, but green and red force a clear call.
• Inform people proactively when scope, priority or obstacles change, and keep reporting predictable. Don't count on others to notice a message. If your stakeholders haven't heard from you in a while, or if they always ask you for updates, that is a bad sign.
• Ask for help early, and escalate early. Don't wait for problems to grow, and have the courage to raise them.
• Give credit. Mention the people who contributed. Be fair. That is how you build enthusiasm and allies for your next project.
• Name the risks early. Ask what could go wrong, write it down, and say who owns each risk.

None of this is rocket science. The hard part is that somebody has to do it, consistently. That is what a clear owner is for.

Do you need authority to be a DRP?

No, you don't need to be a manager. If a decision is outside your scope, involve and ask the decision makers. Your job is to bring clarity and people together around the same goal. Some of the best DRPs I've seen were junior engineers, with more impact than their senior colleagues.

Coding is no longer the bottleneck

For a long time, the scarce skill in software engineering was writing working code. We organized teams, hired and promoted around it.

AI is changing that quickly. I use Claude and other AI tools every day. Boilerplate, tests, scripts and first drafts are cheap, understanding parts of an unfamiliar codebase takes much less time than before, and the distance between "I have an idea" and "I have something running" has collapsed.

What's left is everything around the code, and that is exactly what the DRP guidelines above cover. If AI helps you write the code and the tests, then "I only do the coding part" is no longer a reason to stop where your task ends.

That doesn't mean engineering has become non-technical. To use AI well, you need technical skills, architectural knowledge and engineering experience. Without them you can't guide AI properly, and the work it produces is unlikely to be good.

For some people this shift is frustrating, because the fun of writing code by hand is fading. But that is the future, and it is already happening in many teams. Orchestrating agents, gathering insights, working with stakeholders and making decisions in the company's best interest are the new engineering.

What stays human

AI doesn't own anything. It can't be held accountable, and it doesn't know what is never written down: who really decides, when priorities shift and why, what people want from their careers. That context comes from people. Someone has to define "done", check the result, and stay with it after it ships. That someone is the DRP.

What this means for juniors and managers

Juniors used to learn slowly, one small task at a time, but AI now answers most "I'm not expected to know this yet" questions in seconds. Being new is no longer a reason not to own at least a small outcome.

Managers can use the DRP for upskilling and as a signal of engagement, and letting someone be the DRP of a small but real deliverable is probably the best way to grow them. In another article on engineer's seniority I listed "delivery and ownership" as the first pillar of seniority, and today it is the entry ticket.

How to start

If you are an engineer who wants to try being a DRP, or a manager who wants to grow your reports, you can start immediately. You don't need a big process change.

If you want to be a DRP:

• Pick one small piece of work and put one name next to it. If you can't name anyone, that's already useful information.
• If the name is yours, write down in a few sentences what success means, who needs to be involved, and what could go wrong.
• Use AI to widen your reach, not to shrink your accountability. Let it help with the unfamiliar parts, and keep yourself responsible for the whole.

If you lead a team:

• Say it out loud. Don't assume engineers know they're expected to own the outcome. Tell them which outcomes each of them owns, and give them the room and authority to do it.
• Pick one person and make them the DRP of a small but real deliverable. Then watch how they grow.

Being good at DRP is a matter of practice. Starting small and growing is normal. Stagnation is a reason for alarm. There is no less engineering work in the age of AI. There is more, and the impact per engineer is bigger.

Closing thought

The old days of engineers who just write code are ending quickly. Historically, our profession was always about finding our way in new contexts, changes and unknowns. That is the job we are paid for.

Tools will keep getting better at the "how". That makes the "who" more important. The engineers who matter most will be the ones who can say "this is mine" and then make sure it happens, end to end. Is it just "project management"? They share some (but not all) aspects: planning, tracking progress, communication with stakeholders. The difference is what they are. Project management is a process and usually a role, with budgets, resources and timelines. The DRP is a rule about ownership: one deliverable, one named person who is accountable for the result. You don't need a title or a team to be one, and it works for small deliverables as well as large projects.

If you are an engineer who likes well-defined tickets, with everything you need to do served on a plate, you likely won't enjoy the DRP. If you want autonomy and like to take care of a goal, then DRP is for you. The main benefit is clarity of ownership, so a project doesn't stall because everybody assumed somebody else was on it.

People can ask for a status at any moment, and the DRP always knows what's going on, or whom to ask. One more thing matters to me. A DRP doesn't just connect people and tell them to figure it out. A DRP makes sure it happened, and checks.

I deliberately kept the guidelines short and didn't elaborate on each point. They are a reminder of what to think about when you are a DRP, not a checklist of chores. When you prescribe every step, you get a false sense of progress and less room for ideas and engagement. I'd rather give the principles and let engineers choose and work out how to use them.

What a DRP does

These are the guidelines, in short:

• Agree on the success criteria with stakeholders and write them down. This is your best protection against scope creep. "Why are we doing this, and how will we know that it is successfully done (success criteria)?" should always have a clear answer, and the closer the answer is to customer experience and the business, the better.
• Agree on the priority and communicate it, so everyone knows what comes first. Know where your project stands on the scale of company priorities.
• Find and involve all relevant stakeholders early, in planning, for example: platform, operations, testing, security, legal, product, finance, UX. The later you involve a stakeholder, the more risk you create.
• One shared place for communication, one place for documentation. Don't segment communication, but make it easy. You never know which colleague you'll need in the conversation next. Keep it easy to follow. The best setup uses company-public Slack or Teams channels (avoid "secret channels").
• Plan and drive the breakdown of the work across dependent teams, and map the dependencies. On a big project you can't do it all yourself, but the plan is on you (involve people), and the quality of the plan often decides how the project ends.
• Track progress, and keep it simple and transparent. I recommend only two statuses: green (on track) and red (not going well). The goal is to detect delays and obstacles as early as possible. Some people add yellow for at risk. That works too, but green and red force a clear call.
• Inform people proactively when scope, priority or obstacles change, and keep reporting predictable. Don't count on others to notice a message. If your stakeholders haven't heard from you in a while, or if they always ask you for updates, that is a bad sign.
• Ask for help early, and escalate early. Don't wait for problems to appear and have courage to escalate.
• Give credit. Mention the people who contributed. Be fair. That is alhow you build enthusiasm and allies for your next project.
• Name the risks early. Ask what could go wrong, write it down, and say who owns each risk.

None of this is rocket science. The hard part is that somebody has to do it, consistently. That is what a clear owner is for.

Do you need authority to be a DRP?

No, you don't need to be a manager. If a decision is outside your scope, involve and ask the decision makers. Your job is to bring clarity and people together around the same goal. Some of the best DRPs I've seen were junior engineers, with more impact than their senior colleagues.

Coding is no longer the bottleneck

For a long time, the scarce skill in software engineering was writing working code. We organized teams, hired and promoted around it.

AI is changing that quickly. I use Claude and other AI tools every day. Boilerplate, tests, scripts and first drafts are cheap, understanding parts of unfamiliar codebase takes way less time than before, and the distance between "I have an idea" and "I have something running" has collapsed.

If AI helps you write the code and the tests, then "I only do the coding part" is no longer a reason to stop where your task ends.

For some people that is frustrating, because the fun of writing code by hand is fading, but that is the future (and already happens in many teams). Orchestrating agents, gathering insights, working with stakeholders and making decisions in the company's best interest are the new engineering.

What this means for managers

Juniors used to learn slowly (compared to today's standards when information is easily accessible) one small task at a time, but AI now answers most "I'm not expected to know this yet" questions in seconds. Being new is no longer a reason not to own at least a small outcome.

Managers can use the DRP for upskilling and as a signal of engagement, and letting someone be the DRP of a small but real deliverable is probably the best way to grow them. In another article on engineer's seniority I listed "delivery and ownership" as the first pillar of seniority, and today it is the entry ticket.

How to start

If you are an engineer who wants to try to be a DRP, or a manager who wants to grow your reports, you can start immediately. You don't need a big process change.

For a DRP:

• Pick one small piece of work and put one name next to it. If you can't name anyone, that's already useful information.
• If the name is yours, write down in a few sentences what success means, who needs to be involved, and what could go wrong.
• Use AI to widen your reach, not to shrink your accountability. Let it help with the unfamiliar parts, and keep yourself responsible for the whole.
• If you lead a team, say it out loud. Don't assume engineers know they're expected to own the outcome. Tell them which outcomes each of them owns, and give them the room and authority to do it.

Being good at DRP is a matter of practice. Starting small and growing is normal. Stagnation is a reason for alarm. Because, there is no less engineering work in the age of AI, there is actually more work and bigger impact per engineer.

Closing thought

The old days of engineers who just write code are ending quickly. Historically our engineering profession was always about being able to find our ways in new context, changes, and unknowns. That is the actual job we are getting paid for.

Tools will keep getting better at the "how". That makes the "who" more important. The engineers who matter most will be the ones who can say "this is mine" and then make sure it happens, end to end.

If you are an engineer who likes well-defined tickets, with everything you need to do served on a plate, you likely won't enjoy the DRP. If you want autonomy and like to take care of a goal, then DRP is for you. The main benefit is clarity of ownership, so a project doesn't stall because everybody assumed somebody else was on it.

People can ask for a status at any moment, and the DRP always knows what's going on, or whom to ask. One more thing matters to me. A DRP doesn't just connect people and tell them to figure it out. A DRP makes sure it happened, and checks.

I deliberately kept the guidelines short. I don't elaborate on each point. They are a reminder of what to think about when you are a DRP, not a checklist of chores. When you prescribe every step, you get a false sense of progress and less room for ideas and engagement. I'd rather give the principles and let engineers work out how to use them.

What a DRP does

These are the guidelines, in short:

• Agree on the success criteria with stakeholders and write them down. This is your best protection against scope creep. "Why are we doing this, and how will we know that it is successfully done?" should always have a clear answer, and the closer the answer is to customer experience and the business, the better.
• Agree on the priority and communicate it, so everyone knows what comes first.
• Find and involve all relevant stakeholders early, in planning: platform, operations, testing, security, legal, product, finance, UX. The later you involve someone, the more risk you create.
• One shared place for communication, one place for documentation. Don't segment communication, and don't make people ask for access. You never know which colleague you'll need in the conversation next. Keep it easy to follow. The best setup is one public Slack or Teams channel per project.
• Plan and drive the breakdown of the work across dependent teams, and map the dependencies. On a big project you can't do it all yourself, but the plan is on you, and the quality of the plan often decides how the project ends.
• Track progress, and keep it simple and transparent. I recommend only two statuses: green (on track) and red (not going well). The goal is to detect delays and obstacles as early as possible. Some people add yellow for at risk. That works too, but green and red force a clear call.
• Inform people proactively when scope, priority or obstacles change, and keep reporting predictable. Don't count on others to notice a message. If your stakeholders haven't heard from you in a while, or if they always ask you for updates, that is a bad sign.
• Ask for help early, and escalate early. The DRP is usually the person who knows the project best, so escalating is their job. Don't wait.
• Give credit. Mention the people who contributed. Be fair. That is how you build enthusiasm and allies for your next project.
• Name the risks early. Ask what could go wrong, write it down, and say who owns each risk.

None of this is rocket science. The hard part is that somebody has to do it, consistently. That is what a clear owner is for.

Do you need authority to be a DRP?

No, you don't need to be a manager. If a decision is outside your scope, escalate it to the decision makers. Your job is to bring people together around the same goal. Some of the best DRPs I've seen were junior engineers, with more impact than their senior colleagues.

Coding is no longer the bottleneck

For a long time, the scarce skill in software engineering was writing working code. We organized teams, hired and promoted around it.

AI is changing that quickly. I use Claude and other AI tools every day. Boilerplate, tests, scripts and first drafts are cheap, understanding an unfamiliar codebase takes minutes instead of days, and the distance between "I have an idea" and "I have something running" has collapsed.

What's left is everything around the code, which is what the DRP guidelines above cover. The questions become:

• Did we solve the right problem, and how will we know?
• Are the right people involved, and informed when things change?
• Is it shipped, monitored and documented?
• Who will fix it when it breaks, and will they know how?

Someone has to hold all of that together. Increasingly, it's the engineer. Not to pile more on them, but because the handoffs between separate roles are disappearing. If AI helps you write the code, the tests, the pipeline configuration, the runbook and the release notes, then "I only do the coding part" is no longer a reason to stop where your task ends.

For some people that is frustrating, because the fun of writing code by hand is fading. Orchestrating agents, gathering insights, working with stakeholders and making decisions in the company's best interest are the new engineering.

What this means for juniors

This part may be uncomfortable. The junior role as we knew it is going away.

Junior used to mean taking a small, well-defined task, implementing it, asking for help when stuck, and slowly learning the bigger picture over years. A lot of that learning happened through slow onboarding, being shown things one at a time, and doing the parts of the job others didn't have time for.

AI now helps at every one of those steps, from the first day of onboarding (explain this service, show me how it's deployed, why does this test fail) to the last (draft the write-up). The part of the junior role that was "I'm not expected to know this yet" is shrinking, because the answer is one question away.

That doesn't mean there's no room for people early in their career. It means the expectations start somewhere else, and being new is no longer a reason not to own an outcome.

Managers can use the DRP for upskilling and as a signal of engagement. Letting someone be the DRP of a small but real deliverable is probably the best way to grow them, and with AI as a patient teacher they can take that responsibility much earlier than we used to think. In my article on engineer's seniority I listed "delivery and ownership" as the first pillar of seniority, and today it is the entry ticket.

What stays human

AI doesn't own anything. It can't be held accountable, and it doesn't carry the consequences when something goes wrong. It also doesn't know what is never written down: who really decides, when priorities shift and why, what other teams are measured on, what people want from their careers, or whether now is a good moment to ask. That context comes from people, and a DRP has to collect it. AI will produce an answer whether or not the question was the right one.

So the DRP matters more, not less:

1. Someone must define "done". AI will happily produce things; a person decides what success looks like.
2. Someone must verify. Generated code, analysis and plans all need an owner who will stand behind them. "The AI wrote it" is not an answer.
3. Someone must make sure it happened. Not connect people and hope, but check and help colleagues.
4. Someone must stay for the long run. In my article on the total cost of owning a feature I wrote about "we build it, we own it". When building gets cheaper we will build more, and the cost of owning all of it becomes the real constraint. Without clear owners, cheap code becomes expensive, orphaned maintenance.

How to start

You don't need a big process change.

• Pick one small piece of work and put one name next to it. If you can't name anyone, that's already useful information.
• If the name is yours, write down in a few sentences what success means, who needs to be involved, and what could go wrong. Ask your AI assistant to challenge it, then agree on it with your stakeholders.
• Use AI to widen your reach, not to shrink your accountability. Let it help with the unfamiliar parts, and keep the responsibility for the whole.
• If you lead a team, say it out loud. Don't assume engineers know they're expected to own the outcome. Tell them, and give them the room and authority to do it.

Closing thought

Tools will keep getting better at the "how". That makes the "who" more important. The engineers who matter most will be the ones who can say "this is mine" and then make sure it happens, end to end.

That's all the DRP is: a way to make that sentence normal.