The Recipe for Organizational Excellence: Cooking Up High-Performance Teams
Key Takeaways
Use the VSRA to align everything: business, systems, organization with what the customer want
The Team Topologies team types matter but the interaction is even more important
Team Topologies impacts customer value as much as how you deliver
VSRA (menu), Team Topologies (ingredients), and Flow Engineering (recipe) must work together—missing any one leads to failure.
Like master chefs, high-performing organizations need psychological safety, continuous customer feedback, and patience for iterative improvement.
Introduction
How does your business ensure that they are getting a high quality product, in quick time, that is not going to cost them something else later?
Think of this analogy - what makes an eatery a fine-dining experience where customers are prepared to spend lots of money, versus an establishment where you risk food poisoning?
Where would you take your business?
Stephen Walters cooking
Whether it is cooking or collaboration, there are recipes involved in getting it just right. Now I really like to cook. Watching the cooking shows and trying to replicate those tasty morsels. What I love most, however, is to experiment. Always tinkering and trying something new, blending flavour profiles, textures and different regional cuisines.
The thing is this: everyone has different tastes. I know that when I cook a dish an absolute must is to taste your own food and make sure that it works. At that point, there is only one opinion in the room about whether you have cooked a great dish or not, and that is yourself. The moment you serve that to others, your own opinion does not count for much. There will be those who agree and love it. There are those who are not so sure, but they will nod along not wanting to seem impolite, and then there are those who will screw up their face and exclaim!
When we transform an organization, the same will be true, and it’s not that you can force someone to fall in love with your Chili Chocolate Cheesecake. Some people like chilli, and some don’t. So when we take a closer look at the culinary industry, how do we see the top chefs in the top restaurants being such high performers? That is how we want our organizations to operate. Smoothly, professionally, producing high value products for our customers, and something they are willing to pay good money for. How do we get a Michelin-starred enterprise?
Using our previous analogy for fine dining, let’s take a look at some of the key approaches taken by top chefs to get high-performing teams:
A small, but wide ranging menu to choose from
Using only the best ingredients with flavours that compliment
Formulating the recipe to meet the customers needs
The menu: carefully curated options
Our customers come to us because of something specific we provide. THEY define the product we deliver. But so many other organizations are looking to deliver the same. We need to be differentiated, so we look to provide something unique, something different, and above all, something the customer will desire.
In a professional kitchen, there are different sections responsible for different parts of the meal. In the preparation, they will often create elements of the recipe beforehand to be combined into the overall meal. For every part of that preparation, the individual elements appear to be prepared not for the customer, but the head chef. Yet every piece of preparation is done with the customer in mind. So the first rule in creating this menu is to create something the customer wants, not what the head chef wants, and that is true for every person creating every element of the dish.
For IT organizations, this means aligning three critical architectures: business, system, and organizational. These elements must work together harmoniously, just like complementary flavors in a dish, to deliver products that genuinely meet customer expectations. The key is establishing the right sequence: start with customer needs, let those drive business requirements, use business needs to shape your delivery organization, and finally design systems that support this entire value chain.
This is called our Value Stream Reference Architecture (VSRA). I co-wrote a paper on this with Dr Craig Statham for the Value Stream Management consortium. Its purpose, the needs of the customer, the business, the delivery organization, and all to design the required systems. Using Team Topologies as a pattern language and graph theory as a tool for analysis, this white paper shows how organizations can establish a Value Stream Reference Architecture (VSRA) to optimize for value delivery by reasoning about the four fundamental dimensions of knowledge work: Flow, Impediments, Needs, and Effort (Cognitive Load). The paper demonstrates how VSRA can take the guesswork out of organizational restructures by paying close attention to Conway’s Law and the four FINE dimensions so that lean principles and value stream management can be more easily adopted.
This means that when we put our business model together, every part has its clearly defined responsibility, whether that’s creating a platform as a product, or the value driven application. It means we can blend it together into the perfect dish, and identify that unique element that provides extra value to our customers, and be certain that it leaves our customers feeling happy.
The Ingredients: the best approaches, combined well
The VRSA is formulated from a list of ingredients. Namely, it uses:
Team Topologies as a pattern language for an organized and coherent set of patterns
graph theory as a tool for analysis
the principles and laws of physics for determining flow in the natural world
In my view, the most important base ingredient is Team Topologies, because the team types ensure that the people have a clear understanding of their roles and responsibilities, but most importantly, the team interactions clearly define how knowledge work flows between teams. Clarity is key.
Chefs will determine that all ingredients can be categorized into certain types - proteins, carbohydrates, spice, etc. It takes just the right combination of these working together in a clearly defined way to bring the dish together. Yet again, what these are is unique to every dish. And the combinations are important. Too much spice and flavour profile is ruined. Too little protein and the dish is not fulfilling.
Our organizations are made up of the Team Topologies types identified by Matthew and Manuel. All are important and ensure that we provide value to the customer in some way, but without the right balance, the dish is all wrong. Too few Stream-aligned teams and we begin to question the cost to value ratio for our development organization. Too few platform teams and we have so much pressure on other key teams that they stand out in all the wrong ways, too much cognitive load and not enough value.
But even if we have the right balance of our team types, 70-80% Stream-aligned as indicated by the book, it means nothing if they are not combined in the right way. I have argued this and said it on stage in front of Manuel. The most important part of team topologies is not the team types, it is the team interactions.
If our teams do not interact we have no flow. If they interact in the wrong style, we have poor flow and poor team experience. Getting the team interactions just right preserves our team's goodness, it doesn’t spoil how we blend together and actually enriches and enhances the end product.
The Recipe: How to bring it all together
So we have all of our ingredients. We understand how they should be mixed together, We also know how we want this to be at the end in a way that pleases our customers. Now it is the job of actually making it, so we don’t want to be suddenly going wrong now.
I am sure many of us have seen those cooking competitions on the television. People are set a challenge to cook something. They know what it is they are making. They are often given the freedom to add that piece of uniqueness to their dish and they are provided with all of the ingredients and tools they need. This is usually the point where something for someone goes wrong. Forgetting to add the salt at the right time. Miscalculating the length of time in the oven. Using an inappropriate tool resulting in a poor texture.
We may have our teams and their interactions defined, provided them with all the best tools and also clearly defined the business value we should be delivering and the product we will be creating to produce it, but if our people and tools are not all operating smoothly and together in a co-ordinated and pre-conceived way, our product will not deliver.
The third element that allows us to know our recipe for building that product just right is Flow Engineering by Steve Pereira, Team Topologies advocate, and Andrew Davis. This allows us to state clearly why we are building something according to “our menu” and who we are building it for. To understand how we have done it wrong in the past, to tune our method to get better results whilst understanding how all of our elements, “the ingredients”, come together, and then provide a set play for how we should work to get a product completed quickly, securely, with high quality, that delights our customers.
Service!
Only by combining all three of these elements can you truly define and create a high-performing organization.
Without the menu you have no structure, no definition, no clearly defined responsibilities. You may have teams who interact and produce something, but it is likely to be slow, poor quality and not what the customer really wanted.
Without the correct ingredients, you will know what the customer wants, but never get it right, or actually never end up making it at all.
Without the recipe, the customer will be left with a deconstructed and unfinished product, faults everywhere with complaints to match.
The combination of these three elements, plus that added piece of innovation that the correct, psychologically safe environment can inspire, are what can drive your organization towards excellence. Consider each carefully, but also consider this one final lesson to be learnt from any cook. It takes many, many attempts, with a lot of failures along the way, keeping an open mind to learning and listening to your customer, before you can get to a place where you want to be. It is an iterative journey of learning and it is best achieved by including your customer along the way and always craving that feedback and continuous improvement.
If you want to learn more about how to combine Team Topologies, Flow Engineering and the Value Stream Reference Architecture, go to the VSRA community page and read the “Practicalities of the VSRA” series of blogs.
So, experiment, enjoy and bon appetit!.
About the author:
Stephen Walters, Field CTO for GitLab & Team Topologies Advocate
Stephen Walters is a Field CTO with GitLab and Co-author of the Value Stream Reference Architectures paper with Dr. Craig Statham and the Value Stream Management Consortium, where they are both ambassadors. Both are also founders of the Value Stream Raference Architecture Community.
A highly experienced Subject Matters Expert in Value Stream Management, DevSecOps, DevOps, ALM and SDLC, with experience across end-to-end IT disciplines since 1992. Certified in Value Stream Management, DevOps, SAFe, CMMI, ITIL, TOGAF and Prince2.
Stephen is now driving Thought Leadership in GitLab on Value Stream Management and Team Topologies. Additionally, Stephen is an Ambassador with the Value Stream Management Consortium, the DevOps Institute and a certified Team Topologies Advocate. He has a long standing history in stage presentations, webinars and articles on many subjects over multiple decades.
Learn more about Stephen here.