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 in 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 in that world, great engineering is about solving business problems faster. and better than your competitors can. That just boils down to pragmatism.
their companies, and themselves. I'm Brett Burson, a partner at First Round, and we're a venture capital firm that helps startups like Notion, Roblox, 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 in to these deeper conversations every single week. Learn more and subscribe today at firstround.com. For today's episode of In Depth, I am thrilled to be joined by Jean-Denis Grez. He's currently the head of engineering at Plaid, which securely connects your bank to apps like Venmo and Betterment.
Prior to Plaid, 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 Jean Denis puts it, he's a believer in pragmatism over perfection. which may come from his somewhat unconventional background. After studying CS in 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 he 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 Jean Denis is how much he believes in 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. Jean Denis 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 Jean Denis.
So I thought we would start by talking at 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 is a part of the way that you think about engineering and engineering teams? 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 its skill set.
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, Great 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. computer science and engineering in 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. 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 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 is of 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. 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...
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 a 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 know-it-all who thought he had the right answer to everything.
and thought that it was one right answer to everything, right? Engineering makes you and 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. They 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 rationales behind a decision or the way to get to a decision. 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 all 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 B. It almost doesn't matter when it's not clear that one decision is much better than...
the other, you need to find a path forward. 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, it's actually two separate answers. Both companies shared a value called ownership, which you're going to hate, right? Because 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 point it out and they 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 Plaid. And my guess are those people are the best managers wherever they're working. Can I say that any company that I've worked at, we're 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? It needs operational excellence. That's a totally different skill set. 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
SLAs 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 up-level 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 at Plaid, 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 because 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 because 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 Plaid. You know, Plaid is, we've always grown fast, but I think we've been consciously focused on growing 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 at Plaid, 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 long-term about scalability and reliability. 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?
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 reward it in 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 system that enables it. But I've also noticed something else. And this is 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 balance of their immediate team or their immediate project.
I think such 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 where going deep on a technical problem, they're really focusing on it. and not being interrupted by others, having clean 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. 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 leaders.
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 see themselves as having. I see the most successful managers, I think.
Ownership beyond your domain is a few teams that operate 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 me. Weak related idea, but there's a lot of companies that have founders.
And they bring that ownership. But then you have a lot of founders running around. And to your point, in certain situations, you have to put your head down and get the work done. And so do you ever see downsides to that? Yeah, 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. That's definitely a failure mode. The failure mode that I've seen with ownership is more, it becomes frustration. when people with high ownership can't get the things done that their spidey sense is telling them is right for the business.
And there are a 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, what 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 is very important. It's important on the IC side.
I think of it as a little more constrained to your immediate project in 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. 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. 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 kpi is like a goal like a metric that tracks towards the goal so i give you a plot example that um
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 our SDK.
that is embedded in the apps, web, mobile that our developers that are building on Plaid 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 long-term 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 had 1% on length, 4% on length, 12% on length. Then next month, they went down to 10 and so on and so forth. It was really clear.
It was a rallying call. And for any team that had anything to do with that, any team that was building developer tools, any team that was working on Link itself. Anyone across 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 that are using Plaid 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 spends to get what lift of end users using link. That's like one really powerful way to do it is just to have a really, really clear KPI.
The opposite end of the spectrum actually is when 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 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 it kind of comes and goes in these moments of alignment? I wish I could tell you that we always had the galvanizing metrics. I've been at Platt four 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're globally optimizing for. So we're like, if this metric drives up, it makes our customers really happy. But we're optimizing it for it across all customer types and all geographies. It's also a metric that's really good for the business.
It's 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, 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 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 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 about how to do that 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 very different skill sets 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 a handful of people on the team will feel comfortable enough telling me that I'm an idiot.
just because 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 in management, like the hardest part of management is to manage the times when the expectations and hopes of individuals.
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 clear what 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, Alice or Bob, I have this project. It's really important for the business. And I know it's not quite aligned with how you want to grow 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? 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 misalignment is the hardest part. That hasn't changed for me.
In that sort of specific situation, which this is such a great area to explore because I wholeheartedly agree with it. And it's so tricky. Like when the wants and 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 focus on? 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 in 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.
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 weird 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 because the kind of work that you want.
We 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 at X. It's not at this place that 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 move 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 matter, 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 long term. That's worked well. I've never been in a situation though, where there's like long-term misalignment where I can't eventually.
make it better outside of a few cases. Are there any issues with sort of on that last point you were making a 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. Yeah. And that's a tough conversation, isn't it? If you want to be a manager.
and you haven't shown the skills, what that'll look like. I know you want to be a manager, but 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 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. You got to learn and you got 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 i 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 were doing ML full time. I'm really proud of that one. Really proud of that person. I did no work, right? They're 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.
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.
Maybe they grew or maybe I was wrong about their abilities and maybe eventually they became a 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. That matters a lot. Building on something you shared just a few minutes ago.
You mentioned this idea that when you were a line manager or you were sort of managing a team versus managing managers or managing managers' managers, are there things that as a line manager that you thought about the job of? the manager of managers or the role or what you should do. And now that you're sitting in the seat, you get it or you see it somewhat differently.
2020 would tell me actually that most of the things that managers complain about their lead of leads or VPs not doing well actually are things that their lead of leads or VPs aren't doing well. Like all the examples that I can think about in my head right now is... You didn't communicate to me early enough about this organizational decision and change that you wanted to make.
You didn't provide clarity on the strategy or what I should be optimizing for. And then you've decided to kill the team because it's no longer right for the business. And I feel like it came out of left field. It's like all these things that I keep thinking about that I always complain about. My leads and my managers was like... Not enough clarity about what was happening across the org and around priorities.
Every time I've been in that seat, it's really hard and it takes a huge amount of time to communicate with all your managers about everything that's happening. It's just so difficult. There's so much context sharing. And I think I do a lot. And every time I get in a situation where someone's unhappy, I realize, oh, I could have just...
communicate about this more and earlier. As the recipient, you think something's quite easy. And it seems very simple. Why didn't I know about this? Or why wasn't it communicated? Or why wasn't it set up? And sometimes it is, but a lot of times there's a lot of balls. You're trying to share context all the time. But there's a lot of moving pieces. I don't know if this has ever happened. You send an email to like six people and then you realize you forgot somebody.
And now you know that if you forward the email to them or add them afterwards, you're like, ugh, it's going to hurt their feelings or their ego. because they should have been on the email initially. And just the fact that I didn't think that they should be part of the conversation of itself is like the problem. You kind of wish everybody understood the big picture because you're trying to do right by the big picture.
And so whenever you miss the communication, you send the email to the wrong people and someone gets offended, you're like, yeah, okay, I forgot to include you, but you should understand that I've got 250 people to keep track of.
And you should just think about like, is this the right solution to the problem? And because it's the right thing from an impact perspective, we should all be happy. But then you think about it for a few seconds and you're like, oh my God, no, no, no. My job, my one and only job is to...
globally set everyone's expectations correctly and to communicate about them. And so just the fact that they're offended actually doesn't reflect on the fact that you didn't include them on the email. It reflects on the fact that in general, you're not doing a good job.
of keeping them informed such that you even had to like draft the email in the first place or that they would take it in a negative way because in the past you've made them feel not included in a conversation and so like on the communication front for me it always feels like my fault either in that situation or more globally
I'm not doing my role as a communicator effectively enough. Do you get offended if you're left off of an email? This is the great lesson of being at the top of the pyramid is that you're not allowed to get offended about things because there's no one above you to get offended at. And so it's in a way, it's like, I can't be petty anymore because there's no one who would react to the pettiness. I'm not at all saying that managers below me are in any way petty, but I was at times in the past petty.
about things like this. And I cared about them in a way that as soon as I became head of engineering, I stopped. I don't have that luxury of complaining to anybody. I really liked somebody was describing Bill Campbell and they said, His greatest gift was that as a leader, he had this incredible knack to see the world through each employee's eyes, which I thought was really wonderful. And something I think a lot about, to your point.
If you sit all the way at the top of a pyramid, your experience is very different. What you know is very different. The context you have is very different. And so being able to see the world through an IC engineer, engineering manager, whatever, is a great gift and a superpower. And over time, I think...
extraordinarily challenging to do. I mean, you lose it. I don't remember that much. It's been a long time since I was in IC. I had a re-IC stint seven and a half years ago. I don't recall that much. what was difficult or easy at that scale anymore. And so you just forget. They always say it's hard to teach something when you're an expert at it because you don't really understand why people are failing at the basics because you've so internalized them for you. It's like adding one plus one.
I think similarly for me, there are times when things don't happen. I don't understand why they're not happening. It's almost like, wait. I don't comprehend how this failure mode is showing itself. But that's because I just don't remember what it was like to be in those positions and how difficult it is to deal with certain classes of problems, right? I've forgotten the problems as much as the solutions. Moving in a little bit of a different direction.
If someone was to come in and shadow you for a day or a week, maybe back when we were all in an office or maybe now virtually, do you think there are things they would watch you do that they would say, oh, that's a little bit interesting or I'm surprised that he does that or operates that way?
Are there things that you think are a little bit weird or unique? And if so, why do you do those things? Or why do you run the team in that way? You're hitting on a personal fault. And it's not humility. I don't want to call it humility. I have problems thinking of myself as different than what a reasonably intelligent person in my position would do. And so it's hard for me to think that I do anything, frankly, in a way that's super interesting, especially day to day. There's like...
One thing that I believe in really, really strongly for Plaid right now, which is I think we will succeed if we're really bottom up in our approach to problems. I think one thing that will be quite surprising to people is that my most common answer to a lot of organizational issues that come up is to just say, hey, that's great. Why didn't you tell?
and then insert the name of the right peer about it and be like, you need to solve it with that person. I really want the leaf nodes across various functions. to figure out 90% of the more difficult things on their own. And I've kind of advocated that quite a lot at Plaid. Not saying there's not a decent amount of top down and that happens here and there, but I write multiple emails a day, which is like, yeah, thanks for telling me. I appreciate an FYI.
I don't understand why you and blah, blah, blah can't solve this on your own. Why do you think this is so important? So for me, bottom up is specific to, I think, Plaid right now. Plaid is kind of interesting because we have three...
very strong stakeholders to almost everything that we do. And the stakeholders would be on the one end, we have financial institutions. On the other end, we have developers. And on the third end, we have consumers who are going through this link flow that we've built. And so this complexity is such that it's very costly.
Because everything has three stakeholders. You generally don't want three stakeholders for all decisions that you make. That's not good. It's really hard. And financial institutions' incentives are not the same as consumers. They're not what our developers want. So what we try to do strategically is explain a little bit how you think about the three.
things. But at the unit level, if every time someone runs into a problem, it goes up to me, the cost for me to understand the specific problems of those three stakeholders as it applies to whatever the product is. is ginormous it's just way too complicated but on the ground on that team at the bottom they actually have all the knowledge that they need because
Or they'll know somebody who understands the financial institutions specific to their domain. They'll know somebody who understands specifically that customer segment. So, okay, this is banks that want to use Plaid for doing something. Or it's Google that want to use Plaid. Or it's like a little startup that wants to use Plaid.
And then at the same time, they don't understand the consumer framing, which is like an average person who's trying to connect an app and what are they're going through. They'll have those links back there. The decision to them just seems really complicated because it has high stakes. But when they push it up to me. For me, we have so many segments of developers. Financial institutions have such a varied set of points of view.
And then on the consumer side, between privacy effects on conversion, it's very, very complicated. I don't have any additional insight. The world is just too complicated for me to chime in on it. And so I keep pushing those problems back down because...
you don't get any benefit from going up to me. The only questions that I want to go up to me, frankly, are questions where allocation of budget or of people is a hard trade-off. So if we don't have enough people to both make customer set A and B happy, that's my job. My job is to be like, okay, let me work with Garcia and figure out.
Well, if we can't do both, which one do we do? Or do we do both half-assed? Like, what do you want to happen? How's it going to affect the business? I can help make that decision in a way where the Leaf team won't be able to because it doesn't just touch on their priorities, but on...
those of other parts of the org. I'm not saying other businesses aren't complicated, but I think for us, we keep running into difficulties because of the complexity of the stakeholders. And I really want the units as low as possible to learn. how to deal with that complexity on their own. Because I think that's how we'll move fast. Did the importance of this or the core concept of decentralized judgment and decision-making, did that crystallize for you organically?
Or do you spend time in a certain way? You then have these insights. My initial reaction generally for something like this is this should be about culture. It should be about values, principles, culture, and creating it. What I have found for this specific example.
on the bottom up is that sometimes you need to create the forum for the people with the different perspectives to talk to each other and feel like it's up to them to make the decision. I was mentioning the example where I keep replying to the emails.
It's kind of bad actually that the emails are coming up. What that does tell me is that because they keep happening, people don't feel like they have a way within those smaller bottom-up units to actually get to the right resolution. So I want the bottom-up to work.
The reality is people want to do it, but it's not quite working because there's some missing element there. And that's the hard problem to solve, actually. The cultural thing you can do, but if it's still not working, you have to ask yourself, like, what's process missing or incentive missing or something like that?
As to initially, how do we think that this was the right way to approach? I mean, the truth is we were already kind of bottom up for a number of things. But as we grew, the number of things that weren't solving themselves bottom up kept increasing.
And I think it took us a little bit of time to recognize like, hey, this stuff used to solve it. Why is it not happening now? From that, you have a bunch of questions. Is it, do we hire the wrong people? Do we have the wrong process? Do we not have the right culture? And you use all the knobs, right, to reinforce it.
When you tried to sort of figure out, and maybe this is sort of something you're actively working on and don't have an answer, what the root cause for why stuff was bubbling up, was there sort of a crystallized reason or was it, like you were saying, many knobs that had to be turned? We were bottom up, but within functional walls.
We were very strong functionally. Historically applied, like engineering design worked really well together. And then we grew a product function. So then EPDS worked really well together. But I would say like the separation between those and parts of go to market.
The membranes weren't that fluid. And so people would share information, but the decisions weren't being made. That's kind of the diagnosis. So that's one area. The interesting root cause behind that actually comes from a lot of trust and respect for other functions. So you kind of assume that what the other side is doing is the right thing and you really like trust them. But that means you haven't built a muscle for like arguing with them.
for going from like consensus to making hard decisions. Like those things weren't happening. And that's because we had these really strong multifunction lines, but we have like a really strong legal team. And every time legal has done anything, it's like the quality of the work is.
A plus, but that also means no one's used to asking legal if there isn't like a different way to approach and solve a problem. So I think that was the core diagnosis, like extreme respect and strong functional lines, but not many membranes between. After you diagnose that, you're like, well, what's the best way to solve that? Do you embed people? Do you do like a matrix thing? Do you restate your principles? Do you make a point of like...
Making examples out of people who actually cross the functions. There's, you know, the tools are always endless. That's like the fun part. Management. It's like, which tools do I use? And how do I measure whether we're actually doing better and all that stuff?
But yeah, it came from good places, right? Who doesn't want to have like strong functional identities and a lot of respect for your coworkers? These are like positive qualities, but you just got to see them at some point to their logical conclusion as you grow.
You always have these kind of scale problems where things that are good at one stage don't end up being good at the next one. That's life. That's what's fun about the role. You identify the problem. You solve it. You move on. Something else becomes not as good as it should be. You identify. You solve it. You talk to peers. You make a mistake.
eventually you find the right solution, you move forward. You were just sharing something pretty interesting, this idea of you have a bunch of tools that you can go to to sort of solve a problem. Can you kind of expand on that? What do you think your toolkit is? There's some that you... find are particularly impactful or maybe underappreciated? I'm a pretty big believer in like culture and values and then incentives that align with the values. So a funny one that maybe...
people don't realize can be super helpful is creating like tokens or heroes. Tokens would be objects that you reward for a specific behavior, but you make the like object. kind of fun to go after. You make it like a point of pride for the team. So on this team that I worked at once, we had a model of the rocket ship from Tintin. It's like this cool looking 20s or 30s.
vision of the future spaceship that's like red and white checkered. It was really cool. It was like maybe two feet tall and it had a really nice feel to it. And what we did is every two weeks, all of the managers... describe their like two highlights and two lowlights from the last two weeks. And then we'd all vote and give that spaceship to the team that had the most impact. And then you would come out of the manager's meeting and you would go to that team and you would give them.
that spaceship and the pride of having that spaceship. And oddly enough, people started to like, When they were going to have a launch or they were going to have a feature, they'd really try to get it to go really well when it was happening because they really wanted the spaceship. Because you didn't get the spaceship if you got the impact slowly, like you had to like.
get it. It had to be kind of a splash. I'm not saying it's good always to optimize for the splash, but people took pride in that spaceship. And oddly enough, they took more pride in that thing, I think, than they did in getting green on their OKRs or meeting their bonus targets or whatever it was.
the spaceship took a life of its own as a token of making these launch moments really great. So that's a token. I think I've seen it used in a lot of places, but it's interesting because it means you can substitute something that's non-monetary.
non-OKR, and you can create a subculture around a new value or a new thing. And like humans, we love the object. We love the token. That's one that's interesting. There's a person version of it. It's like where you make the heroes, which I think has many.
downfalls as well, but do the same thing with some people that you put on pedestal. You can even immortalize them by then giving awards to people that are in the name of the heroes, which is a little weird, but you can do it. Humans want to be like other humans sometimes. We have role models. That's a thing, right? People look for role models. They look for a path.
that they can mimic. So I think if you do it with people, it can be really powerful. Just for the record, I'm not big into the people one for Plaid because we have a strong humility kind of feeling. And so that's not something that we do, but we've tokenized a few things. So here's the thing. As a leader, you can decide to do this in a very active way. You can create the token. It's kind of weird. And if you do it in a way that's too overt, people realize that you're just trying to like...
gamify their incentives. I'm fearful now that my team will listen to this, but it's powerful. The best tokens happen naturally. You know what I mean? They happen within the team and then you kind of help nudge them. You help make them a bigger thing than they were. But the spaceship example, totally artificial.
Let's make the spaceship a thing. It's a thing. People are really excited about it. End game. How do you know if your engineering team is running at peak performance outside of, and maybe this is the most simplistic answer, outside of, are you? achieving what the business needs to achieve? Well, you suck right now because that's my answer. Do you step back? The answer is, is the business hitting its goals? And is it okay with how much money is being spent on engineering?
And if the answer to both of those is yes, do you care if people work one hour a week or if they work 80 hours a week, as long as the business is thriving and you're okay with a budget number that you have in engineering? In my mind... That's like an extremely artificial one hour versus 80, but you kind of shouldn't care. So my answer is actually it's that answer applied just to engineering goals. I don't care how many hours people are in the office. I don't like.
Use Git Prime to measure productivity. I'm not saying I shouldn't. I'm not saying that's not a good tool, by the way. It's not what I do. What I look at is the percentage of our OKRs that were green. And I use very, very simple feedback cycle. If you're green on 90, 95% of your OKRs, I would like for you to be more ambitious next time. And if you're green on like 50% of your OKRs only.
I would like for you to be better at estimating and more realistic about what you can do the next time around. How do you know if that's a performance problem or an estimation problem? It doesn't matter. I will ask the manager to answer that question. But just like at my level, I don't care.
I just want next time to get closer to AD all the time to meet my business goals. But I create an environment where people are trying to be ambitious and trying to do good work. We have pulse surveys about that. a belief about most of the humans that I get to work with. And one of the things that I get a lot of peace out of is that I work with people who are trying to do great work, who are ambitious, and they want to be successful. They want to feel like they have high velocity.
They want to feel like they're efficient with their time. And so I provide a framework for them to either challenge themselves more or be more realistic about what they can do. Now, the scenario where they're all like lazy. and just being green just to game the OKRs, that's pretty far from my reality. If I thought that's what was happening, I would no longer use this approach to OKRs. But I have zero indication that that's the problem. What I want us to do is hit business goals reliably.
Getting 70% to 80% on green on OKRs is that. If we're more green, then I just think we need to strive for more. We need to push for more. That's the way that you get people to work harder. And if we're falling behind, I'm going to be like, let's get better at estimating. And if it happens to the same team, to the same tech lead, two quarters in a row, I think then we start asking ourselves different questions.
What about the key indicators of organizational health? One is sort of are you productive and effective? So that's are we achieving what the business needs us to achieve? How do you think about the health of the team? At a really high level, I look at Pulse. I look at KPIs and how we're trending towards them. I look at our annual goals. I look at churn. I look at hiring rate through the funnel. There's like a dozen things that I look at.
But for each of my managers, it better be art and not science. They need to understand the morale of their team, not just from their pulse score, but from the one-on-ones that they're having. I trust them. I hire them for their judgment about how much technical debt we're adding.
whether we're hitting our goals. So we have a framework to think about things like technical debt, which is you measure how much of the team's time is spent on keeping the lights on, how much of it is spent reducing technical debt, how much of it is spent building new features. how much of it is spent on prototype work.
You can look at that and if a team is spending 50% of its time keeping the lights on and another 20% on technical debt, you know there's something deeply wrong. That's why I ask my managers to look at it. I give them some frameworks and ask them to look at the data and to make per team decisions.
Sure enough, at a talent review or a team review, like every six months, something won't smell very good and we'll go deep and try to understand what's happening. And are people unhappy? Is the team no longer focused on the right problems?
Is it like a motivation thing? Is it like a capabilities thing? And so on and so forth. On that sort of framework around keeping the lights on technical debt, et cetera, when you're in equilibrium or it's in balance for you, what do those ratios look like? I think it's company dependent. Because some of it depends on how much technical debt you've accumulated in the past, right? I think if you're in a really good place, a really, really good place, like a really good team will spend 15.
maybe percent, one, five outside of SRE kind of teams, but a team might spend 15% of its time, maybe 20 keeping the lights on. After that, on top of that, it kind of depends what the rest of it looks like. So if you're working on backend and infrastructure.
You might have a concept of system maturity, which is like how many of your systems have playbooks when they have downtime, how many nines they're operating at and things like that. So a team that's trying to get from three, nine to four, nine. It might only have 20% KTLO, but it might have 60% working on technical foundation because that's what you need in order to get from like 3.9 to 4.9. Beyond that, you need to fundamentally rethink.
how your systems work because you only get to 4.9 if incidents are automatically resolved, basically, or close to it. Because if you have humans that are involved, their page and getting room and looking at things, you can lose that 4.9 like really quickly. So a team like that might have a much higher percentage of foundation and then very...
little in the new product, new things, or prototypy stage. Whereas if you look at a product engineering team, you might have almost nothing in KTLO, just very basis. But the way technical debt will show itself is that... you have much lower velocity on features that you're building.
And that's something that for me is actually subjective. That's something that we'll trust surveys for. Like if those teams feel like they're really slow relative to how they were before other environments that they've worked on, that's when you know that you need to invest a lot in technical debt reducing work there.
It's also very company dependent and team dependent. At Plaid, we have a team that deals with very sensitive parts of our system. And there's like one area specifically gnarly. Think of the kernel in your OS. You don't let anybody like...
touch that code without being careful. There are a lot more code reviews. Everything's architected. There's always specs. Specs are reviewed by a bunch of people. So it's like, forget the KTLO framework, just like the velocity of the team is slower, but they're touching something like...
really, really sensitive, and they have naturally high foundation, just because if they make mistakes, it's bad. You have to have that subtlety. I think it's really hard to step back and say, oh, every team should be operating at 15% KTLO. 30% foundation and everything else is product work. That's just not how it works. As we get into the last couple of questions, I thought we might do a very quick lightning round where I sort of throw out a question and you sort of give me your...
60 second synthesis or most important thing or most important idea? I'm going to try, but as you can tell, I'm verbose, but I'm going to do this. This is a challenge. Great. Well, I've set context and so we're good to go. Is there a specific question you ask when you're doing interviewing? Maybe it's interviewing managers of managers or directors or what have you that you find is illuminating. 100%. I asked them to tell me about the time that they failed.
I provide more context behind the question so that they can be honest with me and tell me about a true failure. 50% of people either cannot come up with what I would call a real failure. They give you a fake failure that actually makes them look good. So 50%, they either make that mistake or the other mistake that they make is they point out a failure and then they clearly haven't thought about how they would have behaved differently.
if they had a time machine and could go back in time. Basically 50% of people fail that question and hence don't move forward in the process. When do you hire for experience versus potential? Feels like a false dichotomy, both. Both at all times? no i think always for potential i think experience sometimes you need it sometimes you don't
Obviously, if you're hiring a principal engineer, how much do you really care about the potential? You're already getting somebody that's almost close to the peak of their discipline. So I think at the high end, if you really need someone with that role, you will care most about experience. But I think if you're looking at in the five...
to 10-year experience range, you would not sacrifice on potential, in my opinion. What do you look for when hiring engineering managers? I look for that overwhelming sense of responsibility, that overdeveloped sense of responsibility.
I am a big believer in a deep dive into the best things that you've done as a manager and some of the things that you failed at, as I mentioned before. I think in the deep dives and the successes that you've had, I push hard for people who did things outside of their lanes.
I have a set of questions that I think get me there most of the time. You can't be too direct about it because if you ask somebody directly, like, tell me about a time you were high ownership and operated outside of your lane, like anybody's going to be able to manufacture an example. What you want to do is...
go through an example that doesn't look like that and see about how they thought about the problem outside of the bounds of pure engineering or engineering management. If someone's thinking about that, they might want to become an engineering manager.
or eventually a manager of managers, et cetera, et cetera. Are there any things that they should look and reflect on themselves that would help guide whether they can be exceptional at that? I think you can only be exceptional if you genuinely care about people.
if it makes you happy to deal with people problems. The care is nice, but you have to get joy out of dealing with people problems, I think, to be an exceptional manager. If you don't get joy, it's going to be a pretty painful experience. How do you think about titles? I think most places I've worked, I would prefer not having titles. I think the danger of titles is that the best idea doesn't win and that it creates kind of an internal hierarchy as to who's A-OK you have to get.
for something to happen or whose ideas have more merit than not. So generally that's why I'm against titles. There are, I think, certain situations where they're useful when you actually have someone who knows better or who has more experience that is relevant to a problem.
you want for efficiency's sake, for people to align behind that person and just not question them. I just think you can do that with roles, like tech lead, with things that aren't title, or you can really set expectations that, hey, this person... has the background and the experience necessary. And we're all here to help them drive this project to success. So you can do it outside of titles. That would be my preferred path. How do you get around the fact that a lot of human beings like...
the sense of progress and growth that comes along with a career ladder? Well, you can have a career ladder without titles. So what are the names of the rungs on the ladder? They're like... E2, E3, E4, E5, E6. Nobody knows what you are. You know what you are. You can feel the accomplishment for yourself, but because other people don't know what it is, they're not gonna look at you differently because of your level.
And by implication, right, the point of a title structure, people will use the titles internally. They'll say like, oh. so-and-so is a staff engineer. I think you need to get a principal engineer to review that. And that seems like you need like a senior architect for something of this size, right? Those are the kind of behaviors that I want to stop.
I like much better, like Alice or Bob is the expert in the system. They're really the person that I think should be the prime reviewer for your tech spec because they really know a lot about that. It doesn't matter what Alice and Bob's level or title is, right? It's just, they're the right person.
because they know the most, so they're going to be the most helpful for that problem. And so is that how you've set things up at Plaid? Yeah, no titles, but we have levels, but they're private to yourself. And do people not share their levels? Yeah, some people do. It doesn't mean anything in how work gets done. No one values the level that you have in terms of your importance. Like if a new grad has a really great idea and can defend it in a tech spec, more power to them.
We do have one thing. We have a senior IC kind of offsite. Senior ICs of a certain level or above meet up to discuss cross-team kind of concerns in architecture. We've created some forms that do select on levels, but it is not viewed internally as a token of worth. Have you noticed any downsides or unintended consequences?
Sure. Recruiting people who love titles becomes more difficult. Do you think there's positive selection? Like if they're wrapped up in titles that you'd rather not have them or it actually has nothing to do with if they could thrive at Plaid?
I think if people really care about titles above all else, I think in the kind of culture that we have at Plaid, it may be a little bit weird. So a good benefit of titles is actually like, you know who to speak to on another team when you're looking for somebody who is like a sort of authority.
As orgs get bigger, like if you have a 2000 engineer org and you're looking to touch system A and you know system A is owned by a team, isn't it nice to know immediately who's the person on that team that I should speak to?
who's like an expert on that system. Like if you have titles, it's easier because you just look for the most titled engineer on that team. So there's like information discovery advantages to them for sure. I don't think they're all bad. I think with things like tech lead and...
Other things that we've done, we can get the humility and a really good high humility, like low ego culture, fairly easy with what we have. Pretty sure you can do a title too. I mean, there's companies with titles like Google. that I've done super well and I think have great engineering cultures. So again, this is like the pragmatic point that I made earlier, like a lot of ways to create a culture and a company. My observation on Silicon Valley is that we're all operating in like local maxima.
of what great engineering could be. Because when you think about it, we're all learning from Google, right? There's Google managers, and then they go to like Dropbox, and then the people who learn from them go somewhere else. Then you have like...
Managers from Facebook, same thing. And then you have like the Amazon tree and you have the Microsoft tree and you have the Netflix tree. You have all these trees, right? And these companies do it differently. They're all successful. It's not like there's one path that's better.
But they're all smart about the trade-offs that they make and the culture that they have. Some are good at some things and not good at others, or they have different strengths. But I think overall, we're like at the infancy. of how you build great software. You're like, it's been like 60, 70 years, like it's not really the infancy. But I actually think compared to building bridges, we're still at the infancy of this world. And in Silicon Valley, especially.
Right now, there's these templates about how you build companies and how you build engineering teams that are being passed down. And now you have enough people who've done it two or three times. But if you look at the origin of the templates, it's just a few companies. And so... I think it's kind of exciting. We're still learning and playing with things and seeing what really works. And I think there's both a lot more variety.
of things that need to be tried but also i don't think the trade-offs of what's best and why is yet totally figured out so for me personally i like the culture that we have without titles
But I don't think by any way, shape or form that we could not have built a successful business with a different approach. It just would have had different trade-offs along the way. Do you think we get outside of this local maxima just by having somebody see the world differently and try something bizarre that then...
works and then it gets disseminated and it becomes the new normal and that process happens and fits and starts over long periods of time. I think that's how humans work, right? That's like... the history of human government and democracy and all these things. I think like the distributed team thing that's happening right now, it's funny because I think it's forcing people to, for example, consider different ways to make decisions.
That never would have happened otherwise. It's kind of forcing us out of our existing set of practices. It might be better. You might come back to in-person and have learned a bunch of things from remote work. It'll grow and change. There's a big market for being slightly more efficient at building a company. I think that's a great place to wrap up. This was really wonderful.