End-2-End Teams and a Leadership Team Along the Value Stream

My thesis: Many problems in software, data, and AI teams arise because the organisational system — the teams, the departments, the leaders, the processes — is not set up optimally.

In this article, I present a system that, in my experience, works well. I have seen it in practice in several organisations. It was very successful and people liked it. It was motivating and somehow also cool. It also works in large corporations with lots of complexity and legacy. In one such corporation, I was part of the leadership team (there were three of us) and we were responsible for seven teams.

Much of what I am about to describe is common knowledge. Some of it I developed myself, some of it has been known for years. It is a mixture of both. I keep meeting people for whom all of this is new — hence this article.

Think First, Then Act

In this article, I try to present and explain principles. It is important not to copy the ideas and examples one to one.

Every organisation is different and every organisation has different people. And then there is the market, the customers, the outside world, the available capital, partner companies, unions, affiliated institutions, laws, regulations — so many different factors that force you into trade-offs every day.

Engage with the principles and decide case by case, concretely, whether and to what extent you can and want to apply them.

If this article inspires you to implement it: talk openly with your teams about what you want to implement, what you deliberately do differently, and what you deliberately leave out. We are all adults. Everyone understands that reality is messy, and nobody will have a problem with it.

Full Transparency

Even if you consciously reject something, everyone will accept that more readily than if you say nothing about it at all.

I was often able to observe this in agile transformations. When a leader says "we're doing agile now" and then everything that is agile gets rejected and only a piece of Scrum theatre is performed — while the same leader keeps loudly telling everyone how agile they are — there are three typical reactions.

Most people think: The leader is stupid. They don't get it. They are too dumb to understand what agile actually is.

Others think: The leader is devious. Outwardly they claim one thing, inwardly they do exactly the opposite.

And some think: The leader is weak. They want to be agile but don't dare to implement it properly.

But if the leader says: "Listen, this won't work, because …" and gives reasons, nobody has a problem with it.

Gut Feeling Explicitly Welcome

It is also okay to say that your gut feeling is against it and you cannot yet explain exactly why. People accept that.

That is mature and wise in my eyes.

What is immature and dangerous: buying some framework including a vendor and rolling it out without having an opinion of your own.

That is exactly why you are a leader. Because you carry the responsibility and people expect you to deal with difficult situations. Listen to your gut feeling and find out together with others where it comes from.

My experience: When I have a strange feeling, at least two other people in the organisation have a strange feeling as well. When I don't understand something, at least one other person doesn't understand it either.

That is why I am a big fan of leadership teams that discuss exactly these topics.

Fictional Example

A fictional chocolate manufactory develops a new vegan recipe. An AI model analyses historical recipes, customer feedback, and raw material data and suggests ingredient combinations that are promising in terms of taste. A small interdisciplinary team works in short cycles: Every week, a test batch is produced, tasted, and evaluated. An AI agent takes over parts of procurement.

The example is deliberately a bit far-fetched. You can imagine what is meant, but it is unrealistic enough not to be copied one to one. That is intentional. You should really think about what your end-2-end team looks like. Here is a guide.

Building an End-2-End Team

The chocolate manufactory's team consists of a food product developer, a production process engineer, a machine operator, procurement / raw material sourcing, a data engineer, a machine learning engineer, a DevOps engineer, a quality and regulatory specialist, and a sensory and consumer insights specialist.

It contains all the skills needed to produce a small sample of the new recipe — and the chocolate itself. If someone from the chocolate industry reads this and throws their hands up in despair: It is only an example to show how cross-functional teams are made.

How do you do this in your organisation?

Imagine the customer at one end and the deepest backend infrastructure at the other end. Anyone who works in a large corporation knows it: In between, there is so much that you don't even know what it all is. Legacy stuff, strange manual processes, a piece of AI somewhere, data, who knows what. You don't have to bring all the people from all the departments into your team. It is enough to find people who are capable of driving change in the surrounding systems.

But it has to be the entire chain. Why? You need this focus and the view of the whole, because otherwise you will never find out what you can cut and eliminate. Wherever functional teams stand, there is always too much of a good thing. It lies in the nature of things: Things grow, things expand — and they do so until you limit them. You need a meaningful focus, and that is the customer.

If you are a SaaS with an extremely large number of customers, your end is someone who knows or understands the customer very well. If you are a pharmaceutical company, your customer can be someone who knows all the field sales representatives. If you are a machine builder and your data and AI solution is used for machine maintenance, your customer can be the machine operator.

Who your customer is, you have to find out yourself. But be ambitious. Only taking the business colleague as the customer is often too short-sighted. Who does the business colleague have as a customer? Stretch yourself and be ambitious to make the path to the customer as long as possible — but also be realistic. Start with what you can really implement soon.

A quick note on central things like central data platforms or central infrastructure elements: There is always a central remainder that has to stay central. So don't be dogmatic. It is more about the principle. Very mature organisations manage to build their central functions in such a way that the teams can still work autonomously — by encapsulating them well and building them towards a service model. More on this in a later article.

The team must be small so that real, true teamwork emerges. That is why several people in the team have to cover several skills — or have the willingness to learn them.

There are no managers or other general manager roles in the team. Otherwise, it becomes too many people, and nobody should rest on the assumption that the manager will somehow take care of it.

Build a colourfully mixed team. Everyone at eye level.

Building a Leadership Team

Important: The direct supervisors of the team members stay out of the teamwork. The team and the team members do not report to their direct supervisors. They report to the board, supported by a leadership team.

What is the leadership team?

Everyone who normally works as a leader in various functions around teams is redistributed.

Personnel responsibility, the direct supervisor — this function must become maximally unimportant. In the long run, this person should only be responsible for administrative matters. Why? It is about breaking up career paths. Career progression no longer means climbing up the org chart. It means taking on more responsibility and accountability along the value stream.

That is why leadership is divided into different dimensions:

To prevent extremes, each person gets two or more dimensions.

The leadership team meets regularly to discuss the team's results and to clarify governance questions. Whoever is not there supports the decision of those present.

Bringing Strategy into Effect

The leadership team has to do preparatory work before the team starts. The more thorough the preparation, the better the result of the teamwork. It has to be thoroughly thought through how the strategy can come into effect.

In my experience, the best way to implement a strategy is this: Formulate goals that are short and snappy, that everyone understands, that are easy to remember — and not too many. Start with a maximum of five. Then define measurable KPIs for each goal.

Present it to the teams, listen to their feedback, refine if necessary.

Then give the team autonomy, everything it needs, and tight boundaries.

Give the team recognition for performance and be consistent in keeping commitments — including killing initiatives when the results show that it was the wrong path.

The teams will become high performers, and your strategy will be implemented without problems. People love challenges for the same reasons they love competitive sports.

Setting Tight Boundaries

The expectation of the team: Every Friday, a sample of the new vegan chocolate must be ready for tasting. In the review, a test customer, the leadership team, and the board taste the chocolate. The chocolate is evaluated against the defined KPIs. Likewise, the other KPIs on budget, sustainability, availability of ingredients, scalability to mass production, etc. are evaluated.

Afterwards, learnings are discussed and a new plan for the coming week is set up.

The team has six weeks to develop a recipe that really meets the requirements. If this is not achieved, the topic is killed and you restart later with new ideas — or not. This is how you protect budgets. This is how you make sure you don't burn millions. Set a budget for learning. Decide what budget you are willing to burn if the only result is learning. That is the time in which something has to be production-ready.

Be consistent. If it doesn't work, it's over. Everyone has to know that from the beginning. And then it also has to be followed through.

Starting again later is allowed, but with different parameters. Learn from the mistakes.

If it works, production is rolled out to the line.

Boundaries: The budget for the ingredients is tight and must not be exceeded — even if the teams ask for it. Changing boundaries is only allowed if it really no longer makes sense how they were defined. For that, the entire team has to talk to the entire leadership team. Together.

You see: The leadership team has to have a lot of time available quite often. But because the team has much more freedom than before, many leadership tasks disappear. That is why the leadership team can also relax and do nothing and simply be on call. There are many professions in which this is normal. I consider this very important. You have to be ready for action immediately when you are needed. A fully booked calendar is no longer an option.

Not delivering a sample is unacceptable. The team must be clear about what is at stake. The review must be uncomfortable for them if they deliver nothing. Why? They could have said something earlier. You know a few days in advance that there is a problem. Then maybe something could still have been saved. If that happened and the chocolate is still inedible, the mistakes are analysed together in the review.

Managers do not interfere in the teamwork. The team resolves conflicts among themselves. Real teamwork only emerges when the team goes through highs and lows together. If something really bad happens, the team speaks up.

Rethinking Incentives

How do people tick? Actually, it is quite simple. You want meaningful work in which you grow beyond yourself. You want recognition, to be seen, to be part of something bigger, you want to move forward and achieve more. For me, it starts with an event, a review — but completely different from what you are used to.

Back to our example: The board is present at the reviews. You are seen. Performance is recognised. As soon as the chocolate goes into series production, there is a bonus.

Make reviews hybrid wherever possible. The people who can be on site should feel it. Those who join remotely should be able to follow the review well.

The leadership team that supports the team is also seen.

Keep the review SHORT. Taste chocolate, have it evaluated against the criteria, discuss problems. Briefly check budget compliance and other important governance topics. Done.

The reviews should be COOL. Everyone stands, except the board. It should be the opposite of a 30-person workshop with PowerPoint slides. Think beforehand with a few insiders about what "cool" even means in your organisation. It is about an event. The room has to fit, the moderation, how the team presents itself — all of this influences whether this establishes itself as a way of working or not.

It should feel like you are missing out if you don't go.

Therefore: no blah-blah, no slides. Taste chocolate, evaluate, hard criticism, no sugar-coating, no watering down.

If there is a success to celebrate, you can still have a party afterwards.

The review is open to everyone: Interested people can join as listeners or observers. This is important because it makes other departments want to have something like this too. I have experienced this often. When the review gets really cool, when truly extremely impressive things are shown that NOBODY in the organisation would have thought could be built in such a short time — then everyone else wants it too. That is the best engine for a transformation. Success. And being seen doing it. And having fun doing it. And feeling like the best version of yourself. That is unbeatable.

For it to stay cool, problems must be discussed openly and hard. People who have worked in a corporation for a long time sense within a very short time whether something is fake or meant seriously. Whoever wants change has to mean it. The chocolate has to be ready. The product has to be in production or close to production. No discussion, no softening of standards. That would be the ultimate trust and motivation killer.

The leadership team also gets recognition from the board.

Making a career then means: more responsibility and accountability in these dimensions — instead of team lead, department head, etc.

The dissolution of teams that do not perform must be transparent and priced in from the beginning.

I have experienced organisations that actually follow through with this. For the team members, it is of course still frustrating. But I compare it to the football World Cup (I come from Germany, it is an important event here). Whoever does not survive the group stage is out. It is incredibly frustrating for the players when they are eliminated, strong men cry — but: It does not diminish the fascination of the game, and it in no way diminishes the appeal of participating. Quite the opposite.

Learning Journey

As soon as you have managed with one team to roll out a good solution into production and increase the KPIs, you are ready to scale the new way of working to several teams. The leadership team also becomes more stable and begins to understand how the organisation would have to change. The org chart becomes less and less important.

But: Organisations learn slowly. It will be a long learning journey. In this article, I have started to present some principles and possibilities. It is only the beginning, and it is far from over. We still have to learn how to set up hypotheses, define experiments, measure, and learn. We still have to learn how to orchestrate learning in the organisation, how to establish a cadence, where work-in-progress limits are needed, how to reduce waste, and much more.

Many more articles will follow.