Starting point.

Because of Mambu’s rapid growth and a continuously increasing number of development teams, we realised we couldn’t answer fast to basic questions, applicable in each team:

• Are we on track to deliver our roadmap commitment?
• How do we measure success? What are our KPIs?
• What are our major challenges and what are we doing about them?

At that moment we knew we’re missing a scaling mechanism to ensure clarity and transparency in the decision-making process. To be pragmatic and to avoid reinventing the wheel, we started to look around at how others coped when faced with similar situations. We agreed that the system of Weekly Business Reviews used by Amazon, with slight adjustments would suit us. We were fond of the idea to gather the team, review what happened lately, communicate the accomplishments and challenges and take action to course-correct if needed. At the same time, the crisp one-pager format ensured efficient scaling and a good understanding for our leadership on progress, performance and direction.
Since decisions are two-way doors, at the end of 2019, we aimed to solve our challenge by piloting in one Product Line the Monthly Business Review (MBR). We saw the MBR as a recurring data-driven mechanism that allowed us to openly share and discuss a single slide that aggregated each team’s status and trajectory. We decided the owners of the process as the Engineering Managers. For flexibility, we kept open the option to change the cadence. Depending on the needs, we wanted to be able to shift from weekly, to monthly or even quarterly. Seeing the gained traction, after just two months we deployed the MBRs process tribe level wide.

Our flavour of the process.

To make sure everyone gets to contribute and increase the knowledge sharing between our engineering teams we envisioned a four-step process that besides the offline work, comprise three meetings and an email.

• Step 1 - The Draft - The team’s stakeholders represented by the Engineering Manager, Product Manager, System Owner and the Agile Coach, are the ones starting the draft. They are responsible to gather relevant data, propose narratives and sync to achieve consensus before going in front of the team.
• Step 2 - Team Review - This part has the goal to allow everyone from the team to contribute with input or share an opinion on the content either live during the sync or offline by adding content before the team review. A side goal in the process is to increase the content accuracy to reflect the reality as best as we can.
• Step 3 - Tribe Level Review - During the two hours sync the engineering managers and the champion review and discuss all MBRs. If someone has better ideas on tackling different challenges, we act on-the-spot. Regarding best-practices: I found myself on multiple occasions “borrowing” things suitable in the context of my teams. If we don’t finish reviewing everything in the allocated time-frame the champion or any other interested engineering manager will revisit the MBR offline and leave comments if it’s the case.
  Since our tribe comprises 10 teams, to increase the efficiency of the sync we started to use the Silent Meeting Concept. Reading the document ensures everyone is on the same page so that we can have a concrete and informed discussion afterwards. ow, before going in-depth, we allocate five minutes of reading time to each MBR. Also, to guarantee everyone gets their turn to present we rotate the Product Lines in every session.
• Step 4 - Informing the Product Org - We introduced this step as an action of an MBR retrospective, after seeing people’s interest in the MBRs. After all the MBRs review the champion sends out an email to the entire Product Organisation to inform stakeholders about the latest tribe’s status and decisions. Here too anyone is free to add offline comments.
  Now showing you the entire picture after mapping everything on the timeline:

The content.

To ensure clarity, the first thing we did was to divide the one-pager slide into four main chapters of interest, summarising the context of a team from multiple perspectives: from achievements, metrics, best practices and operational challenges up to goals, roadmap and compliance.

To have everyone aligned on the reporting period we established that MBRs will contain only data-points from the previous month. Meaning that, if we’re preparing the July MBR, it will contain input from 1st of June until 30th of June. Now let’s dive a bit deeper into each quadrant.

Shoutouts and Key Metrics
Shoutouts refer to outstanding team achievements. It can include major team deliverables that are not present on the roadmap (e.g.: We solved a major security vulnerability) but they must be value-focused. It’s important for when it’s read by someone outside the team to understand the relevance.
The Key Metrics is all about tracking the team’s business relevant indicators. It can include Process, Operational and Business KPIs. Concerning processes at team level we chose two flow metrics: Cycle Time and Lead Time for Change. On Operational we can report, for example, issues from Production, or Post-Mortem-Actions status. Regarding Business, since the context varies from one team to another, we customized this part to serve the actual team needs.
As this is an ongoing process, we foresee the section to grow organically in the number of metrics tracked, also depending on how well established the team is. We’re not there with all the teams but this is what we strive for. To present the metrics in a way that is readable and unambiguous for everyone we agreed also upon formats. A couple of examples:

Major breaches or lack of a clear SLA become topics in the third section. Don’t worry, we’ll get there soon.

Goals
This section connects the dots between team status and overall Mambu goals:

• Which are the team’s key initiatives?
• Where do we stand versus each target?
• What delta is there since our previous MBR?

As for goal status we kept it as simple as possible and went for the standard three: On Track, At Risk and Delayed. In case of 2nd and 3rd status an explanation and an action will be available in section 3.

Challenges
This is the most important section of the MBR. The goal for this section is to achieve maximum clarity with minimum words to support rapid decision making. The MBR owner provides a short list of topics, prioritized by their overall impact. These are critical in getting a true understanding of underlying root causes and in giving data points to leadership for difficult prioritization decisions. Each narrative needs to summarise the issue, identify mitigation and provide at least the next step action with an achievable due date. For each defined action it is mandatory to have an owner. After running multiple MBR sessions we reached the conclusion that for clear accountability an action item can have a maximum of two owners. Regarding the number of challenges, the best practice is to stick to 3-5 topics. Above five it’s a sign of an overwhelmed team. As to phrasing, stick to the data and avoid speculation, hyperbole or getting emotional. Some generic examples for a clearer picture:

• Potential contract/agreement infringement for customer X. Inability to deliver features 1, 2 and 3 by Q2 2020 as committed endangers the contract. We’re working with teams A and B to produce an alternate delivery calendar by Aug-20 and will renegotiate with the customer based on results by Sep-20.
• Delivery overdue for Feature X. We did not meet the initial delivery date of June-20 because of scope creep. We are currently green for the revised date Aug-30, with two engineers assisting from team Y.
• Missing performance SLA for topic Z. We have had X complaints because of high latency. We will work to enforce P99 across all API calls below 1000 ms and reduce that threshold by at least 20% by the end of Q3.

If you want to give additional context for some of the challenges, a best practice is to use appendices to avoid cluttering the one-pager. Just make a reference to it, so that the reader will know details are available in the Appendix.

Roadmap Status
In this section, we list the completed deliverable since the last MBR, but also the status for the upcoming one in the current and next quarter. To ensure transparency on the previously missed dates we use colour code.
Like in the goals section, in case of at-risk or delayed deliverables you will have to add a narrative to the Challenges section. As additional notes for this part: We don’t allow missed delivery dates without a new date and no commitment date automatically means it’s an internal commitment only.

Our conclusion.

After running the process for more than six months, we see the MBR as a powerful tool that creates a structure for maintaining the business performance at a high standard. Besides ensuring a shared perspective between the teams and leadership it is also providing value to a wider range of stakeholders (e.g. Sales, Solution Engineering, Customer Success Team, etc.). Through its crisp format, it facilitates cross-company pragmatic scaling and autonomy. It is an evolution towards better collaboration and effectiveness while preserving transparency.