How our Chapters Work: Engineering at Cleo

Intro

At Cleo we operate in cross-functional squads as the core part of our agile organisation.  These teams work autonomously in their focused area but at the same time we want to empower collaboration, knowledge sharing and continuous improvement across the organisation.  So how do we achieve this? In this blog we’ll explore how our chapters help us to do so.

What are Chapters?

Chapters are a collection of individuals that align on discipline (eg frontend engineering).  They are defined in the spotify model for scaling agile.  As seen in the diagram above they consist of individuals from different squads (and some sitting outside squads). Some of the main features of chapters are:

• They meet regularly to share knowledge, challenges and learnings
• They are a peer group that members can use to bounce ideas off, seek feedback from on proposals or ask for reviews on their work (eg Pull Requests for engineering)
• They drive standards and continuous improvement of the discipline at the company
• They provide a go-to place for external queries about the discipline at the company

How does engineering organise into chapters?

At Cleo, we have several disciplines that organise themselves into chapters (eg data and product management) but for the purposes of this post we’ll focus on engineering.

In our cross functional squads we try to have a minimum of 4 engineers (usually 5 when the Tech Lead is included) and those are split in specialism between frontend engineering and backend engineering.  Those form the basis of our engineering chapters. Before we dive into the specifics of each engineering chapter, there are some general similarities between the 2 to call out:

• There is a recurring meeting where chapter members meet to update on previous actions, discuss challenges and share learnings from the week. It is generally in this meeting that changes to standards, tooling or processes are proposed and agreed upon (or not). Often challenges discussed in the recurring meeting will result in smaller action groups spinning off to investigate, build proposals and prototypes and bring back to the group for feedback and adoption. This model helps to build better consistency of engineering practices in the codebase and product and ensures we are continuously evaluating and improving.
• While the chapters meets primarily remotely, we encourage our engineers to get together at least once a term in the Cleo office, during which time there is a dedicated chapter day. At the last event there were some great lightning talks from the team, some focus time in groups progressing the main goals of the chapter before finishing with some social connection building at dinner and drinks!

Frontend Chapter

Our frontend engineers at Cleo work on our React Native mobile app creating interesting and intuitive screens and journeys to optimise the experience of our users. As a chapter the frontend team meet remotely on a weekly basis.

Some recent areas of focus for the chapter have included:

• Adding new design system components for Typography as we collaborate with the design team to create the building blocks that will enable consistent experience across the application.
• Adding performance instrumentation to our application and enabling the easy configuring of measurement for newly added screens.
• Updating some of our outdated key libraries and dependencies to get us back to a more performant and security-compliant place.
• Improving our testing coverage, both in terms of our automated unit testing suite and our manual regression testing suite which we use during our app release process.

The frontend chapter is also responsible for managing the release process of our Cleo App which happens at least once a week. There is a rota for who will be the “Release Pilot” - the person responsible for managing the build, regression testing, tagging and phased rollout of the release to our users.

Below you can see a great pic of some of our frontend team on our company offsite last year!

Backend Chapter

Our backend engineers at Cleo work on our ruby on rails monolith application to create the business logic and APIs that drive the delightful UIs their Frontend colleagues craft.  As a chapter they meet every 2 weeks.

Some recent work the chapter has spent time on:

• Upgrading our Ruby version from 2.7 to 3.0 to 3.1 and most recently 3.2.  This wasn’t without some stumbles along the way but it drove us to develop a culture of building out runbooks for upgrading core infrastructure.  We even gave a talk about this at the October 2022 LRUG meeting.
• Starting the work to upgrade our monolith up to Rails 7 and building out the Rails upgrade runbook to sit along side the Ruby runbook we already have.
• Running and reporting back on progress from action groups to deliver improvements to: the performance of one of our key APIs that has grown slower over time as we add more and more data to the payload, adding more user context data to exceptions generated by our sidekiq background processing infrastructure so we track user impact better when errors occur, and moved our scheduled jobs infrastructure from heroku scheduler to sidekiq scheduler so the config would live in code, and we’d have better reliability.

Releases for our backend code are handled automatically through our CI/CD pipelines so the chapter doesn’t need to manage a rota or process for this.  We also have a platform engineering squad who manage the infrastructure for this pipeline.  What the backend chapter does manage is our rotas and processes for both in-hours and out-of-hours support, to make sure we respond in a timely fashion when there are outages.

Here’s a photo of the Backend team bonding over an icebreaker exercise at our most recent chapter day:

Why you should consider having chapters

Chapters have a lot of benefits for both the individuals who form the chapter and for the company as a whole.

For individuals:

• They have a larger pool of peers, mentors and people to call on for support, to learn from and to grow in their discipline.
• They have a vehicle to influence change in an organised manner, using the processes that the chapter has put in place.
• They can work on things which are different to their day to day squad work, which is good from the perspective of learning and staying fresh.
• They have a potential wider scope of ownership than they have within their team, which gives them opportunities to learn and grow.

For Cleo:

• There is continuous improvement of both engineering standards, which ensures better quality of the product, and tooling and processes which ensures efficiencies in learning at speed and delivering user value.
• There are shared standards and more consistency of the codebase, leading to easier onboarding for new engineers and easier transitions from existing engineers going from team to team.

There are some things to be mindful of, however:

• With squads hyper-focused on delivering impactful work in their product area, it can be easy to fall back and rely on the chapter for critical or high priority changes which don’t directly deliver user value.  Progress on chapter work often relies on individuals carving out time in their squad to work on it, and this does not lend itself well to time-critical or high priority work so this should definitely be avoided. A recent example where we’ve felt this pain at Cleo has been on some critical library upgrades which sat under the remit of the frontend chapter.  The priority of this work was never high enough to displace squad work until it became apparent that it was contributing to degrading performance and negative app reviews. In hindsight, we should not have relied on the chapter as being the driver for this but instead worked with product to divide up and deliver the work across all squads.
• It is important to regularly reevaluate the impact that the chapter is having - it may be that the outcomes being achieved are too low-level and disjointed - in which case looking at the largest opportunities for improvement (and possibly setting goals or OKRs against those) should be carried out by the group.  The Frontend Chapter at Cleo were in this exact position about 6 months ago, and after some retrospection and understanding of the largest problem areas we had, formed 4 main focus areas for the chapter moving forward.

Wrapping up

Chapters are great if you want to foster a culture of community, collaboration and continuous improvement in your company, which I’m going to assume you do!

‍Ps - We're hiring for Frontend and Backend engineers. Check out our open roles here.