1. technology transformations should follow a continuous improvement paradigm.
   • maturity models focus on helping an organization "arrive" at a mature state and then declare themselves done with their journey
   • capability models focus on helping an organization continually improve and progress, realizing that the technological and business landscape is ever-changing.
     • The most innovative companies and highest-performing organizations are always striving to be better and never consider themselves "mature" or "done" with their improvement or transformation journey
2. Teams have their own context, their own systems, their own goals, and their own constraints, and what we should focus on next to accelerate our transformation depends on those things.
   • maturity models are quite often a "lock-step" or linear formula, prescribing a similar set of technologies, tooling, or capabilities for every set of teams and organizations to progress through.
   • capability models are multidimensional and dynamic, allowing different parts of the organization to take a customized approach to improvement, and focus on capabilities that will give them the most benefit based on their current context and their short and long-term goals.
3. Be outcome based
   • capability models focus on key outcomes and how the capabilities, or levers, drive improvement in those outcomes
     • This provides technical leadership with clear direction and strategy on high-level goals (with a focus on capabilities to improve key outcomes).
     • It also enables team leaders and individual contributors to set improvement goals related to the capabilities their team is focusing on for the current time period.
   • Most maturity models simply measure the technical proficiency or tooling install base in an organization without tying it to outcomes.
     • These are vanity metrics
     • while they can be relatively easy to measure, they don’t tell us anything about the impact they have on the business.
4. The technology and business landscape is ever-changing
   • maturity models define a static level of technological, process, and organizational abilities to achieve.
   • capability models allow for dynamically changing environments and allow teams and organizations to focus on developing the skills and capabilities needed to remain competitive.
     • what is good enough and even “high-performing” today is no longer good enough in the next year.

1. get you started on defining and measuring these capabilities.
2. point you to some fantastic resources for improving them

• 46 times more frequent code deployments
• 440 times faster lead time from commit to deploy
• 170 times faster mean time to recover from downtime
• 5 times lower change failure rate (1/5 as likely for a change to fail)

• Turning the right levers / Improving the right capabilities

1. Focus on outputs rather than outcomes
2. Focus on individual or local measures rather than team or global ones

1. LoC
   • Ideally,
     • We should reward developers for solving business problems with the minimum amount of code
     • It's even better if we can solve a problem without writing code at all or by deleting code (perhaps by a business process change)
   • Minimizing LoC isn't an ideal measure either (due to readability issues)
2. Velocity
   • Velocity was designed to be used as a capacity planning tool
   • Several flaws if used as a productivity metric
     1. Velocity is a relative and team-dependent measure, not an absolute one
     2. When used as a productivity measure, teams inevitably work to game their velocity
        • Inflate their estimates
        • Avoid collaborating with other teams (collaboration might decrease their velocity and increase the other team's velocity
3. Utilization
   • High utilization is only good up to a point
   • Once utilization gets above a certain level, there is no spare capacity (or "slack") to absorb
     • Unplanned work
     • Changes to the plan
     • Improvement work
   • Queue theory in Math tells us that ad utilization approaches 100%, lead times approach infinity

1. Focus on a global outcome to ensure teams aren't pitted against each other
2. Focus on outcomes not output (it shouldn't reward people for putting in large amounts of busywork that doesn't actually help achieve organizational goals)

1. Delivery lead time
   • The time it takes to go from a customer making a request to the request being satisfied
   • A key element of Lean Theory
   • Two parts to lead time
     1. The time it takes to design and validate a product or feature
        • It's often unclear when to start the clock
        • Often there is high variability
     2. The time to deliver the feature to customers
        • Easier to measure
        • Has a lower variability

   • The distinction between these two domains

     Product Design and Development	Product Delivery (Build, Testing, Deployment)
     Create new products and services that solve customer problems using hypothesis-driven delivery, modern UX, design thinking.	Enable fast flow from development to production and reliable releases by standardizing work, and reducing variability and batch sizes.
     Feature design and implementation may require work that has never been performed before.	Integration, test, and deployment must be performed continuously as quickly as possible.
     Estimates are highly uncertain.	Cycle times should be well-known and predictable.
     Outcomes are highly variable.	Outcomes should have low variability.

   • Shorter product delivery lead times are better
     1. Enable faster feedback on what we are building
     2. Allow us to course correct more rapidly
     3. Deliver a fix rapidly and with high confidence
   • We measure product delivery lead time as /the time it takes to go from code committed to code successfully running in production/
2. Deployment frequency
   • Reducing batch size is another central element of the Lean paradigm
     1. Reduced cycle times and variability in flow
     2. Accelerates feedback
     3. Reduces risk and overhead
     4. Improves efficiency
     5. Increases motivation and urgency
     6. Reduces costs and schedule growth
   • However, in software, batch size is hard to measure and communicate across contexts as there is no visible inventory.
   • Therefore, we settled on deployment frequency as a proxy for batch size since it is easy to measure and typically has low variability
3. Time to restore service
   • In modern software products and services, which are rapidly changing complex systems, failure is inevitable
   • So the key question becomes: How quickly can service be restored?
4. Change fail rate
   • In the context of Lean, this is the same as percent complete and accurate for the product delivery process

• because it allows you to gather user feedback quickly (using techniques such as A/B testing)
• the ability to take an experimental approach to product development is highly correlated with the technical practices that contribute to continuous delivery.

• Don't outsource the development of software that is strategic to tour business
• Distinguishing which software is strategic and which isn't, and managing them appropriately, is of enormous importance.
  • wardleymaps – Medium

Before you are ready to deploy a scientific approach to improving performance, you must first understand and develop your culture

whenever there is fear, you get the wrong numbers

1. Is well-defined in the scientific literature
2. Could be measured effectively
3. Would have predictive power in our domain

1. Basic assumptions
   • Formed over time as members of a group or organization make sense of relationships, events, and activities
   • The least "visible"
   • The things that we just "know," and may find difficult to articulate, after we have been long enough in a team
2. Values
   • More "visible"
   • collective values and norms
   • can be discussed and even debated by those who are aware of them
   • Provide a lens through which group members view and interpret the relationships, events, and activities around them
   • Influence group interactions and activities by establishing social norms, which shape the actions of group members and provide contextual rules
3. Artifacts
   • The most "visible"
   • These artifacts can include
     1. Written mission statements or creeds
     2. technology
     3. Formal procedures
     4. Heros and Rituals

• Pathological (power-oriented) organizations are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.
• Bureaucratic (rule-oriented) organizations protect departments. Those in the department want to maintain their "turf," insist on their own rules, and generally do things by the book—their book.
• Generative (performance-oriented) organizations focus on the mission. How do we accomplish our goal? Everything is subordinated to good performance, to doing what we are supposed to do.

• Three characteristics of good information
  1. It provides answers to the questions that the receiver needs answered.
  2. It is timely.
  3. It is presented in such a way that it can be effectively used by the receiver.
• Good information flow is critical to the safe and effective operation of high-tempo and high-consequence environments, including technology organizations

• The characteristics of organizations

  Pathological (Power-Oriented)	Bureaucratic (Rule-Oriented)	Generative (Performance-Oriented)
  Low cooperation	Modest cooperation	High cooperation
  Messengers "shot"	Messengers neglected	Messengers trained
  Responsibilities shirked	Narrow responsibilities	Risks are shared
  Bridging discouraged	Bridging tolerated	Bridging encouraged
  Failure leads to scapegoating	Failure leads to justice	Failure leads to inquiry
  Novelty crushed	Novelty leads to problems	Novelty implemented

• This means you can use these questions in your surveys too.

• 	Strongly disagree	Disagree	Somewhat disagree	Neither agree nor disagree	Somewhat agree	Agree	Strongly agree
  Information is actively sought
  Messengers are not punished when they deliver news of failures or other bad news
  Responsibilities are shared
  Cross-functional collaboration is encouraged and rewarded
  Failure causes inquiry
  New ideas are welcomed
  Failures are treated primarily as opportunities to improve the system

• To calculate the "score" for each survey response, take the numerical value (1-7) corresponding to the answer to each question and calculate the mean across all questions.

1. in organizations with a generative culture, people collaborate more effectively and there is a higher level of trust both across the organization and up and down the hierarchy
2. generative culture emphasizes the mission, an emphasis that allows people involved to put aside their personal issues and also the departmental issues that are so evident in bureaucratic organizations. The mission is primary.
3. generativity encourages a "level playing field," in which hierarchy plays less of a role

• the goal of bureaucracy is to "ensure fairness by applying rules to administrative behavior."

1. A good culture requires trust and cooperation between people across the organization -> It reflects the level of collaboration and trust inside the organization
2. Better organizational culture can indicate higher quality decision-making.
   1. not only is better information available for making decisions,
   2. but those decisions are more easily reversed if they turn out to be wrong because the team is more likely to be open and transparent rather than closed and hierarchical.
3. teams with these cultural norms are likely to do a better job with their people, since problems are more rapidly discovered and addressed.

1. Software Delivery Performance
2. Organizational Performance

It all comes down to team dynamics

who is on a team matters less than how the team members interact, structure their work, and view their contributions

• Accident investigations that stop at "human error" are not just bad but dangerous
  • Accidents typically emerge from a complex interplay of contributing factors
  • In complex adaptive systems, accidents are almost never the fault of a single person
• Human error should be the start of the investigation
  • Our goal should be
    1. to discover how we could improve information flow so that people have better or more timely information
    2. to find better tools to help prevent catastrophic failures following apparently mundane operations

Following the theory developed by the Lean and Agile movements, implementing the practices of these movements can have an effect on culture

The way to change culture is not to first change how people think, but instead to start by changing how people behave--what they do

• 4. Technical Practices
• 7. Management Practices for Software
• 8. Product Development

1. Build quality in.
   • build a culture supported by tools and people where we can detect any issues quickly,
   • so that they can be fixed straight away when they are cheap to detect and resolve.
2. Work in small batches.
   • By splitting work up into much smaller chunks that deliver measurable business outcomes quickly for a small part of our target market, we get essential feedback on the work we are doing so that we can course correct.
   • Even though working in small chunks adds some overhead, it reaps enormous rewards by allowing us to avoid work that delivers zero or negative value for our organizations.
   • changing the economics of the software delivery process so the cost of pushing out individual changes is very low.
3. Computers perform repetitive tasks; people solve problems.
4. Relentlessly pursue continuous improvement.
5. Everyone is responsible.
   • A key objective for management is making the state of these system-level outcomes transparent, working with the rest of the organization to set measurable, achievable, time-bound goals for these outcomes, and then helping their teams work toward them.

1. Comprehensive configuration management.
2. Continuous integration (CI).
3. Continuous testing.
   • No one should be saying they are "done" with any work until all relevant automated tests have been written and are passing.

1. Version Control
2. Deployment Automation
   • Teams can deploy to production (or to end users) on demand, throughout the software delivery life cycle.
3. Continuous Integration
4. Trunk-Based Development
5. Test Automation
6. Test Data Management
7. Shift Left on Security
8. Loosely Coupled Architecture (5. Architecture)
9. Empowered Teams
   • Fast feedback on the quality and deployability of the system is available to everyone on the team, and people make acting on this feedback their highest priority.
   • Teams that can choose their own tools based on what is best for the users of those tools
10. Monitoring
11. Proactive Notification

• By giving developers the tools to detect problems when they occur, the time and resources to invest in their development, and the authority to fix problems straight away, we create an environment where developers accept responsibility for global outcomes such as quality and stability.

• Strong identification with the organization you work for (10. Employee Satisfaction, Identity, and Engagement)
• Higher levels of software delivery performance (lead time, deploy frequency, time to restore service)
• Lower change fail rates
• A generative, performance-oriented culture (3. Measuring and Changing Culture)

• These investments will make our technology process more sustainable
  1. Less Rework
  2. Lower levels of deployment pain
  3. Reduced team burnout (9. Making Work Sustainable)
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely (Manifesto for Agile Software Development)

• This is challenging because quality is very contextual and subjective

  Quality is value to some person. - Quality Software (Management)

• Several proxy variables for quality
  • Change fail rates
  • The quality and performance of applications, as perceived by those working on them
  • The percentage of time spent on rework or unplanned work (The strongest correlation)
  • The percentage of time spent working on defects identified by end users

• Continuous delivery predicts lower levels of unplanned work and rework in a statistically significant way

  	High Performers	Low Performers
  New Work	49%	38%
  Unplanned Work or Rework	21%	27%
  Other Work	30%	35%

• Unplanned work and rework are useful proxies for quality because
  • They represent a failure to build quality into our products
  • In The Visible Ops Handbook, unplanned work is described as the difference between

    Paying attention to the low fuel warning light on an auto mobile

    The organization can fix the problem in a planned manner, without much urgency or disruption to other scheduled work

    Running out of gas on the highway

    The organization must fix the problem in a highly urgent manner, often requiring all hands on deck

  • Reducing failure demand (The Vanguard Method)
    • Failure demand is demand for work caused by the failure to do the right thing the first time by improving the quality of service we provide
    • This is one of the key goals of CD, with its focus on working in small batches with continuous in-process testing

• Keep as much things in version control as possible
  1. Application code
  2. System configuration
  3. Application configuration
  4. Scripts for automating build and configuration in version control
• These factors together predict IT performance and form a key component of CD
• Keeping system and application configuration in version control was more highly correlated with software delivery performance than keeping application code in version control.

• the following practices predict IT performance:
  1. Reliable automated tests
  2. Developers primarily create and maintain acceptance tests, and they can easily reproduce and fix them on their development workstations
     • having automated tests primarily created and maintained either by QA or an outsourced party is not correlated with IT performance.
     • the theory behind this is that when developers are involved in creating and maintaining acceptance tests, there are two important effects.
       1. The code becomes more testable when developers write tests.
          • TDD enforces developers to create more testable designs
       2. When developers are responsible for the automated tests, they care more about them and will invest more effort into maintaining and fixing them
     • Testers (still) serve an essential role in the software delivery lifecycle
       • performing manual testing such as exploratory, usability, and acceptance testing,
       • helping to create and evolve suites of automated tests by working alongside developers.
     • It's important to run them (automated tests) regularly
       • Developers should get feedback from a more comprehensive suite of acceptance and performance tests every day.
     • Furthermore, current builds should be available to testers for exploratory testing.
  3. Test data management
     • Successful teams
       1. had adequate test data to run their fully automated test suites
       2. could acquire test data for running automated tests on demand
       3. test data was not a limit on the automated tests they could run
  4. Trunk-based development
     • Successful teams
       • Fewer than three active branches at any time
       • Branches with very short lifetimes (less than a day)
       • Never had "code freeze" or stabilization periods
     • These results are independent of team size, org size, or industry
     • Anecdotally, and based on our own experience, we hypothesize that this is because having multiple long-lived branches discourages both refactoring and intrateam communication
     • GitHub Flow is suitable for open source projects
       • whose contributors are not working on a project full time.
       • In that situation, it makes sense for branches that part-time contributors are working on to live for longer periods of time without being merged.
  5. Information security
     • High-performing teams
       • were more likely to incorporate information security into the delivery process.
       • Their infosec personnel provided feedback at every step of the software delivery lifecycle, from design through demos to helping with test automation.
       • However, they did so in a way that did not slow down the development process, integrating security concerns into the daily work of teams.
     • In fact, integrating these security practices contributed to software delivery performance.
  6. Adopting continuous delivery
     • the technical practices of continuous delivery have a huge impact on many aspects of an organization
     • Continuous delivery improves both delivery performance and quality, and also helps improve culture and reduce burnout and deployment pain
     • However, implementing these practices often requires rethinking everything
       • how teams work
       • how they interact with each other
       • what tools and processes they use
     • It also requires substantial investment in test and deployment automation, combined with relentless work to simplify systems architecture on an ongoing basis to ensure that this automation isn't prohibitively expensive to create and maintain.

1. the software they were building—or the set of services they had to interact with—was custom software developed by another company (e.g., an outsourcing partner).
2. to be working on mainframe systems.

• This reinforces the importance of focusing on the architectural characteristics, discussed below, rather than the implementation details of your architecture.
  • It's possible to achieve these characteristics even with packaged software and "legacy" mainframe systems
  • employing the latest whizzy microservices architecture deployed on containers is no guarantee of higher performance if you ignore these characteristics.
• it's important to invest in your capabilities to create and evolve the core, strategic software products and services that provide a key differentiator for your business.
• The fact that low performers were more likely to be using—or integrating against—custom software developed by another company underlines the importance of bringing this capability in-house.

testability

We can do most of our testing without requiring an integrated environment.

deployability

We can and do deploy or release our application independently of other applications/services it depends on.

1. Make large-scale changes to the design of their system without the permission of somebody outside the team
2. Make large-scale changes to the design of their system without depending on other teams to make changes in their systems or creating significant work for other teams
3. Complete their work without communicating and coordinating with people outside their team
4. Deploy and release their product or service on demand, regardless of other services it depends upon
5. Do most of their testing on demand, without requiring an integrated test environment
6. Perform deployments during normal business hours with negligible downtime

• Conway's Corollary
• Organizations should evolve their team and organizational structure to achieve the desired architecture.
• The goal is for your architecture to support the ability of teams to get their work done—from design through to deployment—without requiring high-bandwidth communication between teams.

1. the use of bounded contexts and APIs as a way to decouple large domains into smaller, more loosely coupled units
2. the use of test doubles and virtualization as a way to test services or components in isolation.

• However, it's essential to be very strict about these outcomes when implementing such architectures.
• Unfortunately, in real life, many so-called service-oriented architectures don't permit testing and deploying services independently of each other, and thus will not enable teams to achieve higher performance.

1. we can achieve better delivery performance, increasing both tempo and stability while reducing the burnout and the pain of deployment.
2. we can substantially grow the size of our engineering organization and increase productivity linearly—or better than linearly—as we do so.

• a goal-oriented generative culture
• a modular architecture
• engineering practices that enable continuous delivery
• effective leadership

• Limit Work in Progress
  • drive process improvement
  • increase throughput
• Visual Management
  • Creating and maintaining visual displays showing key quality and productivity metrics and the current status of work (including defects),
  • making these visual displays available to both engineers and leaders,
  • aligning these metrics with operational goals
• Feedback from Production
• Lightweight Change Approvals

• It's only when they're combined with the use of visual displays and have a feedback loop from production monitoring tools back to delivery teams or the business that we see a strong effect.
• When teams use these tools together, we see a much stronger positive effect on software delivery performance.

• WIP limits are no good if they don't lead to improvements that increase flow.
  • whether they are good at limiting their WIP and have processes in place to do so.
  • if their WIP limits make obstacles to higher flow visible,
  • if teams remove these obstacles through process improvement, leading to improved throughput.
• Visibility, and the high-quality communication it (visual displays) enables, are key. (the types of information being displayed, how broadly it is being shared, and how easy it is to access.)
  • if teams use tools such as kanban or storyboards to organize their work.
  • if visual displays or dashboards are used to share information,
  • whether information on quality and productivity is readily available,
  • if failures or defect rates are shown publicly using visual displays, and how readily this information is available.

• Westrum Organizational Culture
• Software Delivery Performance
• Less Burnout

• Teams that reported no approval process or used peer review achieved higher software delivery performance.
• Teams that required approval by an external body achieved lower performance.

• External approvals were negatively correlated with lead time, deployment frequency, and restore time,
• and had no correlation with change fail rate.
• It certainly slows things down.

• pair programming or intrateam code review,
• combined with a deployment pipeline to detect and reject bad changes.

1. After all, software systems are complex.
2. Every developer has made a seemingly innocuous change that took down part of the system.
3. What are the chances that an external body, not intimately familiar with the internals of a system, can review tens of thousands of lines of code change by potentially hundreds of engineers and accurately determine the impact on a complex production system?

• This idea is a form of risk management theater:
• we check boxes so that when something goes wrong, we can say that at least we followed the process.

• However, this is more of a governance role than actually inspecting changes.
• Such teams should be monitoring delivery performance and helping teams improve it by implementing practices that are known to increase stability, quality, and speed, such as the continuous delivery and Lean management practices described in this book.

• Work in Small Batches
  • The key to working in small batches is to have work decomposed into features that allow for rapid development,
  • instead of complex features developed on branches and released infrequently.
  • This idea can be applied at both the feature and the product level.
  • An MVP is a prototype of a product with just enough features to enable validated learning about the product and its business model.
  • Working in small batches enables short lead times and faster feedback loops.
  • it allows you to gather user feedback quickly using techniques such as A/B testing.
• Make Flow of Work Visible
• Gather & Implement Customer Feedback
  • regularly collecting customer satisfaction metrics,
  • actively seeking customer insights on the quality of products and features,
  • using this feedback to inform the design of products and features.
• Team Experimentation
  • Many development teams working in organizations that claim to be Agile are nonetheless obliged to follow requirements created by different teams.
  • One of the points of Agile development is to seek input from customers throughout the development process, including early stages.
  • This allows the development team to gather important information, which then informs the next stages of development
  • But if a development team isn't allowed, without authorization from some outside body, to change requirements or specifications in response to what they discover, their ability to innovate is sharply inhibited
• To be effective, Experimentation should be combined with the other capabilities we measure here (above)
  • ensures that your teams are making well-reasoned, informed choices about the design, development, and delivery of work, and changing it based on feedback
  • ensures that informed decisions they make are communicated throughout the organization
  • increases the probability that the ideas and features they build will deliver delight to customers and add value to the organization

Development

the activities used to develop and test software

IT operations

the work done to maintain and keep software operational

1. in environment
2. in process and methodology
3. in mindset
4. even in the words teams use to describe the work they do

1. an indication that software development and delivery is not sustainable in your organization
   • Where code deployments are most painful, you'll find the poorest software delivery performance, organizational performance, and culture
   • A high correlation between deployment pain and key outcomes
2. a concern when development and test teams have no idea what deployments are like
   • If your teams have no visibility into code deployments, that's another warning that software delivery performance could be low
   • because if developers or tests aren't aware of the deployment process, there are probably barriers hiding the work from them
   • And barriers that hide the work of deployment from developers are rarely good, because they isolate developers from the downstream consequences of their work

• Ask your team
  1. How painful deployments are
  2. What specific things are causing that pain
• Be aware that if deployments have to be performed outside of normal business hours, that's a sign of architectural problems that should be addressed.
• It's entirely possible—given sufficient investment—to build complex, large-scale distributed systems which allow for fully automated deployments with zero downtime.

1. Software is often not written with deployability in mind
   • A common symptom here is when complex, orchestrated deployments are required because the software expects its environment and dependencies to be set up in a very particular way and does not tolerate any kind of deviation from these expectations, giving little useful information to administrators on what is wrong and why it is failing to operate correctly.
   • These characteristics also represent poor design for distributed systems.
2. The probability of a failed deployment rises substantially when manual changes must be made to production environments as part of the deployment process.
3. complex deployments often require multiple handoffs between teams, particularly in siloed organizations where database administrators, network administrators, systems administrators, infosec, testing/QA, and developers all work in separate teams.

1. Build systems that are designed to be deployed easily into multiple environments, can detect and tolerate failures in their environments, and can have various components of the system updated independently
2. Ensure that the state of production systems can be reproduced (with the exception of production data) in an automated fashion from information in version control
3. Build intelligence into the application and the platform so that the deployment process can be as simple as possible

• Burnout can make the things we once loved about our work and life seem insignificant and dull.
• It often manifests itself as a feeling of helplessness, and is correlated with pathological cultures and unproductive, wasteful work.

1. feeling exhausted, cynical, or ineffective
2. little or no sense of accomplishment in your work
3. feelings about your work negatively affecting other aspects of your life
4. (In extreme cases)
   • family issues
   • severe clinical depression
   • suicide

• costing the US economy $300 billion per year in sick time, long-term disability, and excessive job turnover
• Thus, employers have both a duty of care toward employees and a fiduciary obligation to ensure staff do not become burned out.

1. foster a supportive work environment
2. ensure work is meaningful
3. ensure employees understand how their own work ties to strategic objectives

• even though changing the environment is far more vital for long-term success
• Managers who want to avert employee burnout should concentrate their attention and efforts on
  1. Fostering a respectful, supportive work environment that emphasizes learning from failures rather than blaming
  2. Communicating a strong sense of purpose
  3. Investing in employee development
  4. Asking employees what is preventing them from achieving their objectives and then fixing those things
  5. Giving employees time, space, and resources to experiment and learn
• Employees must be given the authority to make decisions that affect their work and their jobs, particularly in areas where they are responsible for the outcomes

1. work overload: job demands exceed human limits
2. Lack of control: inability to influence decisions that affect your job
3. Insufficient rewards: insufficient financial, institutional, or social rewards
4. Breakdown of community: unsupportive workplace environment
5. Absence of fairness: lack of fairness in decision-making processes
6. Value conflicts: mismatch in organizational values and the individual's values

• If they felt burned out or exhausted
• If they felt indifferent or cynical about their work, or if they felt ineffective
• If their work was having a negative effect on their life

1. Organizational culture
   • How to foster a supportive and respectful work environment
     1. creating a blame-free environment
     2. striving to learn from failures
     3. communicating a shared sense of purpose
   • Watch for other contributing factors
   • remember that human error is never the root of failure in systems
2. Deployment pain
   • Complex, painful deployments that must be performed outside of business hours contribute to high stress and feelings of lack of control
   • Ask teams how painful their deployments are and fix the things that hurt the most
3. Effectiveness of leaders
   • Responsibilities of a team leader include
     • limiting WIP
     • eliminating roadblocks for the team
   • So they (team members) can get their work done
4. Organizational investments in DevOps
   • Investing in training and providing people with the necessary support and resources (including time) to acquire new skills are critical to the successful adoption of DevOps.
5. Organizational performance
   • At the heart of Lean management is giving employees the necessary time and resources to improve their own work.
     1. creating a work environment that
        1. supports experimentation, failure, and learning,
        2. allows employees to make decisions that affect their jobs.
     2. creating space for employees to do new, creative, value-add work during the work week, and not just expecting them to devote extra time after hours

• When organizational values and individual values aren't aligned, you are more likely to see burnout in employees, particularly in demanding and high-risk work like technology.
• When organizational values and individual values are aligned, the effects of burnout can be lessened and even counteracted.

• If there is a values mismatch, burnout will be a concern.
  1. between an employee and their organization,
  2. between the organization's stated values and their actual values

1. are indicative of employee loyalty and identity,
2. can help reduce burnout,
3. can drive key organizational outcomes like profitability, productivity, and market share.

• We may become great at rapidly developing and delivering reliable, secure, technology-enabled experiences,
• but
  1. How do we know which experiences our customers value?
  2. How do we prioritize what we create so that each team’s efforts advance the larger enterprise strategy?
  3. How do we learn from our customers, from our actions, and from each other?
  4. And as we learn, how do we share that learning across the enterprise and leverage that learning to continuously adapt and innovate?

• connects enterprise strategy with action,
• streamlines the flow of ideas to value,
• facilitates rapid feedback and learning, and
• capitalizes on and connects the creative capabilities of every individual throughout the enterprise to create optimal customer experiences.