Ownership Podcast: Unlocking 10x Growth

Key takeaways from my live event with Tiger Abrodi.

Nov 30, 2023

Yesterday, Tiger and I did a live stream on LinkedIn delving into ownership mindset in software engineering. The conversation led to insightful takeaways for engineers trying to 10x their growth.

Tiger Abrodi

is a senior engineer and a tech influencer. He is active on LinkedIn and has his own newsletter

Saiyan Growth Letter

. Consider following him for actionable advice to level up!

Today's newsletter highlights the key takeaways from the podcast. For the key sections, I captured the video timestamps if you want to check out the video snippets.

Link to the full video here

What is Ownership?

Ownership is a key behavior in how you do your work. This can apply to any type of work - coding, presentations, or even house chores. Ownership is about how you solve problems despite the hurdles that come along the way.

Principles of Ownership (6:37)

I like to think of the ownership mindset as being based on two fundamental principles - Identify and Act.

Identify - This is how you develop an eye to identify problems that are pain points. You don't simply point out superficial problems, but dig into the underlying issues.
Act - This is how you evaluate the impact of the problem, the cost of fixing it versus not fixing it, and prioritize it against other commitments the team has.

Most people get better at identifying problems over time but do not act.

How to build an eye to “Identify”

It is a learning process to identify problems, so don't worry if it takes time before you find impactful problems.

Example opportunities (9:22)

Highlighting some opportunities split by levels to help you:

Junior / Mid Engineers - Look for problems that are affecting team productivity
- Is it difficult to work in your codebase? Maybe refactor things
- Are the tests breaking all the time? Improve your process or use linters
- Are you not catching bugs before shipping? Improve your release pipeline!
Senior - Improve team and customer relations
- Is a customer unhappy with your team? Can you resolve it?
- Are they complaining too many times about a workflow or an API? Can you turn the complaints into a feature?
Senior and Beyond - Identify a problem statement from a diverse set of problems

Curiosity is the key! (16:15)

Ask "why" and challenge the status quo. When you ask why for seemingly obvious assumptions in the team, you trigger a conversation. It can either educate you or highlight a gap in the system that needs to be fixed.

Own your career (23:00)

Another aspect of ownership is improving your skills that make you a better engineer. These are not just coding skills but also soft skills.

Some tips to identify areas of self improvement:

Are you less productive in your codebase? Explore that codebase and learn where the key pieces are.
Are you not comfortable using a framework? Spend extra time with it.
Are you struggling to write or give amazing presentations? Seek help from those who are doing it well.
Are you making some mistakes repeatedly? Build a checklist to avoid missing them.

Investing in yourself is more important than finishing your tasks at work. They stick with you forever.

Blind company loyalty? (24:00)

Some people feel they should stick around a company for a long time for no reason. Not true!

You should do what is best for you.

Our framework to stick around in a company or team is:

You enjoy the projects and are growing while working on them.
You like working with your teammates.
You have a good manager.

Why don't some people have an ownership mindset?

Some people will only do what they are asked to, while others go beyond the basic task. The latter will identify more problems and deliver an amazing customer experience. Are the former wrong or untrainable? No.

Unlock Ownership by connecting with the problem (30:45)

I have ramped up many engineers, and I have found that most people do have an ownership mindset, but they haven't unlocked it for everything. They may care more about a personal project or a hobby and show strong ownership there, but not as much at work.

The common problem here is they haven’t truly connected with the problem and the business.

Consider an example where you are asked to build rate limiting for an API.

You could simply build it OR be curious and understand why it needs to be built.
You learn that there was a recent overload that affected reliability.
You become curious and check if the API has subpar performance.
So you transform your task from "build rate limiting" to "make API reliable and overload ready".
Any additional fixes you make will have an impact.

There you go, you have embraced ownership by understanding the depth of the problem.

Act, don’t make excuses

Some folks hesitate to take action after identifying a problem. They feel:

They are not the expert.
How can I propose a solution if I am not a manager?
They are afraid of failures or worried that the new work will take longer.

The feeling is normal, but don't stop there. The top 1% of engineers push through the discomfort and deliver excellence.

Seek help from your mentors, ask a lot of questions, and read books or newsletters like this one. 🙂

Don’t fix everything!

Once you get good at identifying problems, you will see more of them. However, don't do these:

Bombard the team with problems, but provide no proposals.
Become pedantic about concepts you learned in books and not account for practical constraints.
Not give others the room to work on their problems.
Overwork to make more impact

Stories

Tiger and I shared one story each in which we embraced an ownership mindset and delivered high impact.

Tiger’s story (12:16)

Tiger's team didn't focus on accessibility, but their website was used by a lot of elderly customers and people with disabilities. The team didn't have an owner who drove this and it got sidelined. Tiger stepped up to help the consultant working on the problem by identifying all issues and enabling functionalities to improve accessibility.

My story (45:30)

My system would occasionally get overloaded by a customer, which affected reliability. So, I was working on a side project that tackled a specific problem head-on. When I rolled out that project, I eliminated on-call noise and improved core reliability metrics.

How did I learn? (49:00)

At Microsoft, I focused on building features. They were vetted proposals, so I didn't have to have a product owner mindset. I was good at shipping features and a go-to person for all things I built.

However, at FANG, 8 months in, I worked on a feature that I assumed was vetted. I didn't consider the value vs cost trade-offs in depth. It turned out that the cost was higher than expected, and we had to stop the project. That was an eye-opener for me. I had to think like a product owner to expand my ownership mindset. I needed to focus on the right impact - reducing cost and improving reliability at that time.

Thereafter, I always looked for problems that affected the core metrics and found impactful projects.

Key Takeaway

Anyone can unlock ownership mindset by connecting with the problem.

It can take some time to build an eye to identify impactful problems. If you are starting now, focus on problems that affect productivity and customer experience.