Plaid & Dropbox's Jean-Denis Grèze's playbook for building an engineering culture of ownership

[00:00:00] When I was younger, I really liked the idea of building a perfect system and engineering something really, really, really well, and really perfectly. That's nice in the world of computer science and engineering and the abstract, but pragmatically you're at a company with a budget. You have a timeline by which you need to deliver something, or competitors will deliver something better, faster, but you have a lot of constraints.

And in that world, great engineering is about solving business problems faster. And better than your competitors can. That's just boils down to pragmatism.

[00:00:35] Welcome to in depth, a new show that surfaces tactical advice, founders and startup leaders need to grow their teams, their companies, and themselves. I'm Brett Berson, a partner at first round, and we're a venture capital firm that helps startups like notion, roadblocks, Uber, and square tackle company building firsts.

Through over 400 interviews on the review, we've shared standout company, building advice. The kind that comes from those willing to skip the talking points and go deeper into not just what to do, but how to do it with our new podcast in depth, you can listen into these deeper conversations every single week.

Learn more and subscribe today@firstround.com.

For today's episode of in-depth. I am thrilled to be joined by John Deney grads. He's currently the head of engineering at plaid, which securely connects your bank to apps like Venmo and betterment. Prior to plat. He also headed up engineering teams over at Dropbox. So he's got a ton of experience building technical teams that can scale up immensely as John Deney puts it.

He's a believer in pragmatism over perfection, which may come from his somewhat unconventional background. After studying CS and undergrad and inching towards a PhD, he took a left turn to get a law degree and worked as a lawyer for a year, which she calls a four year detour. He probably didn't need. But pointed him back towards his love of building with computers.

What's also interesting about John Deney is how much he believes in the bottoms up leadership. In today's episode, he dives deep into the tactical steps. He takes to empower the teams under his purview to adopt an ownership mentality. From aligning on a single KPI, celebrating team wins with a model rocket ship from an old school cartoon to replying, to plenty of emails with thanks for the FYI, but you can solve this on your own.

Johnny is chock full of examples for making ownership more than just a team rallying cry. We also dive into how he spots his must hire engineering manager candidates. The one question he asks in every engineering interview and why he thinks one of the biggest game changers for his team was abandoning titles.

Today's conversation is a must listen to, of course, for folks at the helm of technical teams and those eyeing management in their future. But even for those not in the engineering side of the house, there's plenty of great tactics for empowering your team to tackle problems at scale. I hope you enjoy this episode.

And now my conversation with John Denise. So I thought we would start by talking to sort of a high level and then use that as a jumping off point and really talk about how you think about, or describe your engineering management ideology. And how your background in both computer science and law school and law may be kind of infused or as a part of the way that you think about engineering and engineering 

It's difficult for me to say that I have a strong point of view on an ideology for engineering management. Outside of using the word pragmatic. I think there's a number of ways to solve a problem. Right? And you have all these constraints as an engineering leader, which is your team. Like it's skillset, the culture that you have, how well your business is doing the competitive environment that you're in the competitive environment for recruiting that you're in and so on and so forth.

And so I look at all that, and for me, greed management is about finding some path from where you are in terms of your capabilities. To being good enough to solve the business problem at hand, if there was another philosophy, one step below it's that engineering exists to serve the purpose of the business.

When I was younger, I really liked the idea of building a perfect system and engineering something really, really, really well, and really perfectly. That's nice in the world of computer science and engineering and the abstract, but pragmatically you're at a company with a budget. You have a timeline by which you need to deliver something, or your competitors will deliver something better, faster, right?

You have a lot of constraints. And then that world, great engineering is about solving business problems faster and better than your competitors can. That's just boils down to pragmatism and I'd hammer this into my teams. It's about impact. Don't build a great system if no one uses it as stuff, no value.

And then the way you get to impact is you've got to be pragmatic about the trade-offs that you're making along the way. I don't know if that's super satisfying, but I think it's realistic. And I think it works. I don't look back at all the decisions that I made in my life. Right. And I think the contact for someone who's listening is that after studying CS and then working in industry and inching my way towards a PhD and not getting one, I went to law school and then worked as a lawyer for a bit.

I think what I learned from that experience, two really important life lessons. One of them is that I really love building things with computers and that the worst day that I have as an engineer is better than the best day that I had as a lawyer. Personally, that's really powerful thing to have because it means that my motivation and my love of what I do is so crisp to me because I've done something which granted I enjoyed and I was good at, but I didn't have that love for it.

That's a really powerful thing. The second thing that I learned in law is that I'm not that smart, I think, before going to law school, when I was an engineer, like in college and after college, I was an obnoxious, no, at all, we thought he had the right answer to everything. And thought that there was one right answer to everything, right?

Engineering makes you in math can make you feel that way. But the reality is like real-world engineering. There's no right answer. There's always a range of answers. You have trade-offs and actually what's really important is convincing other people to align behind one answer. And that's what I learned at law school.

I learned that. People can have very different opinions and you can use arguments clever or not. Right? You can align people on the rationale behind a decision or the way to get to a decision. And you can get agreement even from people who might not have agreed initially. And that's powerful, right?

Because it means it's not a world of black and white. It's just a world of gray. And it's a world about getting groups of people to align on a path through the gray. And that's influenced me as a manager because you'll have teams in engineering. They can't agree on how to solve a problem. And I'm like, well, fundamentally you may never agree.

But you have to find a path forward. You have to pick some solutions that you're all okay with the trade-offs for. And maybe the decision making framework is like today person a makes the decision and next month it's person D it almost doesn't matter when it's not clear that one decision is much better than the other.

[00:07:10] If you were to answer the question, great engineering management at Dropbox looked like this and great engineering management at plaid looks like that. Is it the same answer or to your point about context and environment is actually two separate answers, 

[00:07:27] both, but he's shared a value called ownership, which you're going to hate.

Right? Cause it's like a generic value, but I think the best leaders in my experience, they act like no problem is outside of their purview. It doesn't matter if it's a business problem, a design problem. An engineering problem, a legal problem. They push through and find a way to get groups of people to solve the thing, or they notice something not going well in another function they pointed out and they'd go out of their way to fix it, to find some solution.

Those are the best managers at Dropbox. Those are the best managers at Platt and my guests are, as those people are the best managers, wherever they're working. Can I say that any company that I've worked at were systematically good at identifying such people through the interview process? No, if you mean like more culturally, when I joined Dropbox, initially we were going through, this is the pragmatism.

We're going through a period of hyper growth, two, three X year over year for a couple of years. And that environment actually the best engineering managers, frankly, are the ones that are really good at hiring. But then you get to a point in time where your team doesn't need hiring as much. Right. He needs operational excellence.

That's a totally different skillset. So I think I saw Dropbox kind of. Go from one world to the other one where we really like favoring hiring and momentum driven management. And I think then we reached a much more mature stage where you're storing hundreds of millions of people's files and you can't lose them.

And. SLA is matter and security matters and all that stuff. And I think that took a different set of people to be really, really good at one thing for Dropbox is they both manage that transition really well, but also Uplevel people from one bucket to the other. But it's not in all cases, the same people we can get into specifics.

I'm more than willing to talk about it. But I would say I applied, it's been similar. I value this owner mentality. Very very highly. I think there's like a quote from a good friend of mine. Who's a VP, which is like great managers have an overdeveloped sense of responsibility, overdeveloped. Cause it's a big burden on your life to worry about a lot of things, but you have that sense and that's what gets you to.

Make teams successful. Cause you don't just stop at the boundaries of your team. You stop at the boundaries of the problem that needs to be solved for the business. I think we have that at Platte. You know, Platt is we've always gone fast, but I think we've been consciously focused on going about 50% year over year.

At most that puts a lot less stress on the organization. It doesn't require your managers to be quote-unquote recruiters and we've always operated from a world where. Things like stability and security. I'm not saying those things. Weren't very important at Dropbox. They were extremely important, but I think I applied given the nature of the data that we have and how we interconnect a lot of people's bank accounts to the apps that they love.

We had to have a level of maturity on those fronts that you don't generally find until companies get bigger. And so I think that's required us to have managers. I think that are more mature about say managing risk, thinking longterm about scalability and reliability. 

[00:10:09] Do you think you can teach somebody to be an owner or have an ownership mentality or it's deep, deep wiring that really drives that behavior.

[00:10:20] I've seen people notice ownership and others given feedback about having higher ownership. And I've certainly seen cultures. That value it, that put it on a pedestal that rewarded and performance reviews that use the language all the time, that break boundaries between functions. So that it's clear that it's expected.

Yes, you can mentor people. Yes. You can have a culture or a system that enables that, but I've also noticed something else. And it does not a bad trait, but I have seen people who actually, what they want to do is they want to Excel within the boundaries of a domain that really matters to them. And that domain might be much more constrained.

It might be a domain where they don't want to be asked to have ownership outside of pure engineering and their team, because that's what they really value and enjoy. And so I don't know if it's not teachable, but I've certainly seen people who don't find it that enjoyable to go beyond the bounce of their immediate team or their immediate project.

I think some people can be very successful. And I think there are definitely parts of plaid where things are. So well-designed so to speak that you don't often see the need to move outside of your swim lane, so to speak. So I wouldn't say it's like an ability thing. I think it's more of a desire if you think about ICS, right?

There's some ICS, like what they really like to do is go deep on a technical problem. And if they're at a company we're going deep on a technical problem and really focusing on it, And not being interrupted by others, having clean API APIs, both programmatically and organizationally to the rest of what's happening.

Those people will really thrive in that environment. And if you need that deep technical work, you want those people to be owners of their immediate domain, but nothing else, like you don't want to distract them with anything else, you need them to succeed, but then you might have other places where you need.

Project managers, you need tech leads who are able to wrangle multiple stakeholders and make sure that all these different parts of a complicated project that touches on like 16 systems and five parts of your orgs and like a dozen engineering team lands on time or whatnot. You want that second person to have super high ownership because if they notice a problem somewhere else, you want them to be able to have that owner mentality and tell people like, Hey, this is not acceptable.

We're going to be behind schedule. Like, let me help you fix it. What do I need to do to give you the resources or the space that you need to land it? But if you try to put the first person in the second bucket and the second person in the first, they're going to be bored or they're going to be unhappy, or it's not going to match the impact that they seem themselves as having, I see the most successful managers, I think ownership beyond your domain is few teams that operates so atomically.

And apart from the rest of the business that you can afford to be complacent about what's happening outside of your little universe, but that's 

[00:12:47] me weak related idea, but there's a lot of companies that founders. And they kind of bring that ownership, but then you have a lot of founders running around and to your point in certain situations, you kind of have to put your head down and get the work done.

And so do you ever see downsides to that? Yeah, 

[00:13:01] 100% you were asking me right. About ownership as a management philosophy. I think it's quite important. So you're talking about, everyone's running around trying to do different things. You don't have aligned incentives. Like that's definitely a failure mode.

The Fairmont that I've seen with ownership is more, it becomes frustration when people will high ownership, can't get the things done that their spidey sense is telling them is right for the business. And there are a lot of ton of reasons that can happen. One is like their priority of what's important for the business might not align with what the business itself thinks.

And so then you just don't get the resources. The people, the budget moving towards where it needs to be. And that downside, I think is very real because you're telling people, be owners and then people are trying to be owners and then they get frustrated and then they become complainers, which is a version of ownership where you just point out the problems, but don't really push through to solving them.

And if you have a complaining culture, it gets tough. It's pretty heavy on morale organizationally. When you have to do. Is you can't have just one kind of person everywhere in your team. Like your job as a manager is to first nurture the right mix of talents, perspectives to work for things to be successful for me on the management side, ownership's very important.

It's important on the IC side, I think of it as a little more constraint to your immediate project and many cases, making sure it gets done on the things that you control, but it doesn't mean that you're necessarily going across functionally everywhere, but the most important thing about ownership is having clarity around impact for the business.

Because if people understand what's impactful for the business and ideally their ownership will be funneled towards the right maximization formula, what's really bad is when you have someone who has an idea in their head like, oh, we should build X feature and they try to convince people that X feature should happen.

But X feature doesn't turn out to be successful in business, but no one wants to do that because no one wants to bang their head against the wall with a bad idea. The only reason they do it is because you don't give them the tools to understand what a good idea is. You don't give them the tools to understand what's valuable for the engineering team or for the business.

[00:14:53] On the idea of clarity around impact. Can you kind of give an example of what that looks like if it's being done really well, maybe a prior quarter or the way that you communicated a specific way to describe impact such that people can make high quality decisions. 

[00:15:11] The easiest way, in my opinion is to have a KPI where it's easy for people to understand how they work links up to the KPI, KPIs like a goal, like a metric that tracks towards the goal.

So I'll give you a plot example that I'm proud of, which was just from when I joined the company and actually the creation of the KPI predates me. So I'm not going to take any credit for it, but it was a very good KPI. So the KPI was the percentage of traffic going through plot that was using something that we called link.

Link is when you connect an app to your bank. Account link is the flow that you go through to connect your bank account to that app. And that flow is on plaid property, and it's called link. It's part of their SDK that is embedded in the apps web mobile that are developers that are building on platter are using.

And so before that year, there were two ways to use plaid. You either built your own UI. Or you use link. And what we realized is that it was better for end consumers and for developers longterm for everyone to be on link. So we named it as a goal that we would track. And so like every engineering meeting, every all hands at the company, one of the numbers that we talked about is the percentage.

Where we at 1% on length, 4% on link, 12% on length. Then next month it went down to 10 and so on and so forth. It was really clear. Now there was a rallying call and for any team that had anything to do with that, any team that was building developer tools and ETL that was working on link itself, and you want to cross customer success that we're trying to convince customers to move from their old integrations to link.

I'm not saying you would do it accurately, but you could say like, Hey, the work that I'm doing. Is it going to drive this metric? Is it going to make it easier for developer to adopt link? If so, is this the highest ROI thing that I can do and so on and so forth. And now people thought out of the box about how to get developers on link.

They were like, should we go and embed in the developers are using plod and help them move to link or not. And then we could have a discussion about the ROI of that versus something else that would move that metric. But just the fact that we had that metric just made it a lot easier for people to align their work.

I'm not saying bad ideas along the way weren't generated. But they could be considered. And then if they weren't the best way to do it, you had a language to talk about it. Amount of time engineering, Spence to get what lift of end-users using link. That's like one really powerful way to do it. It's just to have a really, really clear KPI.

The opposite end of the spectrum actually is one. I think you don't have a great decision making framework for helping people who have high ownership decide whether to move on something or not. Do you have a sense 

[00:17:47] of at any given point in time, what percentage of people are able to sort of coalesce around an elegant metric that you mentioned?

And is it most of the time through most of the years, there are these one to three, very, very clear cross-functional galvanizing metrics or a kind of comes and goes in these moments of alignment. 

[00:18:07] Oh, I wish I could tell you that we always had the galvanizing metrics. I've been at pot for years. I think there's two years there where I felt in hindsight, we had a really good metric and like a really good engine that was driving towards that metric really, really well.

And it provided a lot of clarity. And then I think the other half of the time we thought we had the right metric and maybe it was difficult to measure or even worse. It ended up. Not being the right metric. I have an example of that. Right now. We have a metric that we've globally optimizing for. So we're like if this metric drives up, it makes our customers really happy.

But we're optimizing it for across all customer types and all geographies. It's also a metric that's really good for the business. It's a kind of dangerous. It's really good for the business. Really good for customers. It turns out that metric for some customers is the right metric for other customers.

It's not, it's not like a negative metric. They just don't really care about it. It's not the most important thing for them, but we didn't realize that subtlety. The thing about metrics of the danger is like you put them out there and people optimize for them. But if you've picked the wrong metric, you get in trouble.

So this is like an interesting case where the metric was right for like two thirds of the business, but it was not right for one third of the business. And we didn't understand that subtlety for a little bit too much time. Kind of switching 

[00:19:13] gears just a little bit. When you think broadly about the way that you manage and lead engineering teams, are there moments or ways in which you've changed your mind?

[00:19:25] Well, I think as I've had bigger teams, my role has changed completely a few times. So from that perspective, I think it's not just the role of management. It's management of one team managing a bucket of teams or managing a function where. Might as well, be an alien to the average person on your team requires like very different skillsets and approaches and the things that you do at one level don't work at the other level.

Like right now, if I go and read a technical spec and write comments in it, that's a disaster waiting to happen because whatever I write only like a handful of people on the team will feel comfortable enough telling me that I'm an idiot. Just cause I'm quote unquote, the big boss or something like that.

So from that perspective, I think time has forced me to adapt my approach. I came into management a little bit later into my career, and I think one of my fundamental concepts has always been the real trick and management. Like the hardest part of management is to manage the times when the expectations and hopes of individuals don't match the expectations and hopes of the company.

When that happens is when management gets really, really difficult. My solution to that has always been. To be very direct with people who report to me. And I don't love the language I'm about to use, but I think it's important to state it this way, because I think it makes it clearer when I'm quote unquote, trying to get out of them and asking them to be really clear with me about what they're trying to get out of me.

Out of the job. So in the positive sense, the first one would be not what I'm trying to get out of them, but having the most impact for the business would be one way to put it. And then the second thing is what they're trying to get out of me is like, you know, aligned with their career and growth objectives and their desires of happiness kind of at work.

But the reason I like to frame it pretty directly is because I think if you're really direct. And it's really crisp. Then I'm never pretending that I'm asking somebody to do something that they don't want to do by pretending that they actually want to do it. Right. I'm not like, oh, Alice or Bob, this really is the kind of work that you want to do.

You should do it. It's great. No, I'm like, Hey, listen to Alice or Bob out of this project. It's really important for the business. And I know it's not quite aligned with how you want to go in the next six months, but it's the most important thing for the business. Let me help you show you why. And they're like, I really need you to do this.

And I think that's the right thing. That's like such a more trust, inducing, and reasonable way to do it. And then you're clear, right? If they don't want to do it, you understand this because it means at that point in time, they actually value something about their growth more than for the business. That's a good thing to know, to be really clear about.

So I've always believed that ever since I'm a manager. And I think since that's the fundamental. Dealing with that incompatibility, when it happens is the fundamental thing. That's hard about management. Everything else can be hard, but I think that is that misalignment is the hardest part that hasn't changed for me 

[00:22:02] that sort of specific situation, which is, this is such a great area to explore because I wholeheartedly agree with it.

And it's so tricky, like when the wants the needs of an individual and the wants and needs of the company overlap, beautiful things happen. And the farther that those things are out of alignment, that's where oftentimes very negative things tend to happen. And so outside of sort of the crispness and directness, is there any other ways that you approach when those things are starting to get non-overlapping or separating, or that's kind of the main thing you 

I have a speech that I give, which is that in the moment I will ask you. To do what's right for the business. But over time, I'll do what's right for you when there's that misalignment. I'm not going to let that misalignment last too long. So if I ask you to take one for the team, now I tell you next time I'm giving you what you want.

It's my word. Most of the time, my career, when I say most, I don't mean 51% of the time. I mean, like 90 plus percent of the time I've been in a position where I can abide by my word. And if I can't, it's literally because it's a situation outside of my control and that's powerful. And if people need to trust you, right.

And you need to trust them to be open with you. But at times that has meant we are things like telling somebody like, Hey, listen, I really want you to do this project, but I'm not going to be able to meet you halfway for the next one. Cause the kind of work that you want. You just don't have it here. And if you really want that growth, I'll help you find a job somewhere else.

You're a great engineer, right? I have no doubt that you'll be able to find that it's just not an X. It's not a display. So we're at, or it allows you to say like, Hey, what's the best team that you'd want to work on. That has the kind of work that you would thrive. Oh, it's that team. Okay, cool. I will secure now.

That moves so that you can definitely do it in two quarters. Now you always be careful about what you promise for the future, but I think that's your duty, right? You're trying to do right by people because people mattered their careers matter, but you need to take care of the business. So I always put the business first in the short-term and the employee first in the longterm, that's worked well.

I've never been in this situation though, where there's like long-term misalignment, where I can't eventually make it better outside of a few cases. 

[00:24:02] Are there any issues with the sort of on that last point you were making kind of a capabilities mismatch. I want to do X. I want to grow in this area and you just don't believe that they're going to be exceptional.

[00:24:13] Yeah. And that's a tough conversation. Isn't it? If you want to be a manager and you haven't shown the skills, whether I look like, I know you wanna be a manager, but like, if you're a manager, you could work with different personalities or you would be able to deal with ambiguity. And I've got concrete examples here where you weren't able to do that in the last six months, I'll meet you halfway.

I'll find another project that requires you to do the thing that you aren't good at. We'll have an extra one-on-one or I'll pair you with someone who's good at it. And you get to learn and you get to show me that you can do it. One of my favorite examples is an engineer who wanted to become an ML engineer, but had like no experience at all in that space.

And I was like, okay, you can take half a day, every two weeks. And just do ML on your own time, but ask you to do it at the office and like give me a praise of it. And then after that, there was a project, an ML team that required someone really junior. It took like a year and a half, but eventually they were on that team.

They're doing ML full time. I'm really proud of that one. Really proud of that person. I didn't know, work. Right. They were like super smart. They were super self-motivated, all that stuff. I met them with the opportunities, but there's cases where you. Try to meet people and you try to help and you try to provide what they want.

And sometimes it doesn't work out, but I'm really honest about it. It's hard. Right? I can think of people who said they wanted to be managers and we didn't find a path there. And then they stayed and they weren't happy. And they went somewhere else and maybe they grew, or maybe I was wrong about their abilities.

And maybe eventually they became manager and they were very successful and so on and so forth. I'm not saying I'm always right, but I'm always direct and honest. No matters a lot. Building 

Today's episode is with Jean-Denis Grèze, Head of Engineering at Plaid, which securely connects your bank to your apps like Venmo and Betterment. Before joining Plaid back in 2017, Jean-Denis was Director of Engineering at Dropbox and even took a 4-year detour into becoming a lawyer. He digs in deep to his pragmatic engineering management philosophy, including building an engineering culture with a bottoms-up ownership mentality.

Plaid & Dropbox's Jean-Denis Grèze's playbook for building an engineering culture of ownership

Read the article inspired by this episode

Building a Culture of Ownership — Engineering Leadership Lessons from Plaid & Dropbox