Category: Agile (Page 1 of 23)

A few weeks ago, I published an article about how we grew Product & Tech (P&T) at N26 during hypergrowth. I introduced the idea of a Target Operating Model (TOM). The first article focused on the why and what of this tool. In this article, I will share how we’ve evolved the core “building block” of P&T at N26.

From nominal teams to stable Product Teams

When I first started at N26, we had a set of cross-functional teams. This meant that we had people from Product, Design and Tech all sitting together (yay!) We had some organisational smells we wanted to address.

A code smell is a potential indicator of a larger problem. A code smell does not always lead to a problem. Rather you have to investigate and decide for yourself. An organisational smell is similar but to do with the organisation itself.

One such smell was a person moving from one team to another on an almost weekly basis. It also felt like a team’s focus would change on an almost weekly basis. Teams were rarely stable. The result was a lot of activity, but not a lot of outcome.

Our first TOM formalised the expectations of a Product Team. Each Product Team had an ideal size (up to 8) and a product area to focus on. Each team then focused on the evolution and support of that product area. We mapped out the complexity of our product set, to our team size and realised that we had many gaps to fill

A large goal of our first TOM was to bring sustainability to product development. We needed to move away from relying on a handful of individuals (common in a startup) to a more sustainable model. Comparing our rate of hiring to our current needs, and needs for the future showed a huge gap. We kicked off an initiative to improve our recruiting, onboarding and retention approaches.

Part of this model revisited responsibilities of the informal leadership of each team. Instead of having a Product Owner and Tech Lead, we added in an Engineering Manager at a Product Team level. We wanted Tech Leads to focus on managing and aligning technical complexity. We also wanted to provide people with the environment and people support. When a Product Team was small, this was manageable As a Product Team grew, Tech Leads could not focus on both areas well.

From Product Teams to Product Groups

As we filled empty roles in Product Teams, we addressed what we wanted to. Engineers felt less overwhelmed. People could take holidays without worrying about being a single point of failure. We had deeper conversations around architectural direction. We also started having conversations about individuals’ career growth. People had more consistent 1–1s and feedback.

As we grew and changed, we noticed some new trends and organisational smells. As an example, some Product Teams reached the boundary of a reasonable team size. We needed to start splitting teams to minimise communication overhead. Some Product Teams also demanded a stronger focus on skills. As an example, our Payment Product Team was more integration heavy. Our Onboarding Product Team needed more front-end skills. Each Product Team needed more flexibility in how they structured themselves. Sometimes a product area needed a short-lived task force. We wanted to push more self-organisation downwards.

As a result we introduced the idea of a Product Group in our second TOM. A Product Group has 30–40 people from a cross-functional mix of Product, Design and Tech. A Product Group still had ownership over a product area. A Product Group had more autonomy to shape their own team structures and ways of working. We also made sure Product Groups knew company or global standards.

This meant that it was perfectly ok to have a Product Group with 5 teams. Or to have a Product Group with 3 teams and one small task force. Each Product Group had more flexibility to better fit their product area at the time. We expected Product Groups to be explicit about their choices and trade-offs. To aid this, the second iteration evolved the role of the Engineering Manager. Rather than being at a team level, the Engineering Manager moved to a Product Group level. This non-trivial decision deserves its own article, so I won’t discuss it further here.

From Product Groups to Product Segments

Our organisation continued to grow. An internal sample of different Product Groups showed more heterogeneity. Product Groups continued to ship product. Product Groups had more capacity to breath. Product Groups had more capacity to deal with more complex topics. Product Groups handled unplanned work better, minimising impact to other Product Groups. Product Groups had more people with relevant skills for their product areas.

The number of Product Groups continued to grow. We noticed that some Product Groups should co-ordinate more with some other Product Groups, but weren’t. As our business grows, domain complexity grows. We wanted to find a way to keep inherent domain complexity highly cohesive but low in coupling . Product Groups alone were not solving this. We also knew that some areas needed further domain knowledge and specialisation. Hiring needs started to differ.

To address these issues we introduced the idea of a Product Segment in the latest version of the TOM. Product Groups working towards the same goal sit within the same Product Segment. Product Groups within the same Product Segment should better communicate and align their plans with each other as they should be more related to each other (highly cohesive). Hiring plans will now be made on a Product Segment basis.

Reflecting on our journey evolving our TOM

Our latest TOM is still recent, so it’s early days to see it’s impact. When designing software architecture, you consider explicit trade-offs as part of decisions. This is also true if you consider organisational and team structures. No organisation or team structure is perfect. You need to ask yourself, “What are you optimising for right now?” “How are you maximising autonomy and alignment?”

“What are you optimising for right now?”

Building Evolutionary Architectures tells us to design software systems for constant change. Organisational systems are no different. A company rapidly growing needs to optimise for different issues at different scales. It won’t help you to copy our structures if you don’t share the same issues. Gather input and reflect deeply to consider what you need to optimise for. Evolve, document and communicate the TOM best suited for your situation.

I’ll be presenting a new talk at QCON New York next week titled, “Cultivating High Performing Teams during Hypergrowth.” One of the topics covered will be a tool I introduced as the CTO for N26, called the Target Operating Model (TOM).

In this article, I will share its origins, its purpose and where we found it useful. I plan on sharing some details about our current model in a different post next month.

What’s the problem?

The CTO role is one of the most misnamed roles of all C-level roles. Its responsibility vary across companies and industries. When I first joined N26, I described my role as being the shake-up CTO. Imagine a snow globe where the snow had settled on the ground. The snow represents a company’s habits and processes optimised for finding a product market fit. Super useful abilities in a very early stage start up with lots of unknowns. Pivoting a product until customers rapidly sign up.

As more and more customers join, they give feedback. The rest of the business continues to grow as well. More ideas on product enhancements or improvements flow in. During this stage the core business does not change. The biggest challenge at the stage is quickly trying new ideas *whilst* not breaking anything. Growing both speed and stability are key factors here.

Early stage habits and processes break down. Daily changes in direction leads to a lot of activity with few outcomes. Two people making a decision face-to-face excludes gathering input from others. Verbal communication results in missing context for other parts of the organisation.

Imagine a world where customer numbers double every six months. Or where the number of employees doubles every twelve months. Would your organisation be able to sustain that?

What’s the solution?

Our snow globe needed shaking. I wanted to keep useful habits and processes. We also needed to establish other habits and processes that would better scale. I needed to transition our company from startup to scale up.

To do this, we could tackle this one issue at a time. Wait for an issue and react. Or we could copy what other organisations do (e.g. let’s do with Spotify does). I wanted to address our issues and our context. I wanted to do this as intentionally as possible. I also wanted to do this in a way that scaled, not one issue at a time. This gave birth to our Target Operating Model (TOM).

What is the Target Operating Model (TOM)?

The TOM provides a shared view of how Product & Technology (P&T) should work in the next 6-12 months. The name fit well for what I wanted to communicate. Let’s break it down.

• Target – The TOM doesn’t focus on where we are now. It focuses on where we are heading as an organisation.
• Operating – The TOM doesn’t compete with our product roadmap. The TOM focuses on how P&T works best in the anticipated context.
• Model – A model is never perfect. A model is an approximation. Our TOM works with the Pareto principle (80-20).

I versioned our first Target Operating Model (1.0) as I knew we would want future evolutions. As we evolve our product, we would also evolve our operational model.

Important elements of the TOM

Like a good Architecture Decision Record, the TOM outlines the organisational context. We included the current state of the organisation. We highlighted what’s working well in the organisation (what we should keep). We also summarised current pain points across the organisation. We also included some discussion about where the entire company was heading.

After outlining the situation, our TOM focused on what was next. The TOM introduced a few principles for decisions, not only the decisions themselves. I find articulating principles useful for highlighting why we made certain decisions. The TOM introduced new roles (skills, capabilities and responsibilities). The TOM also set expectations for changes in existing roles. Many people often ask, “What’s in it for me?” or, “What’s changing about my role?” and I wanted to provide people clarity on this.

An important part of the TOM is new terminology about structures. I’m a big fan of DDD and the idea of a ubiquitous language. For example, “Do people have the same mental model when you describe a team?”

The TOM also provided visualisations how how our organisation would “look” different. Visualisations provided a way for people to link different concepts together. Imagine the visualisations as the new patterns that settle, after shaking the snow globe.

We also added gaps and next steps in our TOM. A TOM won’t every be comprehensive. As the old saying goes, “Perfect is the enemy of good.” A TOM cannot address all pain points so we found it useful to acknowledge known gaps. Next steps provided answers to the question, “What will change and when?” and, “How does this impact me?”

What was the result of using the Target Operating Model?

I introduced the first Target Operating Model over 18 months ago. As of this article, we’re now on our third iteration (TOM v1.2) and more than five times the size we were back then. Nothing grows at the same rate in a hypergrowth environment.

Given that, the TOM has been a useful tool. The TOM provided a shared vision about where we were heading. Hypergrowth creates a lot of uncertainty. The TOM created some certainty in a very turbulent environment.

The TOM provided a shared basis to have useful conversations. The TOM set expectations about change, even when you couldn’t predict when change would happen. More importantly, the TOM provided transparency across the entire company. It wasn’t information held by a select few. Everyone had the opportunity to understand, reflect and a chance to demonstrate leadership and a step towards the desired direction.

Find the follow up of applying the TOM in Part 2: From Teams to Groups to Segments – An evolution using the Target Operating Model.