Skip to content

November 1, 2022

Role of the Platform: Developer Experience

By Satya Addagarla ,Josh Atwell ,Mik Kersten ,Thomas Limoncelli ,Sara Mazer ,Steve Pereira ,Jeff Tyree ,Christina Yakomin

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.

Current State of the Developer Experience

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:

  • The top-three causes contributing to developer burnout were increasing workload/demand from other teams (39%), the pressures of digital transformation (37%), and the requirement to learn new skills to adapt to new technologies and approaches (35%).
  • More than three-quarters (76%) of organizations say the cognitive load required to learn their software architecture is so high that it is a source of angst and low productivity for developers.
  • 91% of organizations say they need solutions that automate key processes for developers so they can do more with less.

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:

  • Support intrinsic-cognitive load (make the basics invisible and frictionless).
  • Eliminate extraneous cognitive load (prevent excessive mental burden).
  • Enhance and augment germane-cognitive load (facilitate novel development).

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

Determining Your Team’s Cognitive Load Level

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:

  • employee Net Promoter Score (eNPS)
  • employee attrition rates
  • job posting metrics (e.g., if more are opening and few are closing)
  • tooling or process proliferation/increase in need to learn new tools
  • percentage of developers volunteering for versus resisting additional tasks
  • intrateam communication (reduction may mean less context switching and mission harmony)
  • overall flow, quality of work, and fitness of solutions for product teams
  • attendance in optional meetings, training sessions, Q&A with management
  • participation in optional feedback sessions or surveys
  • meeting attendance versus making time to complete projects
  • satisfaction, performance, activity, communication, and efficiency (SPACE)

Using Flow to Drive Platform Investments

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.

Platform Examples for Supporting Different Knowledge Areas

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.

Shared Service Examples

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:

  • provisioning and configuring a new developer laptop or managing VPN connectivity
  • configuring firewall rules or cloud access
  • configuring CI/CD pipelines
  • requests for new firewall rules and other network provisions
  • setup of new users, the provisioning of roles, approval of requests for access, etc.
  • manually making changes in production when required based on a change request from another team

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.

Platform Examples

  • A platform allows developers to remain in a state of flow longer and more often by providing capabilities and self-service on demand and automating common manual tasks.
  • A platform can provide an instantiation of infrastructure, software deployment, monitoring as code, automated attestation, shakeout/synthetic testing, and resilience confirmation.
  • A platform can support operational management with accessible logging, alerting, and incident management.
  • A platform can provide access and the ability to contribute to known good practices, reuse, patterns, and documentation, which also creates a sense of collective community within the development organization.
  • A platform can provide consistent and managed capabilities that provide assurance to the parent organization and support to individual contributors.
  • Platforms are often referred to as platform-as-a-service (PaaS) or internal development platform (IDP).

Platform 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.

- About The Authors
Avatar photo

Satya Addagarla

CIO Home Lending at Wells Fargo

Follow Satya on Social Media
Avatar photo

Josh Atwell

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.

Follow Josh on Social Media
Avatar photo

Mik Kersten

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.

Follow Mik on Social Media
Avatar photo

Thomas Limoncelli

ManagerManager Stack Overflow, Inc

Follow Thomas on Social Media

No comments found

Leave a Comment

Your email address will not be published.



More Like This

Serverless Myths
By David Anderson , Michael O’Reilly , Mark McCann

The term “serverless myths” could also be “modern cloud myths.” The myths highlighted here…

What is the Modern Cloud/Serverless?
By David Anderson , Michael O’Reilly , Mark McCann

What is the Modern Cloud? What is Serverless? This post, adapted from The Value…

Using Wardley Mapping with the Value Flywheel
By David Anderson , Michael O’Reilly , Mark McCann

Now that we have our flywheel turning (see our posts What is the Value…

12 Key Tenets of the Value Flywheel Effect
By David Anderson , Michael O’Reilly , Mark McCann

Now that you've learned about what the Value Flywheel Effect is, let's look at…