Enabling Autonomy

The principles behind the need for autonomy and the six key enabling constraints.

How companies typically change in structure as they scale from startup to large enterprise. We will look at the most common functional structure and review the benefits as well as the drawback and why we need to change.

We examine divisional and network structures to review their benefits and drawbacks.

Functional structures allow people to specialise more and develop greater expertise in particular areas. Network structures require more generalists so there is a risk of loss of expertise. We'll discuss how teams can tackle this drawback and touch on the key enabling teams that are required.

The network structure offers the best fit for modern product development but it limits economies of scale. We'll discuss the impact of economies of scale and how companies can tackle this.

Introducing UXDXAir, our fictional airline. We will use this as our example throughout the course to show how we can implement the ideas starting with designing the right structure.

Create a map of your customer journey and the associated product and stream teams.

In traditional organisations, senior architects prepare the high-level system design for teams to implement. But when teams are working in very short increments a centralised team becomes a bottleneck. We look at how companies empower teams with forcing functions that ensure high-quality solutions.

Good architecture is what enables reliability, maintainability, testability, security and more. We look at the metrics that companies can put in place to ensure that teams are continuously improving on performance across all non-functional areas.

We'll cover the high level Domain Driven Design techniques for identifying boundaries, grouping events into domains, prioritising domains and mapping communications.

We'll review collaboration types and costs, how coordination needs to be designed and how teams decide on the boundaries they want in their architecture.

When reviewing teams from a technical perspective it becomes clear that some products require specialised skill sets. In such cases, you may need to create a separate team to manage this particular area. But this is a high-risk strategy as the increased communication costs can quickly outweigh the training and development costs of upskilling new people. We'll discuss some examples as well as anti-patterns in complicated sub-system teams.

All software is built on layers of abstraction. This enables teams to work on the problems that customers care about without wrangling the issues behind the scenes. Companies can free up their product teams by creating reusable platforms that streamline tedious and repetitive tasks. Agin, there is a risk here that the collaboration costs will outweigh any benefits. We'll review when it is useful to use platform teams as well as common anti-patterns.

Without a clear development track, there is a risk of people stagnating in their skill levels. Not all code is written equally. Patterns and techniques have been discovered and re-discovered many times which enable simpler and more maintainable code. We'll discuss how companies can continue to develop people without functional structures.

Returning to UXDXAir, we'll see how our structure changes based on our architecture.

Update your map to reflect any changes due to architecture and platform / complicated sub-system teams. While in practice, this would require event storming and domain definitions there is still value in creating a map from your perspective.

We review the way that companies use business case approvals to ensure alignment to strategy. We'll look at the assumptions underlying this approach and the resulting challenges encountered.

Accountability requires true independence. Until teams are isolated then it is hard to keep them accountable. We discuss the approaches that companies can take to track teams while they extract themselves from the rest of the organisation.

A team needs a clear purpose that they are trying to achieve. But equally important are the metrics that the team will be assessed on. We'll cover the key approaches to setting objectives and identifying the right metrics for product teams.

A team needs a clear purpose that they are trying to achieve. But equally important are the metrics that the team will be assessed on. We'll cover the key approaches to setting objectives and identifying the right metrics for stream teams.

A team needs a clear purpose that they are trying to achieve. But equally important are the metrics that the team will be assessed on. We'll cover the key approaches to setting objectives and identifying the right metrics for enabling teams.

The network structure is great when teams are isolated but no work can be done completely in isolation. Having separate teams makes coordination more difficult as each has separate priorities. We'll look at how teams can perform day-to-day coordination for short periods of time, how this impacts their metrics and the key things you need to be watchful for.

Sometimes large initiatives call for coordinated effort across multiple teams. In such cases, you need to change the priorities of the teams to align with the goal of the large initiative. And like most things, it will come back to keeping batch sizes small!

What is the purpose, and associated metrics, for our teams in UXDXAir? Does this change our structure?

Let try to enter the purpose for each of your teams. Does this change your structure?

Company Culture is often talked about as a nebulous thing. But culture is the result of the behaviours that are rewarded. We'll review how typical cultures form in functional organisations and the challenges caused.

Looking at the challenges presented by traditional company values we use examples from leading companies like Stripe, intercom and Amazon to define new values. These shouldn't be copied verbatim but they can be useful as a starting point for your internal discussions on the culture that you want and the corresponding values.

Document the values that are important to you and your company.

The goal of a People department is to maximize employee productivity and protecting the company from any issues that may arise within the workforce. We're going to dig into the first point about how companies maximise performance, the assumptions that these approaches are based on and the impact of the approaches on the core goal.

You can do all of the free lunches, extra benefits and enable autonomous teams but if people find out that they are being paid differently to equivalent-level colleagues all motivation will be lost. We'll look at how some companies are making salaries more transparent and even letting teams set their own salaries. If product teams are self-funding then they will need to ensure that salaries are sustainable.

I love extra money as much as the next person but bonuses have been consistently shown to reduce motivation when dealing with knowledge-based work. The key is to tap into the intrinsic motivation of people. And to surprise people with ad-hoc gifts when they deserve them.

People want to see their careers progressing. But everyone has different goals - some want to shift their career into management and others want to improve their skills in their chosen area. We need to offer both tracks for people.

Functional managers have a lot of responsibility. From recruitment, to budget management, to resource allocation, to performance management there is a lot to do, and that doesn't even cover firefighting. But network structures remove a number of these responsibilities. We'll review how these responsibilities are distributed in product teams.

If we have different career paths we have different types of leaders in modern organisations - people leaders and specialist leaders. We'll discuss their different roles and responsibilities.

As companies scale your culture can be quickly overrun as new people join the company who don't align with your values. Therefore it is critical to include value-based questions in the recruitment process that are weighted equally, if not higher, than the technical aspects of the role.

The original purpose of performance reviews was to help people but they've been co-opted into ways to justify giving a pay rise or not. To return performance reviews to their intended purpose they need to be separated from salaries and they need to be a lot more regular. We'll cover the frequency and content of performance reviews.

Coaching is very different to managing. Coaching is about unlocking a person’s potential to maximize their own performance. You care less about the actual strategy that teams are following and more about how they are working and going about delivering on their chosen strategy.

Training budgets are put in place to avoid people going wild on their training. But this can limit people from accessing the training that they need and also creates a flurry of activity at year end. We'll look at other ways that companies can maintain cost control without restriction teams when training is required.

We briefly touched on enabling teams as a solution to the specialisation challenge in the Structure Module. In this course, we will go into more detail about the responsibilities of Product leadership and how they can support their respective teams.

In this course, we will go into more detail about the responsibilities of UX leadership and how they can support their respective teams.

In this course, we will go into more detail about the responsibilities of Design leadership and how they can support their respective teams.

In this course, we will go into more detail about the responsibilities of Dev leadership and how they can support their respective teams.

Taking into account the respective enabling teams we are able to complete our UXDXAir structure.

Complete your organisation structure