SPEAKER

Jean-Denis Greze - Head of Engineering @ Plaid

Jean-Denis Greze is Head of Engineering at Plaid, the technology company giving developers access to the financial system and the tools to build many of the most influential applications and services of the modern financial era. Companies such as Venmo + Paypal, Coinbase, Robinhood, Acorns, Clarity Money and hundreds more are built on Plaid.

"The thing that I think makes over a 10 year period, a really good engineering organization is that at any one moment in time, it has very few spikes, but over a long period of time, it has all the spikes."

- Jean-Denis Greze

Prior to joining Plaid, Jean-Denis was Director of Engineering at Dropbox, where he led the growth, identity, notifications, Paper, and payments teams.

Prior to Dropbox, Jean-Denis worked in fintech in New York and has CS degrees from Columbia as well as a JD from Harvard Law School.

Announcement

Nominations for the 2020 Inspiring Leadership Award are now open!

We created this award to recognize role models of engineering leadership, for the work they do every day to make a difference in their teams and organizations.

Share their story with us and submit a nomination HERE

Shownotes

• How to mitigate weaknesses in your organization using the strategies of Isolation & Outlets (2:47)
• How to use “Isolation” in your business units as an org building strategy: examples from Plaid and Xbox (8:44)
• How to use “Isolation” in recruiting & product strategy: examples of apprenticeships to hire, roles you've never hired for, and incubator programs (12:17)
• How to use "Outlets" to create different conversations, adopt different values, and set new priorities (16:38)
• The “Portfolio Theory of Time Allocation” (19:41)
• How to introduce "Shocks" proactively to change and adapt your organization (28:32)
• How to intentionally use Acquisitions to “Shock” your organization (33:35)
• How to intentionally use Reorgs to “Shock” your organization (36:06)
• The power of peer groups and re-reading (45:19)

Transcript

Two strategies to mitigate weaknesses in your organization

Jean-Denis Greze: I just described how, like the role of the leader is to understand the problems, understand the kind of organ that you need and then understand the weaknesses of that org. And then I wanted to talk about how you mitigate the weaknesses with like very specific examples.

So I'll talk about two strategies. One is called isolation. The other one, I call outlets.

So isolation. Is it. So if you recognize that it's good to have few spikes and you don't want to end up in a world where you have a generalist org that tries to be good at everything, but is not really good at anything. You're going to have a problem. Which is, as you grow, whatever spikes you have will not be enough for you to be successful.

And I'll give you the perfect Plaid example. When I, when I joined. Three and a half years ago was a small teams about 20 people, right? And about nine months into my tenure or about like 30 to 35. , we built three products that were very different. One we built a developer facing API as a developer, like a developer product. Great API, great docs. The second product that we'd launched about nine months earlier right as I joined. It's called Link. It was a consumer facing experience of linking your bank account.

So before that plaid was only like pipes in the background, but we decided to launch with our SDK the visual experience of connecting your bank to your app, so that the user experience of like selecting your bank and connecting it. That what that's plaid, right? Whether you do it today on like Venmo or whether you do it on Robinhood, like , that UI is powered by us.

and then the third problem, the third kind of problem that we have to solve is what you referred to earlier, Jerry, which is pretty hard, is integrating with the banking system. Because there's no standard in the banking system that is wildly kind of followed on, on how to connect. An app to a bank account. That's the only reason plaid exists. Cause there's no such standard.

these three problems are very different, right? Consumer is about user research. It's very like design focused. You don't know exactly who your user is like anyone with a bank account in the United States. That's like, Hundreds of millions of people like good luck, understanding exactly who they are and what they need.

Developers - very different, very easy. You know who they are, right. It's FinTech developers. There's like five to 10,000 FinTech companies. They're developers. So you know, what they care about. API's that work. SDKs that are really easy to use. But there's some weird things in the world of, of developer tools, which is when someone uses your API, you can, you may change the version of the API. There's almost no chance they'll switch the new version. Right. It'll take them like two years to decide, to spend engineering, to make any kind of update. Right.

Whereas on the consumer front, you can iterate as quickly as you want. You can do A/B tests, all sorts of stuff.

So these things were already pretty different. And then we had bank integrations, bank integrations are like a whole different set of problems, like lots of banks. We have different relationships with different banks, the APIs and contracts with them change all the time. And so things break, like it's like code that accumulates rust at like 10x the rate of normal code. a lot of pressure from customers whenever a bank breaks because their users are unhappy that they can't connect their bank account. it's a much faster pace... almost like issue focused style of engineering. On top of infrastructure, that's all about building tools so that you can integrate faster,

so these three problems. And what we found with our small team is that we can not create a culture that could solve all three problems really well. It was very, very difficult because the pacing was too different. I think consumer and developer were like, kind of close enough. You could kind of do it, but like the bank integration stuff was just a different beast.

And what we're trying to do is we're trying to build a Swiss army knife. and then engineers were moving teams and they just didn't have the right mindset for the new kind of problems that they had. And it just wasn't working.

and I got very lucky, which is, and this is the kind of decision that I should be making when I'm walking around, but that's not how it happened. one of my managers Suroosh, who was in charge of the bank integration side of things, he came back from the, end of year holidays. he comes back and he's like... "it's not going to work."

And I'm like, "what do you mean? It's not gonna work?"

He's like, "we're not going to be able to build one team that can do all this stuff. It's just not going to work. it's like rock paper, scissors. Like we need like a scissor somewhere else. We're all rocks here. No, no. We need a scissor somewhere else to build a team, a culture that is focused on crushing how you integrate with banks and building like a true... consulting term... "center of excellence" about how you integrate with banks. Let's be the best in the world at how you integrate with banks."

And he said that, and it was, it was a right, like prompt and it caused, it caused me and William who's the CTO and, Samir, and we're like, yes, we need to do this.

And then we started looking at other offices and we ended up opening an office in Salt Lake City where we hired this manager, Akira who leads, the office who is incredible. And Salt Lake City is a machine at integrating with banks and getting the best data quality in the business. Right. And data quality for us it's like the, it's the blood of the organization. Right. It's the thing thing on which everything is built. and I think if we hadn't done that, I don't think we'd have the outcome that we have.

Jerry Li: . You'll call it lucky to have that moment of asking the question. But I want to ask is that after the company transitioned to a bottom up decision making

Jean-Denis Greze: No, I, that was after it. So I came in advocating bottom up and then the.

Jerry Li: yeah. Then it's not lucky because it's led by the earlier transition to bottom up, people feel more ownership. Then they feel empowered to the thing about these kind of problems

Jean-Denis Greze: I mean, that's very generous, Jerry, I'll take it. Yes. I'll take all the credit in the world. And I think at the end of the day, I'm just happy that it happened. Right? I do think we create an environment where someone could like question a core assumption of the business and I think that's great. You know, it could have happened faster. I'm just really happy that it happened.

How to use "Isolation" in your business units as an org building strategy: examples from Plaid and Xbox

and I think the realization... to go back to spikes, right? This is what's happening. What's happening is we're becoming an organization where our spikes, because initially we didn't actually do the bank integration side, like in the history of the company, you're wrong. We were really good at just developer focus at work. So if you look at the spike of plot, the initial spike, right. The like spirit of how engineering and product approach thing is around building API. It was not around bank integrations and we couldn't get that to work really well now that we needed it to build integrations with 10,000 of banks.

So the insight is like, you need to isolate this new set of strengths that you need to a totally separate business unit or organization that has different culture, different values, different metrics, different way to approach engineering. Like, yeah, they still do quarterly planning with us, but underneath that, the you know they're like day to day flow is different.

And, now you have this, this thing that's so amazing. It's like a jewel. You have like this diamond inside of your org and you can still be really good at building developer facing products because it's like in a separate place and you can still build a lot of connectedness. Like the teams of groups have amazing respect for each other, doing our hack weeks. They work together. All the things are really positive, but we never would have been able to do it in one place.

and I think you could have done it in one office maybe, but like putting it somewhere else, like allows for so much identity creation to happen so much process innovation. Right. Just imagine this. Normally when I walk around the office, for example, and I see things happen that are like weird. I'm like, why is this happening? Is this the right thing to happen? But in Salt Lake City, they could go in like Yolo and try new things. And there was no fear, right. That me or someone else would notice something that was weird.

And then I would hear about it after the fact. Now it'd be like, well, that's a little bit of a weird way to approach recruiting, but like, I guess it works, right? Like why was I going to do about it? It was working.

So I think it's a really powerful idea. And what you notice often actually is when companies open second offices, now they generally only do it because of talent. They're like either they acquire a company or they're like, Oh, it's easier to recruit in Seattle. Let's go to Seattle. Or in New York, let's go to New York.

They do that. And then they're like, "Oh, I'm really worried that the Seattle office is going to be really different from the home office." You're doing it wrong. You want it to be different! You want it to have, you want it to own a thing and you want it to feel proud of how it's different, Because it's so powerful. It's so powerful , you get this free option to build something that can be good at something that you're not naturally.

So I think you should endorse the difference. I mean, some businesses maybe need everything to be the same. Right. And they don't have that, that challenge. I think for us, it was very early that we had the challenge and it was very stark. It was very scary to open a second office because when I was at Dropbox, when we opened other offices, we definitely wanted the other offices to feel like the home office. We eventually actually got smart about making sure they owned really like serious product areas, but they still all felt like Dropbox. I think at Plaid we were quite deliberate at that point that it needed to be different and as like a really powerful learning.

and I think lots of other companies and startups should think when they opened another office for talent, they should still think like, Maybe you should change some key things here and it could be an advantage for us against our competitors.

the canonical example on this is from Xbox division at Microsoft. And on this online, you can find some writing, but right. Xbox. The initial X-Box division when it was launched. I think like in the late nineties built software in a way that was totally different than the rest of Microsoft.

they had like PMs and QA engineers were like embedded in these small pods. Like it was totally different org structure, totally different way of approaching things because they realized that the way they built windows or like word or whatever, wasn't going to work for the console.

it's a good story. You can find good materials on it, but if you don't believe that or what, I just said that makes any sense like, study that. There was a totally different set of buildings and so on and so forth.

How to use "Isolation" in recruiting and product strategy: examples of apprenticeships to hire, roles you've never hired for, and incubators

Cool. So that's , that's an example of isolation in space. I'm going to talk about another form of isolation. I'm gonna apply it to here to recruiting. I was hinting before that one of the problems with having a very high hiring bar, for example, lack of diversity, the lack of risk taking with the kind of candidates that you bring on.

So like a really nice solution to that is to create a totally different way to recruit for certain role.

So like an example that you see in the Valley, I think Slack is pretty notorious for having done this well is having an apprenticeship program. They may not call it apprenticeship, but. The idea there is they have a program maybe aimed at. People without a formal CS background, maybe someone who did a bootcamp, but you could also have it work for just like risky candidates that are outside of your core capability.

And the idea is people only get employed for six months, right. They have like a window with a clear goal after that period of time of what they need to do to succeed. So, suddenly, right. You're not worried about bringing on people that aren't going to work longterm because it's, it's by definition capped at six months.

And you're getting a pool of candidates who are really hungry to break into the industry, right. Or to break into the kind of role that you have open. And so they're more than willing to have a competitive mindset, And to go into this role where the initial interview is not nearly as complicated. And then once you're there, they've got to prove that they can make it.

And then at the six months you have a really clear objective bar and then once people quote "graduate" and if they happened to get like a full time offer... then they can enter the bubble where they feel just as worthy of being there as everybody else. you've not done space isolation, but you've done this kind of role isolation where there's clear expectations, There's no way it can bleed into your broader culture. it's a six month contract. With like a clear criteria to get a full time offer.

I mention Slack cause I think they have a good apprenticeship program. It's not structured exactly like this, but I think for purposes of, the podcast, just thinking about how you can implement something like this is another way to still maintain your culture exactly it is, but like negate some of the negative aspects of your traditional approach.

The other place that I think this works really well for, I would really recommend it is... for specialized roles. if you're hiring for a specialized role that you've never interviewed for before, say you're like looking for a reverse engineer or like a, you know, thing you could do is just pay someone much more for a six month contract, pay him like double the normal rate, right?

Like make it really cash incentive for them to join. So you can take risks on candidates that you don't really know how to evaluate. And then at the end of it, you know, if they, if they're great for you, if they're not, yeah, you paid a little bit more, but at least you didn't spend six months of your life in the abstract, like arguing internally about how you're going to evaluate this candidate that you can't evaluate in 30 minute whiteboard interviews or 60 minute whiteboard interviews, because they are true specialists. They're like a firmware specialist or they're there, like reverse engineering special. There's something that you know, you're just, you're, you're not going to be able to uncover in a really small bit of time.

And I see some companies do that, but I think, I think it's an approach that should be used, much, much more.

the final kind of isolation that I've seen work really well are incubators. like idea incubators, like Dropbox has one, you know, Google has a bunch. It's the idea that you, create a sub part of your org. It can be , your main office that just has a totally different approach to say creativity or problem solving. I think that that can be powerful,

you know, often like idea incubators at bigger companies kind of get made fun of, but the reality is that means you have an org that once was really good at creating ideas that somehow has become average at everything. And then it needs to recreate the magic. I'm trying to avoid you losing the magic, but if you lose it, you can try to recreate it in a pocket somewhere.

Jerry Li: So hearing what you've said so far, in order to create Isolation engineer, a sandbox or sandboxes in different places, within your existing culture, so that it's safe to run experiment

Jean-Denis Greze: Yeah, more pithy and clearer way to explain what I just said over the last 10 minutes yes. It's a sandbox. It's a sandbox and I would say like space or the network of how people relate to each other.

I think there's another kind of sandbox which is a sandbox in time, which I think is even a more powerful idea, which is what we're going to talk about next.

Jerry Li: you have example of that?

you have an example of that

Jean-Denis Greze: Yeah. So, so all we've talked about here is like you, break out a sandbox in your org that has other characteristics. It sounds really nice, but it's difficult to do. it's difficult to do because sometimes when you create a second office, They'll have like an antagonistic relation maybe with the first one or you try to do you try to sandbox like a creativity center within your org, but really can never let go of the things of the initial. Or the worst cases it can bleed into the rest of the org right. That's kind danger.

How to use "Outlets" in org design to create different conversations, adopt different values, and set new priorities

So another way that you can have outlets is to do outlets over time. so the, the canonical example or hack weeks. That companies do hack weeks is just a way to basically allow everybody be super creative, right? Sometimes they're for recruiting or they're you think they're for to make people happy.

But like at the heart of the hack week is you take an org that is very, uh goal-driven and suddenly you're like your goal can be anything, be as creative as you want to be for a week. Let's see what comes out of it. Right. It's a way to say we can have different characteristics as a company for a short period of time.

So like one of the best we call Plaider days, at plaid, the best hack week Plaider days that we had was the most recent one. and the reason is we focused it on, projects that impacted inequality or systemic problems, in finance, around financial inclusion, the underbanked funding for black founders and FinTech.

All of these things that came out of black lives matter that I think were FinTech related. and so what we're able to do is get everybody to think about this problem that like, normally we thought about a little bit, but we were not like centered on it. And number two, we were like, there are no goals except to be creative and see if there's things that we should follow through on.

And it was an incredible week, right. We provided a lot of information. Like we, explained to people the reality that like bank fees. so for example, like we have statistics, like 80% of white people pay no fees from banks, but only 60% of Blacks and Latinos like pay no fees. Right. We put a lot of information out there to, to, to make a case for why it was important to look at these problems. And then there was like 50 projects that came out of our small team of things that we could do. And out of the 50, there's like, I don't know somewhere between like 15 and 20 that we're going to end up following up on.

And there's no way we could have gone that creativity and that focus on that without actually creating the space and time to do it. So that's an example of an outlet, you allow everyone to wear a like different mentality, right? For a period of time.

Jerry Li: and be someone else and be be else or be a littlebit different from from normally who they are

unleash. A unleash A lot creativity.

unleash

Jean-Denis Greze: the the way, notice how powerful it is if you're explicit about the spikes of your org. Cause if you're explicit about them, then people also know the kind of things that they don't normally do and they can, they can endorse it during this period of time. So this is the obvious example, the less obvious example one step is like design sprints.

But that's what design sprints are. I don't know if anyone here is very familiar with them. If you aren't, you should look about them. I think Google ventures has a really cool website that explains them, but it's a way for a team of stakeholders across engineering, product design, marketing to get together. And in one or two weeks, try to like create solutions to any problem space. You're trying to be extra on the product building cycle to extremes, right from like months to two weeks.

well you do on the first day of a design sprint is you break people's mentality around how you approach problems. You would get them to break all the assumptions of the organization that they're in so much like the hack week. It's a way to basically add creativity, to an org that maybe doesn't have it naturally.

The Portfolio Theory of Time Allocation

But there's two more versions of outlets. But the third one I'm about to amendment is my favorite, because I think the best and I think is way underused, including by myself. And I will, I'll provide a Dropbox example for it.

Cause I think that's the place where I saw it used that So I called us the portfolio theory of time allocation. So most managers use a portfolio theory in terms of resource allocation and by resources generally mean people. I don't like calling people resources. So I'll call it a portfolio theory of people allocation.

What they say is we'll have 20% of our engineers working on brand new projects, and then we'll have 35% working on feature improvements, the core product, and then everyone else will be either keeping the lights on or making foundational improvements to the infrastructure. Right. They have these percentages for these core categories of work, and then you go into quarterly planning and you're trying roughly to be in the percentages because you've decided that's the right thing for the business.

Great. Okay. What if, as opposed to breaking people by allocation, you broke people by time. So you said. Well we're going to do is we're going to, for two months, we're going to focus on building new features. And then for one month, we're going to just focus on technical debt. And then for two months, we're going to build features.

And then for one month, we're going to focus on technical debt. And so what you do is as opposed to asking people to like, wear all the hats all the time. Well you just you're like you can get them in a mentality for a period of time that is optimized. for a certain goal. And then you just tell them when it stops and then to endorse a different mentality.

So I'll give the example that I have is from Dropbox. this is like 2013. So, you know, it's like seven years ago, it's a long time ago. At the time Dropbox for business, it was a small product and it had been built by like a skeleton crew of engineers almost as a side project. Okay. But it was growing. Like businesses want to choose Dropbox. It wasn't just a consumer product.

That's the leadership was quite smart and they were like, Hey, listen, we need to have more people work on Dropbox for business. And so they hired this guy, Matt, we ended up actually being VP of engineering and Dropbox, really fantastic engineering leader. and typical, by the way, fashion at the time, like Matt had been like a, like a VP somewhere. He'd like been a VP of VM-ware like a principal engineer.

And he started as an IC for his first, like two months. And then he was like a line manager, right? , every manager at Dropbox at the time, it didn't matter what you did before you like, had to start as an IC for a bit, which is fine. And then you have to be like a line manager before you could be a director. Like the rule was, we just didn't hire directors. We like didn't hire lead of leads into the org. It was, it was honestly, it worked well. Like you could look at the team that was at the time that joined that company and it was. It was a who's who,

so Matt joined, And, if I remember correctly, it was like, no one had answered like support tickets. They were like, the backlog of bugs was like hundreds. Okay. Because they'd been built as this kind of side project and it, you know, the, it hadn't had a full time team. And so he was starting to build a team around it and it was just. People did not have the muscle. People were just building features. People didn't have the muscle of like, there's a Jira ticket. Something is broken. We need to fix it. Right. All the PMs, everyone was just like, let's build features. Right. Let's build the next things that people want, but not about the quality of the core thing.

And so Matt was like, no! He like stopped all the feature work. Right. And he said, we are just going to do tickets. And I think if I remember correctly, I think the rule was that everyone would wear ties to work, or these are people wearing tee shirts. And so they wore ties to work until they got to like ticket zero or like it was also, there's some launches associated with it.

So he'd got this rack of ties with this other guy called, called Tito, who who's like head of engineering. It's they got this rack of ties and the people would come into the team and they would like put in the tie around their they're facing the tee shirt. And they were just doing it until they got to like, , ticket zero or whatever it was.

but it was for a period of time. So no one could be like, Oh, we're always going to be like a ticket answering kind of org. Right. There was no fear of that. And no one was different people thought it was like, cool. We need to do this. This is the way to like rally into it. So for a period of time, people internalized this totally different mindset.

And what's cool is coming out of it afterwards people then understood why tickets were important all the time. You know what I mean? So you'd like you've done this time, escalation of this very different kind of work that normally people wouldn't have respected or thought it was great. And then you got the benefit afterwards that people understood why you always had to make some time for tickets or else you're going to have this weird, like ticket death, March that would happen. and, I think it's a very, very powerful concept.

The other way you see it used often is like, these Polish sprints. Right. Where if you have a team that has like, you know, two weeks sprints every once in a while, they're like, Hey, everyone, let's spend like two weeks to Polish. It's just very powerful.It's very powerful outlet. Cause you can just endorse a different mindset.

And again, you can get people to do things they won't enjoy doing longterm because they feel that it is like capped in time. So this is like another outlet for an org, right? If, you look something that you're not good at, can you do it?

And the good thing by doing the time specialization is that like, they get really good at it for that period. Right. And they're really excited and they can compete as a group about having the most reach outs or the most engaged candidates by the end of it.

I think this kind of like isolation over time is super, super powerful.

Jerry Li: it sounds like, this, time isolation is a good way to introduce new behaviors by designating a period of time that you can try this behavior. And maybe afterwards some of that got lost, but at least maybe you sort of percentage will stay. And, I feel like a few example you mentioned sort of related to that.

Jean-Denis Greze: Yeah, I agree. But I think that's where, that's where my little spidey sense worries. So I know I gave the example with Dropbox about how people started realizing that tickets were an important part of normal work. But I do think the danger is that the new behavior leaks into the normal culture in a way that the fights against the spike. Right. I think that's the thing that's the thing that you need to worry about with any of either outlets or isolation strategies is some things are okay to make it. Right. Cause you're like people have realized a new thing and it's something that should be part of their day to day.

But if you have too much stuff like that, you're basically increasing the cognitive load of your mainstream mode of operation. Right. And ideally your mainstream mode of operation it doesn't, it's not supposed to have cognitive load. That's the whole, that's the whole thing we're striving for.

but you know, this is, this is the part that's provocative. I think some people will listen and be like, actually I do want a well rounded org. Right. And if you do want a well rounded org, actually this is a very good strategy I think, to bring that knowledge right from the specialized zone into the mainstream zone. But I view it the other way. I view it more, like, be careful about that happening

Jerry Li: Yeah it's a great it's very useful to point that out.

How to introduce "Shocks" proactively to change and adapt your organization

Jean-Denis Greze: So, those are some examples of, what I call outlet strategies. the last thing I want to talk about is change and adapting

the world changes. The challenges ahead of you change. Spiky orgs have a problem, which is when the problem ahead of them is different. They may no longer be the right organization.

And my, thesis, like the thing that I think makes over a 10 year period, a really good engineering organization is that at any one moment in time, it has very few spikes, but over a long period of time, it has all the spikes. Right. It is flexible over time. It can adapt itself to challenges ahead of itself.

Maybe every 18 months it changes or it spins off, you know, a child organizations like, or other offices that can take on the challenges. But it, you know, it doesn't say stagnant in one mode.

cause like change is normal, right? and it's uncomfortable and it's difficult. And when you're spiky, it's very uncomfortable and it's very difficult because you've basically made everything optimized for just a few dimensions. And if anything, you will have antibodies, you'll be allergic to other ways to do things.

I'm gonne talk about one example of a way that you can wake up an organization that's too stagnant. So this is again like a COVID example. Its about Plaid, and after that, I'll go back to generalities.

So an interesting way to think about how you change an organization is you shock it. You shock it into changing. So I'll give you an example of a shock

during the covid crisis. The federal government passed legislation, supporting a paycheck protection program. PP P basically it was a system whereby the government would with third parties work to offer loans to businesses. So that they could pay payroll. Right. And the idea was that a lot of businesses were longterm. Okay. But short term, they were going to let go of their workers. And that was going to cause a huge financial crisis in addition to the C ovid crisis

So this is interesting because the way the program was designed is it required lenders to make the loans. But to make the loans and then for themselves to get reimbursed by the federal government, they had to get a bunch of information from businesses and the information from businesses. A lot of it was held either by other financial institutions like banks or by payroll providers.

The audience may not know a lot about FinTech, but one thing you hopefully realize is that it takes a lot of time for various parties in FinTech to agree to do things together. It's hard to negotiate with the bank. It's hard for a payroll provider and a lender to decide to work together. It just, it takes time. It takes six months, 12 months, 18 months for contracts to be signed. You can take six, 12 months for APIss to be integrated. Right?

Why? Because a lot of players in the space are not tech companies and because there's a lot of risk averseness right. because it's people's money. Right. And so you have to be very careful.

What's amazing is like literally as PPP was getting passed, literally every FinTech bank lender, payroll provider, everyone was working together and collaborating. It was like, honestly, one of the most powerful moments that I've seen in my career. Everybody was thinking out of the box, even the most conservative kind of players. Everyone was trying to help businesses and Americans regardless of their commercial differences, people were putting aside personal gains, like offering APIs or products on which they were never going to make a penny, right. All to, to share into this positive outcome for the country. It was great. And, there's companies out there like square that I think that have, spoken about how well worked, who they work with and some of the really positive outcomes. But you can almost look at any like bank or FinTech and it's pretty impressive how people work together.

so that's the shock, right? And the shock has a lot, all this positive action and, and PPP loans got dispersed and yes, it didn't all go perfectly, but you know, it happened much better and much faster than anyone thought it could have happened initially. So you step back from that and then you come to work the Monday after like, you know, like these, these players that have started working together and you're like, Wait a second. Why does it take us 12 months to do this normally? Considering if we can just like align slightly, apparently we can do it all in like five days or like two weeks.

And so the funny thing about the shock is , it's caused in FinTech a number of people to be like, well, maybe there's just a better way now. There's still a lot of other structural challenges and you're not going to get that broad alignment that you had in that moment. But even internally for us to plan, it's like, why can't we ship faster? Why can't we work with our payroll providers better?

But what's interesting is like some of our partners are like more willing to work with us now. Right? There's like more Goodwill in it. There's more of a realization that it can be faster.

So this is like, I think this would be like very powerful. Right? You can introduce a shock to a system. This is not one company. This is about how multiple players work together. And you can get to an outcome that affects longterm, how well people work together.

So talking about adaptation. I think the first strategy in my mind is shocks. and the problem with shocks is their very difficult to like artificially create.

How to intentionally use Acquisitions to "Shock" your organization

So there's, two main categories of shocks that I've experienced. The first ones are, is acquisitions. Acquisitions are a shock. They can often be a very positive shock.

So that the Plaid example would be, we acquired a company called Cuovo about a year and a half ago. they're similar to Plaid in many ways, but they had a better product around sharing brokerage information. and so they allowed like fintechs to build apps that help you analyze your financial portfolio, for example, or plan for retirement. And they were just better at sharing data in the, in the broker space. But they, also did things that were pretty similar to what plaid did in terms of integrating with banks, and working with consumers and developers.

So after we acquired them, like a wake up call for me, was to look at how they integrated with banks. And I don't mean the technical, how, and although there were technological differences, but yeah, it's like the programming languages were different. The way they thought about ROI was totally different. The way they staffed technical program managers with engineers, it was different. And it was a shock because they were better on some metrics than we were, whereas before we thought, you know, we were the best.

and so it was a shock and it was a shock, not just to me, like, you know, we sent Some engineers to like go in like collaborate and learn how they work. Then people came back and they were like,x, y, and z are better. T ey weren'th better across the board. Right. But they were things to be learned. And so it was a really interesting shock.

And sometimes you look at acquisitions, right. And there's like a desire to, to either like, keep them totally separate or to make them part of thethe mothership fatherland like to just integrate them, but don't forget to get the learnings, right? Because that group of people that are acquiring, even if it's an Aqui-hire, they have a set of capabilities that you don't have. And if you force them to integrate you, lose the capabilities. Right, but you could either learn from them or you could create a pocket that is good at this separate set of problems.

That's the first kind of shock that I know how to introduce. The second kind of shock that I know how to introduce, will not have any friends in this, in this audience, but it's forced competition actually within your organization where you set two different orgs to tackle the same problem. If you do this, the end result almost certainly is that they will take different approaches, different technical approaches, different cultural approaches, because they're set off to compete with one another. And generally people who compete, try to generate like different values.

I've not seen this work, so I'm not going to like recommend it, but I have heard of it being used by large companies. Whether it's a good one or not. I don't know. But I think it's worth, at least considering . I would love if anyone in the audience has ideas of how you can introduce shocks, let me know.

How to intentionally use Reorgs to "Shock" your organization

final point is the one shock that you can introduce , that I would advocate you should introduce is, a reorganization. So that's like, that's like maybe the last big point.

everyone's like, Ugh, not another reorg. That's often. I think those reorgs are reactive. Right. What happens is you notice that you're no longer aligned with your business goals and that your structure is broken and it is not optimized to what you need to be successful at. And so then you cause a reorg, right? And you're reactive and being reactive is very bad.

I want to talk about reorgs in like a more progressive proactive way. So the example that I would give you is, avoiding the dreaded matrix org. So if you're, hopefully everyone knows this, I'm not gonna explain it, but there's, three main structures for teams you have vertical teams that own the full stack from the product experience all the way to almost SRE in some cases, it's a virtual team organization, and you have a horizontal team organization where you split your stack in layers that are stacked on top of the other.

And then there's a matrix that tries to get the best of both worlds. And I think we all know how I feel about the matrix. So we're not going to talk about it.

An interesting idea just for the, for the listener is whether you should just say every 12 months we switched from vertical to horizontal, regardless of business needs. I just want you to play with that idea in your head. That means everyone on your teams knows that every 12 months you switched from vertical to horizontal. They know that for 12 months, they're going to be really good at iterating on new products and owning the full stack as in vertical. And then they know that the 12 months after that, they will be really good in a horizontal world, right? At building quality and stable APIs and common abstractions. And on it goes.

And if people knew that ahead of time, right? This is if you're being proactive about how you reorg. They will not stress out about their manager changing or their career tracking. It will align perfectly with performance review cycles, right? There's like a lot of nice advantages.

It's actually impossible. I've never seen this being done. I just want to point out that you can communicate a strategy around when you reorg that is aligned with a longterm view about what your organization needs to do to be successful. And it's totally okay. And I think if you do that, like people will not feel like. Oh, no, another reorg. They will feel like you're being thoughtful as a leader about when is the right time to change the strengths and weaknesses of your company.

And that's, that's the main thing about a spiky org and the thing that's really important at the end is. You can't be reactive on the spikes because when you switch from one, like spiky kind of set up to another, it is very painful, it's like a really, really big reorg. And so my, you know, my urge is if you have to do this, if you have to change your spikes and it's rare, you've got to Telegraph it a ton so that it feels to people like something strategic that's been coming for six months. That's right for the business that everybody knows about.

And so at Plaid for example, It's not a huge reorg, but we are going to create a product platform group. And it is like this Telegraph. People know that I'm thinking about it. They don't, no one knows exactly when it's going to happen, but there's no doubt that it's going to happen. There's people on product teams that have no doubt that they will be pulled or asked to be pulled into this platform.

And just the fact that people know that is like really reassuring. It is not going to feel like a giant reorg. It's going to feel like we knew we had this problem. We knew where the solution is, we're waiting until the right time to enact a solution.

so I think reorgs are the best tool, but you need to telegraph them. And that means you need to know your strengths and weaknesses. You need to know your domain and you need to know how you need to change ahead of time. And then when you, whether you do it at the perfect time, I don't think matters a ton. I think what's important is that you've telegraphed when you're going to change it. And you understand how it's going to change, like people's incentives and so on and so forth.

Jerry Li: that way people expecting it. And also they know this is a good for the company, longer term. So my question for that is when you do the reorg do you just shuffling the mapping between team and their responsibilities, or are you also shuffling the team itself? Like people changing their, managers, because that can be, another thing that can be disruptive

Jean-Denis Greze: yeah, that's a really good question. It actually reminded me of. There's forget about yours, right? There's some companies who believe it's really valuable for managers to move around independently of teams so that managers are aware of different parts of the business. So even if the org structure overall stays the same. They'll like every 18 months or something force kind of managers to move around, especially like, directors. and it's actually, there's a lot of good to that because that I think can end politics. And it can make people aware of, of different ways to do things, but it has a real cost. I think people over time identify really strongly with our manager.

So my opinion is I don't think there's a really good answer to what you've asked. I think this is where we get into art and it, it depends on your structure. Like obviously if you can reorg keep every team the same and just point them at new goals, like that's perfect. I just don't think that's possible because generally the point of the reorg is you need to get talents to be organized differently to focus on different problems.

So maybe you need all of your systems thinkers to be more on the same layer. Whereas before that you wanted every team to have a systems thinker, right. And if you do that by definition, all those people are going to change managers every time that it happens. So I think you just have to look at the details of what your organizational structure is.

We have at Plaid, we try to actually force people to move teams like ICs every 18 months. Because we want, the reality is we want people to understand that the business is changing over time and we, we are changing team structure.

We don't change it for, we don't do like engineering wide reorgs, or we do more like the localized changes, but we do them pretty actively like every quarter or two. and we want people to understand that if it's the best thing for the business, they should be ready for it. And we also want people to understand different sets of problems that we're faced with. And so we want them to move around.

And I think we've created a culture where people are okay with that, but we talk about it in recruiting, right? So like, you know, if someone wants to work on the same problem for six years, first of all, you shouldn't be joining a, you know, 200 engineer company, or you should go somewhere much bigger that has like a six year roadmap.

but you know, if you really care about having the same manager forever, either we make an exception or you know, that you shouldn't come to plaid. Because it's not the kind of place that's gonna like promote that mindset and that's okay. Right. Because if you're transparent with people about it, you'll just select the candidates that want that experience.

Right. And again, we're not big enough that, like we have an engineering brand, there's a set of people that enjoy working at plaid and that's who we try to attract. And it's not for everybody. That's totally fine. You can endorse it. If you're honest with people about how things operate, you attract people who are okay with the constraints. So I just don't think we have a lot of people who would get freaked out about changing managers.

And so when it comes to reorging, I'm much more focused on who are the right people where, than I am on like keeping the management chains in

Jerry Li: Yep. And recruiting is a big part of building culture because that has to be communicated. And, up front with the candidates as a as a filter.

Jean-Denis Greze: So I think, that's the way I think about spikes and about how you, how you manage it. You know, obviously I haven't seen, so I've heard of some places that like, do pretty structured reorgs. I think Microsoft at times in its history was. It was pretty adamant about forcing like big changes in order to force adaptation. So I think that's a powerful concept

I think at plaid, what I've realized is from previous jobs, big reorgs are painful. Right? So I believe in adaptation, I just try not to do it across all of engineering at once, you know, as much as possible.

So, in our organization structure, we have kind of this big group that's horizontal. And then we have these vertical groups on top of it. And so often what happens is it's about the interaction between these two, that you have to move, you have to move things maybe from vertical to horizontal or horizontal vertical, like that's one of the big, like friction points. And the other organization. Like reorg lever that we press is, in terms of how we segment our users. Right. Do you segment by all developers or do you segment small developers from big developers? And I think there, you always have to adapt because I think it relates to go to market and marketing and how, how they segment customers.

So these are two areas as a leader. I think that you should also always look at it's like the boundary between the vertical horizontal teams. Number one. And number two, the boundary between user segments that you use in product design and engineering and how that maps to go to market, because you have changes. Right. And like clear example would be like, if you introduce a growth team, that's focused on like growing, like, do you have one growth team that's advising all of your verticals. Does each vertical have its own like sub growth pod or growth team? Like how do you think about that? And if you have one growth team and it really needs to go deep in an area, does it take over that group? Right. Or is it an advisor?

Like, and these are the kinds of things that change, right. Initially you can look at like history of like the growth team at Facebook or Uber. Right. And there's like one model for a few years, and then it kind of doesn't work at that scale anymore. And then you have to change to another model of how growth interacts.

So I think there's a s et, a set of problems where you could, you could figure out reorgs that have been pretty common in companies. And I think as an engineering leader, if you know about enough of those, you kind of know what to watch out for.

The power of peer groups and re-reading books

Jerry Li: I wanted to zoom out a little bit, What are the practices or resources do have for yourself to learn?

Jean-Denis Greze: the one I recommend the most is I have a few peers that I, that I talk to. they're close peers. It's, it's not like a hundred people. It's five to 10, either VPs or directors. and generally they're mostly at companies that are, you know, between half of our size and maybe four times our size. I just talk to them and share problems. So I have, a couple of VPs I have monthly calls with and we just, we just share ideas. that's really useful for

I've also a Slack with eight other VPs where we be asked questions, like I want to go deep with somebody and it's like, it's not me sucking knowledge or it's not someone lecturing me. It's like a back and forth. And sometimes I'm adding something to the conversation and some, sometimes they are, these are people that I know well, right. I would say that. they're friends, and so we, we don't mind being really honest with one another. So that's been really valuable.

There's also, I mean, you, you have such a community, right. , going to the conference that you're organized. even though I was only there for one of the days, I had like a lot of great Convos there, so that stuff matters.

And then I read, but I basically reread the same books. like high output management, I literally like rescan that thing all the time. And. It may seem silly, but like every time it's not, like I learned something new, it's not about learning. Cause I've read the book. So I've like, I've all the things, but you can't practice all of the things in the book. It's like too much stuff. Right. You like to forget half of it. So every time I read it, I remember something and I was like, Oh, I'm not doing that. And it seems adaptable to the current situation. there's a of these books that are, that are kind of good to scan through every once in a while.

Jerry Li: it's good to know that you keep reading the same book over and over again, and try to incorporate it because I totally get you. I feel the same. It's one book. And regardless of how many times you've made it there's always something that you miss and the reinforcement it really matters.

Jean-Denis Greze: I feel like maybe I'm too old I mean I'm definitely getting slower like intellectually as I am as I push in my forties Um but I don't have that much mental space to adopt a new system for anything You know I just like mentally I just can't I have a way of doing things that works pretty well for me And then anytime I read a new book about management it like adds 17 things that I'm supposed to think about And I can not think about 17 things I can think about three things right Maybe at most And so it's again this is the thing where I would rather take fewer fewer books like fewer frameworks Have the things be really high level right Like the the perfect concept of like the idea of spikes is not something that clouds your decision making every day It's not it's something that you maybe think about once a quarter right Or once every six months And you like force yourself to think in terms of spikes and the problems that you have and it helps to drive decisions It's really high level concept You don't it doesn't It's not a system It's not a thing It's not a framework It's not something that clouds or makes your life more complicated So I think that's the kind of thinking I wish I did more of or the kind of research that I have and even high output management which doesn't say a ton of things right It has like way too much for for me to be able to apply