LLMs and Generative AI in the enterprise.
Inspire, develop, and guide a winning organization.
Understand the unique values and behaviors of a successful organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how to enhance collaboration and performance in large-scale organizations through Flow Engineering
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
Exploring the impact of GenAI in our organizations & creating business impact through technology leadership.
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
The debate over in-office versus remote work misses a fundamental truth: high-performing teams succeed based on how they’re organized, not where they sit.
Leaders can help their organizations move from the danger zone to the winning zone by changing how they wire their organization’s social circuitry.
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
August 10, 2021
While the traditional IT organization is structured into functional silos, DevOps relies on empowered, cross-functional teams. Is it possible to blend the two approaches and work within the traditional structure? Or do you need to restructure your organization to support DevOps?
The traditional structure offered a way to continuously improve skills in individual practice areas—software development, infrastructure, operations, and security, for example. When you organize around cross-functional teams, do you lose the ability for more skillful infrastructure experts to oversee and coach more junior infrastructure specialists, and do you lose opportunity to build capability and expertise within that technical specialty?
The traditional functional organization can be highly efficient at allocating experts across different projects, reassigning technical experts based on the company’s needs. Must a DevOps organization sacrifice this efficiency?
These are questions that many of us grapple with as we travel along the DevOps transformation journey to improve our organizations. This paper addresses those questions, identifies some of the models that enterprises and organizations are currently using, and proposes four organizational models for leaders.
Download the Full Paper
In Thinking Environments, the authors described four organizational models, and the benefits and drawbacks of each model with respect to DevOps. They recommend moving away from a matrixed organization to overcome the drawbacks for DevOps teams. In some cases, especially large traditional organizations, there are good reasons for not moving away from a matrixed organization. For example:
In other cases, organizations are structured to reflect customer organizations, or the organization is early in their DevOps transformation and there’s insufficient support for reorganization.
This paper focuses on the problem of organizations that can’t or won’t move away from a matrixed organization. In particular, it focuses on those matrixed organizations in which:
While traditional architecture principles focus on the “ilities” of software development, such as usability, maintainability, scalability, availability, extensibility, and portability, the value stream architecture model focuses on creating a transparent, repeatable, self-healing model for the delivery of software. The key difference in the two architecture paradigms is that the traditional “ilities” model focuses on the software product while the value stream model focuses on the delivery of the software product.
As organizations continually evolve and rely on cross-functional teams coming together and adopting DevOps practices, the process of delivering software products must also evolve. Value stream architecture is the facilitator of organizational process change and transparency, and should be the primary focus for every organization striving for DevOps greatness.
The adaptability that the value stream architecture gives an organization to optimize its delivery processes is measurable and repeatable through the flow units and flow metrics, as described in this paper. These attributes of the architecture allow for a self-healing capability that drive positive change and value back into the architecture through feedback loops. The value stream architecture approach to DevOps and process improvement will continually add value back into the delivery process as long as the architecture is the key focus of the process improvement journey.
Enterprises can no longer rely on long-established business models in which technology was merely applied to drive more efficient business processes. In our current digital economy, technology is now key to all business strategies. The traditional approaches to manage technology planning and delivery are not optimized for this new reality. These models were optimized for cost and segmented responsibilities to drive localized efficiency of the different processes across the technology value stream. These models need to fundamentally change to drive more connectedness between business and IT. This enables businesses to shift focus from optimizing for cost and a false sense of timeline predictability to optimizing for the speed and rate of business value delivery. Those that have embraced this shift or were born in this era are disruptors that are uniquely positioned to capitalize in this new economy.
For the rest of you, being Agile and implementing “code to cloud” DevOps practices are necessary but no longer sufficient to keep competitors from disrupting your business and taking your customers! The differentiation has now shifted left in the value stream and requires a new way of thinking about how work flows, how to make bottlenecks visible, and how to empower product-based teams. Will this journey be easy? No. Is it necessary to start now?
This paper first clarifies what a product-based software delivery model is and then provides some simple guidance on how to start your journey.
Instead of another paper on why you should move from project to product, this paper focuses on on how to make the move. By using the decades of experience from our authors and peers at the DevOps Enterprise Forum to glean as much as we could about the do’s and don’ts of enterprise product transformation, we compiled that knowledge into something digestible and applicable to you and your organizational transformation.
To gather information that is both relevant and that has been proven successful, we interviewed industry thought leaders across fourteen large enterprises who successfully drove product and technology transformations. These leaders had amazing insights from their successes and failures in moving organizations from project to product at scale. We took the enlightening moments from those interviews and broke the learnings and recommendations down into exercisable guidance. Through the interview process, we noticed similarities and themes that formed the main structure of this paper. The interviews conducted intentionally spanned a breadth of industries to demonstrate the applicability of the product operating model in any industry.
The companies assessed span the following industries: retail, banking, airline, telecommunications, apparel, accessories, sports equipment, financial services, insurance, technology, food and beverage, and medical software.
Traditional IT and project funding models pose a critical business risk and, if not changed, threaten the survival of technology-based organizations. Balancing the high-risk investment of innovation (research and development) with traditional business-as-usual tasks has always been tricky for corporations. Too much risk could, in the event of a sudden failure, lead to a company’s dissolution; too little innovation and the company may eventually be overtaken and lose market share to competitors and new upstarts.
Understanding the criticality of funding both innovation and business-as-usual efforts means organizations also need to use the right investment selection process, establish guardrails to avoid misuse, and meet fiduciary responsibility requirements. Organizations must fund the right investments with the right allocations under uncertain conditions, while fulfilling internal and external financial reporting responsibilities.
This paper outlines the conflict between how traditional funding processes handle fiduciary risks and what Agile and DevOps teams need to perform well. It provides three case studies to illustrate new ways of funding that avoid such conflicts.
This paper discusses the myth of the full-stack developer and describes a more sustainable paradigm called the full-stack team, also known as a balanced team or a cross-functional team.
A full-stack team is a balanced team. It has many people, each with a core set of skills plus different specialties. As a whole, the team’s knowledge covers the entire stack. Team members are always seeking to educate and empower their coworkers to help them improve their skills. This creates a division of labor and a healthy system of specialization, and also encourages learning and growth for the entire team.
Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.
Very informative post.
Reply
Superb post. Very helpful as well.
Your email address will not be published.
First Name Last Name
Δ
As enterprises move beyond initial experiments with generative AI, establishing robust governance becomes critical…
Artificial intelligence and large language models (AI/LLMs) have emerged as powerful tools that can…
As enterprises begin exploring generative AI, understanding the core technical components becomes essential—even for…
Organizations building complex cyber-physical systems face mounting pressure to innovate faster while maintaining reliability,…
