If we are doing something for our user, (who now secretly turned into a customer, because the user now does not actively use our work product) we need to focus on the workflow for the activity. This workflow is actually the value stream. There is a number of methods or recipes out there that tell and educate you on how find the value stream. Just find it yourself. When you are done you will have a structure like this:

Value stream for a hypothetical activity executed for our customer

There are three “swim lanes” associated with with three different teams or competences or manufacturing stations, and the work is being passed through the different entities and teams until it gets finished. There are parallel activities, there are dependencies. Each box describes a discrete activity that has a start and an end, receives some specific input and delivers a specific output. This work breakdown is like an architecture of the workflow. The building blocks are specific activities. Time by the way is running from left to right. There might be some improvement potential, but at least the work is structured and well prepared for improvement measures. I will not discuss them here. They are in the expertise of lean management or lean manufacturing.

For me it is enough that we see clear input and output and clear interfaces. The work can be modularized and measured and improved in the sense of scientific management – if the management knows how to do the steps in the boxes or we can use the ideas from the Toyota Manufacturing System to have the value generators improve the process. (The only place where value is generated is a the shop floor. Everybody else is doing work classified as “non value-add necessary”. In best case. All other cases qualify as “waste”.) In a way, this is also classical scientific management by F.W. Taylor.

In the case of a physical or logical product, i.e. some output the customer wants to use him or herself to generate value no his/her own, we have a similar concept: the boundary diagram.

A boundary diagram for a system. Boxes denote an internal structure called subsystems. There are well defined inputs and outputs for the system and its subsystem.

There probably are a number of definitions for boundary diagrams. A very simple one is that we structure the system in such a way that all sub-units are independent and communicate with the environment though interfaces with defined

• material transfer
• information transfer
• energy transfer
• mechanical contact.

(Yes, information transfer is the same as energy transfer in a Physics world, but in engineering it is smart to separate both, even when it is not correct at all.)

If you follow me down this rabbit hole (see “Alice’s Adventures in Wonderland” by Lewis Caroll), we can realize that all products and services can be implemented in independent boxes with defined interfaces. Pretty spooky thing, right?

Now it is time to learn from some big guys. I can describe everything in units with interfaces. Sounds like service based solutions. Yes. This would be service based and each box represents a service. If I now freeze the interfaces, all these services now become independent. Correct? In consequence, all the insides of the boxes can be hidden behind a magic curtain. You might want to check out the famous example of the Mechanical Turk. From the outside you cannot detect if there is a machine or a person. (Yes, you can remember the Turing test now ). Same story: as long as I do not tell you what is in side the box, I can do what I want and you will not be unhappy as long as I am delivering according to what I promised. In our speak: I deliver according to my output specification.

If you are at that point, you may want to check the ideas of Simon Wardley on Wardley mapping. (Simon, I know I am oversimplifying, but this is the way my brain works. Sorry.) The Amazon way of monetizing services is also an option. I believe this is how Amazon Web Services were started.

Back to our architecture. Perfect situation: I am free to do whatever I like if and when I keep my promise. I can optimize my work. I can use the tools I want, I can use the methods I want, etc. Which tools and methods do I want? Typically the ones that make my life as easy as possible. Nature always takes the path of least resistance. No, that is a lie. Nature takes the path of least action, which is the physicist way of saying: “The path of the least effort.” We can describe nature pretty well, when we assume it to be lazy. Now tell me Physics is not fun. After sneaking in some Richard Feynman wisdom, let us have a look at the ideas of Application Programming Interface first (API-first) as a useful concept.

The Steve Yegge’s “Google Platforms Rant” CSE 452: Google’s Introduction to Distributed System Design

“[…]

His Big Mandate went something along these lines:

1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols – doesn’t matter. Bezos doesn’t care.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn’t do this will be fired.
7. Thank you; have a nice day!

[…]”

This is what Steve Yegge claims has been mandated by Jeff Bezos for Amazon. Quite some time ago.

In the light of what we just looked at before, these are some simple rules to follow in order to generate something very modular, adaptable and externizable, i.e. if you find the function somewhere a bit cheaper and it is not of strategic value for you, buy it, don’t make it. If you can sell the function as a service: sell it. Maybe you have heard of Amazon Web Services before. Something they sold to the outside world. This is the meaning of “externizable”. If you can sell it, sell it as a package. The same thing in reverse: If you can sell it as a package, you can easily also buy it from somebody else and weave it into your solution.

Wait a second though. Steve Yegge writes that Jeff Bezos wrote about teams, while I talked about functions and subsystems. You can match sub-system structure with team structure. Mathematically this is an isomorphism. In the original paper, Melvin Conway promoted a homomorphism between team structure and product/service architecture. He did not talk about service architecture, but see above. Difference between isomorphism and homomorphism? Something is isomorphic if the structure is exactly the same. If two subsystems or two functions are very small and it for some reason makes sense to keep them separate, you can ask one team to work on both. Voilà: the isomorphism becomes a homomorphism. Very simple. One team does one sub-system. If the sub-system is too large, make it smaller, BUT fix the interfaces.

The screw can be turned one more notch: Haier, the appliance maker, or rather its CEO Zhang Ruimin has taken an extreme approach to generate sub-system solutions: Micro-enterprises. The internal contracting as principle for coordination can be seen as a (very abstract) API. Simply an API between companies. In the bottom of the article, you will find the statement that complex systems cannot be engineered top down, but that they need to emerge bottom up. We will come to this point in the next chapter.

On the practical side: How should I know in the beginning which structure is the right one? Building teams takes a bit of time and in the end we are dealing with people. We do not want to move people around the organization with a high frequency. Simple solution: Separate the flow organization from the hierarchical organization. In the areas of high uncertainty, it make sense to separate line responsibilities from content responsibilities. If you do that, you can borrow the idea of “Tiger Teams”. Keep the team structure malleable until the solution becomes clear. Then harden the structure to give security to people. Still hierarchical leadership does not need to coincide with technical leadership. It can however. Understanding this concept explains the success of a number of startup compared to teams from corporations. In the startup, you focus on the product and the hierarchy follows. Like the Bauhaus Form follows Function concept. Keep even your hierarchy product centric. Corporations often react differently to challenges.

• Separate line organization from technical organization, i.e. line leadership is different from technical leadership. This causes conflicts between leaders, but this is not presenting a problem, since leadership is “non-value add necessary” at best and the developer produce the value in the organization. The conflict is not where value is generated.
• Match the technical organization to the product architecture. That allows the right people to be in close vicinity (not necessarily in physical proximity, but in terms of functionality.
• Understand that the architects in your organization are in a leadership role. Choose and and educate them wisely. Listen to them and provide them with the necessary power. A seasoned developer may not necessarily be the best architect. Make him or her a senior or “executive” developer. A more junior developer may in fact be a better architect. Architecting things and developing things are two different trades. Sometimes.
• Architecture is more than the documentation of your product. It is defining the products future and modularity and feature roadmap. As a Danish proverb says: “Predictions are very difficult. Especially about the future”, the task is difficult. One solution thus is to keep the architecture as adaptive as possible.

So far so good. As takeaway for now, we have:

1. Understand the product/service.
2. Decide if you need a modular and adaptive architecture or you are better off with a monolithic solution.
3. If you want a modular and adaptive product/service, structure your product or service with focus on modularity.
4. Define and document the architecture. Make sure the architecture welcomes adaptations.

And two more things.

• There is intentional architecture and emergent design. Both work hand in hand.
• A monolithic solution has its benefits, just as modular solutions have their benefits. As always: It depends on the context. The lead architect needs to make a decision. The decision may be right or wrong, but a decision is needed.

Intentional and Emergent Design

Architecture plays at different levels. Above we discussed abstract boxes of functionalities in value streams and boundary diagrams. How boxes are connected at the level of interest is the realm of intentional architecture. An architect understands the functionality of the product or the execution of the workflow and structures the topic. This is what we understand as “intentional architecture“. What happens within the box is in the authority of the team, developing the functionality. On this level, one level lower than the “intended” architecture, we also have an intended architecture. Just one inside the functionality. When we now add feedback or “correction loops” into the system, i.e. we allow the architects and developer from inside the boxes to communicate with the architects defining the system architecture, new ideas and solutions may appear. If they do, new solutions ideas may manifest. This is the realm of emergent design. Emergence means that the system has properties that could not be foreseen in the properties of its constituents. Emergent design results from iterative delivery of constituents of the system we are working to deliver. (See also the HBR article on Haier.) There is no such thing as emergent architecture. In order to control the design of things, architecture needs to be intentional. If architecture just “happens” it may be seen as emergent, but in fact it is just reverse engineering of a solution and trying to justify decisions taken on the fly. Emergent design is a very useful consequence of iterative development. Architecture may change and evolve as the solution develops. There is no contradiction: if architecture is sketched/documented/drawn as the solution is developed, the solution structure is validated with an architectural description. Trust me: you will find flaws right away. It is similar to the statement “If you can’t explain it to a six-year old, you don’t understand it yourself.” (Probably by Einstein.) If your design is not simple, it will not be easy to modify and to extend in the sense of iterative development. Thus, you will automatically kill it after a few weeks latest. Simply BECAUSE you cannot extend the functionality in the sense of iterative development. But, you will only kill it if I insist on interactive development and frequent demos. This is where puzzle pieces fall together and generate a solution. Remember this thing with with agility? Always demo the product. This is the very reason why. If you can demo every week or every other week, you HAVE a modular architecture that welcomes changes. If you can’t demo frequently, I have an idea why… BTW: you can plan a modular architecture. Agility is not a must. It just points you to an adaptive solution.

After discussion architecture in general, let us have a look at possible solutions for easy and cheap adaptability: The API-first approach.

The post Architecture Considerations. More Important Than You Might Think. appeared first on Grado.

But that doesn’t stop there: the second step, if not the core, of Wardley Mapping is the development of a concrete strategy, the “strategic gameplay”. or “stratagems”.

Most of these actions are typical business activities, but some involve deception, deception, or even things that could be viewed as an abuse of power. Wardley has one Games value system used to classify the individual actions.

The post Strategic gameplay with Wardley Maps appeared first on Grado.

Managers are well aware of the need to adapt their strategy development processes to their competitive environment. Yet, the study found, many rely in practice on approaches that are better suited to predictable, stable environments, even if their own environment is known to be very volatile or changeable.

What is preventing these leaders from designing their strategy to suit their situation? Perhaps they lack a systematic approach: a strategy for strategy development.

Here we introduce a simple framework from Martin Reeves that breaks strategic planning into four styles, depending on how predictable your environment is and how much power you have to transform it. With the help of this framework, business leaders can adapt their strategic style to the specific conditions of their industry, their business function or their geographic market.

The strategy palette suggests five different strategic approaches:

• Classic strategy: Achieving a competitive advantage through optimal positioning. Example: Shell
• Adaptive strategy: Achieving an advantage through quick adaptation. Example: Zara.
• Visionary strategy: inventing an industry with a certain degree of predictability, determined pursuit of an opportunity. Example: Tesla
• Shaping strategy: Shaping companies shape or redesign an industry by influencing the development of a market by coordinating with other players in their favor.
• Renewal strategy: A renewal strategy approach renews the vitality and competitiveness of a company when it operates in a crisis or a harsh environment.

The post Your Strategy needs a Strategy appeared first on Grado.

The Workforce Portfolio needs to exhibit the same characteristics as the Product Portfolio. It however is in the leading role in the mid term horizon. The Workforce Portfolio has to be more progressive than the Product Portfolio because the workforce generates the value that is delivered by the products. There is no chicken and egg problem. The lead is clearly with the products when it is about the definition of the future portfolio or portfolio vision. In the intermediate time frame the Workforce Portfolio is clearly in the lead.

For both Portfolios, the concept of splitting capacity between

• run the business, i.e. operate and maintain
• grow the business, i.e. enhance and expand
• transform the business, i.e. innovate and drive

needs to be understood. For more details on the concept you may refer to Gartner’s Run-Grow-Transform model.

When discussing portfolio management, we actually are not looking for methods of how to decide in which basket to put our eggs. It is that PLUS keeping an eye on running and growing and transforming the business. Depending on the character of the organization or rather the vision for the character of the organization (conservative or innovative) put more or less capacity is put into the different areas from satisfying committed business, extending current business areas and developing future business.

Portfolio management provides guardrails to reference business relevant decisions to fix points and it needs to be taken to the next level of Portfolio Management.

The post Portfolio Strategy appeared first on Grado.

1. Organizational archetypes and strategy development: 
2. Strategic gameplay as part of Simon Warley’s mapping method.
   

   Simon Wardley is one of the critics who denies the usefulness of these methods. Unlike most of the others, he presents a alternative concept.

   
   

More resources

1. Your strategy needs a strategy Five organizational archetypes for an adequate strategy development. Martin Reeves, HBR.
2. Your strategy needs a strategy (book) 
3. Wardley mapping 
4. On 61 different forms of gameplay 

Recommended Resources

The post Strategy Definition appeared first on Grado.

“Identity is the sense-making capacity of the organization”

A strong and coherent identity is the strong backbone of an adaptive company. It provides clear guidance for people operating within the company.

The trip around identity always starts with defining a clear purpose of the company and what value you will to create for whom. You need identify market needs and map it with what you believe your company can create in terms of differentiated value for customers.

Safety Advice

Don’t get trapped in pursuing to many disconnected customer segments and value propositions at the same time. That dilutes your ability to focus and reduces the changes to be truly excellent at anything in the long run.
Also make sure to not over-constrain your identity creation by your current portfolio and customers.

Related

• Strategy Definition
• Portfolio strategy
• Organizational capabilities

Recommended Resources

1. Start with why by Simon Sinek (TED Talk)
2. The 3 Elements of a Strong Corporate Identity by Paul Leinwand and Cesare Mainardi

The post Identity appeared first on Grado.

“Strategy is not a lengthy action plan. It is the evolution of a central idea through continually changing circumstances.”

Jack Welch, ex-CEO General Electric

Tweet

In a business environment of increasing volatility, uncertainty, complexity and ambiguity, strategy development is not something you do once and follow the plan for the next five years. A lot of things may cause the business environment to change. That forces you to adapt your strategy accordingly. So you will want to visit this region “Evolving Strategy” more often.

Strategy needs to be a continuous process of discovery, execution, reflection and alignment. The ultimate goal is to not only adapt to the change, but also take advantage of it.

The post Evolving Strategy appeared first on Grado.

Start with Why is Simon Sinek’s mission to help others do work, which inspires them, and uses real-world examples of great leaders to show you how they communicate and how you can adapt their mindset to inspire others yourself.

3 lessons you should take away from Start with Why:

• If you want to inspire others, always communicate your why first.
• Excited employees are the best resource for any business.
• You don’t need sleazy sales tactics when you start with why.

References

• A short description of the principles: Sinek: Write A Vision Statement That Works

The post Start with Why appeared first on Grado.

1. Document your portfolio as it is today.
2. You can find a center of gravity in there? This is your identity. Your portfolio defines your identity. If not, give yourself an identity. How do you want to be perceived today? How do you want to be perceived in future. Two identities. Nothing pathological. One is today, the other tomorrow. Suddenly we have target and direction.
3. From your future identity you can define the portfolio you want to entertain in future. Here again the portfolio defines the identity.
4. Voilà! Your path from Situation to Strategy.

Don’t overdo it. An 80% solution is great. Your predictions will be wrong anyways, but not completely. Work in iterations. Remember the P-D-C-A cycle.

This was the Quick Start. Go to Portfolio Management.

The post From Situation to Strategy appeared first on Grado.

• What is your competitive environment?
• Where should you focus? (Why here over there?)
• What should you own and build in-house? What should you buy off-the-shelf or outsource?
• Which methodologies should you use?
• Where are your competitors relative to you?
• What market changes can you anticipate?
• How can you organize to accommodate continuous change?
• Which context-specific strategic plays are currently possible?

What is a Wardley Map

A Wardley Map decomposes a product along the Value Chain (some prefer the term supply chain) to get deeper insights into the structure and the forces shaping the evolution of the market and the necessary decisions.

The vertical axis concerns with dependencies, the horizontal axis positions the elements along their evolutionary state, aka maturity.

The analysis cycle

While the map is a useful and actionable visualization of the situation, Wardley Mapping gets really useful by applying it the analysis cycle. The cycle uses the vocabulary of Sun Tsu (Wardley points out that it is about the same as John Boyd’s OODA loop.

A typical analysis goes along the cycle above.

Purpose

Your moral imperative. The scope of what you are doing and why you are doing it. The reason others follow you.

Strategy is all about observing the landscape, understanding how it is changing and using what resources you have to maximise your chances of success. Obviously, you need to define what success is and that’s where your purpose comes in. It’s the yardstick by which you currently measure yourself. However, as this is a cycle, your very actions may also change your purpose and so don’t get to stuck on it.Simon Wardley in 

On Playing Chess

Climate

The climate may affect your purpose, the environment may affect your strategy and your actions may affect all… Your purpose isn’t fixed, it changes as your landscape changes and as you act. There is no “core”, it’s all transitional.Simon Wardley in 

On Being Lost

Landscape

A description of your competitive environment, including its features, your position, and any obstacles in the way.

To map your landscape:

1. Know your users (who you serve)
2. Know their needs
3. Know the prerequisite activities to meet those needs
4. Add position (connect users, needs, and prerequisites from top to bottom according to dependence)
5. Add movement (place needs and prerequisites left to right according to evolutionary stage)

Determining Movement

The movement of a component along the X axis is determined by its stage of evolution.

Don’t worry if some of the terms are confusing… just use what you can. Like Chess, mapping is a craft and you will get better with practice.Simon Wardley in 

Finding a Path

Evolutionary Characteristics Cheat Sheet

An interactive list of characteristics to help you determine how evolved something is (select cells to highlight).

Based on Simon Wardley‘s Evolutionary Characteristics Cheat Sheet, CC BY-SA 4.0.

Climate

The forces acting upon the environment. The rules of the game, patterns of the seasons, and competitor actions.

Based on Simon Wardley‘s, Climatic Patterns, CC BY-SA 4.0.

Your First Patterns

Pattern 1: Everything evolves from left to right under the influence of supply and demand competition.

Pattern 2: As components evolve, their characteristics change.

Doctrine (Self-Assessment)

The training of your people, the standard ways of operating, and the techniques that you almost always apply. Select cells multiple times to progress through colors indicating a weak, warning, good, and neutral (undetermined) status.

Phase 1: Stop Self Harm

Phase 2: Becoming More Context Aware

Phase 3: Better for Less

Phase 4: Continuously Evolving

Adapted by Tasshin Fogleman from this tweetstorm and Better for Less, courtesy of Simon Wardley, CC BY-SA 4.0.

Additional Instructions

By examining the doctrine in an organization, you can get an idea of how adaptable it is and how well it will respond to external change or gameplay. You can do this with your own organization, or with other organizations.

In-person? Gather several people from different levels of the organization and perform the above self-assessment together. (There may be arguments, but that’s not a bad thing.) Distributed? See this form-based assessment by Justin Stach.

Once you’ve assessed the status quo of doctrine in your organization, you can go about addressing areas of weakness. Simon suggests you do this in phases. The above self-assessment’s phases presents his best guess at the order in which you should tackle them.

Leadership (Gameplay)

The context-specific strategy you choose after considering your purpose, the landscape, the climate, and your capabilities.

Based on Simon Wardley‘s, On 61 Different Forms of Gameplay, CC BY-SA 4.0.

Glossary

Sources

Get started by reading Simon Wardley’s free book. You can find additional learning resources and tools here.

Wardley Mapping is licensed Creative Commons Attribution-ShareAlike 4.0, courtesy of Simon Wardley.

source: https://learnwardleymapping.com/#

The post Wardley Mapping appeared first on Grado.