How To Take Ownership - Dev Leader Weekly 80
TL; DR:
Exclusive Article: How To Take Ownership
I wanted to write this article in a slightly different format so that I could share some stories with you. I can't wait to tell you about my most recent screw-up that has everything to do with taking ownership -- but first, we'll dive into what this topic is all about.
What Is Ownership And Why You Should Care
Ownership is all about responsibility and accountability. As you're growing in experience as a software engineer, you'll start to hear these words come up more and more frequently.
As more junior developers, we're often working through less complex problems that have a (relatively) understood scope. That's not to say the tasks are easy, but they are often less complex with fewer moving parts in them -- and this way juniors can have a better chance of success.
As engineers work through mid-level and senior roles, the work becomes more complex:
There are more things that could go wrong, delay, interrupt, or otherwise complicate your ability to deliver on a project -- and this is exactly where ownership comes in.
If you've been assigned a project and your manager is expecting you to see it through to completion, they want to trust in you to get it done. That means that you'll often find yourself in tricky situations because other moving parts that seem out of your control are getting in the way of you making progress.
In order to demonstrate ownership, this means that you won't settle for things interfering with your ability to deliver. There will always be challenges and setbacks, but you won't place blame or accountability on others and allow your project to be completely compromised.
Instead, you get creative. You get resourceful. There might be situations where you have to do additional work or unplanned work -- perhaps work that you were counting on others to do. However, the goal is to be responsible for seeing the project through to completion.
People want to build teams of engineers that take ownership. When you can trust that engineers on the team take responsibility, accountability, and demonstrate ownership, then you can trust that things will get done.
But now it's story time.
Principal Failure
I wanted to talk about a story of failure of ownership -- but no, this isn't my most recent mess up. That comes later. This one is a story from earlier in my time at Microsoft, and I think it has a happy ending at least.
I was tasked with representing my team to work on a cross-organization project. There were lots of teams involved, each helping take on an aspect of the project that they'd need to drive forward so that it wasn't centrally owned by one team.
I worked with my project manager on this, and we had to get partner teams to agree on a path forward. This meant that we needed sign-off on designs and a plan that would work for each time participating in this area -- but getting people to align was tough. My project manager was leading this aspect because it was a great fit to have PM support work across teams on this. Finally, at the time we seemed to reach consensus, my project manager had to head to another team and it was time for implementation to start. (Disclaimer: no hard feelings with the PM -- he was great to work with)
When our engineers had wrapped up the work we agreed on, we realized there was a problem. Other teams seemed to disagree that this was the solution, despite us all getting on the same page. But isn't that what we spent all the time agreeing on before?
We were back at square one. I was frustrated. I wanted to blame the other teams. I wanted to blame my PM (even though I know he worked through getting people aligned). I wanted to blame everyone but myself, because everyone else had participated and agreed.
The problem was that I was the owner of that part of the project and I wasn't owning a damn thing. At that point, I had all eyes on me for why it WASN'T coming together, and I was sitting there feeling like it was everyone else's fault.
So it was time to change.
I spent the next months (literally) building back up relationships across teams. Getting the right stakeholders involved. Making sure partner teams were educated about interdependencies that we weren't all aware of before. I needed to find a path forward.
Ultimately, this took finding additional stakeholders on partner teams that could also help take ownership. I had to find individuals I could hold accountable for deliverables, and then I had to make sure:
By the time I had to walk away from that project, I felt it had completely turned around. I had feedback from other managers and principals that things felt much better. I even had a partner team member in the office call me out for helping turn that work around.
It was a ridiculous amount of extra work. It was frustrating. But it mostly felt this way because I was expecting others to do things without setting clear structure for accountability. If you want to hear more about that and another real (but generalized) example, you can check out my video that I posted on Code Commute :
So, I Messed Up.
Alright, now the juicy scoop you've been waiting for. I screwed up pretty badly in a project that I need to own-- I failed at accomplishing my first milestone.
To be clear, I use the word "fail" on purpose and I don't use it to mean it's the end of the road. I treat all of my failures as learning opportunities, but I use that word because I don't want to be afraid of failures and I want to encourage others to embrace failures too. So if it sounds like I'm being hard on myself, I view it as just being real about the expectations and it's a learning opportunity for me as well -- not something that will haunt me forever.
I'm heading up a big project at work, and it requires that I'm coordinating between dozens of engineers across several teams. We scoped out all of the work. The engineers are making progress on things. I feel pretty good about it -- it's stressful because it's A LOT, but I feel good that I have great engineers to work with and I can trust.
The first big milestone is presenting the project status to leadership. Given my role in the project, it makes sense for it to be my responsibility to own presenting this. I need to be the owner of it as I need it to be successful for the project to be successful.
So I coordinated getting things ready to present. I answered the questions on the details asynchronously. And when it came time to meet, the feedback was straightforward.
I failed. I wasn't able to clearly articulate how all of our efforts align to the objectives we agreed on. Instead, it felt like a list of work with no cohesive goals.
Ouch.
Getting feedback like this is hard -- and not because it was delivered in a mean or angry way. It's hard because I did try to do a good job. I did think I was doing what I needed to do.
But I missed the mark.
The good news is, the feedback was given very clearly. We knew what needed to change for the next time. And as for ownership?
In fact, for some owners that haven't had as much time, I've even volunteered to do their parts initially so that we can derisk the delivery. Yes, this means "extra" work for me. But I already had one failed attempt at this, and I need to demonstrate ownership that I will see the second attempt be successful.
That means getting creative. That means it might be more work. That means not accepting excuses to see it through to completion.
Wrapping It Up
While the specific details of my stories aren't really that important for you, I wanted to share them because being accountable, being responsible, and taking ownership are all things that become expected of you as you become more experienced in your role.
If you've started to hear this feedback from your manager and don't really understand it, perhaps you can see it in my stories. How did I go from not being fully accountable to trying to take additional steps to ensure I could own the success of the project?
If we move away from being passive, move away from excuses, move away from blaming people... Yes, it might feel like more work. It might feel unfair in some cases. But you get to be in the driver seat and be responsible for making positive change.
领英推荐
Weekly Recap
How To Escape TUTORIAL HELL As A Software Developer
Nothin' wrong with reading articles and watching tutorials... Until you find yourself stuck in tutorial hell!
Let's discuss how to get out.
Fusion Cache in C# - Removal, Expiration, and FailSafe Cache Operations
Fusion Cache is an awesome third-party package that we can use in DotNet for both in-memory and distributed caches.
Let's dive into how the removal and expiration of cache entries work alongside the fail-safe mechanism!
AI Advancements: Machine Learning Is DONE FOR! (or is it?)
Someone wrote in to ask for advice regarding the start of their career given their focus on machine learning given all of the AI advancements. Are they done for, or is there a bright future ahead?
Zuckerberg On Rogan - Software Engineers OBSOLETE Or Augmented?
I did finally watch the Mark Zuckerberg and Joe Rogan podcast episode. Everyone has been spreading fear, but I agree with a lot of what Zuck had to say.
The FASTEST Way From Junior To Senior Developer (doesn't exist)
Everyone is looking for efficient paths forward -- so what is the most efficient way to go from a junior developer to a senior developer?
Well, it depends.
AI Replacing Mid-Level Engineers - Principal Software Engineering Manager AMA
The Mark Zuckerberg announcement about AI replacing mid-level engineers has developers spooked -- and every week there's one more reason programmers seem to have something new to be afraid of.
But what was his actual statement and should developers just give up now? Let's discuss.
As with all livestreams, I'm looking forward to answering YOUR questions! So join me live and ask in the chat, or you can comment now and I can try to get it answered while I stream.
TOP STRUGGLES Of Junior Developers And Interns
A viewer asked for thoughts on common challenges that early-in-career developers face when getting started. I've worked with many, and I'm happy to share some common patterns!
Thief Of Joy: Comparing Yourself With Other Software Engineers
A viewer wrote in to describe how they don't feel they're making progress at the same rate as their classmates. As developers, how should we approach this?
DREAM JOB As A Software Engineer But... I'm Stagnating!
A software developer seemingly had a dream job BUT... they were worried that they were stagnating in their career. How should they move forward?
Waste Of Time For Developers?! Is College Or University Worth It?
A viewer wrote in to ask about how to balance their efforts when it comes to learning to be a software developer -- but are college and university even worth it for the course material?
At A Crossroad: Software Development Or Other IT Role Instead?
A viewer wrote in to ask about their upcoming dilemma: Do they try to pursue a software development role since they enjoy programming? Or should they stick to the type of non-programmer IT role that they've been enjoying?
As always, thanks so much for your support! I hope you enjoyed this issue, and I'll see you next week.
Nick “Dev Leader” Cosentino [email protected] Socials: – Blog – Dev Leader YouTube – Follow on LinkedIn – Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!
Java ? Spring ?? TS/React ?? | Craft, Care & Ownership
1 个月Just read it and highly recommend! I liked that you also mentioned not beating ourselves down because of a mistake/failure. For me, learning to take ownership, actually internalize it was the first step. The next was to learn being calm and level headed, stop apologizing and only focus on stating the facts and options for solving the situation. When I understood that my tendency to say how bad I felt about it and how sorry I was only made things worse, was annoying af and was sabotaging my goal of building trust . I am pretty sure I built the most trust from my team and client during the aftermath of one unfortunate data migration that didn't go exactly as planned...?? In short, acting like an adult really helped