patkua@work

The intersection of technology and leadership

Category: Organisations (page 1 of 6)

Book Review of An Elegant Puzzle: Systems of Engineering Management by Will Larson

Introduction

When you say the word, “management,” it’s easy to drum up terrible images. Dilbert, Ferris Bueller’s Day Off, The Office and Silicon Valley reinforce these bad stereotypes. Poor leadership and management is common as people transition into a different role for the very first time. As the old saying goes, “It’s not a promotion, it’s a role change.” Great management may be emotionally exhausting but is also extremely rewarding. Unfortunately I can’t point to enough material about what great management looks like. That’s why I’m excited by “An Elegant Puzzle: Systems of Engineering Management.

The beautiful book cover of An Elegant Puzzle (image courtesy of @lethain)

In my constant journey of learning, I stumbled across Will’s blog. Add it to your RSS feeds today (assuming you still use one these days!) If not, at least go back and peruse the great entries Will published. It was through his blog that I learned about his upcoming book and joined the waiting list. I bought it as soon as it came out and pleased to say I’ll be recommending it from here on.

Managing engineering teams is different from many other fields. Software systems interconnect via invisible API, data or tech dependencies. While the pace of software increases, so does the tech stack complexity. Any reasonable software product demands strong collaboration across many people. All these people often have very different backgrounds and skill-sets. Harmonising and optimising this ever-changing environment demands managers understand complex adaptive systems.

When I read Will recommending Systems thinking early on, I knew this was going to be a good read. You can’t manage modern software organisations with Tayloristic mental models.

What’s in this book?

The book contains five main sections Organizations, Tools, Approaches, Culture and Careers.

Organizations

This section covers many elements of effective organisation of engineering teams. It discusses optimal team sizes, breaking points, varying structures and trade-offs. Many people underestimate the impact of the poorly designed organisation. Yet many people suffer within them. This topic is also close to my heart, as an advocate for the Inverse Conway’s Manoeuvre and the Target Operating Model (TOM) I recently wrote about.

Tools

This section is the largest in the book. It offers a broad range of concrete and actionable advice. This section covers everything from systems thinking, basics of product management, vision and strategies, metrics, how to deal with migrations and reorgs amongst many more.

This section highlighted the author’s variety and breadth of experience. Not all engineering management will find themselves in each of these situations. It’s useful to have tools to approach these situations in advance.

Approaches

I like to describe this section as the author’s personal style to engineering management. It covers how to handle execution, personal philosophy’s, managing in growth and common traps.

Of all the sections, I found this the most opinionated. It may or may not suit you, the reader.

Culture

This section covers deliberate approaches to cultivating culture. An example is the opportunities you create and who you offer these opportunities to. Another example is reflecting on the representatives you have with your leadership team. A final example are the ranges of policies and the impact that has on the types of freedom.

In this section, I learned the concept of negative and positive freedoms. These are sometimes referred to as negative or positive liberties. Negative freedom is the freedom from external constraints, freedom of interference, or absence of external limits. An example of negative freedom is the USA’s right to free speech.

Positive freedom (or liberty) is the ability to act on one’s free will, or the absence of internal limits. Examples of positive freedom include personal growth and self-mastery. This article has some great examples of positive freedom.

Careers

This section covers everything to do with the employee lifecycle at a company. It covers sourcing, recruiting, interviewing, performance management and career growth.

My thoughts on the book?

This book will appeal to a broad range of people. Those considering engineering management will taste the different set of responsibilities expected in the role. Existing engineering managers will grow their toolkit and discover new ideas. Directors or VP Engineering will particularly benefit with concrete approaches to managing managers.

This is an opinionated book. The author offers approaches that worked for them across many situations. You won’t find a rule book or a guided how-to. Instead, you will find a wealth of experience packaged into actionable chunks. This may or may not be relevant to your current situation. It may or may not suit your own personal style. That is part of the difficult and challenge of effective management. An Elegant Puzzle offers you a head start.

What would I like to see done differently?

I understand how hard it is to write a book, and it’s rarely perfect. Two of my issues stem from reading the book in its digital form. Unfortunately the printed copy was not available in Germany, where I’m currently living. My first is the regret of not experiencing the beautifully designed front cover. I’m sure it’s a better experience in real life than on the Kindle. My second issue also stemmed from this, with some of the visuals being hard to read on the kindle. My final issue was the constant use of the word, “resources,” when I’m pretty confident the author meant, “people.” At least in many cases.

Highly recommended. Grab a copy now!

Agile methods and practices went mainstream over the last two decades. We’ve improved our architectural, technical and processes landscape. It’s time we pushed our management and leadership practices even further. An Elegant Puzzle is a great addition to the field of engineering management.

Get a copy of the book here.

From Teams to Groups to Segments – An evolution using the Target Operating Model

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

The “Team” model

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.

The “Product Group” Model — more autonomy and flexibility appropriate for the area

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.

The relationship between a Product Segment, Product Group and Product Team

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.

Introducing the Target Operating Model – An Architecture Decision Record for the Organisation

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.

Snow globe with a corgi dog, where the snow has settled at the bottom
A snow globe, ready for shaking (thanks to James Pett under the CC licence)

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.

Diversify Your Twitter Feed in Five Easy Steps

I recently came across Diversify Your Feed. It reminded me of a tool I forgot, called “Proporti.onl.” Both tools estimate the gender distribution of people you follow on twitter. I was interested to see how my twitter feed did.

Initial results from http://diversifyyourfeed.org/

What a surprise and disappointment!

There are many reasons to support diversity. A 2018 study from BCG found that diverse management generates up to 38% more innovation revenue. The analysis went further to find four key diversity factors that influence this too:

  • Industry background;
  • Country of Origin;
  • Career Path; and
  • Gender

Inclusion matters as much as diversity. After all, there’s no point in finding diverse sets of people if your environment excludes them from contributing. I also realise there are many other types of diversity other than gender. I can imagine writing a tool to categorise other types of diversity may be much harder.

I wasn’t expecting a 50-50 ratio for men/women for my twitter. I was surprised that my twitter account scored really really low! Here are five steps I took to diversify my own feed. I hope they serve you well too.

1. Collect data on your feed today

Run “Diversify Your Feed” and “Proporti.onl” to see how far off your feed is. You influence less the followers you have, but you can control who you follow.

2. Find inspiration from tech conferences with a diverse set of speakers

Many modern tech conferences recognise that diversity and inclusion are important. Many support blind CFPs, or specifically ask if people identify with a minority group. Others reach out to proactively build a diverse speaking group. Many try to support and inclusive environment with tools like a Code of Conduct.

Find conferences who list speakers from previous years. Focus on connecting with different speakers from more diverse backgrounds. My favourite diverse and inclusive conferences include the GoTo series (Amsterdam, Berlin,Copenhagen, Chicago), LeadDev (Austin, London, New York), Craft Conference, and the Pipeline Conference.

3. Look at curated lists

Some websites have done the hard work of searching for people and give you a good springboard to start following new people. Try:

I searched for terms like “inspirational women twitter”, “women in tech 2018,” and “great women leaders list.” I’m sure you’ll find others too.

4. Look at their “Followers”

People are often connected to people like themselves. Twitter makes it very easy to look at people’s followers. Look through a person’s followers list for inspiration. Using this approach helped me find connections I would never have before found.

5. Take action and follow them

I used to have specific rules when following people. For example, I had a rule that I would follow someone I either worked with before, or least met them in real life. Don’t let rules like these hold you back from being exposed to more diverse ideas and opinions.

You can unfollow people if your feed becomes too noisy or less relevant.

Give people a chance. Follow a broader selection of people today.

You may wonder what applying these rules did for me. The result? See below:

A few days later

What’s your tip to diversify your feed?

With a little bit of data and a few concrete tips, I am exposed to more diverse thoughts and people. I hope these tips help you as well.

Leave a comment if you have additional resources or tips!

What hypergrowth is like at N26

It’s an understatement to say that N26 is experiencing hypergrowth. In August 2017, we had 450,000 customers. We now have more than 2.3 million customers, with many more joining everyday. We’ve almost quadrupled the number of people in tech in that very same time.

It is my first experience of working in a hypergrowth company as a permanent employee. Although the US has its large share of hypergrowth companies, Europe has very few. In this post, I want to share some lessons learned and insights.

What is hypergrowth?

You can find several definitions of hypergrowth on the internet. I like to describe it as a company experiencing a doubling effect in growth. Some refer to this as the snowball effect.

The Snowball Effect

Or simply put:

“The game changes really, really, really fast.”

Patrick Kua

What does it feel like?

I’m sure I picked up this analogy elsewhere, but I can’t find the reference. Regardless, the imagery stuck with me.

“Working in hypergrowth feels like you’re building the spaceship as its flying”

Unknown source
Riding the rocketship of hypergrowth

Hypergrowth can feel chaotic. The organisation doesn’t grow at the same rate, so you feel where bottlenecks emerge. At the same time, a few weeks later, the constraint is often resolved and moved to a different area. Hypergrowth means constant but rapid change. Upon returning from a week’s holiday, many people ask, “What’s changed?” They know that somewhere a team structure, process, or decision has changed.

Hypergrowth means uncertainty. I am comfortable stating what I think may happen in three or six months time. I’m also used to being wrong. I try to put statements about the future into context, explaining possible alternatives.

Hypergrowth demands new capabilities and skills. I read how an organisation grows exponentially faster than individuals. I’ve seen this first hand. Skills take time to develop mastery. An organisation requires that skill now. Although you can wait for people to learn all the required skills, I’ve learned you need to support both. Allow people to grow, but also bring in expertise to learn from. This is why I am a big fan of pair programming (or pairing in general). It’s a great way of transferring experience across people.

Why work in an environment like this?

You may be reading this and wonder, “Why on earth would I want to work in an environment like this?” Here are five reasons why it’s worth it:

  1. New problems to solve – Engineers love tackling new problems. Our product changes all the time. We improve the security build into our product. We look at ways to scale our systems and improve our ways of working.
  2. New skills to develop – New problems and a changing environment forces people to build new skills. I have seen so many people grow in many different ways.
  3. See a business “grow up” – Every six months, it’s like working with a new company. At the same time, you have personal relationships across the business. This means you’re now always starting from scratch. What started out as a single person may now be a whole team. What was once a whole team may now be an entire department.
  4. Ability to have a big impact – Our founders have a broad mission. It’s exciting to work on something that millions of people use. It’s also great to be a B2C product where you get to use your own product too!
  5. Everyone can be a leader – Some people may get hung up on titles. Like I wrote in a previous blog post, everyone can be a leader. There are always opportunities to show acts of leadership and have immediate impact.

How we support people

Although everyone owns their personal career paths, I’ve tried to support people as much as I can. I run an explicit Tech Lead Development Program. This gives people explicit expectations and tools about how people in or heading towards a Tech Lead can improve their impact. Leaders build other leaders. We’ve been deliberate in how we structure our Product and Tech teams. I introduced a Target Operating Model. The Target Operating Model represents a written down mental model of how we’d like to work. This often incorporates new roles, structures and explains the why and the what. Although we experience hypergrowth, it doesn’t mean we do so without trying to shape it.

We listen for feedback throughout the organisation. The leadership team takes a company wide pulse on a quarterly basis. Tech teams use retrospectives to take on improvements. Organisational smells outside of influence of a team get escalated and we try to deal with them as much as we can.

I tried to create as much transparency as possible. We have a shared product roadmap. As a company there are updates about events announced at the start of each week. We end the week with company wide celebrations.

Is this for you?

I will admit that this environment is not for everyone. Our environment may be suitable if:

  • You are looking for new and interesting challenges; or
  • You love an environment with constant change; or
  • You want to work in a place which tries to manage this intentionally; or
  • You are looking to rapidly grow and show acts of leadership.

We are always looking for new talent to add to our culture. Join me on our mission, to build the bank the world loves to use. Look at our open roles and apply now.

Goodbye CTO, Hello Chief Scientist

What was the Challenge?

Hypergrowth land is fun. Things change all the time. My challenge as a CTO was to shake-up the early-stage startup “snowglobe.” It was to transform “start-up” habits into a “scale-up” culture. It was to prepare and launch into hypergrowth. I took on this challenge because I saw the kernel of engineering talent that I could nurture and support.

What Changed?

Looking back at the time I’ve been there (it feels like ages in startup time!), so many things have improved. It’s hard to count all changes as the company constantly evolves. Here are some of the changes I’m proud to have influenced:

  • Clear priorities – It’s easy to fall into reactionary mode and want to switch gears all the time. As the old saying goes, “If everyone is a priority, then nothing is a priority.” Engineering is always the bottleneck. Ideas are cheap. Ideas are easy. You have 5 ideas. I have 5 ideas. Engineers have 5 ideas. To maximise our opportunity, we needed to be clearer about where to focus attention. We now have a better planning process that enables clearer trade-offs and decisions.
  • Almost 4x tech growth – When I first started, I looked around asking, “Where are all the engineers?” Our ratio of tech to non-tech was way off! We worked hard with the People team to change our recruiting strategy. We improved our onboarding process. I spent a lot of personal time writing articles and speaking on our engineering culture. The result? Tech is almost 4x the people compared to when I started. We also managed this while continually delivering value to customers too.
  • A clear Target Operating Model – Change is hard. What helps is a shared picture of how we wanted to scale Product & Tech. You can’t have more people working on the same problem. You need to create a clear focus. You need to encourage high cohesion and low coupling across people and teams. We established a shared Product & Tech Target Operating Model. This model visualises and explains new structures, processes and how they fit together. Each iteration aims to addresses organisational smells and maximise Autonomy and Alignment. We’re working on our 3rd iteration of this now.
  • Product versus Portfolio Management – We have individual product area priorities. We also have cross-cutting projects. We now can focus on ensuring the bottleneck or critical path has full support and attention. We can manage both product and portfolio priorities well.
  • Fuller life cycle ownership in teams – When I arrived, we already had cross-functional teams. Not all teams were responsible for the full “life cycle” of a product. Sometimes back-office or operational processes belonged to a different team. The separation lead to queues and bottlenecks. Our teams are on a journey of integrating more responsibilities. They continue to extend the definition of done to remove hand-overs. We build security and quality in from the start. Teams can better respond to customer issues, incidents and build new or on existing products.
  • Technical governance practices that scale – As we grow, we also focus on alignment where it makes sense. Organisations can only support a certain amount of variation or entropy. Alignment helps. We adopted a lightweight RFC process and iterated on our internal Tech Radar. We built decentralised support structures like Technical Working Groups and an Architecture guild. These work without relying on the same individuals to make decisions.
  • Three Product and Technology Hubs around the world – We’ve moved from being completely centralised in Berlin to operating three successful P&T hubs in Barcelona, New York City and Berlin. We transitioned major product ownership to one office as it grew. The team evolved and released completely new features and services in record time. We’ve maintained speed and throughput, and quality remains high.
  • Rapid growth of individuals – As a I leader I invest in people I work with. I’ve mentored, coached and trained many individually personally. It’s wonderful to see how it’s accelerated people’s growth. People have better ways to deal with imposter syndrome. Engineers have more impact and influence through stronger leadership skills. Better yet, I know they have done this with an explicit support.
  • Diversity, inclusion and culture – I remember one big change I first made was removing a degree requirement for engineers. I created the #diversity slack channel. I sponsored the celebrations for International Women’s Day. This lead to a wonderful support of CSD in Berlin. Watch this amazing video! I know we’re not perfect but we are improving. Our gender ratio in tech can still improve. We have, however, built an inclusive culture where everyone in Product & Tech can express ideas in safety.

What’s next?

The CTO is one of the most confusing roles. Some call it a chameleon role. Companies have different requirements of the role. It changes rapidly in the same company (particularly one going through hypergrowth). There are just many different explanations. As our company grows, the needs of the CTO role grow and change.

As a leader, I found myself asking others (and myself), “How does this scale?” I’m constantly looking at ways to scale myself too. To scale with the growing set of responsibilities, we are splitting this role.

The CTO for our company, in our stage, demands a more operational, management and inward focus. I will step into a new role called, “Chief Scientist.” This new role takes a more outward focus and still guides the technical direction and growth of the tech team.

Our “Chief Scientist” role focuses on three areas:

  1. Representing the external face of technology
  2. Supporting and enriching technical decisions
  3. Accelerating the growth of people in our technical team

I’m look forward to refocusing my attention and energy. These areas not only bring significant value to the company, but also play to my strengths. Here’s to embracing constant change, evolution and experimentation!

Sekt on a mountain

PS. If you’re interested in joining me on building the bank the world loves to use, check out our open opportunities.

The Trident Model of Career Development

Careers ladders are all the rage in software firms. They create structure and shared expectations around different levels. Like any model, career ladders have pros and cons. Career ladders are a starting point for shared expectations across an organisation. However career ladders cannot be comprehensive, as people are unique, like snowflakes. People bring their different strengths and experiences to what they do. Everyone will do this differently. As a result, I like to explain that levels in a career ladder do not represent a checklist. Rather, levels reflect how people can have a different impact in an organisation in different ways.

In my most recent talk, “Talking with Tech Leads,” I explain how, some companies have a two-track career model. Two tracks are great, as they allow for more development and growth in different areas. Most of the research I did seemed to focus on two main tracks. In Silicon Valley they refer to these as Individual Contributor (IC) and Management tracks. I actually don’t think a two-track ladder is enough. This is why I present you the Trident Career Model below.

The Trident Model of Career Development

The Trident Career Model has three tracks. Each track represents where people spend most of their time or energy.

The Management Track

In this track, people spend a majority of their time (70-80%) on management activities. This still includes leading people, supporting people, managing structures & processes and organising. People in this track must still have some background in the topic they are managing.

Most importantly, their main value add is not necessarily through making decisions related to the specialist field (e.g. system architecture). Instead, they manage the surrounding system & structure to ensure people closest to the work have the best context and information to make better decisions. They provide enough support, time and/or budget to enable others to do what they do best.

Example roles in this track: Engineering Manager, VP Engineering, IT Manager

The Technical Leadership Track

In this track, people spend a majority of their time (70-80%) leading people on a technical topic. People in this track must have relevant hands-on technical skills and experience. They should have good but not necessarily the best skills in the team they are leading. People in this track draw heavily on refined leadership skills to be successful. Classic activities for this role (in the field of software) include:

  • Establishing a Technical Vision
  • Managing technical risks
  • Clarifying/uncovering technical requirements
  • Ensuring non-technical stakeholders understand technical constraints, trade-offs or important decisions
  • Growing technical knowledge and cultivating knowledge sharing in and across teams

Example roles in this track: Lead Developer, Tech Lead, Principal Engineer, Software Architect

The True Individual Contributor (IC) Track

In this track, people spend a majority of they time (70-80%) focused on “Executing/Doing”. Software engineers early in their career reflect this very well. This track still requires people to have excellent communication and collaboration skills. People in this track have impact through the deep/detailed knowledge or skills they offer. Most small companies do not need a deep IC track, as there is no need for specialisation. As an organisation grows, they may need more of these roles. The number of these roles will always be smaller than the other two tracks in a well-functioning organisation.

Example roles in this track: DB Specialist, Performing Tuning Specialist, Domain Specialist.

Conclusion

This model is indeed a simplification. In real life, the Management and the Technical Leadership tracks are not always so clearly separate. I know some companies where Engineering Managers also take Technical Leadership responsibilities, or where Tech Leads or Lead Developers are also expected to take on Management responsibilities. This is not necessarily wrong.

I have personally found that, at scale, it is often hard to find people who have deep skills and experiences at both of these areas, and that it can be useful to have a discussion around where someone’s focus, passion or development progression lies.

As the famous quote goes:

All models are wrong, some are useful.

George EP Box

I have found this Trident Model a useful starting point to contrast differences in roles or expectations. Considering using this model:

  • To develop skills in an area you may want to work
  • When building out your own company’s Career Ladder
  • To explain differences/focuses on existing roles and responsibilities

I hope you found this post interesting. Please leave a comment about your thoughts of the Trident Model of Career Development.

Learning about More with LeSS

Background

I took part in a three day course before Christmas to better understand Large Scale Scrum (LeSS). LeSS’ tagline is “More with LeSS”. I’m pessimistic about most “Scaling Agile Frameworks.” Many give organisations an excuse to relabel their existing practices as “agile.” Not to fundamentally change them. Bas Vodde (one of the founders of LeSS’) invited me to take part in a course just before Christmas. I took him up on the offer to hear it “From the horse’s mouth.”

This article summarises my notes, learnings and reflections from the three day course. There may be errors and would encourage you to read about it yourself on their LeSS website, or post a comment at the end of this article.

About the Trainer

I met Bas Vodde about a decade ago. We met at one of the Retrospective Facilitator’s gathering. He is someone who, I believe, lives the agile values and principles and has been in the community for a long time. He still writes code, pair programming with teams he works with. He has had a long and successful coaching history with many companies. He worked with huge organisations where many people build a single product together. Think of a telecommunications product, for example. Through his shared experiences with his co-founder, Craig Larman, they distilled these ideas into what is now called LeSS.

What I understood about LeSS?

LeSS evolved from using basic Scrum in a context with many many teams. I took away there are three common uses of the term LeSS.

  • LeSS (The Complete Picture) – The overview of LeSS including the experimental mindset, guides, rules/framework, and principles. See the the main website, Less.
  • LeSS (The Rules/Framework) – The specifics of how you operate LeSS. See LeSS Rules (April 2018).
  • LeSS (for 2-8 teams) – Basic LeSS is abbreviated to LeSS and is optimised for 2-8 teams. They have LeSS Huge for 8+ teams, and modifications to the rules. See LeSS Huge.

Practices & Rituals in LeSS

LeSS has a number of practices and rituals as part of its starting set of rules. Some of these include:

  • A single prioritised Backlog – All teams share a single backlog with a priority managed by the Product Owner.
  • Sprint Planning 1 – At the end of this, teams have picked which Backlog Items they work on during a sprint.
  • Sprint Planning 2 – All teams do this separately. Like in Scrum, Sprint Planning 2 focuses on the design and creation of tasks for their Sprint.
  • Daily Scrum – Each team runs their own Daily scrum as per standard Scrum.
  • Backlog Refinement – Teams clarify what customers/stakeholders need. Good outcomes include Backlog Items refined into sizes where teams can take 4/5 into a Sprint. LeSS encourages groups, made up of different team members, to refine Backlog Items. This maximises knowledge sharing, learning and opportunities to collaborate.
  • Sprint Review – Teams showcase their work to customers/stakeholders for feedback. The Product Owner works to gather feedback and reflect this in the overall Backlog. Sprint Reviews should not be treated as an approval gate. It’s about getting more input or ideas.
  • Sprint Retrospective – Each team runs their own retrospective. As per standard Scrum.
  • Overall Retrospective – Members from every team plus management hold a retrospective. This retrospective focuses on the system and improving the overall system.
  • Shared Definition of Done – All teams share an overall Definition of Done, which they can also update. Teams can build on the basis of the shared Definition of Done.
  • Sprint – There is only one sprint in LeSS, so by definition all teams synchronise on the same sprint cadence.

Roles in LeSS

  • Scrum Master – Like in Scrum, LeSS has the Scrum Master whose goal is to coach, enable and help LeSS run effectively. The Scrum Master is a full time role up of up to 3 teams.
  • Product Owner – The Product Owner is the role responsibility for the overall Backlog prioritisation
  • Area Product Owner – In LeSS (Huge), Area Product Owners manage the priority of a subsection of the Backlog. They also align with the Product Owner on overall priorities.
  • Team – There are no explicit specialist roles in LeSS, other than the team (and its members).

Principles of LeSS

A key part of LeSS is the principles that guide decisions and behaviours in the organisation. People can make better decisions when taking these principles into account. You can read more about LeSS’ principles here. Like many other agile ways of working, Transparency is a key principle. Unlike other agile methods, LeSS calls upon both System Thinking and Queuing Theory as principles. Both are useful bodies of knowledge that create more effective organisations.

Another explicit difference is the principle of the Whole Product Focus. This reminds me very much of Lean Software Development’s Optimise the Whole principle. I also like very much the description of More with LeSS principle. This principle challenges adding more roles, rules and artefacts. So think carefully about these!

Overall observations

  • In LeSS, having LeSS specialisations is a good thing. This encourages more distributed knowledge sharing.
  • LeSS explicitly priorities feature teams over component teams to maximise the delivery of end to end value. Both have trade-offs.
  • LeSS doesn’t explicitly include technical practices in it’s rules. It assumes organisations adopt modern engineering practices. To quote their website, “Organizational Agility is constrained by Technical Agility.”
  • A lot of LeSS has big implications about organisational design. Agile teams showed how cross-functional teams reduce waste by removing hand-off. LeSS will be even more demanding on organisations and their structure.

LeSS Huge

The creators of LeSS made LeSS Huge because they found a Product Owner was often a constraint. Since Product Owner’s focus on prioritisation, it’s hard to keep an overview and manage the priority of 100+ Backlog Items. (Note that teams still do the clarification, not the Product Owner). With 8+ teams, they found even good Product Owners could not keep on top of the ~100+ refined Backlog Items (which normally covers the next 3+ sprints).

LeSS Huge addresses this by introducing Categories (aka an Area). Each Backlog Item has its own category, and each category then has an Area Product Owner to manage the overview and prioritisation of Backlog Items in that category.

Guidelines for creating an area:

  • This should be purely customer centric
  • Often grouped by stakeholder, or certain processes
  • Could be organised by a certain market or product variant
  • No area in LeSS Huge should have less than 4 teams

Conclusions

After taking the course, I have a much stronger understanding of LeSS’ origins and how it works. After the course, it feels much LeSS complex than when I first read about it on their website. It includes many principles which I run software teams by. I can also see many parallels to what I have done with larger organisations and LeSS. I can also see how LeSS is a challenging framework for many organisations. I would definitely recommend larger product organisations draw inspiration from LeSS. I know I will after this course.

6 Lessons Learned in my year as CTO at N26

Life has been a bit of a whirlwind trip in the last year. I moved cities (London to Berlin). I started a new role as a CTO. I transitioned from 14 years of consulting into a management role. I joined the hyper-growth startup, N26 – the mobile bank the world loves to use.   It’s been exciting to particularly see the company growth. Our customer base has grown from 500K+ users to more than 1 million. Our users transact more than €1B in currency. We’ve expanded our offices from Berlin to New York. We also announced moving to Barcelona and this is only the beginning. 

In this blog entry, I will share my personal lessons learned on the rollercoaster ride from this year. 

1. Management overlaps with leadership, but is different

Over the almost 14 years of consulting, I spoke all the time about leadership. I still believe that anyone can be a leader. Leading is less about a title, and more about how you act. In my role, I also better appreciate the important role of effective manager. Google even proved that effective management matters.

I still think great managers are also great leaders. We try to test for this at N26 during our interviewing process. We hold our managers accountable for having difficult conversations. We want them to be kind, not only nice.  We want managers to nurture an environment of candid feedback. Great managers manage things and lead people. Managers, unlike coaches or consultants are also held accountable for this. 

2. Hypergrowth stretches everyone

I’ve definitely grown over this year. Our company has also grown rapidly (both with users and people). Hypergrowth means people have opportunities for new tasks. We are also not the first company to experience this. The community has been very generous with sharing their knowledge. I will contribute more to this in the future too, as I build on lessons learned.

I have found myself repeating, “The company will grow much faster than people.” 

With this in mind, I have tried to support, develop and grow as many people as possible. At the same time, I’ve focused on bringing in new skills and experiences that we need. Combining a learning workforce with experienced people is tremendously powerful.

3. Really underscore the Why, not just the What

I believe very much in Simon Sinek’s “Start with Why.” A group of brilliant, collaborative problem solvers will end up with a better idea if they understand why.  You can, of course, still give your input. Your role as a leader it to explain the context. Or to clarify the goal or problem. Not just the solution.

I’ve seen too many technical debates fail because they first didn’t agree on the problem. Agree on why, then move on to what. 

In a fast moving startup, I found people underrate listening. Listening and asking questions are my most powerful tools as a leader.

4. Investing in people has exponential returns

I always try to be generous with my knowledge and experience. I’ve particularly enjoyed helping people grow. Sometimes it’s required tough, candid conversations. Effective feedback helps people grow. Coaching and training helps people see potential they don’t see. It’s been wonderful to help people discover, test and practice tools that make them more successful. 

I’m proud of N26’s technical leaders (both formal and informal). I’m impressed with how people have rapidly grown. I’m also impressed with what they do to pass it on.

5. What got you here, won’t get you there

I read the book, “What got you here, won’t get you there” many years ago. It’s message resonated with me during this year. Startups often go through several phases, “Start Up, Scale up, and Optimise” is how I like to think of it. We are definitely in the Scale Up phase. This phase demands different thinking. 

Acting as if we were in the Start Up phase no longer scales. It’s an educational journey for many people. At scale, you can no longer manage every single situation. At scale, you can no longer make all the decisions. At scale, you have to decide on where you will have the greatest impact. At scale (as a manager), you make less, and need to focus on multiplying more. 

6. Focus on Capabilities, not just People

In Hypergrowth, it’s too easy to hire lots of people. I am wary of this after reading the Mythical Man Month many many years ago. As a manager, I first focus on understanding what capabilities we need. I also think about how those capabilities are best met. Be clear on what you need before hiring people. 

Focusing on what you need helps you find the right people. It also helps those people be clear about how they will be successful. 

Conclusion

I have learned many other lessons in this year as a CTO. The six lessons above reflect some of the major themes for this past year that I hope you many learn from.

I’m super proud of the people I work with. I’m super proud of the product we produce. It’s been a great ride so far, and it’s only the beginning of the journey.


Book Review: Accelerate

I first heard about this book when I saw Jez Humble (@jezhumble) keynote at OOP earlier this year. You will get significant value from this book. Jez has already made many contributions to our industry. He introduced Continuous Delivery (CD) and the Lean Enterprise. He also helped shape the field of DevOps, as we know it today.

The Science of DevOps: Accelerate Book

Think about this book as a very readable academic paper, based on the long-running State of DevOps report.

Rigour in its research method

The book describes how the authors gathered vast data and their research methods. They discuss their observations and lead you to their conclusions, with concrete examples. The author shared how some of their assumptions turned out false. An example is the study showing how there is a positive correlation with Trunk-Based Development (TBD) and quality. This technical book is a rare gem based on rigorous research methods. Nicole Forsgren obviously had a large impact on the book

I’m amazed at how rich their raw dataset is. The authors draw on four years of data from many responses around the world. Their sample size towers over many academic studies. Many academics rely on student control groups instead of real industry data. Rarely academics also get to study a few companies or teams within a single company. The wealth of the raw data gives more weight to the report’s authenticity and credibility.

Martin Fowler highlights one point in the Foreword which I agree with. Even though the survey raw data comes from many sources, it is still self-assessed. Self-assessments are naturally biased by Dunning-Kruger effects.

Strong guidance and good advice

Our industry struggles with useful performance measures in IT. Metrics are either irrelevant or drive poor behaviours. This book debunks false prophets like Gartner’s Bi-Modal IT. Spoiler: You can got fast AND have quality, unlike normal assumptions. The book, Accelerate, gives strong suggestions for useful KPI measures. The authors present convincing conclusions that any modern technology firm should take on. This book gives many ideas to improve software and organisational architectures, and processes.

Many studies such as this focus only on the technical practices (such as CD or TBD). Many experience people realise a focus on technical practices is not enough. They realise organisational processes or structures constrain the value technical practices bring. To make the most of technical practices, management must look at their processes and structures. (Disclaimer: We address this topic in our book about Building Evolutionary Architectures). Maybe it’s confirmation bias, but the chapter on Transformational Leadership is super important.

Here’s an simple example why. Imagine you have an organisation with a Head of Development and Head of Operations. Each have hundreds of people with different reporting structures and processes. If the Heads do not support new initiative like DevOps, collaboration won’t move very far.

Conclusion

I found this book extremely easy to digest. I wanted to read more about their research methods. The authors convinced me of their conclusions and made them come to life with concrete examples. I highly recommend this book for any technology executive in the modern world. Accelerate sets the standards for measuring the performance of technology firms in 2018.

« Older posts

© 2019 patkua@work

Theme by Anders NorenUp ↑