How we work

Cheerz Engineering & Product organisation

Very often, I find myself being asked how our team is working: How are you structured, what are the relations between product and development, who are the managers, who make sure that you deliver at the right pace?

Well, if many aspects of our organisation are similar to those of other tech companies (yes, we have squads, and we practice Scrum), some details make quite a big difference!

This is why I wanted to describe here how we work, but also some of the reasons why we chose to do so.

🛤 One Roadmap to rule them all

Each quarter, we build a Product Roadmap for the whole company.

This roadmap is carefully crafted by our amazing Product Team, and describing this process would require another entire story. (Please do email 📩Laure Bachy, our CPO, to tell her that you would love her to write it).

However, the key point here is that we have one global Product Roadmap.

Its purpose is to give vision to all members of Cheerz of what we want to address and what we plan to build in the following months, so that people can project themselves, prevent project collisions, reduce dependencies, and increase the belonging sense to the whole Cheerz project.

70 / 20 / 10

This is our recipe for a good roadmap.

• 70% of the time allocated for features and “product” user stories
• 20% kept for technical user stories (platform projects, refactoring, etc.)
• 10% for quickwins, quickfixes.

This allows us to continuously improve the quality of our platforms instead of piling up features.

Solve a problem, not a solution

We try to allocate time to solve a user pain-point, not to implement one solution:
In our experience, projects too carefully detailed almost always led to a lot of frustration from the teams who lacked flexibility to adapt, and thus to project being late. Each “solution” or detailed project can reveal itself much longer to implement than expected, we think that what matters is to know approximately how much time we would be ready to invest if it could improve our most important “problem”.

🙅‍♀ Not a release plan

️This roadmap is not a release plan. The team does not commit on deadlines and their ability to end all the projects. Actually, we ended up estimating that if we achieved ~80% of our roadmap, we would be quite proud of the work done.

Actually, the roadmap would probably change during the quarter. Because we have new priorities that we could not predict, because we have a better understanding of some business aspects once we start working on them, there are many reasons for that. This is why, along the road, we try to communicate very frequently about our progress: Every 2 weeks, we send an update to the whole company, explaining what has been released, and what are the next topics we will work on.

Alright, so, now that you have that roadmap for the next few months, how to make it happen? 🤓

Let’s not be too hasty. Before we can actually build things, we have a bit more work to do.

(🛤x4) From one to four roadmaps

We split our roadmap into four roadmaps. Each of those roadmaps would then belong to a team (= squad).

One roadmap should try at all costs to not depend on the work of another. Every time we failed to do so, we ended up doing a lot of painful and valueless synchronisation work, and the projects almost every time ended much later than expected.

At Cheerz, here is how we decided to split our roadmap in 4:

• “MadMen” squad: Onboarding of the users, until they start creating a Product
• “Evolution” squad: Help our users have the best experience when customising a product
• “Replay” squad: Make sure our users have the smoothest experience after customising their product, including payment and account management.
• “Deliver” squad: Once a purchase has been placed, Deliver make sure we print it, ship it, and communicate well to the customers.

Now, I can tell you a bit more about those squads.

👨‍👩‍👦‍👦 One squad per roadmap

Once we know what we want to do and who will do it, we need to make it happen!

This is the squad role. This is the team that is going to refine each project of the roadmap, find concrete solutions, build, deploy, monitor, analyse, and iterate.

A typical squad is composed of:

• 1 or 2 developers for each platform (platform = [backend, frontend, iOS, Android]). Ideally two developers of each to foster more collaboration per platform.
• One Product Manager
• One QA Tester
• One UI/UX Designer

If some of these roles could not be in the squad (because we don’t have enough Designers or QA for instance), those roles can eventually be shared, but we try to avoid this as much as possible, especially for Developers and Product Managers.

** If we can keep things even simpler, we do. For instance, our “Deliver” squad only has two back-end developers. No QA, no designer, no Product Manager. Because they work on very important tools, but mostly internal and with almost no UI and no API to mobile apps, we were able to build this very autonomous squad. **

In the team, we generally also have a role of Scrum Master. This is a role, not a job: Sometimes, this role will be played by one developer of the team, or the team will have set up a rolling-role (we assign one scrum master per sprint, and change each sprint).

And since we speak about Scrum Master, you might ask us: “Are you doing Scrum?”
Absolutely. As close to the book as we can.

Scrum

I won’t go into too much details about Scrum, since the literature about it is far from being scarce, but to still give you some insights:

We use 2-weeks sprints.
Sprints start and end on wednesday, because we experienced that Friday was too much of the week-end already, and that Monday was too much stress to start the week with.

But with an “intersprint”:

Something new that we try this year: After two sprints, for one week, we do what we call an “intersprint”. During this week, we will encourage platform teams to work together on training and some technical projects while this should help the Product Team to be ahead, and always have enough backlog ready for development.

Our main rituals include:

• Daily Standup Meetings: 5 minutes exchange every morning to sync-up
• Groomings: ~ 1h. To discuss the business goals of the project to come, refine the tasks.
• Review: ~ 40 min. To show to the stakeholders what has been done, and what’s next to come.
• Retrospective: ~1h. Inspect how the sprint well, and plan actions to improve.
• Planning: ~1h. Plan what’s to be done in the next iteration.

Squad autonomy

It’s key that we make sure that the squad is as much autonomous as possible. The squad must be able to deploy autonomously, to create new API, to take architecture decisions, etc. Of course, sometimes, things must be decided in a broader way than just at the squad level, but this should be for some big topics only, and not a regular situation for the squad.

OK. So far so good, but, if you read carefully, you might poke me with two main questions:

• I don’t see any manager in the squad! Who is working on developing the developers? 🤔
• The developers of each platform are split into different teams, how do you unify the technical guidelines, create a vision for the platform, and take care of technical debt? 🧐

And you would be completely right, those are two very valid questions. Here’s a free cake for you 🍩.

The answer to those two questions is actually the same: This is the job of Engineering Managers.

Engineering Management

For each platform (back, front, iOS, Android), we have one Engineering Manager.

Engineering Managers are the glue of the platforms.

They are in charge of developing the technical & human skills of each people of its platform, to give vision.

In some companies, a “Chapter Lead” would be in charge of federating people working on a same discipline. At Cheerz, this is the job of the Engineering Manager.

So, 1 developer = 2 teams?

Exactly.

You guessed it right. And this a key takeaway of our organisation. Each developer belongs to:

• 1 project team: This is the day-to-day team with which the developer will work.
• 1 platform team: This is what is also referred to as a “chapter” in some companies.

I see you going “But, what exactly is a platform team?”

Platform Teams

Well, a platform team is simply a group of people who work on the same expertise (iOS, Android, Front-End, Backend, etc.).

The main goal of having a team is to be able to exchange with the team. To collaborate with the team. And this is what Engineering Managers make sure we organize: Opportunities for the team to gather, and work together.

For instance, a Platform Team can meet twice a week, with an agenda shared to all in advance, on which a member could have written technical questions he wants to discuss with the whole team: Style guide, technical debt, organization, etc.

It’s also the role of the Engineering Managers to make sure that the whole platform team share the same technical long-term vision, that each member is involved enough in working on the technical debt, etc.

🛠 Platform Days

Every year, during december and until Christmas, we have a huge pike of traffic. During this period that is highly strategic for us, we take the occasion to take a break from the fast-paced rythm of the year, and work on long term projects while minimizing risks: We dissolve squads, and work by platform on the platform backlogs.

This allows us to minimize risk by not releasing new features, while breaking the routine and investing in long-term technical projects.

Product + Tech = 1 or 2 teams?

For a long time, we had one Chief Technical Officer (me), directly managing the Product Managers, in addition to the Engineering Managers.

Product Management is key to align teams, reduce frictions and create business value. But Product Management is also hard. Like really really hard. Maybe I just didn’t have enough time to do it well, but what I can say for sure is that I did quite poorly at it.

One of the recent choices that I’m the happiest of, is my decision to hire a Head of Product, 18 months ago, who then structured the Product team (QA, Design, PM) and its processes.

With the time, we decided to promote the job of Head of Product to a job of Chief Product Officer, so that the Product Team would be directly represented in our Executing Committee, to reflect our vision of how key the Product Management is at a company level.

We (CPO & CTO) work together closely, to setup methodologies, processes, work on culture, organisation and projects, so that not only we deliver well, but that we also always improve.

In the history of Cheerz, since Tech and Product have long been only one team, we didn’t have much trouble making Product work well with Engineering, but by speaking often with other companies who are not in this situation, I have strong clues that making Product work well with Engineering is one key component in our success.

Next steps

Adding more squads, more layers of engineering management, setting up Impact Teams, OKR, try Shape-Up methodology, improve our Career ladder system: If we have the feeling that things work quite well for us right now, the road is still endless.

Choices that we made at a given time won’t be valid a bit further down the road, because we would have became more demanding, because the team would have grown, because the technology would have changed, because our product organisation would have changed, etc.

Our journey to arrive at the current organisation has been long, but we know that we still have a long road ahead of us, and even if our organisation works really well for us right now, we know that we need to continue improving and changing, adapting our way out, but we are eager to come back to you when things will have changed again!!

😘 Merci

A big thanks to all the people who have contributed to our journey, and those who continue to do so: Olivier Bazin, Laure Bachy, Cyril Leroux, Florian Bruniaux, Alexandre Parisot, Hugo Perrier, and many others!