Observations on Ownership
Hey!
Welcome back to another week of musings. We're done with the NFL Football season, and the Eagles won the Superbowl.
Anyhow, I hope you had a restorative weekend and spend some quality time with your loved ones.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
I've been watching LeadDev's youtube channel, if you're interested in that kind of topic. If you want to get a sample, I recommend watching some of the episodes from their podcast.
I was recently catching up on Kubernetes current state of things, and came across this article: Cloud vs. On-Prem: Which Is Better for Your Kubernetes Cluster?
Observations on ownership
Since becoming a staff engineer, I've been constantly thinking about ownership. I also coach other people to understand what's needed to achieve the staff engineer level, what that means for their current level of ownership, and what would be expected at higher levels.
Generally, when you read about ownership, someone will say, "If you're wondering who should be doing this, that would be you."
Ownership and Level
Even junior engineers are expected to own something. At the starting level, this might mean owning the assigned task. If you have questions, raise your hand; if you're blocked, notify your manager, etc.
But once you go beyond your tasks and into the realm of your team projects or cross-organizational projects, ownership becomes both large in scale and abstract in the sense that not everyone will point out what's needed or missing. Instead, you must pick up cues or reach out to teams to determine their needs.
Ownership and Pragmatism
If you've read the book Extreme Ownership, you'll know that its idea of ownership goes beyond what's logical for one person to own. This mainly means that there's always something we could have done to prevent a failure; if not, we should own that failure.
I like the sentiment of that thought, but on the flip side, there's a level of pragmatism when it comes to owning things, especially if you're in more junior positions. You might get burned out or disappointed if you lack the leverage to effect change.
Ownership and ego
We generally think of ownership in terms of picking up tasks, making sure a project is successful, etc., but it also means owning up to the misses and failures of things being done by you or your team.
Ownership comes at the cost of ego. You must accept your and your teammates' failures without shifting blame to anyone else.
Ownership After Layoffs
With the number of re-organizations and layoffs occurring, teams have been more cognizant of reducing the amount of things they own or are accountable for. This affects when you need to do cross-organizational large programs, only to discover that some crucial piece of software is either in maintenance mode or abandoned because whatever original members created it have moved on.
It's expected that teams will reduce the scope of ownership to protect themselves, but we're left with the choice of taking over things without clear ownership or letting upper management handle that.
Unmet Ownership expectations
Dealing with teams that don't want to make themselves owners of a more extensive scope means we have to deal with the side-effect of owning the pieces they don't. That might imply contacting teams, asking for updates, keeping tabs on cross-functional teams, etc. It also means that every interaction with this team either needs to have an expectations meeting before a project or, from the get-go, manage them instead of delegating an aspect of a project.
Your Turn
Have you ever thought about your scope of ownership? Have you ever wanted to increase or decrease it? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others