When you first launch a startup, you’re just trying to build a product and get it to market. The first group of engineers has an “all hands on deck” mentality, and they’ll do whatever needs to be done to make the product happen. But as your business grows and its needs change, that mentality is no longer as viable, particularly as you bring more people on board.
As you add more talent, you’ll have to organize your engineering team into more logical groups. That means more defined roles, with individuals and teams made responsible for specific parts of the product while continuing to expand its capabilities. How well you manage the transition from an organically grown team to a more purposefully organized, efficient machine can be key to how successful your company will be as it scales.
Plaid CTO Jean-Denis Greze, whose company creates APIs for banks, had to deal with that kind of transition when he arrived in 2017. The company was in the midst of Series A financing with about 20 engineers who were still trying to feel their way to product-market fit.
Since his arrival, the engineering team has expanded to 350 people, and the company’s valuation has blown up to $13.4 billion. Carefully growing and organizing the engineering team has been been a big part of that success, especially for company building tools designed for developers.
How did a growing company like Plaid scale the engineering team 17.5x, in four years and keep everything in working order? We talked to Greze to get some answers.
It’s all about planning
When Greze joined the company just as it was reaching the tail end of its Series A maturation, engineering was organized in a more generalized fashion, reacting to customer requirements as needed with little specialization. And he felt that while this was working for the short term, it wasn’t really sustainable.
“If we had an important product requirement for a set of customers, we would just take some engineers — not randomly, but with the right skills — and we would have them work on that project until it was done. And then they would go back to the general pool,” he explained.
After six to twelve months at the company, the team had already grown to over 30 engineers, and Greze recognized that the company would soon need to take a different approach.
The solution was to divide the engineers into more dedicated teams, but he is careful to point out that he wasn’t simply dictating these changes. Before he did anything, Greze met with the founders as well as the engineers doing the work to discuss the new way of working, and he found most people were coming to the same conclusion that he had.
“So effectively, I started a conversation about whether we should change how we are organized with a subset of the entire team, but in an environment where most people were realizing that the current construction wasn’t adapting,” he said.
When all was said and done, they decided to go forward with Greze’s idea: “We organized the company into these horizontal layers to deliver the product to customers. We had a team that was responsible for getting data from banks, a team that was responsible for storing and caching the data, a team that was responsible for the APIs that our customers are using to access data, and a team that focused on the end user experience of connecting to the actual user interface.”
Going horizontal
From an engineering perspective, the original generalized approach resulted in a few problems. For starters, if an engineer saw something that interested them, it would be difficult to pull them off what they were doing. Another issue was figuring out who was responsible when something required maintenance, or who should build something when they identified a new feature.
All of this could be solved by moving to a system that defined responsibilities more clearly, but also allowed for some flexibility to move people around when they wanted to stretch their skill sets. “People were on the permanent teams, and we created mechanisms for people to switch teams when they wanted to. So people who still want to move around could [do that], but it was in a predictable way — like with a quarter of advance notice,” Greze said.
At this point, Plaid was still pretty small, but it was growing quickly, and Greze had to spend a fair amount of time hiring new engineers to keep up with the demand. In some cases, this involved selling engineering talent on the company and its culture, and Greze says the team approach really carried the company forward.
“We had teams, and we split teams, or there were things that had to be tweaked. But the structure we put in place helped sustain an amazing amount of business growth, and I’m really proud of it,” Greze said.
Making bigger feel smaller
BY 2020, Plaid was set to be acquired by Visa for about $5.3 billion, a deal that eventually fell through. The resulting publicity, though, helped give the startup access to engineering talent that might have passed it by previously — people who wanted to work on the kinds of scaling problems experienced by big companies like Visa.
But even independent of the acquisition, Plaid continued to grow, and this necessitated a third phase for the engineering group. Phase 1 was the growth phase with few defined roles, Phase 2 was when the company started to organize into teams. By Phase 3, the scale required another way of thinking about the engineering department.
“Eventually we jumped into the third phrase, which is organized internally more along the lines of business units, which we think of as goal-based teams. Effectively, Plaid as a whole is now composed of more autonomous, self-sufficient, higher ownership groups of people that are solving problems for customer groups,” he said.
As with the teams in Phase 2, this gets pretty specific with a group for lenders, a group for payments, a group for personal finance management, and so forth.
By the end of 2020, Plaid’s engineering headcount had surpassed 150 people, and as they scaled the company, the business unit organization enabled the company to not just build groups with engineers, it also let it build other functional units like product, go-to-market and marketing. Greze said that with the company passing 1,000 employees, this made sense for everyone to have these smaller working units.
At this point, hiring was getting easier because the company was growing in leaps and bounds, and people were hearing about it. Plaid was solving more complex problems, and even without Visa, it still could offer a couple of ways of working: the kind of autonomous early company feel for engineers who were looking for that, while offering challenging scaling problems for people who were looking for that.
Ultimately, Plaid has evolved and seen its value increase dramatically, with the engineering team growing with it. Greze has been able to develop that group from a handful of dedicated early employees to 350 people by understanding when it was time to reorganize for greater efficiency.
Today, he says his role is to make sure that everything is working from a high level. He mostly stays away from the day-to-day operation of these groups, leaving that to managers and their charges. “My job is no longer to do the strategy as much as it is to make sure that they come back with a good one.”