Org Design Stories: Spendesk

‍

Today, we’re talking with Lucas Bédout—former Head of Engineering at Spendesk and now founder and CEO at Hyperline—about the growing pains that companies making the transition from start-up to scale-up eventually go through and how to work through them as they arise. Here’s what he had to say about his unique experience at the company.

‍

About Spendesk

Spendesk is a french fintech unicorn that offers a complete spend management solution for finance and employees alike. On a mission to elevate finance leaders, they've built CFO Connect, the largest global community of finance professionals with more than 10,000 members. Founded in Paris in 2016, Spendesk has raised $312 million and grown to serve thousands of finance teams all across Europe.

‍

How did the team evolve from Seed to Series C? 

When I joined Spendesk in 2017, the engineering team was just me, the CTO, and one other person. However, as the company started to grow, the CTO stayed focused on all things related to tech implementation while I led all efforts around strategy, hiring, and team management. By the time I left in early 2022, the team had grown to 60–70 people.

‍

‍
At a high level, the engineering team was responsible for building and constantly iterating on Spendesk’s B2B SaaS solutions and, therefore, served as a direct support system for the customer success team. From a team design standpoint, the engineering team was broken up into a number of functional “squads”—each composed of a several front-end and back-end engineers, a product designer, and a product manager—that had its own objectives to achieve during any sprint. This was complemented by cross-functional resources, like project managers and operations managers, that worked to streamline and unify efforts across the squads.

We've always kept reporting lines into functional management (i.e. Engineers were managed by Engineering Mangers) but organaized our broader EPDD (Engineering, Product Design and Data) team into cross-functional squads. And then within each sub-team we'd have OKRs.

‍

‍

What tools did you use to manage the ins and outs of your org? 

We tried a lot of different things and eventually ended up collaborating mostly via Notion and a series of spreadsheets and slide decks. Instead of creating hard and fast processes just for the sake of process implementation, we let every team manager “manage” their team in the way that worked best for them. However, when it came time to report on goals and OKRs, we aggregated everything in a single, templatized slide deck to make things a bit more apples-to-apples. Otherwise, we would have had to make sense of 35+ different OKRs in an unwieldy spreadsheet; that simply wasn’t a good—or easy—way to share that information. 

The biggest problem, however, was that everything we did to keep tabs on goals, resources, and other happenings within the team was incredibly manual. We also didn’t have a central repository for org charts, which meant that it was not easy to communicate who was on who’s team. The most official documents were owned by the People (HR) team, but because they weren’t involved in the day-to-day of the org, much of that information was typically outdated.  So, I simply kept it all in my head, without documenting it in a standardized way. I wouldn’t necessarily say that this is a good way to go about things, especially as a team grows, but I also wouldn’t have wanted to go overboard with processes that would slow us down.

‍

What were your biggest team design challenges?  

This is a tough question to answer because each phase of the company’s—and, therefore, team’s—growth came with its own unique set of challenges. However, if I were to take a cumulative approach for answering this question, here’s what I feel were the recurring trends:

• Scaling resources with growth: As the engineering team grew, I wasn’t able to oversee every team member anymore. At a certain point, we had to start hiring middle managers to make sure that nothing slipped through the cracks and all critical information was cascaded down to the team members working in the “trenches.” Unfortunately, we quickly learned that this approach created communication silos, where different squads ended up working on very similar projects or became too dependent on each other in order to get their work done well. To overcome this, we decided to hire cross-functional operations experts, like project managers, to ensure that the entire team was working towards the same goals without doubling up on efforts. When I look back on this experience, one thing sticks out: sometimes you need to “fix the problem” before throwing more resources at it because more resources simply creates more complexity.
  
  
• Maintaining organizational performance amidst growth: This piggybacks a bit off of what I said above. Simply put, the more a team grows, the slower it starts to move. And this can be a huge problem when your marching orders are to move fast. So you really have to ask yourself, “How can I not lose organizational performance every time a new team member gets onboarded, the code base changes, and so on?” Obviously, it’s normal for there to be a learning curve whenever big changes happen. The key here is to figure out how to not let those changes derail progress. It’s not an easy task.
  
  
• Managing organizational politics: When you’re in pure startup mode, everyone is pretty much marching to the same drum beat. It’s much easier to rally around and execute on a unified vision when there are fewer cooks in the kitchen, so to speak. However, as you bring on new team members from the “outside,” they come to the organization with their own ambitions, their own perspectives, and their own gripes.
  
  Sometimes, as a team leader, you need to carefully straddle the fine line between what you believe—or know—to be the best plan of attack versus picking your battles and playing nicely in the organizational politics sandbox. For example, there was one time when I knew in my heart that we needed to optimize the team for it to perform better, not grow it. But one of the business’s measures of success was headcount growth, so I nonetheless had to deliver on the business’s strategy even though I didn’t feel as though it was the best approach for my team, specifically.
  ‍
• Evolving role of team leadership: This last one is a personal challenge that I’m guessing most team leaders feel, especially as their team undergoes significant growth. In my case, I started to feel more and more disconnected with what was happening at the ground level. The information I was getting was being passed up to me from manager to manager. It felt like a game of “telephone.” Certain critical details would drop off somewhere along the chain of communication. On the one hand, I didn’t like feeling so disconnected from the hands-on work that was happening on my team; on the other hand, when the updates I got were missing important information, I couldn’t make the right decisions for the team. And here’s the hitch: wherever the kink in the chain may have been, if something ever went wrong, it was still on me.

What were the biggest points of friction in the org structure?

There were quite a few points of friction around ownership and accountability that we needed to address on a regular basis. But here’s what stands out most:

• Enablement vs. Product Delivery: A classic point of friction within any engineering team is who’s ultimately responsible to fix the bugs—and it’s not always clear if that responsibility lies with the enablement or product delivery teams. Although we did a lot of work to create a “code quality”-first culture across the board, we still ran into a lot of situations where neither team wanted to claim accountability for the fixes.
  
  
• Banking vs. Payment: Friction is likely to happen whenever there’s overlap in a product flow. This was certainly the case between our banking team—responsible for the credit cards we issue—and our payments team—responsible for how the Spendesk product processed and leverages credit card transaction data. This not only created friction internally for the engineering, product, and designs teams, but it also proved to be a sticking point for our cross-functional partners in sales, marketing, and customer success as well. As a result, we had to create a lot of internal documentation and even a dedicated Slack channel to keep everyone aligned.
  ‍
• Pricing: Adjusting packages and pricing was never an easy task, both from a sales and tech perspective. To address this, we created a pricing committee made up of representatives from marketing, product, sales, operations, and engineering. This helped improve alignment across teams while creating a safeguard against missing any dependencies. Funny enough, it was this experience of seeing people battle it out to be the final decision-maker around pricing and overcome the technical complexities of testing and optimizing pricing models that inspired my new venture, Hyperline.

‍

How much time did you spend on team design?  

Team design primarily came into the picture when something “popped up” and a reorg was needed to address a new business objective or a new engineering need immediately. And this is not something that we could pine over for months; if a team redesign was needed, we had to pull together a recommendation in less than a week. 

My general philosophy about team design, however, is that you shouldn’t overthink it. The problem isn’t putting everyone into an org chat. More often than not, when you need to make org changes, whether big or small, you instinctively know how to do it. The real challenge is getting everyone aligned, managing expectations (especially up to the executive committee), communicating the changes effectively, and reassuring everyone that change is a good thing. This is what makes the term “team design,” for me, a bit of a misnomer: everything surrounding the actual design phase of the process is what requires all the time and effort. 

‍

Who were your key stakeholders in the team design process? 

There were a lot of different stakeholders in the team design process, primarily: 

• Management teams: I’d typically solicit feedback from the most senior (Director-level) resources on my team and then get input from senior mid-level managers after. They were a great sounding board to help me bullet-proof my ideas and get a deeper understanding of what was happening on the ground level.
  
  
• Head of Product: Once I gathered input from my team leaders, I’d action it and then share the output of those conversations with the Head of Product to get additional input and, more importantly, buy-in before presenting my ideas and getting approval from various committees across the organization.
  
  (As a side note: When the team was still relatively small, any changes we wanted to make only had to get the CEO’s blessing. As the team grew, however, the team design process got much more complicated with many approval layers to work through.)
  
  
• HR: This was more of a formality than anything else, but we had to work with them for the logistical side of hiring, resourcing, and reorging. 

If you could do it over again, what would you do differently? 

I learned a lot from my experience leading the engineering team at Spendesk. Now that I’m back in a startup environment, and will potentially be in the position again to grow and lead another team, these are the learnings that I’ve really taken to heart: 

• Think twice before adding more resources: I know I’ve said this above already, but it’s worth reiterating here one last time. Everyone’s knee-jerk reaction to addressing a business’s desire to crank into hyper-growth mode is to simply throw more resources at the problem. The general belief is that with more hands on deck, more work can get done. While that may be true in some circumstances, it’s not always the most effective approach—not to mention, more resources creates more organizational complexity.
  
  Instead, I’m making a point to first thing about how to adapt my team’s working style, including the tools they use and the processes they follow, to maintain the same level of output and performance without having everyone work 40+ hours a week. I’ve always found that fixing a potential problem—aka, a perceived resource gap—is a much better interim fix than spending the time on hiring and onboarding new resources and getting them caught up to speed. Is this the right long-term approach? No. As teams grow, new skills and competencies will inevitably be required. But before you say, “I need XYZ resources on my team,” think first about optimization before going down the hiring path.
  
  
• Don’t get the tools until you really need the tools: A lot of companies love their tools and processes. Sometimes this is necessary once a company reaches a certain size for the sake of consistency alone. But if, for example, your team is most effective by organizing workflows via post-its on a board, don’t fix what’s not broken. Sometimes adding new tools and processes actually create more problems when, prior to, no real problem existed. That being said, there is a time and a place for any assortment of tools; just be sure that if you decide to use a tool, commit to using it organization-wide. There is no value in having thousands of different tools used by different teams. Try to maintain some semblance of consistency, but don’t force it if it’s unnecessary.
  
  
• Limit management layers as much as possible: You’ve got to strike the right management balance for your team. On the one hand, managers should not be overseeing 25+ team members—that essentially makes their job a “manager” and doesn’t leave time for doing their actual job. On the other hand, however, you should avoid having management layers on top of management layers, as that simply creates organizational complexity and the potential for increased communication breakdown. The truth is, sometimes this happens without even realizing it. But this is precisely where team design comes into the picture; when you see your team starting to go down one of these two paths, it’s a sign that something needs to change.