In This Context

When development teams are responsible for building an application and supporting it in production, if they also try to build the build the platform to run it, the organization can end up with multiple irreconcilable platforms. This is unnecessary, expensive to operate (if even possible), and takes time away from teams that should be focusing on delivering features, not the platform they run on.

• Handover between development and operations teams kills production speed and agility.

• Adding an Ops person on each developer team is how you end up with 10 irreconcilable platforms.

• Conway’s law says that software architecture will come to resemble the organization’s structure, so if we want the platform to be independent, then the teams developing an application need to be separate from the team running the production platform.

• There is a limit to the capabilities a team can have. Devs are devs; they can extend their knowledge to a certain level, but they are not Ops.

• Maintaining Ops and Development as separate disciplines/teams is not sustainable in cloud native.

• Too much freedom brings chaos, but too much standardization strangles innovation.

Therefore

Create teams that each have their own capability to build a distributed system with microservices managed by dynamic scheduling.

Build-Run teams will be responsible for building distributed applications, deploying them, and then supporting the applications once running. Build-Run teams all use the same standardized set of platform services and deploy to a single unified platform that runs all applications for the entire company. This platform is the responsibility of the Platform Team, which implements and supports it.

• Build-Run teams are not DevOps teams in the traditional sense that devs and operations people sit together.

• In Agile, the development team also includes software testing capabilities, but the products are handed over to a separate Ops team to be delivered to production.

• In cloud native a true cross-functional team must be able to build distributed systems.

• The Platform Team is a specific kind of Build-Run team in that it builds, deploys, provisions, and supports the cloud native platform and infrastructure, but it works separately from the application development teams.

In This Context

Once a platform is built and in production, attention is often directed away from improving internal processes and runtime performance. This can cause degradation over time, reducing quality and performance.

• Dev teams are measured on functionality, Ops on stability, SRE on improvements.

• SRE is a very expensive team to operate because it requires the most experienced and knowledgeable engineers.

• Opportunity cost arises when you pull your best engineers from development teams to SRE.

• If improvements are the priority for this team, then this is somewhat removed as a responsibility/priority for the Build-Run teams.

• SRE is more relevant when an application enters maintenance mode, rather than during the initial build.

Therefore

Create a team that is focused 50% on reliability and 50% on continuous improvement of internal processes and development practices.

This SRE team worries about overall site (platform) availability. However, each individual service has its own operational needs as well. It can be helpful to add SREs into each individual build squad (or at least tribe) to focus on service availability.

• SRE engineers are in charge of improving whatever it takes to create better infrastructure, better runtime, and better user support.

• The SRE team makes the error budgets and helps the dev team define its operational model and the Platform Team to improve the platform.

• Most tasks are automation rather than manual support.

• Every 18 months the SRE team needs to automate everything it is doing manually (so it can move to the Platform Team’s responsibility).

• You have a highly knowledgeable and experienced team, with good knowledge of operations but also devs who can write code.

Consequently

The runtime stability and quality is continuously increasing, and automation is also increasing.

• + Developers are aware of operational concerns and incorporate that knowledge into their development cycle.

• + The SRE team works closely with the Build-Run teams and the Platform Team.

• − SRE teams are expensive and take top engineering talent away from other projects.

In This Context

When team members are located in different places, they tend to communicate less and focus on their jobs rather than personal relationships. This hobbles team problem-solving, because individuals will attempt to solve problems separately and then contribute that solution back to the team—rather than solving them collaboratively with teammates.

• Creative teams especially are more effective when personal relationships are on a higher level.

• Complex communication is better in person.

• Cloud native is a paradigm shift that requires new ways of working and creative problem-solving.

Therefore

All members of a given dev team will work in the same physical location and meet daily.

All meetings and collaboration will be first done using whiteboards, pen and paper, etc. Teams will be chosen based on location. If the team is in the same office, then move the members to sit at adjacent desks.

• Periodic team-building events to strengthen personal relationships.

• Encourage the team to talk to one another in person.

• Consider pair programming.

Consequently

High level of trust and proximity naturally increases collaboration.

• + Quick and effective communication.

• − Not always possible due to distribution of teams.

• − Possibility of personal conflict exists.

In This Context

In a changing cloud native world, with ownership for application services divided across teams, managers don’t know enough to provide effective advice, much less make good decisions. At the same time, managers have the illusion of knowledge and control—they don’t know what they don’t know—so the team’s abilities and effectiveness are only as great as its manager’s capability.

• Cloud native tech is complex and takes time to learn.

• Most delivery decisions in cloud native happen during automated delivery process or very close to it.

• Dependencies between teams and a need to get permission for any change slow down delivery.

Therefore

Create domain-specific tribes that operate outside of normal management hierarchy.

Use tribes to share specific technical and organizational info and to provide perspective and advice for complex decision making.

• Members of tribes belong to different teams.

• Meetings are regular and open-ended.

• Tribes play advisory and coordination roles but have no decision-making power.

• All the tribe members are knowledgeable in the tribe’s domain.

Consequently

The company has groups that cross-cut traditional organizational units. This helps those people who are closest to and most knowledgeable in a particular domain subject identify areas for running experiments and making changes.

• + Tribe members share ideas and advise one another on issues and problems.

• + Managers have limited ability to intervene.

In This Context

When the teams responsible for delivering stable and scalable products are given too much freedom to innovate and explore, they introduce new risks that harm product quality and increase the cost of development.

In many cases the new cloud native platform is not yet ready or stable enough to accommodate all the new teams, while most of the teams have to maintain old systems and release new incremental updates. Allowing those teams to start innovating too early may come at a significant cost to productivity and product quality.

• Established companies desire creativity because usually they don’t have enough of it.

• Startups are highly creative yet desire proficiency because they are striving to build a consistent, deliverable product.

• The typical enterprise culture strongly supports a proficient, even algorithmic, way of working.

Therefore

Run the execution teams the way they have always been run. Focus on repeatability and optimize on quality and speed of delivery.

As an organization transforms itself into a cloud native entity, most teams will eventually need to evolve to cloud native’s more flexible, intuitive, and problem-solving way of working. During the transition, however, there will be teams still tasked with delivery of the core business on the existing system while the new platform is built. It’s important to keep the proficient teams proficient and run them as they have always been run, not changing to cloud native techniques yet.

Once a system (or new product) has left the innovation phase and is in steady production, most resources can typically be moved away from research and experimentation, and back to a mostly proficient approach.

• Let them know that they are valued: keeping existing product lines going at high quality is important to the business.

• Promise them that they will be onboarded to the new system when the time is right.

• Aim to create team pride around the best possible results and highest-quality products.

• Management of proficient teams requires high repetition, high feedback, and a strong sense of belonging.

• Emphasize that both types of teams are needed and important to the organization; avoid the perception or reality that creative work is rewarded more.

Consequently

Teams in charge of delivering the company’s profit-generating products/services in a proficient way are being managed to optimize this. Proficient and creative teams are loved and appreciated equally.

• + If the market changes in a large and/or frequent way, the company can shift resources into creativity and innovation when necessary. But creative is expensive, so drop back to proficient when things are stable/predictable.

• − Some teams may need to work in the legacy codebase permanently (see “Lift and Shift at the End”).

In This Context

Onboarding too many teams at once will stress the Core Team and reduce its ability to continue improving the platform. Educating people too early, however, will create anxiety in the teams and desire to start as soon as possible (and frustration if there is a long wait before the new system is available).

• A team that releases a tool on a large scale with low quality will struggle to improve it.

• People have little patience and are eager to apply recent learning.

• If you learn something new, you need to start using that knowledge soon or risk losing it.

• Good people may go to other companies to have a chance to work with the new and exciting technologies.

Therefore

Start small organizational changes early in the cloud native transformation. Prepare materials to onboard other teams and execute it slowly when teams are ready.

Continue onboarding the rest of the organization gradually over a period of 3 to 12 months.

• Start educating teams one to three months before onboarding.

• Prepare Developer Starter Packs and all relevant educational materials to simplify the onboarding.

• Onboard two to five teams at a time. Take breaks in between to use their feedback to improve the platform.

• Continuously improve the platform and the onboarding materials based on the feedback from the recently onboarded teams.

Consequently

The Core Team can support teams as they onboard and improve the process as they go. The first few teams onboarded to the platform can help educate and support the teams onboarded later.

• − Some teams may not join for one to three years.

• − Slower perception of scale.

In This Context

When faced with a problem, people typically spend only the minimum time required to find the first satisfactory solution, even if it’s not the best one or doesn’t involve all stakeholders. This leads to reasonable solutions, but misses the opportunity to find excellent ones.

• Law of preservation of cognitive energy leads people to choose the first good solution.

• Developers typically are decision makers on tech solutions.

• Devs aren’t trained in business or market forces.

• Elegance and beauty are also relevant for internal systems.

Therefore

Take the basic first idea and run it through a series of divergent and convergent thinking exercises to rethink the idea’s boundaries and explore alternatives.

Ideation/brainstorming is followed by application experiments. In-depth explanation of Design Thinking is beyond the scope of this pattern, but guidelines for running Design Thinking workshops can be found online²

• Create 10 to 20 new solutions/problems/ideas based on the first idea, narrow that list to the two to three best ones. Then expand and iterate these two to three best ones into 10 to 20 new possible variations, and then again choose two to three of the most promising to run longer experiments and choose to implement.

• Hold regular Design Thinking workshops.

• Use the workshops to refine big ideas/problems.

• Invite major stakeholders.

• Facilitate collaboration to help excellent solutions emerge.

Consequently

Ideas are thoroughly explored. Cost of initial exploration is still low, as it requires little to no actual development (No Regret Moves).

• − Too many people involved slows down the decision-making process.

In This Context

Teams are either endlessly researching and collecting information or, conversely, starting to deliver and optimize very early. In the first case, value is delivered to customers late, ends up being of poor quality, or never gets delivered at all. In the second case, the solutions are too simple and underdeveloped and miss the opportunity to solve customer problems.

• Many processes aiming to increase productivity attempt to do so by pushing out innovation.

• Radical innovation and proficient delivery can’t be done in the same way.

• Innovation without delivery is academic research.

• Delivery without innovation is blind to market changes.

Therefore

Run alternating iterations of research and development.

Spend about 20%–30% of the time running proof-of-concept experiments and other research activities. Use the rest of the time to implement the discovered solutions and increase the quality.

• Every third or fourth sprint in Scrum should be used for research.

• 20%–30% of Kanban backlog should be dedicated to innovation and improvement tasks.

• When a solution is not clear, use experiments or PoCs to discover and eliminate options.

Consequently

Delivery and innovation are separate and in balance.

• + Team can still change product direction relatively easily.

• + Quality of the products constantly increases.

• − One-third of the time is not immediately monetized.

In This Context

Innovation and evolution are inevitable in technology. However, there is little need to innovate when a proficient system is delivering stable value and maintenance cost is low. And we often see that, in an otherwise proficient system, the team continues to introduce new tools and solutions that constantly destabilize the product while needlessly consuming time and budget.

• Repeatability leads to boredom.

• Quality demands investment.

• Creativity and proficiency require different management frameworks.

• Proficiency and mastery require repeatability and standards.

• Creativity requires freedom and psychological safety for generating experimentation.

Therefore

Reduce work in progress, focus on optimizing delivery process, measure quality and speed of delivery, and aim to improve both.

Lean management optimizes proficiency and value to customers while eliminating anything that does not bring value to the end product/service and ensuring continuous incremental improvement.

• Use Kanban with optimization and new features backlog.

• Measure everything that matters.

• Optimize price versus performance ratio.

• Optimize proficient processes.

• Automate repeatable tasks.

Consequently

Delivery is fast and proficient. System is stable, and quality is consistently going up.

• + No destruction of an efficient system.

• + Gradually increasing quality.

• − Very limited innovation.

• − Some people are bored.

In This Context

When there is little information about an ongoing cloud native transformation, people don’t automatically assume it’s a good idea. People don’t resist the transformation because they think it is the wrong thing to do—they resist because it is new and scary. Change creates anxiety, and most people just don’t know much about cloud native in general. Without clarity, people tend to fill in the gaps with imaginary negative information (negative attribution bias), and they may fear their jobs will be dramatically different—or even eliminated.

Most people enter the transformation process from a traditional Waterfall hierarchy. In such organizations, managers have always just told them what to do. Cloud native teams, however, are highly independent and so require full participation and active involvement from all members. Without motivation to learn and do it right, the result could be disastrous for the company, as only a few teams will fully embrace the cloud native way of working.

• People have a lot of ways to resist by dragging their feet or even actively sabotaging an initiative.

• People need to be encouraged to behave differently.

• Punishment works to stop behaviors, but it will not work to inspire and engage people with new behaviors.

• People do not automatically receive a new message. They need many touch points to hear the new story until they accept and internalize it.

• Negative attribution bias: if you aren’t telling them about the change, they assume no progress is being made/nothing is happening.

Therefore

Share positive, clear, and abundant information about the transformation to create acceptance, support, and even excitement across the company.

Metamorphosing an organization’s tech and especially culture is a tribal movement. If people are not sure whether it’s a good idea, then you need to help them understand. Negative attribution bias can be powerful here: without enough info, you fill in the gaps with negativity. The solution is to fill in the gaps with a lot of information all the time—not just about what is happening, but why, how these changes will benefit the entire organization.

• Organize events, send newsletters, show demos. Essentially, do internal marketing.

• Tell the story over and over in a positive and inspirational way, rather than a “do this or else” way.

• Internal Evangelism should be led by someone who is committed and knowledgeable and involved. This person makes it public, involves people, and creates the movement.

• It’s imperative the evangelist demonstrates good knowledge of the business itself and what it does now, so their opinion is trusted as being informed and based on thoughtful judgment.

• The Transformation Champion is a possible candidate for this role, but only if it does not distract from their duties leading the transformation itself.

Consequently

The transformation is understood across the organization, and people feel motivated to join and support it. There is plenty of time and opportunity to mitigate any resistance originating through fear of uncertainty.

• + People have had time to get comfortable with the idea.

• + The message starts out very simple and gradually grows more detailed as both the project and the acceptance progress.

• + Small projects and experiments are opportunities for evangelism.

In This Context

People are joining the organization’s cloud native initiative without fully understanding the possibilities it offers or the wide variety of solutions available. New technology is introduced all the time that renders current tools and techniques out of date. When this happens, productivity suffers, and change slows down.

• Only some people are motivated to learn on their own.

• People learn better in groups.

• Formal education is more effective after some initial exposure to/experience with new information.

• Most people need to learn something a few times before they fully understand it.

• The cloud native ecosystem is changing fast.

Therefore

Build and continuously run an education program about cloud native for everyone in the company, from basic education for newly onboarded or new joiners to continuous and more advanced trainings for more experienced engineers.

• Onboarding bootcamps

• Hackathons

• Periodic knowledge updates

• Management trainings

• Online self-learning opportunities

• Books, blog posts, and other reading

• On-the-job learning by pair programming, whiteboarding, etc.

Consequently

Team knowledge is constantly refreshed and updated.

• + Easy ways to roll out new information.

• + A lot of inspiration arises for trying out changes.

• + Developers are better able to adapt to technology shifts.

• + Technology changes, which are inevitable, will be minimally disruptive since developers are better able to adapt to shifts in tech.

• + By disseminating best practices and successful ways of using technology, you can replicate success and avoid missteps.

• − There is cost related to frequent education.

In This Context

Committing too early to a solution you don’t yet fully understand. Teams are likely to do one of three things: Choose a known solution that is not a good fit for the problem, because they are familiar with this solution; undertake a lengthy analysis of the solution that leads nowhere (analysis paralysis); or else jump on the first available solution (availability bias).

• In Waterfall all questions need to be answered before actions are taken.

• People learn best by doing.

• Difficult problems are better solved by a team.

Therefore

Explore the problem space. Mitigate the risk by delaying critical decisions long enough to run a series of small scientific-style experiments to uncover missing information and evaluate alternatives.

Each experiment should have a hypothesis that can be proved or disproved by the experiment. When a hypothesis is disproved, the experiment itself can still be called a success. It is critical to avoid assigning blame or punishing those involved in the experiment in cases where the results are not satisfactory.

• Identify one problem/idea and choose two to five small—taking a few hours to a few days—experiments to test it.

• Form a hypothesis to query: What is my problem in the first place, does this solve it, what is the cost, and can we afford it?

• Identify and compare possible alternative solutions.

• Establish clear and measurable criteria for success or failure. Collect data and evaluate it.

Consequently

The team is granted time and given a process for experimenting with solutions when it encounters a complex problem.

• + Teams learn by doing this, which helps them in future decisions and work.

• + By showing a small, quick success with an experiment, you are able to make a first small and easy step in a new direction.

• − When experiments are cheap and easy enough to run, it can be hard to determine when it is time to stop experimenting and make a decision/move forward.

In This Context

Once some initial experiments have uncovered a likely transformation path, it is time to test it. Committing to it right now could, if it is wrong, cause large problems and expense as the initiative continues.

You simply don’t know enough to make a large commitment at this point. Any full commitment right now carries massive risk because switching to an alternative later will be very difficult. Adopting a solution you don’t fully understand too early in the process compounds the risk, because you will continue to build further functionality on top of this solution.

• Hands-on work, rather than promises or explanations, is better for demonstrating value to skeptics.

• Changing early decisions is costly in the later stages of a migration project.

Therefore

Build a basic functional prototype to demonstrate the viability of a solution. Define the questions that need answers before starting the PoC and stop the work once the questions are answered.

• This should take a few days to a few weeks.

• Build the most primitive version you can get away with. Be ready to throw it away when you are finished. (This doesn’t that mean you must throw it away, but often when initial quality is intentionally low, it’s cheaper and easier to just scrap it and rebuild from scratch).

• Only work on hard issues related to the specific needs of the current project, and stop when the solution is clear.

• Try to demo something functional so you can collect business-related information regarding how this solution will impact future development.

Consequently

Risk is reduced for the overall project in the early stages of the migration. Critical knowledge and experience are gained during the experimentation process.

• + You have gained the knowledge and proved the solution works, and now understand how it fits into the overall project.

• + You now have reasonable confidence that this is the correct decision.

• − Running PoCs carries cost. Every time you do it, you pay for it.

In This Context

Decision making via chain of command is not sustainable in cloud native. Using hierarchy to resolve conflicts and agree on decisions takes too long, and solutions are limited to the capabilities of the managers making that level of decision. Engineers might find a superior solution that never gets implemented because it takes too much time and effort to navigate the bureaucracy to get permission. So they will give up and just move on with whatever they have.

• Recent speed of technological change is growing exponentially.

• Market is now also changing frequently, with unexpected new competitors appearing.

• In traditional organizations, managers make all the decisions and give instructions to engineers.

• Further you go from the change, the slower the decision over time.

Therefore

Push the decision power as close as possible to any change as it is happening. It is typically best if the dev team itself makes the decisions.

Because your team works as part of a bigger tribe of teams, sometimes your decision must involve others. For example, if you want to change APIs, you must inform those who use them—and they may object to the change. So whatever happens inside of a microservice is fully the domain of its development team, but anything going in/out is also the domain of the teams that consume them.

• Put in place security and regulation to make sure people are allowed to make these decisions.

• Complete separation of duties: execs in charge of strategy, managers in charge of setting objectives, engineers free to execute their work as they see best.

• Instill that it’s OK to fail into the organization’s values.

• Use hierarchical management for conflict resolution.

Consequently

Executives delegate the power to create the vision and objectives to middle management, and middle managers delegate power over technical decisions to the execution teams.

• + Strong incentive to resolve conflicts first within team, then within tribe, only then go to management.

• − Time and effort are required to coordinate with any teams who are consuming your particular service to make sure it works all around.

In This Context

People are often blind to their own biases and live in their own bubble without realizing it.

During a cloud native transformation, teams that have always worked in a proficient way now are tasked with innovation. They have no experience being creative, so they will keep using past solutions to attempt to solve new problems.

Lacking external perspective you will be blind to your own confirmation bias and interpret results to fit your preconceived notions, leading the project to very poor results. At the same time, other people within the organization can clearly see the problems before they happen.

• Judgmental tendencies are hardwired.

• Most people don’t give positive feedback unless prompted to do so.

• Without empathy, feedback can be perceived as aggression or attack.

• For people who have never given feedback it can be difficult to start.

• An existing team has already solidified their relationships and will find it difficult to change their behavior.

• Significant feedback requires some level of personal relationship.

Therefore

Create a safe environment and simplify ways for people to give feedback—positive, negative, even confrontational—in a constructive way.

Facilitate team activities to build personal connections between team members; this helps to create a sense of mutual trust that allows feedback to flow freely.

• Offer training or tools to teach people how to give constructive feedback.

• Create opportunities, such as one-on-one or group meetings or weekly email updates on the project, to exercise giving constructive feedback.

• If someone is doing something well, feel comfortable giving them praise.

• If you think someone is taking a wrong approach, tell them in a constructive way.

• Someone needs to act as leader to model how to do all this.

• Psychological safety is an essential prerequisite for Productive Feedback.

Consequently

Productivity goes up because people can learn and improve their work and behavior, and because they feel seen and appreciated.

• − There are costs involved: honest and constructive feedback relies on personal relationships and psychological safety.

• − High risk of personal conflict, but this is the chance you have to take if you really want to go fast. People will learn on their own without feedback, but it will take a lot longer, and some things they will never learn on their own.

In This Context

In uncertain environments, what worked in the past may not work here, so you need to invent rather than attempt to reuse existing solutions.

• Creativity requires trust and volunteering information.

• By default people will use existing knowledge to solve a problem.

• People will not volunteer information to an expert.

• They will only volunteer when there is trust and a personalized connection.

• New solutions are best achieved in highly collaborative, small creative teams.

Therefore

In complex environments where there is no clear path forward, a strong team needs personalized relationships to collaborate on creative solutions. Creativity is not the goal—co-creation is the goal. Creativity is open-ended and may not lead to anything, but co-creation generates results.

Cloud native is better suited to co-creative relationships where the team itself collaborates on the future solution with all team members participating. People are solving the problem together rather than relying on the expert advice of individual members.

Co-creation teams are significantly more innovative and creative because people are thinking together and drawing from group understanding and experience. They work by building mutual trust, volunteering extra information, and being willing to take risks as a group.

• To create closer relationships, literally reduce the physical distance between team members. Teams should share the same workspace whenever possible.

• Run trust-building experiences, bringing people together to build personal relationships.

• Encourage collaboration and co-creation by working in groups.

Consequently

The team has established trust and a relationship that helps people share information effectively, which leads to co-creating new solutions.

• + Each person on the team is helping to create solutions.

• + The team as a whole is more creative than each individual.

• + People have individual expertise, but they contribute it to the wider team objectives.

• − Effort is required to bring people together for social events, extra activities, etc. Not just money and time, but also psychological safety and other organizational culture aspects that take investment.

In This Context

When no inquiry is done after a problem occurs or an experiment fails, the team doesn’t improve and is likely to keep making similar mistakes. In many organizations, fault-seeking occurs, and blame gets assigned to anyone involved with a problem. This leads to mediocre performance, since most innovative actions carry significant risk.

• Once punished for failure, people tend to avoid risks.

• Waterfall organizations tend to punish teams or individuals associated with problematic events to ensure stability; novelty is discouraged.

• There is no innovation without risk.

Therefore

Understand what went wrong by focusing on the problem instead of the people involved.

Talk about what went wrong and why, and how to avoid it in the future. Don’t punish people for mistakes—encourage them to learn from the experience instead. This creates the psychological safety required for taking risks.

• Gather everyone involved and review what happened.

• Share the results with the rest of the team.

• Find possible solutions for avoiding similar problems in the future.

• Focus on the problem, not the people: don’t ask who did what and never assign blame.

• If some mistakes occur repeatedly, find out who is involved and introduce personal commitment/responsibility.

Consequently

People have the autonomy and the confidence to try and fail, and try again.

• + Teams are always improving by learning how to find and avoid repeated mistakes.

• + Progress happens faster since people don’t waste time and effort trying to find a solution that is “guaranteed to work” before they even risk trying it.

• − If there are no consequences for failure, some people may fail due to not taking personal responsibility for solving problems as they arise.