What the CTOs of Plaid and Brex learned scaling their teams, skills, and products during years of hyper growth

The successful fintechs that found early escape velocity did so by rapidly responding to their customers’ needs for complementary products and services. There are just a handful of companies that were able to do this – to go from 0 to 1 in a way that required massive scaling and building product platforms that can support this growth. And a lot of times that required scaffolding, deconstruction, and re-scaffolding while the growth engine is revving.

Plaid’s Jean-Denis Greze and Brex’s Cos Nicolaescu are two of the best in the business. I felt like this discussion was a masterclass in what it takes to lead tech and product teams at the highest level. Having both CTOs on the podcast was also interesting to see where they concurred with one another and where they departed.

We discuss the biggest challenges they’ve learned in scaling and the organizational changes they’ve made to support different stages of their growth. We look at the acquisitions both companies made and how Brex and Plaid integrated new teams, technologies, and products. I ask both Cos and Jean Denis about their approach to talent and how their teams are organized to harness their people’s talents. Lastly, we drill down further into how their product planning and product pipelines work, and how both have evolved as their companies have grown.

Here’s my conversation with the CTOs of Brex and Plaid.

The big points

• Lessons learned in scaling the team. 
• How did the team structure change over time?
• Importance of domain expertise.
• Integrating new talent into the company. 
• The evolution of the business model. 
• Thinking about product surface area.
• Turning R&D budget into operating budget.
• How far out does product planning go?

Subscribe: Apple Podcasts I SoundCloud I Spotify I Google Podcasts

The following excerpts were edited for clarity.

The guests

Cos Nicolaescu, Brex: I’m the CTO of Brex. We empower employees anywhere to make better financial decisions. I’ve been here for almost five years now and joined when the company was really super tiny. We were like 40-ish people and engineering was about 20 people. Before that, I was at Stripe for about four and a half years, joining when the company was about 100 people and worked on financial infrastructure. I’ve been in the payment space for quite some time. And before that, I was working at Microsoft for about five and a half years. I worked on Azure and Office 365 way back when when we were first building those out.

Jean-Denis Greze, Plaid: I’m CTO at Plaid. I’m responsible for product, engineering, design and our entire product direction and technical strategy. As a company, Plaid exists to improve people’s and businesses’ access to better financial tools, so they can have better financial outcomes. And we do that by creating a platform and technology that enables banks, fintechs, and developers to reduce friction, have access to financial services, reduce the cost of moving money, offering loans, and just generally we want to increase access to financial services for everybody. I’ve been at the company almost seven years — from 40 people to about 1000 today. I worked at Dropbox before on the payment side, working on billing and subscriptions and growth.

Scaling for growth, in retrospect: Plaid

Jean-Denis Greze, Plaid: I’ll start with two things I wish I’d done better. Plaid in its early days was really good at zero to one. And I think, as we grew, we started to have a lot of challenges around building more reliable systems, building more mature systems. And so we really look to hire people who had those experiences. And I think we did a good job at that. But after a while, you take for granted that you’re really good at building new products, and you start to realize you’ve lose a little bit of that DNA. And so one thing I wish we’d done differently through hyper growth is focus more, especially in the middle years, on hiring ex founders, or people who had experience with zero to one. Eventually, we realized that we needed to grow that kind of power. And now we’ve got it back. And you can see our shipping velocity of new things has gone up tremendously. But I think there was a period, maybe like, three, four years ago, where kind of we lost sight of that.

And then the other lesson is hyper growth basically breaks everything all the time. I think as a leader, one thing for me is you have to keep that muscle of going deep on things, because your intuition about what’s happening on the ground actually changes a lot. You remember what it was like when you’re closer to the everyday engineer and the team, but then suddenly, you’ve added 100 engineers, and actually, the day to day experience of people on your team is fundamentally different than what you remember. And if you don’t rekindle that, if you don’t force yourself to go deep and go into the details and understand what’s going well and what’s going wrong, your mental model of the org doesn’t adapt as quickly, as the hyper growth is actually changing the org. So from a leadership perspective, that’s the thing that I do a lot more now. I go deep more and go talk to people more than I used to and try to understand what’s going on on the ground. Not because I think things are going badly, but because I need a better understanding of the day to day of folks.

Scaling for growth, in retrospect: Brex

Cos Nicolaescu, Brex: What I’ve noticed is that it’s not the absolute number that typically breaks or changes. There are times when Brex was growing so fast that I honestly couldn’t tell you exactly how many people we had. There are step function changes. And what I realized is that most of the times those happen when you add layers of management — like, every single time we added a new layer, a bunch of processes broke, more communication was necessary, and inconsistencies crept into the product.

The other thing that, for me, was very helpful when I joined Brex, there was no organizational structure. It was just 20-ish engineers, some front end, some back end, basically all working together. Every month, Pedro would decide what we’re working on. And that was kind of it. In that kind of growth stage, having to plan ahead and having a solid foundation, I think really helped us scale. I remember when I first joined, some of those folks felt we were too small to have a structure. Are we being too rigorous about these sort of things versus just like embracing the chaos?

With hyper growth, you have the chaos no matter what. I tell people, you either have a problem with things breaking too much because of growth or things not growing fast enough. I will always take the growth pain anytime. Having that foundation allowed us to constantly be ahead of that scale, whether it was team structure where we’re hiring, the roles that we’re hiring, bringing in management, bringing experienced managers who have seen this scale and absorb it.

In the last year, the thing that’s changed the most for me is the high order bit in the organization based on the scaling needs. Over the last 12 to 18 months, we have had significantly slower growth in terms of headcount and organization than in the previous few years when everybody was growing as fast as possible. And that also means adjusting how we think about what’s important for a manager, what his career trajectory looks like. But for managers, especially, I think there’s a lot of transformational focus in the last 12 months.

How teams have evolved

Cos Nicolaescu, Brex: When we started, everything in the team was basically front end, back end, no structure. The first thing once you add a structure, you start having the need for managers. But when I joined, none of the people on the organization had management experience — there were just really talented engineers, and for a lot of them, we were their first company or their second company. We definitely skewed more junior. And being able to figure out how to find the right balance between hiring externally and coaching for management was one of the early challenges.

And then you just start having more specialized roles. I remember we hired people for security, hard infrastructure, and data scientists. And then even within those data scientists, you start hiring ML folks and analytics folks and infrastructure folks, and you start getting more and more specialized. The challenge that all of us have at some point is, I’ve primarily been working on cloud infrastructure and back end services. I’ve done some front end — personally, I didn’t enjoy that. Now you have to familiarize yourself with all these different functions and disciplines and hire people that really know what they’re doing and empower them versus manage them directly and tell them what to do. Because I don’t know what the best data science organization in the world does — you hire someone that does that and then figure out how to help them.

My philosophy is to keep the org as flat as possible for as long as possible, and then generally have some formulaic aspect. There’s also time to figure out what systems they own. What the business problems, the goals are in the early days. My general advice for founders that I talked to is embrace the chaos and the change, because so many things are evolving so quickly, especially in that hyper growth. Over the last couple years, as things have slowed down, we’ve started finding more of a rhythm, more of a structure. You’re hiring zero to one people a lot, and you’re dealing with zero to one challenges, and then over the years, you’re starting to maintain stuff and evolve systems. And so changing the organizational structure probably doesn’t make as much sense to have massive shifts. I think that’s generally helped build momentum, as well.

Jean-Denis Greze, Plaid: A couple of things pop out. First of all, I’m hiring experts. I underestimated the importance of not just the traditional areas where you hire experts, these are people who have experience with scale, but expertise really specific to the domain that we have. At Plaid, we launched a really good fraud product. Initially, when we launched it, we had this kind of typical Silicon Valley hubris, which is like, Oh, we’re really at good data science. This is a data science problem — we’re going to be really good at it. And we actually built a really good model, but then we are selling to the fraud and risk teams at very sophisticated banks and fintechs. And those folks said, it’s great that you have like a new perspective on fraud, but they have decades of experience dealing with fraud and a certain way and vocabulary that they add attributes to their models, a certain way to make a decision.

So we had this great product, but I don’t think we had enough people on the team who actually really understood the user’s perspective on the other side. Then we started hiring people who had real depth in things like account takeover or fraud, or traditional ACH rails. And some of those folks’ backgrounds weren’t at startups. The reality is the domain expertise is so important. These are people who’ve lived fraud for a long time, so they understand it. The cool thing is you can still bring that new thinking to the existing approach, but at least you really understand how traditionally that domain thinks about the problem.

Second, you were talking about org design, and you made me think of reorg. First, when you’re hyper growth, your current org structure never feels good. It just can’t, because you set it at point A, and then you’ve got 50% more people 180 days or 365 days later, and it’s totally going to feel like it’s breaking. But you have this danger where you’re basically reorg-ing too much. One thing I applied that we did is we really forced ourselves through the hyper growth to just be like, Look, this is the way it’s going to be for two years. We’re going to power through the pain points. Embrace the chaos, because the cost of always trying to optimize when you’re going so quickly just doesn’t make sense. But, you take discrete points of time, like annual planning or whatnot, and you do it because you got to do it. But you don’t let it distract you the rest of the way.

And then we’re organized differently for the last few years than we ever have been before — we look more like business units. One thing that we did that worked really well for us is we split out platforms. And we were pretty explicit, like this set of functionality is a platform. But then for each of the BUs, we let them tweak the way they operate based on their customers and how their customers expected us to ship product. So, some of the BUs are shipping the UX and the UI that your end users go through everyday when they connect a bank account or verify their identity through Plaid. And there you can iterate pretty quickly on that because it makes sense. Another team has been building fraud models. Well, you don’t really want to iterate on your fraud model live — everything’s very different. When you have a new version of it, you need to do a proof of concept of back tests with your customers, the shipping timelines are totally different so that those teams need to operate differently.

It’s not just about org design. But I think you really have to ask yourself, like different parts of your product, different teams, they operate on different timelines. Some are shipping APIs. Some are shipping UI. And so you’ve got to adapt your process and the way that you operate. When we switched to the BUs, we have leaders who could change the way product, engineering, design, and data science operate. They could tweak the relationship between the BU and go to market for that product. And that’s proven. It’s been super useful because before we were trying to fit everything into one product development process, one customer approach, and it was no longer working as our product became more and more complicated as we’re selling to different customer types, and so on and so forth. I don’t know if we could have done that much earlier. But I think we’re very explicit about that change, and the whole company turned to it. And today, different parts of Plaid feel culturally different because of how much they’ve absorbed this point of view.

Integrating acquisitions

Jean-Denis Greze, Plaid: We did two big acquisitions that are pretty different. The latest one is a company called Cognito. They have an identity verification product. We acquired them, not just for the talent, not just for the technology, but actually for their knowledge and understanding of that space. And actually, we did not want their culture to normalize to Plaid’s. I think this is really important when you acquire a really successful business. You don’t want to mess with the magic, right? We’ve mostly left them, culturally, to operate as they always have. There’s some technical and cultural things where we decided it made sense to do the same. They plan the same way that we do. They do semi annual planning, roughly how everybody else at Plaid does it, because if they depend on other parts of the org. They use Linear for a lot of their products. But when they rely on the rest of the Plaid, they use JIRA, Slack — you define the interfaces that have to be in common, but otherwise, it’s not a pirate ship. I want this part of the org that thinks differently, because they need it for their domain. And as long as you don’t develop too much of an us-versus-them mentality, as long as everybody really understands that for my problem set, this is the right way to approach it.

On the technical side, it’s tougher — they use a different stack than we do. And it would make no sense to rewrite their entire product on our stack. And so what it’s meant is for our infrastructure team, it’s more burden. It’s like another language that has to be supported, like observability, RPC, all these things in the end, you’ve got to eat that cost. You can’t ignore those costs when you make an acquisition. There are other costs, like when they need a UI front end expert, that person goes over there. And they have to familiarize themselves with the new stack. And then if they don’t stay in there, and they go work on another project, you’ve kind of eaten those ramp up costs of that person, and you don’t get long term payoff. So you have to think about those things differently. You’re moving people around, and you don’t get the benefit as quickly.

Cognito is a different product that we added to our suite and wanted a cross sell. And that’s worked really well. A few years ago, we acquired a company that effectively did a lot of what Plaid does, it was like 70% overlap in the product portfolio: Quovo. And there, we actually made a really explicit decision that over two years, we wanted to totally integrate the stacks, integrate that culture, and only because they did a lot of bank and financial institution integration, we just wanted one way to do that. Now we wanted the best of both worlds. So there, we did actually take some of the way they did things and incorporated them into the Plaid way and then kept some of the Plaid things and had them adapt to it, because that’s how you would get the best benefit. But today, people don’t think themselves as Quovo. There’s none of that — it’s just Plaid. Those are two different approaches. I think whenever you go into an acquisition, though, you have to be really thoughtful because I’ve seen organ rejections or places where it really doesn’t work. I don’t think there’s one universal playbook. Like when we acquired these companies, I want to talk to dozens of founders and CTOs who’ve done integrations and it was like, what worked and what you learn is lots of different things work, but it’s very specific to the domain.

Cos Nicolaescu, Brex:: I very much agree, not a lot to add there. I would say we’ve done two major acquisitions, a company named Pry, which does financial reporting and helps founders do modeling for for early stage revenue. Then we acquired a company called Weave, which was building a platform for integrating with ecommerce platforms which we can then use for underwriting. And similar to Plaid, there’s different approaches — the platform stuff is less customer visible, more internal. So you have more liberties on what you do. But it was a very successful product when we acquired it and we didn’t want to mess with that.

At Brex, we very much subscribe to letting the cultures stay as independent as possible, because you’ve hired them for a reason. We actually had folks from Brex join those teams, moving to them when they joined. And it helped for two reasons. One, it helped bridge the gap in cultures and learn and disseminate that across the company. The way I look at it is the Brex culture actually folds to each one of these M&As and their cultures also adapt stuff from Brex.

And the second one is just inherent knowledge of the company: When we’re talking about companies where Brex and Plaid are roughly 1000 people, you’re acquiring companies that are like 10 to 100 people, so smaller scale. And that’s generally the case for most acquisitions that are not just mergers. Having some people that know how the company operates, know who to talk to, and know the systems can help accelerate so much more. It can also help bridge gaps when it comes to technical arguments or debates or decisions that need to be made, because they can provide context from both sides. The thing that I try to always make sure that there’s no us-versus-them. We typically let folks who join be called the like “Pry crew” or the “Weave crew” for some time, but over time, the fact that you actually add folks from Brex to those teams makes it less clear. It’s like, oh, that’s that entire cohort, that’s not Brex employees, because everybody is Brex at that point.

Scaling the product platform

Cos Nicolaescu, Brex: We’ve gone through two types of product growth: I think both of them bring their own challenges. Most companies tend to experience it in one direction. The first one is going from single product to multi product. For Brex, we started as a credit card for startups. And then we said, hey, we can make this credit card work for other types of companies. So we went through ecommerce and nonprofits and life sciences and other industries. Then we said, hey, founders really also need a back end, like what do you need before you even enter credit card, you need a bank account, so we built Brex Cash to facilitate that. And then over time, we’re like, okay, we can help companies manage their spend, because you go from this trust-based model to one where you have a finance team start putting some process in place. So we started building fund management, as well. So you can see how these things evolve.

For Brex, in particular, it was always an evolution that was very complementary and unified. So despite having all these different product lines, we have to learn how to operate as a multi product company and give different product cycles at different stages. But we didn’t actually go down the GM/business unit model, because they’re so interconnected. Like if you’re a Cash customer, you also have a card. And so there’s a lot of usability there.

The second type of growth in the product is in our persona. We started with startups. And now if you look at the last couple of years, we’ve moved so much up market and serving enterprise companies, public companies. We have companies like DoorDash, Indeed, Lemonade, and others who have very different needs. And so the spectrum of companies that you’re supporting for your customers is so wide that the product doesn’t make sense. When you’re talking about like, let me build feature X because a startup will use this feature, even if they use it, enterprise is so vastly different. You have to start adapting to that and even within each of these segments, we started in enterprise, you have employees and managers and the finance teams, but then we realize there’s a travel person and a procurement person. And even managers have different levels and different needs. You have execs at companies and you have EAs at companies. You just start diversifying the persona, starting to be very explicit about the segment you’re optimizing for and the persona, what’s the ideal experience? Sometimes that comes with tradeoffs for other personas, sometimes you can optimize for both, sometimes you basically build it slightly differently, depending on the persona. But that was a big change for us out in the last couple years.

Jean-Denis Greze, Plaid: Because Plaid is mostly an API company, meaning most of our products, even if they have UI or UX for someone to adopt them, something that our customer has to integrate with a new API, expansion into multiproduct takes much longer than at a lot of other businesses. At a lot of businesses, you build a new feature or a new SKU, and it’s in the UX, and then someone starts to use it, and you put them in a trial. And then after 30 days, the seat cost goes from $9 a month to $12 a month. And for us, that’s not really an option. So I think the first thing we have to realize is multiproduct for us makes a ton of sense, because our customers do want to consolidate APIs. There’s a whole lot of downstream problems like fraud, identity verification, speeding up the rate at which money moves around, that we can solve for our customers. But, given the longer timelines, we have to convince them, they’re like, Yeah, I want to do a trial, then they’re like, oh, we’ll put it on our next quarter’s roadmap, and then do the trial. And so the next thing is like it takes three quarters to get the product out into usage.

Given that, we’ve opted to be really picky where we go multi product, and we’ve looked at it through a couple of lenses. One, we have to fundamentally believe that we can offer best in class, meaning better than the best solution products in that vertical or in that new SKU area. And I think that’s actually different than a lot of new multi product — actually, you can build something that’s at best in class. And it’s okay, because people want a bundle. There might be some synergy in the UX or whatnot, so they’re willing to go for it.

But for us, from an integration standpoint, people are always going to make a decision of Plaid versus somebody else. Do I stay with my current DPI solution here or do I integrate a new one, and it’s costly. So that’s the first filter. And I think that’s really pushed us as a business to ask ourself, like, what is our competitive advantage? Fundamentally, why can we build things that nobody else can? And it’s always gone back to network effects, either data network effects, where we see enough that we can deliver a better fraud solution, a better ATO solution, a better credit risk solution. Or it’s because we see users multiple times that we can build higher converting UX for the end consumer that’s trying to use a financial service. And so, we get a yes on either one of those two, or ideally on both, then we’re like, Hey, this is an area to go multi product.

And then once we do it, we’re very aware that until we get the product market fit, it’s not going to feel like an accelerated growth rate for the product. But what’s really key for us is once it has product market fit, can we drive a really high attach rate for new customers? Can we drive 40% to 50% attach rate for new account signups that doesn’t drive a ton of ARR that year? But if you look at a four year horizon, those customers are going to go into multiple SKUs. And so that’s kind of how we rank success of a new product, because we can get the attach rate for new customers really high.

The second one is whether we can cross sell effectively into existing accounts. And there you can use muscle like price bundling. But again, the way we look at it is our solution needs to be better than market, literally every product needs to be better than market because it leverages network effect. And so far, for us, that’s worked really well.

The third thing is we’re trying to get to a product surface area that is more UI-based, because what I would love is for people to be able to try and adopt products without having to involve their engineering teams. So we have a version of Plaid Link for delivery, where basically you don’t need to do almost any back end integration. And after someone connects their account, we put you in applied UI that allows you to do most of what you need to do without needing to involve a ton of your engineering team. And then if you see value from that, then it’s easier for you to decide like hey, I’m going to do a deeper integration with this new product because it’s really valuable.

When I was at Dropbox, some visual products on your desktop used to go in dropbox.com. I just didn’t appreciate the extent to which API products are more complicated. Now, the flip side of all this is API products are extremely sticky once you’re in there, because ripping them out costs your engineering to move to a new vendor. And so you have more cost upfront, but you have an LTV that tends to be much higher. That’s how we think about it.

It’s always a challenge: new products, culturally where zero to one people are very impatient. And in turn, inside companies, they see a thing that driving hundreds of millions of revenue, that’s growing like,mid double digits, they’re really happy about it. And then they see a new product that’s driving $500k of ARR, they’re like, Well, what’s going on there? And you have to tell people like, hey, like, the question is, can we quadruple it? Can we triple it? Can we double it? And then it starts to be really interesting. But that’s an eight year journey. And so your team needs to understand that leadership has to tell people like, look, listen, these things will be huge. And they’ll be huge for the business. But you have to give them the time to grow. Because we’re not can’t just put UI in front of 100 million people and get them to use a new feature.

Plaid’s moves in payroll

Jean-Denis Greze, Plaid: What we found around payroll is that people chose to use Plaid because of the rest of the product: the bank connectivity, the income verification based on bank accounts. Payroll is much lower in the flow. What happens if you can’t qualify alone? We had a bit of product, we would verify your payroll, and we built it ourselves. And then eventually, we decided to partner with a few companies where they do the payroll verification. We were like, Okay, what’s the waterfall of usage by our customers? First, they want to do income based on bank data, that’s the best, highest converting one. And they know Plaid is best at that. Then they look at the income model. And again, Plaid’s data science is best at that.

But there are some people where even after those two, you’re not quite sure it’s the person. You still want to verify payroll. We built a really good product that was actually best in class. But it was no better. And we looked at it, we’re investing all these people in this. I’d rather invest people in something that’s unique. And I can tap other really good companies to get that functionality, which is downstream of the lending funnel — like it’s just not the most important part. And so now we have a product suite that covers everything. And I’ve been able to turn R&D budget into operating budget on which I get nice margin. That’s a really good solution, because then I can take that bundle of engineers, and I can have them work on the next thing in that area that we think is a huge difference maker.

But actually, the reality is, since we did that, not only do we have much better economics, we have more product bandwidth on the things that our customers are actually thinking is the most important for them. That’s how you make great decisions as a business. Now, if we had unlimited resources, that’s not how I would have treated it. You learn that partnerships are really powerful. But the cool thing about this as these companies were competitors, now they’re partners. And we bring them a lot of business. And so now they can focus more on the thing that they’re really good at, and our customers get it and our incentives are aligned. That’s a nice place to be — not everybody has to be your competitor in the world.

Decisions of build vs. partner

Cos Nicolaescu, Brex: We think about the cost of building X. How many engineers, how many PMs, designers, go to market, marketing, blitz? And you look at a number and then you can do some math to say how much revenue I need to get over what period of time. While I think that’s very helpful, and we do that with every new product, we actually look at the initial investment and the ongoing investment over time because if it’s successful, it’s going to grow. No product I’ve seen is like, Oh, it’s a team of five people that build it and maintain it for the next five years, 10 years, and it’s just going to be a huge product. Everything grows. So we model that.

But the thing that we’ve learned at Brex — we’ve gone through times when we’re too broad, and then we’ve narrowed the focus. There’s two main things. One is leadership bandwidth. It’s not about just about executing, but like, who has the vision? Who has this kind of thinking ahead? How do all the pieces fit together? In general, you need certain people for that. And you have a very fixed amount of great people who are have the right maturity, expertise, and authority to be able to do that. And most of the times, that is the number one limitation that we have — we can always hire more people to build things, but the leadership bandwidth is the one that’s generally tends to be the costliest. Whenever we realized that we spread ourselves too thin, it comes down to we had enough engineers, but we didn’t have enough focus, both at the leadership team in the company and the leadership on that product.

The second one is not just the financial cost, but the opportunity cost. And I think that’s what most companies tend to underestimate. It’s not should I spend 10 engineers working on X, but what else could I have those 10 engineers working on that might be way more valuable, both short term and long term. And this is more of an art — I don’t have a formula for how to decide that. But a lot of times when we think about that, and especially if we kind of have a more constrained view of budgets and headcount and where we want to apply it, it really forces you to focus. Because if you think about unlimited resources, people, and everything else, of course, you can build everything that you want.

On the partnership side, that’s been pretty core from Brex from from the beginning. Because we work with a lot of companies. We work with Plaid, for example. We work with banks, we work with Mastercard, and we also partner with other companies where there’s API integration. And the way I thought about it is, is this core to our business? And is this where we have most of our expertise? And I tried to think about it from that lens versus like building everything. And it goes all the way from infrastructure into product.

And we haven’t gotten it right. I’ll talk about a more controversial example, potentially. But in the early days, we talked about spend management. We were simply a credit card. And we’re like, Hey, should we build, partner with spend management. And we went on the approach of partnering. And two things came to mind there. Looking in retrospect, number one was that some of the spend management solutions that we’re working with realized that, from a margin and revenue perspective, if you actually have the revenue on the card going as well, you have much better numbers. And so they started looking into ways where they can offer a card. So all of a sudden, someone you’re working with is turning more competitor, and that makes the relationship more complex.

The second one we underestimate is the time it takes to having an all in one solution. We looked at American Express — Amex works with all these management providers. And it really works well. And so we should just do the same. That’s not our expertise. I was very much in that same mindset. And that was probably one of the biggest earlier mistakes that I did, where I underestimated the value of the software and a financial stack together, and how that’s actually better from a customer perspective. I think if you look at it only internally from the perspective of revenue or anything like that, of course, you’re always going to want to build stuff. But we looked at it mostly from what’s best for the customer? What experience can be more differentiated? How do we actually build something that cannot be built unless you have this all in one?

And that’s been really successful for us as we launch travel, as we’re looking into procurement spend, and all these other types of flow.

Product planning

Cos Nicolaescu, Brex: I think planning is an overloaded term. When we started, every month we would basically say what we want to get done this month. Literally every horizon was in survival mode. That’s all we did. And then we moved to quarterly planning, biannual, and kind of traditional. We have a few different ways to do planning. We start with a five year plan, which is mostly financial driven. We refreshed every year over the last five years, and we actually tend to add another year to the next year. So if you start with three years, then next year model is for four years and five years, because over time, you want to have longer time frames.

The second thing we do is then we talk about product vision which has a few different horizons. So there’s horizon one which is the current thing that we’re building and how we’re serving customers. Horizon two is where we’re looking at next year, and then horizon three is longer term, more ambitious, if all these things pan out, what does that unlock over time?

And I’d say, again, that’s mostly the visionary level. And what’s useful is for teams to think about decisions that don’t put their future selves in a bad position, where you’re like, Oh, I never thought about this. And now I have to make a lot of changes two years from now. It’s not really about which features you prioritize now.

Then, on the yearly basis, we have what we call Big Rocks, where we look at the things that really need to happen in the company, and that’s at the project level product. We have key metrics in the company. And then we do planning every six months against those Big Rocks. And then the last thing is, we have quarterly business reviews every quarter, where we basically check in on progress for that any tweaks, mid mid cycle, so every three months, we have the ability to tweak for the next few months. But the bigger planning cycles, I would say are for H1 and H2.

Jean-Denis Greze, Plaid: For us, it’s like three years versus five years. With planning, there are two things that I always ask myself. One is, are we concrete enough in terms of the gap between the two to three year product vision, and we need people to now do a failure mode? I’ve seen at many companies, including Plaid at times, where the CEO says this is the vision, these are the things we want to build. And then you look at what we’re doing today and like two thirds of it doesn’t really match up with the vision.

Because you haven’t shown all the nodes between the vision and today that make it clear that there’s some things we’re working on today that we really shouldn’t invest as much in. And so I don’t love top-down — at Plaid we have always been proud of a lot of bottom-up. But as we’ve grown, I’ve realized that I need to provide more clarity on the big things and how they come to today. I need to show the next 18 months how they play out. And I’m going to be wrong. And we’re going to be wrong about that. But at least along the way, we can learn where we’re wrong and adjust the plan, but at least it allows you today to cut a lot of stuff that is not aligned with that three year vision.

I’ll give you a really concrete example, like we had the Big Rocks and all that. But we were at a year where everyone knew revenue growth was really important. And so there’s a lot of incremental work that was happening across the company to add half a million of revenue here, a million there, cut costs by like $2 million. And it was happening kind of organically in the company, because people knew that it was really important to grow revenue and lower costs. But actually stepping back, that wasn’t the most important thing: the most important thing was this bigger thing that would take 18 months, but the short term pressure of people because of the annual goal was to really care about getting to profitability. And so when people had extra brain space, they were going to that, and they weren’t going to the two to three year vision. And that’s because I hadn’t made it clear what they could do now that would ladder up to the vision. So there’s the word strategy and planning — I’m like show me a list of milestones. That’s what I want to see. I just want to see milestones on what you’re delivering when and why and how it builds up.

This year, we have not started annual planning, because I want to start it as late as possible. Because I feel it’s a distraction. Right now, you should be focused on hitting q3 and q4 goals. When we do start annual planning, it’s not just going to be the strategy like annual goals, but it’s going to have two years of milestones where people understand what all the things are that ladder up to the product vision.

But the second thing is the most important part for planning for me. There’s evidence-based management. This is where you force yourself to look and stop with the conventional wisdom. So stop with your vision and your plan and your strategy and you ask yourself, what am I seeing on the ground? What is it telling me critically about my business? And what do I need to change? And so, at Plaid, we changed one of our annual goals roughly at the midpoint of the year. And we change it to something that is like the most important thing for the company. That’s because we ran a bunch of experiments in the first half of the year that told us about this new thing.

That’s a huge opportunity, and it should be a big focus for the company. And I think in the traditional world, if we had just been in on our planning cycle, we wouldn’t have done it in June when we did it. We would have waited until annual planning, but you needed to force yourself and like, where you look at all the data, and like, this is huge. And we can’t ignore it — every day counts. This could be such a difference for the business. And there’s a lot more of these things that happen at all levels in the org.

I think the danger with plans and planning is it can give you a false sense that you’re on these rails. But when you’re a fast growing company, the biggest opportunities are not exactly where your rail track is going. You don’t want to get distracted all the time. But you do need to have this muscle as a company sometimes to look at what you’re seeing in the world — it’s telling you something different. You have to turn the ship 20 degrees to the right, and you have to do it now. I think that’s the part that I actually spend a lot of my brainpower on. Because I’m like, planning cycles, it’s happening. There’s people that are running that. My job is actually outside of planning to think about what pieces of evidence am I coming across? Where do I need to understand the domain better? Were we ignoring an opportunity because we’re waiting too much for the traditional cadence of the company to get us there.

Cos Nicolaescu, Brex: Yeah, I couldn’t agree more. Two things really quick on this one: building that culture of adaptability and being open to change has been so good for us. I think it wasn’t necessarily an explicit decision that we made early on, but we did force ourselves to whenever there were one of these hard choices, do we wait, do we change? We always chose the rational thing to do — just do it and absorb the pain. And you have to bring people along because change is hard. People don’t like when plans change.

And the second is more tactful and planning: timeboxing. I know companies that literally plan for like three months out of six months or four months out of the year combined. It’s just madness. And when we realize with all the processes, whether it’s quarterly reviews, annual planning, biannual bonding, whatever it is, it will fill whatever time you allot. If you give it two months, you might think, oh, I need all this time. People will fill it and they will still be unhappy that there’s too much pressure. We need more time. If you take the same process, and you say now it’s a month, people will have exactly the same thing, and you’ll get roughly the same output. So we’ve been very strict over time just capping the planning process and say that it will be more intense during that time. We’ll make some mistakes and we’ll figure some stuff afterwards.