Inspire, develop, and guide a winning 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.
Understand the unique values and behaviors of a successful organization.
LLMs and Generative AI in the enterprise.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
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.
New half-day virtual events with live watch parties worldwide!
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Is slowify a real word?
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
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.
November 1, 2022
This post is adapted from the 2022 DevOps Enterprise Forum Guidance paper The Role of a Platform by Satya Addagarla, Josh Atwell, Mik Kersten, Thomas A. Limoncelli, Sara Mazer, Steve Pereira, Jeff Tyree, and Christina Yakomin.
Adopting a “you build it, you operate it” (YBYO) model requires a company to provide an internal developer platform that enables developers to build and operate their products. This platform can standardize processes and enable (or enforce) recommended practices. However, the platform can potentially overwhelm engineers by increasing their cognitive load. This can lead to burnout, productivity problems, low morale, and high attrition. A well-built platform can reduce cognitive load and lead to enhanced productivity, making compliance with standards easy, while also becoming a competitive advantage.
A product delivery platform is not just to ship applications but to be a vehicle for standardization that can ease compliance with recommended practices and simplify the daily work of engineers, all while reducing cognitive load.
Doing it right is not easy. It puts a high burden on the platform’s creators, especially if care and attention aren’t dedicated to product management and usability. However, the investment required to provide a capable platform is amortized across teams supported by the platform, and it will grow in value like any other product. It is a requirement for success.
Digital transformations require organizations to address their fundamental delivery operating model. To align with models for scaling Agile best practices, including the Scaled Agile Framework (SAFe) and the model introduced by Spotify, some organizations have sought to federate previously centralized functions, such as centralized quality engineering, and put greater autonomy in the hands of development teams. With the move to these YBYO teams, along with the increased complexity of evolving software and technology stacks, the demands on the developer have dramatically increased.
The mental burden can become overwhelming when engineers are tasked with designing, developing, maintaining, and improving systems across many different dimensions. Engineers working in highly dynamic environments can experience stress, confusion, burnout, and other negative effects, which can have an adverse impact on the engineer and the organization they support. As many organizations shift from specialized roles to “full-stack” engineering roles, a single engineer could be responsible for a wide array of tasks, including feature development, security, and incident response. While an argument can be made that knowledge of specific context is critical, how can we expect software developers to deliver at a high level when context switching and cognitive load are so high?
One solution is to take many of these responsibilities, standardize them, and put them directly into the platforms that engineers use. Standardized developer platforms become an important and viable mechanism to improve cognitive load for engineers. Standardized platforms accelerate developer productivity and focus when they are well defined and well implemented. In this paper, we will guide senior technical leaders on refining, simplifying, and scaling standardized platforms that enable software-engineering teams to work at their fullest potential and quickly deliver quality software.
Full-stack software engineers shouldn’t have to know and do everything. They should be provided capabilities that allow them to excel, grow in their strongest areas, and operate competently in areas not essential to their contribution. Pushing every responsibility out to individuals also poses a significant risk to organizational standardization, security, performance management, and the accuracy of audits.
When engineers are tasked with understanding, supporting, maintaining, changing, improving, and developing systems across many different dimensions, the mental burden can become overwhelming. It can lead to stress, confusion, and other negative effects.
In a 2022 study conducted by Mulesoft:
Figure 1: Before: The YBYO Cognitive Challenge
Similar effects have been observed in other knowledge-work industries, such as medicine, for many years. In many organizations, without adequate support and specialization, a single engineer could be responsible for concerns across:
Cognitive load can be defined as the total amount of mental effort being used in the working memory. This can be split into three distinct categories: intrinsic, extraneous, and germane cognitive load. Intrinsic load relates to aspects of a task that are fundamental to the problem space. An example of the intrinsic cognitive load for a web developer could be the knowledge of the coding language being used (along with the programming basics) on a project. Intrinsic cognitive load covers the basics of day-to-day operations.
Extraneous cognitive load includes parts of the environment in which the task is being done. The extraneous cognitive load for a web developer might be the need to remember multiple console commands for a dynamic testing environment. Extraneous cognitive load is essentially undifferentiated heavy lifting.
Germane cognitive load includes aspects of the task that need special attention for learning or higher performance. The germane cognitive load for a web developer could be the specific aspects of the business domain that the developer is programming, like a billing system or a data-processing algorithm. Germane cognitive load can lead to valuable insights, innovation, and differentiated value creation.
Figure 2: Flow Facilitating Joy as the Positive Balance between Skill and Challenge.
Source: Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (New York: Harper and Row, 2009).
In general, organizations should aim to act on each type of cognitive load strategically:
YBYO can push engineers into extraneous cognitive load by demanding each keep a vast array of knowledge in working memory and then saddling them with the responsibility for customer outcomes across that entire array of capabilities. YBYO is often ill defined, which means you could own anything from customer value to operational uptime to API response times, and the criteria are seldom defined until an issue arises beyond the definition. It can set a high bar for hiring, training, standardization, and assessment, and it can drive unmeasured costs, risk, and impact across the organization.
A platform can enable and maximize germane cognitive load by providing and automating capabilities that don’t lead to differentiated value, such as minimizing extraneous cognitive load so that an engineer can spend their time in deep focus and flow at the intersection of challenge and skill. The more time engineers can spend in that state of flow, the more likely they are to generate novel and valuable output, leading to coveted differentiated value.
Figure 3: After: Platform Provides Access to Standard Capabilities that Facilitate YBYO
If your goal is to reduce a team’s extraneous cognitive load using a standardized platform, then the level of cognitive load should be measured periodically, which will establish a baseline and identify trends over time. Additionally, recurring checks of an organization’s cognitive load may provide insight into more acute and urgent problems.
While measuring cognitive load can be difficult, as there are no standard classifications for dimensions of cognitive load, there are a few formal processes and informal assessments that may determine your team’s cognitive load. More than one technique could be used.
A formalized process might be periodic surveys, such as the Engineering Experience Feedback Survey provided in the Remote Team Interactions Workbook by Matthew Skelton and Manuel Pais, to track the overall developer experience and feedback. Of course, forms can be customized for your organization, but try to identify if a developer feels effective and able to respond to work that was assigned in a timely fashion.
Beware of misguided metrics, such as lines of code or number of modules, but pay attention to more informal signs that cognitive load is higher. Measures worth tracking include:
Investment in platforms needs to be defined at a strategic portfolio management level. For example, it is not uncommon for enterprises to have 20% of their overall technology budget allocated to platform development.
In contrast, digital natives such as Shopify have 50% allocated to the platform portion of the portfolio. While 50% may not be the right allocation for all organizations, this stark difference is indicative of how important platform investments are to technology leaders. The reason: underinvestment in platforms is a common bottleneck to the speed of digital product delivery.
It is notoriously difficult to quantify the key metrics of a platform, including cognitive load and technical debt. However, the effects that platform improvements can have on improving the flow of value are measurable. Understanding and measuring flow via value stream management makes bottlenecks like this visible and can help guide investing appropriately in platform products while also measuring the outcomes of those investments on overall flow and business results.
The Flow Framework® outlined in the book Project to Product by Mik Kersten provides an approach for measuring and optimizing the allocation of a software portfolio with platform investment. The goal of a software portfolio is to drive business outcomes. At the highest level, these portfolios are composed of products that serve external customers that are directly tied to business outcomes and platform products that support the external products and are indirectly tied to business outcomes. For external-facing products, the greater the end-to-end flow of value (as measured by flow velocity) or the faster the end-to-end delivery of value (as measured by flow time), the better the business outcomes should be—assuming product-market fit. However, when measuring flow via value stream management platforms, many enterprises will find that dependencies on platforms produce a bottleneck to the overall flow of value to customers. This indicates that additional investment needs to be made in platform products to accelerate business outcomes.
Determining the portion of platform investment should be an iterative process with its own feedback loop. This can be achieved via a regular (weekly, monthly, or quarterly) measurement of whether the platform investment accelerated flow. If not, it is likely the bottleneck was outside of the platform portion of the portfolio, and investment should be put elsewhere. If investment accelerated flow, then additional platform investment is likely to accelerate value delivery and outcomes. This iterative approach can identify the most effective portion of portfolio allocation to platform investment for a particular organization. We recommend avoiding one-size-fits-all assumptions such as “invest 50% in platforms” and instead invest in measuring flow to determine the correct allocation to drive outcomes for your particular organization.
What is the difference between a shared service and a standardized platform? A shared service does work for you. A platform enables you to do the work.
A common shared-services model is a DevOps team that accepts requests directly or tickets within a task system to support dependent teams. They typically work in a highly disruptive, variable, and unpredictable flow, which is stressful for the participants and their dependent teams. Following a ticket-order flow accompanied by interruptions from dependent teams means they lack autonomy and can’t choose where or how to invest—if they get any time for that at all.
Common shared-services tasks include:
Shared services are typically a bottleneck for organizations because they tend not to be standardized, operationalized, or automated; and the work varies dramatically—which leads to unpredictable delays and downstream impacts.
A 2020 assessment across several cases provides some data on the impact a platform can have on developer effectiveness.
In our next post, we’ll explore our recommendations for standardizing the developer experience through the platform.
You can read the full paper for free here.
CIO Home Lending at Wells Fargo
Multi-disciplined marketing and technology leader who has moved from hands on technology to leading marketing and advocacy teams to improve customer enablement and engagement.
Dr. Mik Kersten started his career as a Research Scientist at Xerox PARC where he created the first aspect-oriented development environment. He then pioneered the integration of development tools with Agile and DevOps as part of his Computer Science PhD at the University of British Columbia. Founding Tasktop out of that research, Mik has written over one million lines of open-source code that is still in use today, and he has brought seven successful open-source and commercial products to market.Mik’s experiences working with some of the largest digital transformations in the world has led him to identify the critical disconnect between business leaders and technologists. Since that time, Mik has been working on creating new tools and a new framework for connecting software value stream networks and enabling the shift from project to product.Mik lives with his family in Vancouver, Canada, and travels globally, sharing his vision for transforming how software is built.
Thomas Limoncelli is an internationally recognized author, speaker, system administrator, and DevOps advocate. He manages the SRE teams at Stack Overflow, Inc., and previously worked at Google, Bell Labs/Lucent, AT&T, and others. His books include Time Management for System Administrators (O’Reilly), The Practice of System and Network Administration (3rd edition), and The Practice of Cloud System Administration. In 2005, he received the USENIX SAGE Outstanding Achievement Award.
No comments found
Your email address will not be published.
First Name Last Name
Δ
"This feels pointless." "My brain is fried." "Why can't I think straight?" These aren't…
As manufacturers embrace Industry 4.0, many find that implementing new technologies isn't enough to…
I know. You’re thinking I'm talking about Napster, right? Nope. Napster was launched in…
When Southwest Airlines' crew scheduling system became overwhelmed during the 2022 holiday season, the…
