Ownership
Ownership
Hello!
Welcome to another week of this newsletter. For the past couple of weeks, I've been thinking of challenging myself by doing a daily newsletter. Doing daily newsletters seems like a lot, but also I've been reading "Show your work" by Austin Kleon, which I felt made a very compelling case for doing something daily that records the process of your work.
The book lowered the bar from the perspective of the daily issues are more around the process or behind the scenes of what it takes to write a weekly one. And my learnings and failures during the week led me to write about a topic. Like this week's topic!
This week's newsletter issue around ownership was triggered after seeing a new leader come to our organization and see them turn multiple projects back on track and fix some long-standing issues. Those interactions made me think about how I approached leadership and ownership of my scope and the teams I work with.
Who? Me?
From the start of my career, I've been the type of person who wanders around and "finds problems" to solve.
In the beginning, I was that annoying person that kept asking, "Why do we do it that way?" thinking I knew a better way to do it. In reality, I was too new to understand past constraints or organizational context around why a thing was done a certain way.
Over time, with experience, I came to understand (through multiple failures) how to approach these issues better and think more in terms of Chesterton's Fence.
Another aspect that comes into play as you gain more experience (and scope) is that there are times when you ask, "Who is doing task X?" and the room turns to you to do that task. The higher you're on the ladder, the more range you're expected to provide, from meetings to planning to writing down documentation, securing the investment, de-risking projects, etc.
Once you've grown past a particular scope in your career, you're effectively expected to take ownership of larger and more significant things.
Why, though?
You're accountable for the success and failure of your work, team, org, etc.
As I've taken on a larger scope, I fall back into "finding problems" mode, but I'm trying to identify other things than gaps in the design or implementation.
I'm also looking at what is causing friction to teams or which roadblocks have teams and projects seen multiple times across the organization. Or if we need to set up a project plan, get approvals from other departments (e.g., Legal, Marketing, etc.), or identify stakeholders, who are responsible, who needs to be informed, etc.
In general, I want to see my teammates succeed. If I want that to happen, I need to focus on unblocking them or enabling them to move forward instead of taking on more tickets or doing individual tasks.
Solving problems
Finding and solving problems take different shapes at different times, especially if you're a staff engineer.
Keeping a pulse on the projects our teams are working on helps me be ahead of possible issues that might come. Being proactive instead of reactive significantly improves overall dynamics in the organization. I cannot tell you how demoralizing it is to feel like you're only putting out fires.
Other times, it means looking around and helping sponsor teammates' ideas and setting them up for success so their opinions are implemented. It can also mean investing in people and helping them find projects that challenge their abilities.
I've taken to mentor people that are new to the organization or with our projects. Also, simply connecting people or having people read documents from other organizations. Occasionally, it feels like being a Document and People directory for my teams.
More importantly, it means being accountable for things that happen. For example, when my manager asks: "Why is project X blocked?" I no longer answer like: "Because Y team didn't do Z," and more like: "I didn't work with team Y to de-risk our feature. I'll schedule a time with them to get us back on track." I take it as being accountable for the outcome of a project.
Fear
While typing that last sentence, I recall being afraid to take responsibility for something other than my work. But also felt that it needed to be done. I had to do it if I wanted to see the team succeed.
I won't say that I'm in some "extreme ownership" mode. I fail and must constantly bring myself back, learn from those mistakes and try again.
Since I tend to make written notes, I write about what I fear about a particular project or what I fear will go wrong. With that list, I trace down to what things I can control and take ownership of.
This is certainly a journey I need to choose every day to pursue. It's certainly not easy, but I would feel bad if I didn't.
Your Turn
How are you taking ownership of things at work? How do you deal with the fear of owning more extensive scopes? Let me know by replying to this email!
Happy coding!
Things I read the past week
- This two-part series on becoming a VP by the VP of Engineering at Honeycomb.io, Emily Nakashima.
- This post from Shreyas Doshi about high-agency, which he qualifies as an attitude he's seen on successful leaders.
website | twitter | github | linkedin | mastodon | among others