How to Create a Culture of Ownership in Your Engineering Team
Ownership doesn’t happen by chance -> it’s built through deliberate actions that leaders often overlook!
DX (Sponsored)
If you‘re an engineering leader or on a platform team, at some point your CEO will inevitably ask you for productivity metrics.
But measuring engineering organizations is hard, and we can all agree that simple metrics like the number of PRs or commits don’t tell the whole story.
That’s where DX comes in. DX is an engineering intelligence platform designed by leading researchers, including those behind the DORA and SPACE frameworks.
They give engineering leaders and platform teams the data they need to take the right actions to drive higher ROI per developer.
Visit their website to learn why some of the world’s most iconic companies like Dropbox, Etsy, Pfizer, Twilio, and Vercel rely on DX.
Let’s get back to this week’s thought!
Intro
A lot of leaders expect ownership from the team and it's people and yet often neglect how important their specific actions are.
As a leader, you need to create the right environment and culture and people will gladly take ownership.
The actions of a leader either inspire or discourage ownership.
But how do we create such an environment and culture?
Luckily for us, we have Taha Hussain, joining us as a guest author. Taha is a former engineering executive at Microsoft, Yahoo, Walmart Labs, Startups and now a dedicated Engineering Career coach for Engineers and Leaders.
In today’s article, He is sharing lessons learned from his time at Yahoo, where he transformed his way of thinking → from discouraging ownership to inspiring!
P.S. This is our second collab. If you’re interested in reading the first one, you can read it here: Why your job search is failing as an engineer or a manager (and how to fix it).
Taha, over to you!
I was unaware that others were frustrated with me
In 2013, I was a Principal Engineer at Yahoo, blissfully unaware of the mutiny brewing around me.
I overheard whispers about a farewell party for Nilo, a scrum master I’d been supporting across four teams. I strolled into the conference room, expecting the usual cake and awkward goodbyes.
Instead, I got silence. Conversations died. Eyes bore into me. I'd walked into a goddamn minefield.
I froze. Then, Nilo appeared. She walked toward me, calm and deliberate. She gently held my elbows, looked me in the eye, and said:
“Taha, be nice to people.”
Be nice? What the hell had just happened?
Later, my boss gave me the truth: over 200 engineers and managers were frustrated with me. I’d been relentless → pushing for code quality, on technical debt, on deadlines. And the team? They pushed back with excuses, lowered standards, and enough tension to choke the room.
Normally, I would’ve shrugged it off. But this time, I didn’t.
I was curious:
Why was ownership so damn hard to find? And how could I unlock it?
This search transformed my career. By 2019, I was leading 250+ engineers and managers, fostering a culture of accountability and growth.
Understand the Elephant. Guide the Rider.
My transformation started with a deceptively simple idea: Jonathan Haidt’s Elephant and Rider metaphor from The Happiness Hypothesis.
Imagine your brain as two distinct entities:
1. The Rider, who plans and directs.
2. The Elephant, who provides the power to act.
The Rider believes it’s calling the shots, but the Elephant has its own agenda. When they disagree, the Rider turns into a lawyer, defending the Elephant’s nonsense instead of guiding it.
The Rider rationalizes. The Elephant decides.
You can’t force the Elephant. You can’t drag it. You can’t yell at it. You have to understand it, guide it, and motivate it.
This was my “aha” moment. My problem wasn’t technical standards or deadlines. It was my inability to connect with the Elephants on my team.
I’d been barking orders at Riders, while their Elephants—overwhelmed by fear, doubt, and resistance—stood firmly in place.
If I wanted my team to step up, I needed to speak to both the Rider and the Elephant.
Lesson #1: The Elephant craves safety
When Marissa Mayer announced that all software development would move to Sunnyvale, chaos erupted. Remote teams were given two options: relocate or accept a severance package.
One of my teams was in India. I joined their weekly stand-up expecting business as usual. But this time, only six faces appeared on the screen—down from twenty.
“What’s going on?” I asked. Silence.
Then one engineer admitted: "Taha, we’re screwed. Half the team's gone. Managers have checked out. It's just us."
Their anxiety was understandable. They'd chosen to relocate, but their visas were pending. They felt adrift, uncertain about the future.
And I remembered something critical:
The Elephant doesn’t move when it’s scared. It freezes.
"Let's start small," I said. "If everything was normal, what would you be doing?"
"Daily stand-ups, sprint planning, working through our backlog," one of them replied.
“Then let’s focus on that,” I said.
I spent the next week diving into their backlog, connecting with stakeholders, identifying key deliverables. Together, we created a plan. A simple, achievable plan to keep them moving forward. Within six weeks, they were executing confidently, turning their anxiety into action.
A week before the team arrived in the US, my manager asked me to lead them.
Takeaway: Fear paralyzes progress. Safety unlocks it. If you want to move people, start by building a bridge over their fears.
Lesson #2: The Elephant is chained to beliefs
 | A guest post by
|