I recently reflected on an insightful conversation with Jean-Denis Grèze, Head of Engineering at Plaid, which securely connects your bank to your apps. Before joining Plaid, he served as Director of Engineering at Dropbox, and even has law school and one year as a lawyer under his belt before diving deep into the world of CS. That unconventional path sharpened his perspective on leadership and culture in ways that deeply resonate with how I build product and engineering teams.
Jean-Denis calls becoming a lawyer a “four-year detour he probably didn’t need,” yet the discipline and judgment he developed there clearly inform his approach. He strongly favors pragmatism over perfection — a stance I share. In product management leadership, that bias toward outcomes, rapid iteration, and accountability is the backbone of a healthy engineering culture of ownership.
What stood out most was his modern playbook for engineering leadership, stitched together from years at Plaid and Dropbox. Ownership starts with clarity: sharp priorities, explicit decision rights, and fast feedback loops that connect product roadmapping and sprint planning to measurable business outcomes. When teams understand the why and can see their impact in the right KPIs, they lean into responsibility rather than waiting for directives.
We also dug into org design choices that amplify ownership. His engineering org doesn’t have titles. In my experience, removing titles can reduce ego-driven friction and elevate scope, impact, and outcomes as the true signals of growth. But it requires strong frameworks for leveling, compensation, and the IC to manager transition so people still understand expectations and career paths.
I was particularly intrigued by the one question he asks every engineering manager candidate. While the question itself is simple, the signal it seeks is profound: can this leader create clarity, foster accountability, and drive outcomes across ambiguous, cross-functional work? When I hire, I look for the same traits — leaders who translate strategy into outcomes vs output OKRs and consistently raise the team’s bar for execution.
We also unpacked the perennial balancing act: prioritizing technical debt and keeping the lights on versus sexy, brand-new projects. My approach mirrors his emphasis on sustainability — dedicate explicit capacity for reliability, security, and platform health, anchor the roadmap to product and engineering KPIs, and make trade-offs transparent. When technical debt is framed as risk mitigation and velocity enablement, it earns its rightful place alongside new customer-facing bets.
This conversation is a must-listen for technical leaders or anyone eyeing the engineering leadership track. From motivating a team to tracking the right KPIs, the tactics and stories from Plaid and Dropbox offer practical guidance for cultivating an engineering culture that owns outcomes, moves fast with judgment, and scales without sacrificing quality.
Leave a Reply