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

EP.08 - Jean-Denis Greze

Jean-Denis: [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.

Brett Berson: [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 [email protected].

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 

Jean-Denis: [00:03:41] 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 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.

You need to find a path forward. 

Brett Berson: [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, 

Jean-Denis: [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. 

Brett Berson: [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.

Jean-Denis: [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 

Brett Berson: [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, 

Jean-Denis: [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.

Brett Berson: [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. 

Jean-Denis: [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 

Brett Berson: [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. 

Jean-Denis: [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 

Brett Berson: [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?

About how to do that? 

Jean-Denis: [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 

in 

Brett Berson: [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 

Jean-Denis: [00:22:30] focus?

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. 

Brett Berson: [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.

Jean-Denis: [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 

Brett Berson: [00:25:40] 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 

Jean-Denis: [00:26:07] differently. 20 would tell me actually, that most of the things that managers complain about their lead of leads or VP's 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 or.

You didn't provide clarity on the strategy or what I should be optimizing for. And then you've decided to like 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 is like, 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 I could have just communicated about that earlier as the 

Brett Berson: [00:27:04] recipient, you think something's quite easy and it seems very simple.

Why didn't I know about this or wasn't a communicator while I was in 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. 

Jean-Denis: [00:27:18] 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 like add them afterwards, you're like, Ugh, it's going to like hurt their feelings of 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 like 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 

Brett Berson: [00:28:39] offended if you're left off of an email? 

Jean-Denis: [00:28:41] This is the great lesson of being at the top of the pyramid is that you're not allowed to get offended about things cause 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, you know, 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, 

Brett Berson: [00:29:12] uh, 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 the 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 

Jean-Denis: [00:29:46] to do. I mean, you lose it. I don't remember that much. It's been a long time since I was an IC.

I had a re IC stent 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 gets hard to teach something when you're an expert at it. Cause you don't really understand why people are feeling at the basics because you've still 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 this is 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 forgotten the problems as much as the solutions. 

Brett Berson: [00:30:28] 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, but 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 them team in that way? 

Jean-Denis: [00:30:51] You're hitting on a personal. Fault. And it's not humility. I don't want to call it humility, but 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. And 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 ride multiple emails a day, which is like, yeah, thanks for telling me.

I appreciate. And FYI, I don't understand why you and blah, blah, blah, cancel this on your own. Why 

Brett Berson: [00:31:59] do you think this is so important? 

Jean-Denis: [00:32:01] So for me, bottom up is specific to, I think plaid right now, plot is kind of interesting because we have three very strong holders 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. Like you generally don't want three stakeholders for all decisions that you make.

That's not good. It's like really hard. And financial institutions, incentives are not the same as consumers are not what our developers want. So we try to do as strategically as explained 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 with 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. I want you to supply for do something. Whether it's Google that I won't use plat, or it's like a little startup that wants to use plod. And then at the same time, they don't understand the consumer framing, which is like an average person who's trying to connect to an app and whatever 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 like privacy affects on conversion, it's like 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 if people is a hard trade off.

So if we don't have enough people to both make customer set a and be happy, that's my job. But my job is to be like, okay, let me work with Griseo and figure out, well, if we can't do both, which one do we do or do we do both? Half-ass like, what do you want to happen? How's it gonna affect the business? I can help make that decision in a way with the leaf team will 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 

Brett Berson: [00:34:37] 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 

Jean-Denis: [00:34:49] 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 processed, missing, or incentive missing or something like that.

That's doing the initially, like 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 processes? Do we not have the right culture? And you use all the knobs right. To reinforce it when you 

tried 

Brett Berson: [00:36:10] 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? 

Jean-Denis: [00:36:21] We were bottom up, but within functional walls, we were very strong functionally. Historically, they 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 a 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 a consensus to making hard decisions, like those things weren't happening. And that's because we had these really strong multi-function lines, but we have like a really strong legal team and every time legal has done anything, it's like the quality of that 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 co-diagnosis like extreme respect and strong functional lines, but not many membranes between after he diagnosed 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 that 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 of 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 that you just got to see them at some point to their logical conclusion. And as you grow, you always have these kinds of scale problems where things 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 it, you solve it. You talk to peers, you make a mistake. Eventually you find the right solution. You move forward. 

Brett Berson: [00:38:22] 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. 

Jean-Denis: [00:38:37] I'm a pretty big believer in like culture and values and then incentives that align with the values.

So a funny one that may be. 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 10, 10, it's like this cool looking.

Twenties or thirties vision of the future space ship. 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 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 will come out of the managers meeting and you would go. To that team and you would give them the 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 to spaceship because you didn't get the spaceship.

If you've got the impact. So lead, like you had to like get, it had to be kind of a splash. Now 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 like getting green on their OKR or, you know, meeting their bonus targets or whatever it was.

The spaceship took a life of its own as a token of making these like launch moments. Really great. So that's like 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 like 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 they 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 like role models. That's a thing, right? People look for role models. They look for like 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. Cause we have like a strong humility kind of feeling.

And so it does 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 over to people realize that you're just trying to like gamified her 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 were really excited about it and game. 

Brett Berson: [00:41:44] No. 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? 

Jean-Denis: [00:41:55] Well, you suck right now. Cause 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 the aspect. Do you care if people work one hour a week? Well, 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 extreme, an artificial one hour versus 80, but you kind of shouldn't care.

So my answer is actually to that answer or applied just to engineering goals. I don't care how many hours people are in the office. I don't like use get 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 OKR that were green.

And I use very, very simple feedback cycle. If you're green on 90, 95% of your OKR hours, I would like for you to be more ambitious next time. And if you're agreeing on like 50% of your OKR is only, I would like for you to be better at estimating and more realistic about what you can do the next time around.

Brett Berson: [00:42:58] How do you know if that's a performance problem or an estimation 

Jean-Denis: [00:43:00] 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 ed 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 and 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 gain the OKR is like, that's pretty far from my reality.

Like if I thought that's what was happening, I would no longer use this approach to OKR, but at zero indication that that's the problem. What I want us to do is hit business schools reliably. Getting 70 to 80% on green, on old cars is that if we're more green than 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 like 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. 

Brett Berson: [00:44:15] 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 this 

Jean-Denis: [00:44:26] at a really high level? I'll look at pulse. I'll 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 judgments 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 you work. You can look at that.

And like if a team's 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 asked 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 and sure enough, at a talent review or a team review, like every six months.

Something will 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 like a motivation thing. Is it like a capabilities thing and so on and so forth that 

Brett Berson: [00:45:37] 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 are those ratios look like?

Jean-Denis: [00:45:46] I think it's company dependent because some of it depends on how much technical debt you've accumulated in the past. I think if you're in a really good place, a really, really good place, like a really good team, we'll 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 are 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% KTL yellow, but it might have 60% working on technical foundation because that's what you need in order to get from like three, nine to four nine beyond that you need to fundamentally rethink.

How your systems work because you only get to four nine, if incidents are automatically resolved basically, or close to it. Because if you have humans that are involved our page and getting a room and looking at things, you can lose that 49, like really quickly. So a team like that might have a much higher percentage of foundation and then very little in the like new product, new things or prototype stage.

Whereas if you look at a product engineering team, you might have almost nothing in KTL 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 seams 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 applied. We have. A team that deals with very sensitive parts of our system.

And there's like one area specifically gnarly. Think of the Colonel and your own boss. 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 Katie yellow 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%. KTL low 30% foundation and everything else is product work. That's just not how it works. 

Brett Berson: [00:48:00] 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 62nd synthesis or most important thing or most important idea.

Jean-Denis: [00:48:14] I'm going to try, but as you can tell them for both, but I'm going to do this. This is a challenge. 

Brett Berson: [00:48:18] 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 

Jean-Denis: [00:48:31] a hundred percent.

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. Now they give you a fake failure. That's actually like, makes them look good.

So 50% either make that mistake or the other mistake that they make as 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 

Brett Berson: [00:49:02] you hire for experience versus potential 

Jean-Denis: [00:49:05] feels like a false dichotomy, both. Both at all times. No, I think always for potential 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 disciplines.

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, 

Brett Berson: [00:49:32] what do you look for when hiring the engineering managers? 

Jean-Denis: [00:49:35] I look for that overwhelming sense of responsibility, that overdeveloped sense of responsibility.

I am big believer in like a deep dive into the best things that you've done as a manager. And some of the things that you failed that I mentioned before, I think, and the deep dives and the successes that you've had. I push hard for people who did things outside of their lanes. I've 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 is going to be able to manufacture an example where you want to do is go through an example that doesn't look like that and see about how they thought about the problem, like outside of the bounds of pure or engineering management.

Brett Berson: [00:50:20] 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? 

Jean-Denis: [00:50:35] 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 it, 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 whose AOK 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 like roles like tech lead or 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. 

Brett Berson: [00:51:40] 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 where 

Jean-Denis: [00:51:52] you can have a career ladder without titles. 

Brett Berson: [00:51:54] So what are the names of the rungs on the ladder? 

Jean-Denis: [00:51:56] They're like, , 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 going to look at you differently because of your level and by implication, right? The point of a title structure that 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 kinds 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 primary veer for your texts back because they really know a lot about that.

It doesn't matter what Alison 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. 

Brett Berson: [00:52:45] And so is that how you've set things up at Plex? 

Jean-Denis: [00:52:47] Yeah, no titles, but we have levels, but they're private to yourself. 

Brett Berson: [00:52:51] And do people not share their levels?

Jean-Denis: [00:52:53] Yeah. Some people do it doesn't mean anything. And 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 and architecture.

We've created some forums that do select on levels, but it is not viewed internally as a token of worth. 

Brett Berson: [00:53:23] Have you noticed any downsides or unintended consequences? 

Jean-Denis: [00:53:28] Sure recruiting people who love titles becomes more difficult. Do you think 

Brett Berson: [00:53:32] there's positive selection? Like if they're wrapped up in titles that you'd rather not have them or that it actually has nothing to do with, if they could thrive at plat.

Jean-Denis: [00:53:39] I think if people really care about titles above all else, I think in the kind of culture that we have at pod, it may be a little bit weird. So good benefit of titles is like, she, like, you know who to speak to on another team when you're looking for somebody who is like a sort of authority as org get bigger.

Like if you have a 2000 engineer org and you're like looking to touch system, a and you know, system is owned by a team, isn't a nice to know immediately, like. 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. Cause 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 really good high humility, like low ego culture, fairly easy with what we have pressure. You can do a title, Sue.

I mean there's companies with titles like Google. That I've done super well. And I think of 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 maximum 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 and you're like, eh, there's only, 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 yeah, 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, a business with a different approach. It just would have had different trade-offs along the way. Do you think 

Brett Berson: [00:56:05] we get outside of this local maximum 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 in fits and starts over long periods of time. 

Jean-Denis: [00:56:19] I think that's how humans work, right? That's like the history of human government and democracy and all of these things. I think like the distributed team thing that's happening right now.

It's funny. Cause that's like it's forcing people to, for example, consider different ways to make decisions. That would never would have happened. Otherwise it's going to forcing us out of our existing set of practices. It might be better. You might come back to in person and I've learned a bunch of things from remote work it'll grow and change.

There's a big market for being slightly more efficient and building a company. I think 

Brett Berson: [00:56:44] that's a great place to, to wrap up. This was really wonderful.