Building a spiky org

A few months ago, I spoke on the SFELC podcast (Part I, Part II) on my experience as an engineering leader at Plaid. I’ve since received some great questions on leadership and growing a company. I felt it might be helpful to summarize some of my ideas here. My hope is that this might be helpful for you as you think about building teams and growing an organization for impact.

The origins of a spiky org

One of the things that makes Plaid different from many other companies is our emphasis on building what I like to call a “spiky org,” as opposed to a balanced org. There’s often a misconception that the most successful orgs are ones that can strike a balance and make sure the company is good at everything. But striving to be good at everything can be unnecessary and sometimes counter-productive. Being best at a few things is an easier-to-achieve recipe for success. At Plaid, this model works well for us because we are a lean team with a little over 500 employees but this model also works for larger companies. We focus on building an organization that focuses on a few key skills and capabilities that are truly excellent. We don’t, and can’t, focus on trying to be proficient at everything. Indeed, the hardest part of great leadership is to be great at identifying the very few things you need to be best at. Ignore most other things. That’s it.

For our team members, having this focus helps our decision-making because they aren’t required to prioritize along too many different dimensions, and it also enables us to more effortlessly build our organization. Additionally, we find that we’re also able to identify problems we won’t be able to or shouldn’t try to solve because, due to being a spiky org, we know exactly where our strengths as a company lie. We know we can ignore things outside of our spikes, because by definition those things aren’t on our critical path to success. To provide more clarity regarding what exactly a “spiky org” is, I’ll delve deeper into a couple examples of spikes we have at Plaid and some strategies to maintain those spikes.

The first spike involves building a team that can tackle our challenges by focusing on how we recruit as a key pillar of our people strategy. For most of Plaid’s history our spike was focused on recruiting well: putting in a lot of work up-front to ensure that only people who are going to be successful within our organization are actually hired. More specifically, we look at things like technical, collaboration and communication skills candidates need to have to be successful at Plaid. Over time as we’ve scaled and grown, we started to transition to another spike: professional growth.That is ensuring that our teams have the necessary support and skills to grow. This is now much more critical to our success than recruiting. And thus growth is the spike we are keenly focused on.

The second spike is focusing on impact, even at the cost of craft and other dimensions typically valued in engineering. Some of the hardest questions I receive from folks at companies I advise are, “How do you know if you’re investing enough in reducing technical debt?” and “How do you know when you’ve invested so much in moving fast that it’s going to hurt you in the long term?” These questions are difficult to answer all the way from the VP level down to the IC level; focusing on both speed and quality really hampers your ability to achieve either outcome. If we take a look at smaller startups, many are laser-focused on achieving business impact. Eventually, they reach a point at which quality starts to fail, and, in turn, pivot to trying to balance impact and craft. Ultimately, they find that they’re not achieving either impact or craft. Upon reaching that point, I think it would be best for companies to focus exclusively on quality for a period of time. For most of Plaid’s history we have been almost entirely focused on impact -- with shorter bursts on velocity, quality, and craft during well-defined phases of our growth. We’ll discuss later how one can balance conflicting goals like these effectively without asking the team to make difficult and exhausting tradeoffs day-in and day-out. It’s possible to toggle in and out of this quality phase as needed.

Our third spike is to operate bottom-up. When building an org, it’s also important to consider whether you want to create a top-down org or a bottom-up org. It’s very difficult to have a company that functions as both top-down and bottom-up without creating a lot of confusion and mistrust. At Plaid, we’ve focused on being a bottom-up org for most things so that teams are empowered to make decisions at the IC level and have impact, but a very few longer-term planning decisions are still primarily top-down. Long term, we’re trying to get to a place where everything happens from a bottom-up manner. As companies grow, it’s inevitable for senior leadership to lose touch with what’s happening on the ground and cease to understand the product and the market. Once that happens, it’s critical to immediately pivot to more of a bottom-up org. It’s also critical for VPs and senior leaders at fast growing companies to be thinking about whether they have enough information to make decisions, and if not, how to convey that to teams so they understand what decisions now fall under their purviews. Having this kind of mutual awareness creates an environment in which employees have transparency around accountability as well as how decisions are made.

Now that we’ve talked about three spikes at Plaid, here are three key things that are essential for leaders to orient their organization towards the right spikes. Firstly, and obviously, you need to identify and understand the types of problems/opportunities you need to solve to succeed. Second, you need to understand what kind of organizational spikes you need to have in order to actually solve these problems. Instead of asking “Can my team do X?”, try asking “If I need to do X, what capabilities would I have in an ideal world?” Lastly, you need to identify the blind spots that come with those spikes. If you deeply understand these three things -- your business’ problems/opportunities, the spikes necessary to succeed, and the blind spots implied by those spikes -- you will have an organization set to succeed.

Mitigating Weaknesses and Catalyzing Change: Outlets, Isolation, and Shock

Finally, I want to pivot to talk about three strategies that can be deployed to mitigate weaknesses within an org: isolations, outlets, and shocks.

The first strategy is called isolation. When I joined Plaid about three and a half years ago, there were about 20 people in engineering. What we were focused on building was a product that powers the experience of connecting your bank account to another app. We found that, with our small team, we could not create a culture that could handle building this product alongside other Plaid products because the pacing varied too much by product. Eventually, one of my managers flat-out told me things weren’t working and raised the idea of focusing exclusively on building the best bank integrations. Simply put, we were not scaling our excellence at bank integrations with our current approach. We considered a variety of solutions, and ended up deciding to create that culture of excellence by opening an office in Salt Lake City that more-or-less exists solely to focus on this particular platform; today, Plaid connects with more than 11,000 financial institutions at a level of quality beyond what we could have imagined at the time thanks to the singular focus of our Salt Lake Team (which has grown to include parts of our New York office as well). To successfully build our bank integration product, we needed to isolate a new set of spikes, which we facilitated by creating a team with different values, metrics, culture, and approach in a new office.  

Another strategy is called outlets. Whereas with isolation we isolate a spike physically, with outlets we isolate the spike to a period of time. Hackathons are an example of an outlet: a finite period of time during which companies allow employees to tap into their creativity by giving them the opportunity to work on new problems and opportunities. We call our hackathon “Plaiderdays”. For example, during our latest Plaiderdays, we focused on the theme of financial inclusion. When we look at things like bank fees, 80% of white customers don’t pay any bank fees, but only 60% of Black and Latino customers don’t pay any bank fees. We also know that a large majority of under-represented groups are unbanked. These are real problems that we can tackle as a group and are at the core of our mission as a company. There were about 50 projects that came out of our small team in response, about 15 to 20 of which we’re pursuing now. These kinds of creative and focused solutions could not have been realized without a designated outlet.

Another example of an outlet is what I like to call the portfolio theory of time allocation. One way of allocating team members is by thinking along the lines of, say, having 20% of engineers working on new projects, 35% of engineers working on feature improvements, 25% focused on keeping the lights on, and so on. What if, instead, we broke allocations by time? So a team might work on new products for 6 months, and then might take 3 months to focus on quality, reliability, and technical debt. The benefit of planning in this way is that people are able to operate within a certain mentality for an optimized period of time as opposed to having to wear many different hats for an indeterminate period of time. Also, we’re able to have people do things they don’t want to do because they know they’ll only be doing them for a temporary period.

The last thing to add here concerns shocks as a way to force change and adaptation towards new spikes. Over time, you will have the wrong spikes, and you will no longer be the right kind of organization as the problems you’re trying to solve change. My thesis about mitigating this issue is as follows: at any point in time, an org should have very few spikes, but over long periods of time, your org should have all the necessary spikes. One way to force a stagnant organization to change is by literally shocking it. Here are two common examples of shocks I’ve experienced. The first is an acquisition -- acquisitions can often provide a very positive type of shock but this needs to be thoughtfully executed. Things like culture, retention, transparency are really critical to making sure this process results in a positive outcome. Acquisitions are exciting and bringing groups of people together can make for fresh perspectives and new ways of doing things that can help teams grow faster. Reorgs are the other example of a shock: they force the exchange of information and help disseminate ideas that help create new equilibriums. What I’ve realized is that big reorgs are painful. I believe in adaptation, but I try to avoid subjecting, for example, all of engineering through a reorg at once. I’m much more focused on moving people to where they need to be, not necessarily preserving management chains. Sometimes, we move teams from vertical to horizontal, and other times, we have to change how we segment our users. We’re constantly monitoring and modifying the latter because the segmentation of users is so closely related to our go-to-market strategy as well as growth in general. Overall, as an engineering leader, I think there are a set of problems that are known for catalyzing reorgs, and if you’re familiar with what to watch out for, you’ll know how to respond and when a shock like a reorg is the best tool to align your organization with the spikes it needs to succeed.

An essential component of getting all of this right is having the ability to introspect and think creatively as a leader. It’s important that I intentionally create time and space to think. My process for introspecting is to set aside time every week to walk around (yes, with a mask!); I take some paper and a pen with me and jot down my thoughts on what’s working and what’s not working within the org. I’m not always able to think of solutions to what I identify as problems during these walks, but at least I get some fresh air and occasionally a great idea. It’s very important for me to take this time to take a step back and think more broadly and long-term, even if it feels a bit frivolous in the moment. Sometimes, it can lead to meaningful realizations that can have a transformative impact.

I hope this post explains how focusing on a few things in a very opinionated way can enable an org to succeed. Spikes also apply beyond org philosophy -- indeed, the best products are often better in just a few very opinionated ways. But that’s a topic for another day.