.svg)
Book the right meetings faster with one-click scheduling
.svg)
Engage website visitors with automated Journeys and live chat
.svg)
Qualify, route, and schedule prospects directly from your web form
.svg)
Route records in Salesforce based on a Trigger
.svg)
Route and schedule prospects from bizdev to sales to implementation
.png)
We don’t shy away from hiring globally at Chili Piper. It allows us to attract the best talent and engineers in the world — literally.
Over the past year, our engineering team has more than doubled in size, increasing from 22 employees to 55 employees.
Amazing, right!?
Yes… but there’s a catch.
With rapid growth comes an increased need for structure. Otherwise, things can quickly fall apart.
On top of the hiring frenzy, our CTO retired from the company, creating a perfect storm to rethink the way we did things.
Around the same time, I noticed some pain points that were starting to develop in the engineering team.
So I thought, let’s use this as an opportunity to solve them.
Our top challenges were:
Within the engineering team, we often have the inability to share responsibility — we tend to rely on one person for all our needs and expect them to shoulder all of the responsibility.
And while our previous structure was super agile, our CTO was managing everybody and there was no intermediate manager layer.
To continue growing as a company and as individuals, we needed to be better at sharing responsibilities among team members.
Our engineers' assignments were decided by the product team. While not always a problem, they don’t have as much knowledge about engineering — both on an intrinsic level, and for things like codebase knowledge, autonomy, and will of stability.
From the product side, when the product development doesn't go as fast as expected, the product manager is a bit limited in their capacity to improve that.
And on the engineer’s side, there can be some frustration with the fact that our tech debt keeps accumulating if we focus only on the product.
It’s important to have someone you can go to if you have questions — especially for newcomers.
At the time, it wasn’t super clear who our reference was.
As we were restructuring our team, these were questions we wanted to keep in mind.
Lastly, and most importantly, we needed a team structure that would foster optimization, ownership, and effectiveness.
1. Finding a way to make roles and responsibilities clear for each person, and make sure they were aware of them and knew how to implement them.
2. Make the progression path and career development clear for our engineers.
3. Create space for growth (we want our engineers to be in roles where they truly shine and use their strengths to their advantage).
1. We want a structure that is scalable and flexible:
2. We want a structure that will allow us to build fire products as efficiently as possible.
In early 2022, we began a journey to find the optimal structure for our engineering team, keeping all of our challenges in mind.
Above all, we’re a company that builds products so we decided our teams must reflect what we do — hence the need to organize our teams around the products.
Here are four steps we followed when restructuring our team.
The first thing we did is define the boundaries of our products so that they could be mapped into proper teams.
This helped us create our current framework — product pods. At Chili Piper, our product pods are cross-functional teams. In each pod, we have a PM, BE engineers, FE engineers, and a QA analyst.
Our product pods are responsible for the products we sell directly, like Distro, Concierge, Instant Booker, and Handoff. We also have multiple other teams focused on shared assets that are used by all of the products that we sell (we’ll get into the more later in the article).
The pods must be as separate as possible.
Why? We want to prevent dependencies.
Dependencies are a huge pain and slow things down to a dangerous level. Especially at a fast-paced company where things can change on a dime — being dependent on other teams or pods can hinder growth and innovation.
Product teams need to remain relatively small. Here’s the ideal format:
Of course, the balance can change depending on how the product evolves, and the priorities of the team. If the team is focused on end-user products, you might have as many FE as BE engineers — or even more FE if you’re building a mobile app or desktop app. But it is important that the team remain below 10 people.
On top of our product pods, it is important to have helper teams. Helper teams’ are other engineering teams whose main job is to provide services for each of our product pods. Their main goal is to make each team:
Consistency in product pods is super important. When team members inevitably switch from one team to another we want to make sure the learning curve isn’t too high and that the learnings of one team can be easily applied to other teams. Also, we want to make sure that best engineering practices are enforced across each team.
In each team we have five categories that need to be covered:
The tricky part was figuring out how each product team would encompass each category and how to split them among the different stakeholders.
We made a few attempts:
The first way we tried to organize our team was with the PM and CTO owning everything. The PM would be in charge of the project, process, and product, and the CTO would be in charge of technical and people.
It worked well… until we grew.
The pros: It ships fast, there are fewer processes, and it’s easy.
The cons: It wasn’t scalable.
You can't be responsible for so many things, especially as your team grows and you start to work on more projects and have more technical responsibility.
On our second version, we introduced the concept of a tech lead. The idea was to have one FE and one BE tech lead in each team. They were supposed to own the technical part and help the PM on the process and project section.
However, this didn’t work well for multiple reasons:
1. The tech leads didn’t necessarily want to handle projects, processes, and people. They like technical responsibilities, but the other things aren’t necessarily appealing to them.
2. Collaboration between teams wasn’t optimal (there was no clear leader as we had two tech leads per team).
3. The head of BE and FE report numbers grew and gave them less time to focus on the technology and core responsibility.
Finally, we found a structure that worked for us and removed silos. And for that, we introduced the concept of the Engineering Manager (EM). The final implementation at Chili Piper looks a little something like this:
The EM: Responsible for people, projects, and processes
The PM: Responsible for the product
The whole team: Responsible for technical
We now have one single person (EM) who is responsible for setting up OKRs across the whole technical team. They ensure our goals are aligned across departments and that everyone (FE, BE, QA) is rowing in the same direction, thus bridging the gap between departments — no silos, but shared goals.
Another problem we solved for was the technical aspect. Now, the whole team is responsible for technical. However, sometimes a single person will be named “owner” of some part of the code.
Pros:
This structure helps us change the primary focus to be on the product, which is beneficial for the company (since our main focus is on building a new suite of products), but also for our engineers. As we build and successfully ship products, we believe engineers will inevitably grow.
While engineers won't necessarily be supported by a manager from their discipline, they’ll still have mentoring sessions with their tech peers.
Once we have settled on the structure of the teams responsible to build products, we had to also structure our helpers teams.
The Core teams provide each team with the best tools to own the services and part of the code the teams are responsible for.
These teams are managed by our head of discipline (head of BE and head of FE) and have non-temporary members. But every engineer who is part of a product team can and should contribute to these teams. In fact, most of the contributions to these teams directly come from our product teams.
Here’s an example of usage:
BE: Our guide for creating microservices was built by the first teams which created these microservices. Our core and shared libraries are also created by the engineers of our product teams and are improved by engineers of other product teams.
FE: Our Backend for Frontend (BFF) allows us to more efficiently aggregate data from multiple services. It was built by one FE engineer and will be improved/maintained by the teams using it.
They’re responsible for our e2e pipeline and validating the health of the features of our product before making releases. The QA team puts one QA analyst per team which allows each team to own as much of their QA strategy as possible.
Our SRE team is responsible for our whole infrastructure and providing best practices for GitOps, security, and help with deployment Best Practices. The SRE team allows each team to own as much of its infra as possible by providing tools where deploying the infra and the code is very easy and convenient.
After a few months of iteration, we also decided to appoint one SRE per team.
Their main goal is to provide the tools for our different product teams to be able to gather insights about the product’s usage. The analytics team allows each team to gather insightful data in order to properly understand usage and make the best product decision.
The design system team ensures that style and components are consistent across the different part of our app. They work closely with the design team and then provide tools for each team to either use or create customizables and reusable components.
The structure we chose allows us to provide trust and autonomy at the product team level. Using helper teams to support product teams enables us to ship fast while keeping our engineering best practices consistent.
This structure might not work for everybody’s use cases and will probably be changed as our company evolves, but for now, it allows us to support the vision of the engineering department — to deliver stable, scalable, easy-to-maintain, deterministic software. that supports the company’s vision.
We don’t shy away from hiring globally at Chili Piper. It allows us to attract the best talent and engineers in the world — literally.
Over the past year, our engineering team has more than doubled in size, increasing from 22 employees to 55 employees.
Amazing, right!?
Yes… but there’s a catch.
With rapid growth comes an increased need for structure. Otherwise, things can quickly fall apart.
On top of the hiring frenzy, our CTO retired from the company, creating a perfect storm to rethink the way we did things.
Around the same time, I noticed some pain points that were starting to develop in the engineering team.
So I thought, let’s use this as an opportunity to solve them.
Our top challenges were:
Within the engineering team, we often have the inability to share responsibility — we tend to rely on one person for all our needs and expect them to shoulder all of the responsibility.
And while our previous structure was super agile, our CTO was managing everybody and there was no intermediate manager layer.
To continue growing as a company and as individuals, we needed to be better at sharing responsibilities among team members.
Our engineers' assignments were decided by the product team. While not always a problem, they don’t have as much knowledge about engineering — both on an intrinsic level, and for things like codebase knowledge, autonomy, and will of stability.
From the product side, when the product development doesn't go as fast as expected, the product manager is a bit limited in their capacity to improve that.
And on the engineer’s side, there can be some frustration with the fact that our tech debt keeps accumulating if we focus only on the product.
It’s important to have someone you can go to if you have questions — especially for newcomers.
At the time, it wasn’t super clear who our reference was.
As we were restructuring our team, these were questions we wanted to keep in mind.
Lastly, and most importantly, we needed a team structure that would foster optimization, ownership, and effectiveness.
1. Finding a way to make roles and responsibilities clear for each person, and make sure they were aware of them and knew how to implement them.
2. Make the progression path and career development clear for our engineers.
3. Create space for growth (we want our engineers to be in roles where they truly shine and use their strengths to their advantage).
1. We want a structure that is scalable and flexible:
2. We want a structure that will allow us to build fire products as efficiently as possible.
In early 2022, we began a journey to find the optimal structure for our engineering team, keeping all of our challenges in mind.
Above all, we’re a company that builds products so we decided our teams must reflect what we do — hence the need to organize our teams around the products.
Here are four steps we followed when restructuring our team.
The first thing we did is define the boundaries of our products so that they could be mapped into proper teams.
This helped us create our current framework — product pods. At Chili Piper, our product pods are cross-functional teams. In each pod, we have a PM, BE engineers, FE engineers, and a QA analyst.
Our product pods are responsible for the products we sell directly, like Distro, Concierge, Instant Booker, and Handoff. We also have multiple other teams focused on shared assets that are used by all of the products that we sell (we’ll get into the more later in the article).
The pods must be as separate as possible.
Why? We want to prevent dependencies.
Dependencies are a huge pain and slow things down to a dangerous level. Especially at a fast-paced company where things can change on a dime — being dependent on other teams or pods can hinder growth and innovation.
Product teams need to remain relatively small. Here’s the ideal format:
Of course, the balance can change depending on how the product evolves, and the priorities of the team. If the team is focused on end-user products, you might have as many FE as BE engineers — or even more FE if you’re building a mobile app or desktop app. But it is important that the team remain below 10 people.
On top of our product pods, it is important to have helper teams. Helper teams’ are other engineering teams whose main job is to provide services for each of our product pods. Their main goal is to make each team:
Consistency in product pods is super important. When team members inevitably switch from one team to another we want to make sure the learning curve isn’t too high and that the learnings of one team can be easily applied to other teams. Also, we want to make sure that best engineering practices are enforced across each team.
In each team we have five categories that need to be covered:
The tricky part was figuring out how each product team would encompass each category and how to split them among the different stakeholders.
We made a few attempts:
The first way we tried to organize our team was with the PM and CTO owning everything. The PM would be in charge of the project, process, and product, and the CTO would be in charge of technical and people.
It worked well… until we grew.
The pros: It ships fast, there are fewer processes, and it’s easy.
The cons: It wasn’t scalable.
You can't be responsible for so many things, especially as your team grows and you start to work on more projects and have more technical responsibility.
On our second version, we introduced the concept of a tech lead. The idea was to have one FE and one BE tech lead in each team. They were supposed to own the technical part and help the PM on the process and project section.
However, this didn’t work well for multiple reasons:
1. The tech leads didn’t necessarily want to handle projects, processes, and people. They like technical responsibilities, but the other things aren’t necessarily appealing to them.
2. Collaboration between teams wasn’t optimal (there was no clear leader as we had two tech leads per team).
3. The head of BE and FE report numbers grew and gave them less time to focus on the technology and core responsibility.
Finally, we found a structure that worked for us and removed silos. And for that, we introduced the concept of the Engineering Manager (EM). The final implementation at Chili Piper looks a little something like this:
The EM: Responsible for people, projects, and processes
The PM: Responsible for the product
The whole team: Responsible for technical
We now have one single person (EM) who is responsible for setting up OKRs across the whole technical team. They ensure our goals are aligned across departments and that everyone (FE, BE, QA) is rowing in the same direction, thus bridging the gap between departments — no silos, but shared goals.
Another problem we solved for was the technical aspect. Now, the whole team is responsible for technical. However, sometimes a single person will be named “owner” of some part of the code.
Pros:
This structure helps us change the primary focus to be on the product, which is beneficial for the company (since our main focus is on building a new suite of products), but also for our engineers. As we build and successfully ship products, we believe engineers will inevitably grow.
While engineers won't necessarily be supported by a manager from their discipline, they’ll still have mentoring sessions with their tech peers.
Once we have settled on the structure of the teams responsible to build products, we had to also structure our helpers teams.
The Core teams provide each team with the best tools to own the services and part of the code the teams are responsible for.
These teams are managed by our head of discipline (head of BE and head of FE) and have non-temporary members. But every engineer who is part of a product team can and should contribute to these teams. In fact, most of the contributions to these teams directly come from our product teams.
Here’s an example of usage:
BE: Our guide for creating microservices was built by the first teams which created these microservices. Our core and shared libraries are also created by the engineers of our product teams and are improved by engineers of other product teams.
FE: Our Backend for Frontend (BFF) allows us to more efficiently aggregate data from multiple services. It was built by one FE engineer and will be improved/maintained by the teams using it.
They’re responsible for our e2e pipeline and validating the health of the features of our product before making releases. The QA team puts one QA analyst per team which allows each team to own as much of their QA strategy as possible.
Our SRE team is responsible for our whole infrastructure and providing best practices for GitOps, security, and help with deployment Best Practices. The SRE team allows each team to own as much of its infra as possible by providing tools where deploying the infra and the code is very easy and convenient.
After a few months of iteration, we also decided to appoint one SRE per team.
Their main goal is to provide the tools for our different product teams to be able to gather insights about the product’s usage. The analytics team allows each team to gather insightful data in order to properly understand usage and make the best product decision.
The design system team ensures that style and components are consistent across the different part of our app. They work closely with the design team and then provide tools for each team to either use or create customizables and reusable components.
The structure we chose allows us to provide trust and autonomy at the product team level. Using helper teams to support product teams enables us to ship fast while keeping our engineering best practices consistent.
This structure might not work for everybody’s use cases and will probably be changed as our company evolves, but for now, it allows us to support the vision of the engineering department — to deliver stable, scalable, easy-to-maintain, deterministic software. that supports the company’s vision.
Martin is the Director of Engineering at Chili Piper. When he's not leading the team that's building the next unicorn, you'll probably find him playing for Carva FC, the football team he created (that's soccer, for you Americans).
.svg)
