My father once explained how organizations scale with the analogy of fabric. If you take a piece and stretch it, holes start to appear everywhere. In order to keep that fabric stable, you need to weave new thread into it.

It’s a beautiful analogy. And I hated it. All I could think about was how those new threads were frustrating middle management layers that created bloated bureaucratic organizations. And let’s not kid ourselves, that can happen.

As I got older I realized why those new threads are needed and I’ve been learning how to best design them. I can’t say I’ve perfected it. But I can say with my first year at Pleo I learned a lot about how to notice, prioritize, and thread the gaps in the fabric as we continue to grow. When I joined Pleo a year and a half ago it was about 300 people with about 60 in engineering. Today we’re nearly 1,000 with about 200 in engineering.

I see now what my father meant. The new threads are not there to fill holes simply because holes appeared, the new threads are connectors. They provide structure, information flow, and coordination. They keep the system alive and functioning as it scales. Over the last year and a half of high growth at Pleo, we focused on weaving a few core threads to address organizational and technical challenges.

The Plan at Pleo

The approach we took at Pleo was admittedly not perfect. If you try to hit perfection, you never get started. However, I share how we did things because I hope it sparks inspiration as to how you might approach similar types of challenges in your organization. I will focus on a few key initiatives that I believe made the most difference: a plan to approach organizational challenges, a career framework that created space for technical leadership, a way to make technical decisions at scale, connecting people through communication and rituals, and developing our capabilities through training and hiring.

A Plan to Approach Organizational Challenges

At the beginning of 2022, Pleo had few managers that were stretched thin across many people. This meant managers did not have time to focus on elements of organizational development, such as a career framework.

A vision was painted of what a multi-hundred person organization looks like. This vision included a diagram that articulated the lifecycle of a typical engineer at a company — essentially applying design thinking to employee experience. The diagram provided a way to understand the different segments of engineering experience.

With this, a brainstorm of possible initiatives was generated along with a general vision and guideline for structuring the organization. This idea list spanned years of potential initiative work. In order to accomplish this, we created a prioritized list with input form stakeholders and introduced a working group structure. With working groups, anyone in engineering could participate in the initiatives. The goal was to create a participative model with the potential for distributed ownership. The working group structure provided a template to launch and participate in initiatives.

Most of this was run by a small team of myself and a program manager, under the name of engineering experience. During one team offsite, we drew a diagram of how our team worked. This is a helpful way to think about how program management can look.

The approach we took provided an important mental model for how to think about the different areas of engineering experience and therefore helped us focus on initiatives in higher priority areas. It normalized talking about this kind of work, so we were also able to make the work done here more visible and get support from others. The biggest challenge became the rollout of the initiatives and ongoing maintenance work. To get each manager and each team aware of and participating in initiatives, required multiple channels of communication and often high touch 1:1 interactions — this is not shocking information, but it’s worth noting because the amount of work that is required to do this successfully is easily underestimated.

A Career Framework that Created Space for Technical Leadership

You can read more about the career framework we created in this post -> There is one fundamental thing the career framework did that’s so easily missed. It created a clear path of technical leadership, where getting a higher level of seniority did not require switching to a management role. This has helped us grow and hire people into technical leadership roles, as well as have a way to talk about these roles in organizational design.

One of the things that made the career framework successful was the working group structure outlined above. It created a way to source feedback, gathering perspective from both people’s experience and what would work at Pleo. You can see all the contributors on this post. This was not a design by committee, rather it was a consultation and research format, much like we would design a product by talking to users.

Some things were missed in the career framework, such as making “glue work” more visible (e.g. interviewing, etc.) and setting clearer expectations on testing and incident management. But as an overall structure, it was mostly spot on and created a shift in the mental model of how to build out the organization such that technical leadership could have a voice. The hardest part of course, executing on that new mental model to have technical leadership.

A Way to Make Technical Decisions at Scale

An architecture group was created that sourced technical leaders across the company. Management helped create the meeting and helped source important discussion topics. But the meeting and the decisions are owned by the technical leaders. This helped us make important architecture level decisions such as how many programming languages we will support, how we will design our APIs, and how we will break apart an older monolithic microservice. Minutes from these meetings are recorded for others to follow along and input is gathered from other engineers. And most importantly, because our technical leaders are discussing, gathering input, and making the decisions, it becomes much easier for us to execute on them technically. Management then helps with the rollout and communication of the decisions as well as communicating them to stakeholders.

Connecting People Through Communication and Rituals

This is easily overlooked. And there is a lot we need to do here around how we rollout changes to the organization — better including people, providing managers with context to enable their people, and setting clear expectations. But what we have done in this space has helped us get a better understanding of our culture and create channels to share information and source feedback. The culture book project helped us better understand what people love about Pleo engineering. An All Hands meeting was created to share updates, learnings, and successes within engineering. As part of the All Hands, a Q&A was created for questions — this was a fascinating one to see evolve, while the first meetings had little engagement, now people actively ask questions and we’ve improved the way we get people answers, creating trust by getting real answers rather than answering on the spot each time. Further we architected slack channels, email alias, and meetings to create a basic structure for transparency and participation.

Developing Our Capabilities through Training and Hiring

Being able to hire and train people is key in any organization. We added some basic hiring structures such as interview training, consolidating team hiring requests, and offering a boilerplate interview set for roles. One key aspect in hiring is the type of roles you hire, are there any types of roles missing in the organization you need to hire for? We spent several months building support for and hiring a TPM, for example, because we saw a need for this particular kind of competence for managing large cross team projects. Finally, we realized that for any organization, but especially a rapidly scaling one, mentorship is crucial. We launched a peer mentorship program that offered suggestions of mentorship topics based on the career framework and paired people across teams. Most important, the mentorship provides a sense of feeling connected to and supported by the tech community in the company.

Conclusion

We may not have been able to weave a thread through every hole in the organizational fabric. We will of course swap or update threads as we move along — this continuous learning and iteration is key. However the threads we were able to weave by focusing on the key things outlined above continue to provide valuable structure, information flow, and coordination. For any engineering organization a plan to approach organizational challenges, a career framework that creates space for technical leadership, a way to make technical decisions at scale, connecting people through communication and rituals, and developing people capabilities through training and hiring can help cultivate a thriving engineering organization, especially as you scale.