Ebi Atawodi (Director of Product Management at YouTube Studio, previously at Netflix and Uber) and the host (an engineering manager at Uber at the time) recount how they went from a rocky start to building one of the most productive working relationships either had experienced — and how that relationship transformed their shared team into a high-performing, startup-like unit inside a large company.
How engineering and product went from siloed to one team
The rocky beginning: When Ebi joined as the new PM, she shared candid feedback from a monthly product review — including concerns about headcount — in a team meeting with engineers present. The engineering manager was blindsided and upset; engineers were demoralized. Neither side understood the other’s world.
The turning point was a personal connection: After initial friction, the two started having weekly one-on-ones — not just about work, but about personal lives (family, relationships, life in a new country). A dinner that was supposed to be two hours turned into a much longer conversation. This built trust that carried over into every professional interaction.
“The magic happens in the confluence of our differences”: Ebi describes the friction between product and engineering not as adversarial but as productive — like rocks tumbling together in a washing machine, polishing each other. The tension is an opportunity, not a problem.
Tactical moves that created shared ownership
Shared business scorecard: The team created a table of P&L metrics (gross bookings, conversion rate, failed payments, cancellations, cash) that everyone — not just product — owned. This shifted the dynamic from “product said we have to do this” to “we collectively haven’t hit our numbers.”
Engineers started acting like product people: Once engineers could see the metrics, they began proposing ideas — like building a web platform for payments, inspired by comparing Uber Eats to DoorDash. Engineers got involved in roadmap prioritization, asking “should we even do this?” rather than just executing.
State of the Union: Ebi and the EM took a day off-site to build a presentation showing the team’s impact — including a graph of incremental payments that was “bigger than a country.” They showed market trends, cash data, and on-call pain points. This gave engineers empathy for why regional GMs were pressuring the team and helped them understand the business context behind their work.
“Product is all of us”: The team deliberately broke down the language of “product said this” or “I’m blocked on product.” In a startup, nobody talks that way — everyone has skin in the game. They made that the culture.
Getting headcount by bootstrapping, not asking
The pattern: When the team was denied headcount for a web payments platform, two engineers built it anyway while still shipping all their existing product work. Six months later, they came back with real customer numbers and revenue — and got the headcount approved.
The general tactic: Don’t ask for permission to build something visionary. Take a real, immediate problem, solve it in a way that also builds toward the larger vision, and then show the results. Worst case, you solved the problem. Best case, you’ve created something worth billions (the API they bootstrapped now processes over $1 billion).
This repeated across multiple initiatives: Uber Pay (which “everyone said would never work”), the web payment flow, and other platform efforts all followed the same pattern — use a small, real problem as the wedge to build something bigger.
Principles behind the working relationship
Principle 1 — Roles are a construct: The magic happens when PMs, engineers, designers, and data scientists stop staying in their lanes and start genuinely collaborating. Ebi managed the design team when the design manager was on leave; engineers wrote PRDs when she was swamped.
Principle 2 — Know the human behind the role: Ebi knew when engineers were thinking about having kids, changing mortgages, or moving partners from other countries. The host knew when PMs were considering leaving. This wasn’t soft — it was strategic. People bring their whole selves to work whether you acknowledge it or not.
Principle 3 — Rhythm and cadence matter: Weekly one-on-ones that never got canceled, regular team meetings with a consistent format (product section first, then tech), and periodic planning sessions with all PMs. Humans are creatures of habit; a reliable rhythm lets people do their best work.
“It’s not cheating to connect at a human level during working hours”: The host initially felt that spending time meeting people and having personal conversations was “not real work.” Ebi reframes this as the most efficient thing you can do — because once you have a human connection, every subsequent interaction (even a blunt disagreement in a document) is contained and productive.
Traits of standout engineers (and strong people generally)
They never stop learning: Directors writing code for fun, VPs who go deep on details outside their domain, ICs who experiment with new models and share observations. The hunger to learn is consistent from L4 to VP.
They roll up their sleeves: The best engineers don’t just talk — they write code, dogfood their own products, go through their own onboarding flows, and open competitor apps. They’re willing to get their hands dirty and also willing to have others challenge their work.
They have conviction but are willing to be wrong: They think before they speak and have strong opinions, but they can say “you know what, I take it back” when presented with a good rationale. Vulnerability is a strength.
They communicate human to human: They don’t hide behind acronyms or jargon. They distill complexity into simple terms. The ones who make you feel like an idiot are net-negative, no matter how brilliant.
The “genius jerk” pattern: Across Uber, Netflix, and Google, the one consistent negative pattern is the brilliant person who drags the entire team down. Different companies have different tolerances, but the net effect is always worse than not having them.
Career advice: play the long game
Be a product leader regardless of your role: Understand the business impact, the technical feasibility, and the customer experience. Know how your team’s metrics ladder up to the company’s core metrics. Contribute to OKRs, PRDs, and vision docs — not as a checkbox, but meaningfully.
Treat your career like a project: Have periodic check-ins with your manager and peers about progress, risks, and skill gaps — don’t wait until performance review season. Ask “how am I doing on X skill?” and “who does this well that I can learn from?”
Seek sponsorship, not just mentorship: Sponsorship is someone advocating for you when you’re not in the room. It comes from doing great work and caring deeply — not from checking mentorship boxes. Ebi has never gotten a job she applied for; every opportunity came from someone who had worked with her and vouched for her.
Care about the work itself: People can smell when you’re doing things for an outcome versus doing them because they’re the right thing to do. When you focus on the work, sponsors appear naturally.
