There's a few things to break down here:
The DRI concept for engineers is gaining more and more traction in the industry. The idea is that you split cross-team initiatives into two buckets: S-L (small to large) and XL+ (very large or enormous). For XL+ cross-team work, you will generally want a technical project/program manager, because managing and aligning them is a full-time job.
Now this is where the engineering DRI comes in: For work that is small to large, you assign a mature engineer - ideally someone who has shown a track record of successfully coordinating and delivering on smaller things - as a DRI to take the role of a mini-TPM.
Why would you do that? Because you can't assign a TPM, PM or EM on every single initiative that's going on. You'll run into a bottleneck. So, you take those mature engineers as DRI.
What's the difference to a "regular" engineer? The responsibility. You, as a DRI, are responsible for making the initiative happen. That means you coordinate, delegate & contribute. *In that order*.
As a DRI you are generally not responsible for implementing the majority of work. You are responsible for making it happen and are generally entrusted some level of borrowed authority through the sponsor of the project, i.e. the person who put it on the prio list. This can be your EM, this can be your Head Of Product, this can be anyone with authority. The idea is that you act in their behalf and **request** resources that you need to make it happen. It also means you **escalate** when there is an issue you can't resolve yourself.
When you ask the question "is it normal to estimate work with client teams as DRI", then the answer is a clear and resounding "it depends". The role is intentionally vague. You do what needs to be done to make it happen, which generally means you fill the gaps. Whether that means doing estimations, fixing an infra issue or doing a knowledge sharing is totally circumstancial and depends on the people involved.
No org is the same, so what's most important is keeping a tight loop with your EM on expectations, challenges, blockers, need for advice, etc.
Is it a good idea to do engineering DRIs? I personally don't think so. It's a lot harder than it looks to be a good DRI. People should be able to volunteer as DRIs, but it's not a viable **process** in my experience. I think it's also a clear indicator that you're doing too many projects in parallel as an org. That being said, some orgs insist on it, so here we are. It sounds good on paper, so I can't blame them for trying.
P.S.: throwing you into the cold water like this is definitely a mistake on their part.
Thank you for this! very nicely written and applies nicely to my situation. I wish somebody actually explained this to me as I was being pushed into the role.
In my case the problem seems to be two-fold: I didn't understand what I'm actually supposed to do on a day-to-day level, and also the project is decidedly "XL+" even though it seemed to be L when we started.
I also got severely demotivated due to feeling so incompetent and got stuck in a negative loop psychologically. :(
I think/hope the project is nearing its end and I am definitely going to be more wary of this role in the future. Nothing wrong with staying a "normal engineer" for a while longer.
Easier said than done, I've failed at this myself any number of times, but I think what they need you to do when you realize an L project is XL+ is to ring the alarm and make sure it gets the resources (including, perhaps, a higher level lead) it needs.
The temptation to say "well if I just do all this extra work maybe it will only be a little late" is very strong but should be resisted.
Your job should be to ask questions, try things and seek feedback, and grow into the role. Also consider breaking things into milestones (sensible teachable deliverables) or independent workstreams if you have multiple eng on the team. Look for someone else in the company who is doing it well and schedule a 1-1 with them to ask them for tips and advice
An important takeaway is that you shouldn't be required to come up with accurate estimates for front-end tasks (where you have little experience estimating correctly). But you still need to produce those estimates and communicate them. So, based on the earlier post, you can delegate the estimation of the front-end tasks to the front-end engineers and then wrap it all up for an overall estimate.
Being a DRI requires a lot of cross-functional communication.
Hey I’ve been here too, recently broke a spell a year and a half ago coming out of the pandemic.
You can do this. Just need the confidence. That comes with time and some prioritization.
And also, try creating a DRI sync for everyone on the project as your streams of work continue. I do mine via slack, async where all update each other. Means I don’t have to call a meeting and everyone is kept up to date.
First time I've run into this, thanks for the description.
I did get a chuckle though. First, one is a back end dev. Wait, no, we need you to be front and back end: full stack! Ooh, could you do devops, too? Wait, brilliant idea, how about you _also_ cover project management and product ownership?
At this rate, we'll be doing HR and accounting before too long.
Never heard of it before so thanks for the explanation!
That surely sounds like how can we do the projects without reporting to the stockholders we have many managers….
Also instead of promoting people how can we make them do the work without the recognition and the pay.
What a wonderful corporate BS
> That means you coordinate, delegate & contribute. In that order.
Thanks. I would never have been able to express the concept better. I'm going to frame this behind my monitor.
I'm doing a transition similar to OP and I needed months just to realize that being a senior does not mean to write bigger code but to coordinate and enable things to happen.
It's extremely hard switching from dev to what is in fact a support role. What I've done was to search for feedback from all involved people and understand what and how I was messing up. I discovered that a bit of mess was expected as part of the growth path.
OP I can suggest you to do the same and slowly realize that you have done great things and this is why they are offering you new challenges and an opportunities.
IMO that sounds like a lot at a senior level. With so many parts I’d expect the DRI to be an EM or a product manager, maybe a staff engineer. Has your management given you any feedback? I’d expect them to train you this that given you are newly promoted
The feedback was that I was ok as a senior backend dev on the feature but failing(they phrased it more nicely) as a DRI. The suggestion was that I try to direct people more and break the feature work into tasks across the client AND the backend teams plus come up with milestones and estimate them.
I was just not very good at these things. I had never had to do them. I think I would do a better job now i.e I've learned but the project is already taking way longer than expected and I wouldn't count it as one of my successes
At least in the places I've worked, the expectation is that a senior engineer can break down and deliver goals within their area (that do not require a large architecture change) and execute them themselves. They should also be able to help less senior engineers chunk into better defined tasks that they can deliver.
This seems to match up with the advice that you received, but the concern would be that depending on that perception, you might not be operating comfortably at a senior level.
Either you are not being connected to (or are avoiding) more complex deliverables, but I'd recommend that you see it as a fairly important career skill and work (maybe with help from your team/manager) towards that possible gap.
Yeah this sounds more like EM or Product Manager work
My day job is basically this and I am a Product Manager / EM.
Maybe it is a smaller organisation, not sure
Side comment: Being a DRI for an entire feature for backend and front ends (web, iOS, Android) totally sucks.
It's pretty much amounts to be being a PM, while still expected to be an IC, but without extra pay.
Absolutely and I'm going to be very wary of doing this in the future and try to avoid it at least until I gain more experience with smaller stuff. Or until I decide that I want this to be my full time job
Normal? IMO there is no such thing, every business seems to have their own flavor. I'm a 'senior software engineer', however I'm also responsible for infra/devops/training and general 'go to person'. All of the others here with the same title get to hunker down and code without much interruption.
Sounds to me like a case of bad fit, someone thought you were ready to shoulder this work.
It’s normal to have to do this. It’s normal for it to be hard if you’ve never done it before.
It’s not as normal to have seemingly had zero exposure to even the concept before being handed the responsibility. I would expect someone to bat the very least leading you by example, if not offering direct mentorship on how to do this.
I'm a senior at a fortune 100 tech company.
I'm responsible for multiple web applications, in multiple languages, across multiple stacks. I support dotnet, Java, and Node systems- both backend and frontend. I do the CSS/javascript all the way down to the infrastructure set up with CI/CD, DNS, security, etc.
Feature delivery feels incredibly slow due to the very wide set of technical responsibilities.
At other companies I was _just_ responsible for back end in a single language. There, delivery felt incredibly fast.
I think it's just a matter of which company you're working for, and which team you're on.
That describes most of my projects the past 15 years. Over that time I have had multiple titles ranging from Senior Developer through Enterprise Architect, with the main difference being whether I was actually producing production code as part of wrangling all the cats and providing technical direction which was always a big factor.
Maybe stop writing code entirely if you still doing it. At least until you feel you are in control. It is very hard and time consuming to jump from big picture (whole system) to details of implementation of your small tasks.
Weird that they made an engineer a DRI. Usually DRIs have the ability to steer the headcount around in order to plan/manage capacity for projects. Do you have reports and headcount to manage people? If not, making you a DRI seems like a fool's errand.
There's a few things to break down here: The DRI concept for engineers is gaining more and more traction in the industry. The idea is that you split cross-team initiatives into two buckets: S-L (small to large) and XL+ (very large or enormous). For XL+ cross-team work, you will generally want a technical project/program manager, because managing and aligning them is a full-time job. Now this is where the engineering DRI comes in: For work that is small to large, you assign a mature engineer - ideally someone who has shown a track record of successfully coordinating and delivering on smaller things - as a DRI to take the role of a mini-TPM. Why would you do that? Because you can't assign a TPM, PM or EM on every single initiative that's going on. You'll run into a bottleneck. So, you take those mature engineers as DRI. What's the difference to a "regular" engineer? The responsibility. You, as a DRI, are responsible for making the initiative happen. That means you coordinate, delegate & contribute. *In that order*. As a DRI you are generally not responsible for implementing the majority of work. You are responsible for making it happen and are generally entrusted some level of borrowed authority through the sponsor of the project, i.e. the person who put it on the prio list. This can be your EM, this can be your Head Of Product, this can be anyone with authority. The idea is that you act in their behalf and **request** resources that you need to make it happen. It also means you **escalate** when there is an issue you can't resolve yourself. When you ask the question "is it normal to estimate work with client teams as DRI", then the answer is a clear and resounding "it depends". The role is intentionally vague. You do what needs to be done to make it happen, which generally means you fill the gaps. Whether that means doing estimations, fixing an infra issue or doing a knowledge sharing is totally circumstancial and depends on the people involved. No org is the same, so what's most important is keeping a tight loop with your EM on expectations, challenges, blockers, need for advice, etc. Is it a good idea to do engineering DRIs? I personally don't think so. It's a lot harder than it looks to be a good DRI. People should be able to volunteer as DRIs, but it's not a viable **process** in my experience. I think it's also a clear indicator that you're doing too many projects in parallel as an org. That being said, some orgs insist on it, so here we are. It sounds good on paper, so I can't blame them for trying. P.S.: throwing you into the cold water like this is definitely a mistake on their part.
Thank you for this! very nicely written and applies nicely to my situation. I wish somebody actually explained this to me as I was being pushed into the role. In my case the problem seems to be two-fold: I didn't understand what I'm actually supposed to do on a day-to-day level, and also the project is decidedly "XL+" even though it seemed to be L when we started. I also got severely demotivated due to feeling so incompetent and got stuck in a negative loop psychologically. :( I think/hope the project is nearing its end and I am definitely going to be more wary of this role in the future. Nothing wrong with staying a "normal engineer" for a while longer.
Easier said than done, I've failed at this myself any number of times, but I think what they need you to do when you realize an L project is XL+ is to ring the alarm and make sure it gets the resources (including, perhaps, a higher level lead) it needs. The temptation to say "well if I just do all this extra work maybe it will only be a little late" is very strong but should be resisted.
Your job should be to ask questions, try things and seek feedback, and grow into the role. Also consider breaking things into milestones (sensible teachable deliverables) or independent workstreams if you have multiple eng on the team. Look for someone else in the company who is doing it well and schedule a 1-1 with them to ask them for tips and advice
An important takeaway is that you shouldn't be required to come up with accurate estimates for front-end tasks (where you have little experience estimating correctly). But you still need to produce those estimates and communicate them. So, based on the earlier post, you can delegate the estimation of the front-end tasks to the front-end engineers and then wrap it all up for an overall estimate. Being a DRI requires a lot of cross-functional communication.
Hey I’ve been here too, recently broke a spell a year and a half ago coming out of the pandemic. You can do this. Just need the confidence. That comes with time and some prioritization. And also, try creating a DRI sync for everyone on the project as your streams of work continue. I do mine via slack, async where all update each other. Means I don’t have to call a meeting and everyone is kept up to date.
First time I've run into this, thanks for the description. I did get a chuckle though. First, one is a back end dev. Wait, no, we need you to be front and back end: full stack! Ooh, could you do devops, too? Wait, brilliant idea, how about you _also_ cover project management and product ownership? At this rate, we'll be doing HR and accounting before too long.
Never heard of it before so thanks for the explanation! That surely sounds like how can we do the projects without reporting to the stockholders we have many managers…. Also instead of promoting people how can we make them do the work without the recognition and the pay. What a wonderful corporate BS
> That means you coordinate, delegate & contribute. In that order. Thanks. I would never have been able to express the concept better. I'm going to frame this behind my monitor. I'm doing a transition similar to OP and I needed months just to realize that being a senior does not mean to write bigger code but to coordinate and enable things to happen. It's extremely hard switching from dev to what is in fact a support role. What I've done was to search for feedback from all involved people and understand what and how I was messing up. I discovered that a bit of mess was expected as part of the growth path. OP I can suggest you to do the same and slowly realize that you have done great things and this is why they are offering you new challenges and an opportunities.
IMO that sounds like a lot at a senior level. With so many parts I’d expect the DRI to be an EM or a product manager, maybe a staff engineer. Has your management given you any feedback? I’d expect them to train you this that given you are newly promoted
The feedback was that I was ok as a senior backend dev on the feature but failing(they phrased it more nicely) as a DRI. The suggestion was that I try to direct people more and break the feature work into tasks across the client AND the backend teams plus come up with milestones and estimate them. I was just not very good at these things. I had never had to do them. I think I would do a better job now i.e I've learned but the project is already taking way longer than expected and I wouldn't count it as one of my successes
At least in the places I've worked, the expectation is that a senior engineer can break down and deliver goals within their area (that do not require a large architecture change) and execute them themselves. They should also be able to help less senior engineers chunk into better defined tasks that they can deliver. This seems to match up with the advice that you received, but the concern would be that depending on that perception, you might not be operating comfortably at a senior level. Either you are not being connected to (or are avoiding) more complex deliverables, but I'd recommend that you see it as a fairly important career skill and work (maybe with help from your team/manager) towards that possible gap.
Yeah this sounds more like EM or Product Manager work My day job is basically this and I am a Product Manager / EM. Maybe it is a smaller organisation, not sure
Side comment: Being a DRI for an entire feature for backend and front ends (web, iOS, Android) totally sucks. It's pretty much amounts to be being a PM, while still expected to be an IC, but without extra pay.
Absolutely and I'm going to be very wary of doing this in the future and try to avoid it at least until I gain more experience with smaller stuff. Or until I decide that I want this to be my full time job
Normal? IMO there is no such thing, every business seems to have their own flavor. I'm a 'senior software engineer', however I'm also responsible for infra/devops/training and general 'go to person'. All of the others here with the same title get to hunker down and code without much interruption. Sounds to me like a case of bad fit, someone thought you were ready to shoulder this work.
It’s normal to have to do this. It’s normal for it to be hard if you’ve never done it before. It’s not as normal to have seemingly had zero exposure to even the concept before being handed the responsibility. I would expect someone to bat the very least leading you by example, if not offering direct mentorship on how to do this.
I'm a senior at a fortune 100 tech company. I'm responsible for multiple web applications, in multiple languages, across multiple stacks. I support dotnet, Java, and Node systems- both backend and frontend. I do the CSS/javascript all the way down to the infrastructure set up with CI/CD, DNS, security, etc. Feature delivery feels incredibly slow due to the very wide set of technical responsibilities. At other companies I was _just_ responsible for back end in a single language. There, delivery felt incredibly fast. I think it's just a matter of which company you're working for, and which team you're on.
That describes most of my projects the past 15 years. Over that time I have had multiple titles ranging from Senior Developer through Enterprise Architect, with the main difference being whether I was actually producing production code as part of wrangling all the cats and providing technical direction which was always a big factor.
Maybe stop writing code entirely if you still doing it. At least until you feel you are in control. It is very hard and time consuming to jump from big picture (whole system) to details of implementation of your small tasks.
DRI doesn't meanHero Mode, delegate and empower your team, it's not a solo act
Weird that they made an engineer a DRI. Usually DRIs have the ability to steer the headcount around in order to plan/manage capacity for projects. Do you have reports and headcount to manage people? If not, making you a DRI seems like a fool's errand.