Lessons From Evolving Kustomer’s Engineering Org

Kustomer began in 2015 as a two-person company with a vision for a better form of customer service software. Seven years later we now have hundreds of employees, but are still focused on the same vision. Along the way we’ve constantly evolved both how we build software and set up our engineering team for success. We started with a single team that handled everything and briefly evolved to project teams for a year back in 2018. Most recently, we’ve worked for the last three years as a group of cross-functional squads that each own specific areas of our product.

At the beginning of 2021, our squad-based model was under strain. All teams were still one level deep, with engineering managers reporting up to our VP of engineering. As we hired and grew, we ended up with teams that had inconsistent levels of experience, weren’t necessarily aligned with our company priorities and often operated in knowledge silos. Larger initiatives lacked ownership, growth paths for team members were not clear, and some similarly-sized teams had much larger areas of ownership than others. We received feedback from some engineers that they didn’t feel supported in making good decisions, and were concerned that workloads were not always fairly balanced. We also had constant pressure related to driving projects forward that made it difficult to take on more future-oriented cross-team initiatives.

Iteration and learning is a key part of Kustomer’s culture. As part of that, we make sure to review our teams and priorities every quarter and evaluate opportunities to improve. When we reviewed our structure in the spring of 2021, we had the opportunity to take the feedback from our engineers into account and decided to enter into an exercise of reimagining our structure once again. Our goals were to improve in four key ways, we wanted to:

• scale our team more easily,
• make workloads and responsibilities clearer and more equitable
• align our teams’ missions to our organizational priorities
• make sure our key priorities were properly staffed and not competing against each other

The process started with our executive team identifying the primary personas and areas of focus for our team based on our up-to-date product vision. We then discussed how we would want to organize our team to create a structure that would provide proper support for each of those personas and priorities, and set us up to grow rapidly in 2021 and beyond. That led to a two month sprint toward a new model: communicating the proposal to our engineering leaders, mapping teammates to new squads based on skills, interests and experience, and then taking feedback from the broader team ahead of rollout.

The structure that resulted was an evolution of our squad model. Our teams are now broken down into cross-functional squads grouped into domains. Squads are made up of three to eight engineers, an engineering manager, designer and product manager. They have ownership of a specific area of the product like our automations capabilities or our chat product. We encourage squads to act as mini startups within their area of ownership, taking feedback from customers, stakeholders and their own research to build a roadmap and prioritize impactful work. In addition to the squad level teams, we have functional leaders operating at the domain level who keep teams aligned. These domain level teammates are responsible for supporting all of the squads in their respective domain, as well as driving our higher level strategic vision and fostering partnership and knowledge sharing across squads.

The new structure serves a few purposes for us. There are now multiple clear career paths for engineers at Kustomer — excellence at the squad level as an individual contributor engineer or engineering manager, or broader technical leadership at the domain level as an architect or senior manager. Similarly our product and design teammates now have scope to grow into leadership roles that touch a broader part of the organization. This change also ensures proper support for every team, with each squad having access to a pair of experienced engineers in the form of their domain architects. Architects are also able to take the lead on longer term initiatives that will benefit the company more broadly. Finally, because we’re starting with relatively few domains and a consistent structure across domains, we expect this approach to scale for some time without needing additional hierarchy.

Six months after rolling out the changes, we’ve been excited to see many of the benefits we were targeting come to fruition. We received a lot of feedback from engineers over the first few months that they appreciated the additional support in their roles from having dedicated architects to work with, we’ve already seen engineers and designers grow into new roles and have seen greater cross-team coordination on high-level company objectives. Our most recent survey of employees also showed a marked improvement in scores for how fairly work is distributed across teams and roles. As we begin 2022, we’re starting to add our first new teams within this model, and the domain structure has provided clarity to this process.

There is no perfect org structure, only structures that work for a particular company at a given point in time. However there are a few universal lessons we can pull from the last year at Kustomer.

First, all structures go stale as you scale. The processes that work for a team of 10 won’t work for a team of 100, and those for 100 won’t serve a team of 1000. So it is key to check in on what is and isn’t working on a regular basis and make changes when needed.

Second, fairness matters. When expectations, workloads or resources are drastically different between teams, people notice. Different problems may put different demands on teams and no two teams will ever be identical. But working to remove unnecessary inequities in expectations builds trust.

Third, communication is key. We received a lot of positive feedback on the restructuring of our team and this was due to the carefully orchestrated communication. Before we announced the changes broadly, we had every manager communicate the upcoming changes to their direct reports. As many team members were changing managers through this restructure, we created a brag document template that every engineer filled out in partnership with their existing manager and reviewed with their new manager. The template contained information about the engineer’s growth path, interests, goals and accomplishments. This ensured full continuity for every teammate’s career progression.

Finally, it’s important to match business needs to growth opportunities for your teammates. That doesn’t necessarily mean adding more layers or titles. It definitely doesn’t mean creating roles for “growth” that don’t serve the business. It does mean identifying teammates who are ready for more responsibility and matching them to important problems that will stretch them and help the business. This type of matching makes for a stronger team full of interested and challenged team members.

We’re excited to continue tweaking our approach as we grow in 2022 and beyond. We fully expect that there will be new challenges ahead that require new approaches, but we’re ready to face them and find new ways to create an environment for our teammates where they can learn, grow and build great software.

Written by: Blaga Lund and Ben McCormick