The Power of Platforms: A user centric approach to achieving positive business outcomes

The talk below I gave at Red Hat Summit: Connect 2023 in The Netherlands. Transcribing, I tried to stay as close to the actual story as possible. Please share your thoughts, views, and provide feedback in the comments of this article. Thank you very much.

A quick introduction: My name is Stefan van Oirschot and I've been working at Red Hat since 2017. I have been working with Red Hat technology since 1999. My background is computer science and I love to talk about organisational change with my customers to figure out ways to get more from their technology? investments.

This article is about the importance of a user-centric approach to achieving positive business outcomes. How open practices can help you better understand your current and desired path to production and how to facilitate a session using open practices yourself as well as how to sell initiatives to your organisation using quantified value.

“Your code has no business value until it’s deployed”.

Taken from my fellow associate Burr Sutter’s talk Teaching Elephants to Dance. Burr Sutter is known to many as a great speaker, product manager and developer advocate. He has loads of fans around the world and is famous for his fast pace, enthusiasm and interesting demos.

This quote connects the worlds of business and IT in a great way. In this article we will quickly cover the business value side so we all know Why we do things. After that we will go a bit deeper an put all of this into practice.

Keeping up with an ever increasing demand for more speed is hard. Our customers demand that we improve our time to value. This is easier said than done because of many underpinning challenges, for example:

• Poor quality delivered by product teams due to lack of proper testing, due to possibly time constraints, is the team too busy?
• Poor product management, no practices in place to really know what the customer desires, what is feasible and what is viable?
• Poor retention of the workforce because of legacy ways of working, processes, technology in use?

The interesting thing about being slower is not that you will reap benefits a little later, the impact of this cost of delay is actually much greater to the extent of:

• reputational damage;
• customer satisfaction dropping;
• market share permanently lost.

We touched upon a couple of underpinning challenges but you can probably think of a lot more for example; shadow IT, being too slow because of cumbersome workflows and definitely more.

If anything the underpinning challenges just mentioned should show that speed can not exist without a stable foundation.? Here stability incorporates resilience and thus the capacity to withstand or to recover quickly from difficulties.

Do you have a user-centric approach to achieving positive business outcomes Let’s dive a bit deeper into the meaning of this.

Do you have a desire to really understand what is going on? We know that happy engineers produce happy code. But do you know what good looks like?

To measure is to know and research shows us as we will discuss in more detail later that we need to measure both the perception as well as the hard metrics taken from our workflows.

What do you actually know about your developers cognitive load? What about their flow state and their feedback loops?

Measuring both the hard metrics as well as the soft, perception metrics will complement your learnings. Your insights will become richer and it’s interesting to figure out what you can do to close the gap.

Let's take a look at how software development teams spend their time at a high level by looking at the flow distribution of their value stream.

Product teams strive to maintain a healthy flow distribution. A healthy flow distribution refers to the balancing of flow items in a way that they support the organization’s key metrics around market agility and reliability. This means effectively balancing time spent working on features, defects, risk and technical debt.

But what happens when you do not keep a healthy balance?

Not having a healthy balance can lead, as illustrated in the image above, to technical debt being built up. While technical debt is a fact of life, not paying enough attention might lead to no longer being able to deliver on promises.

In this example, based on a real world case, this led to no longer being able to deliver fast enough and definitely not being able to provide a reliable service resulting in poor customer experience.

Having to spend too much of your time on technical debt as mentioned means undelivered features, unfixed bugs and too little testing.

When not balanced, adding new features, for example something with a set deadline, might result in a delivery with too little quality because of lack of proper testing due to these time constraints.

This is where the technology platform comes in and this is where platform engineering comes in.

Providing reusable patterns and other enabling constraints help moving from a cognitive overload for product teams to a manageable cognitive load with a higher focus on what really matters leading to increased market agility and reliability leading in turn to happier customers as well as happier engineers.

“Gartner expects that by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery.”

This refers to the hyperscaler platforms and other cloud services complemented by your own value added services, and making it consumable for your organization.

Your platform teams providing reusable patterns and other enabling constraints help to deliver on the DevOps promise of product teams being high-performance, end-to-end responsible with manageable cognitive load.

Over the last 10+ years we have witnessed the evolving engineer, being asked to increase both breadth and depth of knowledge growing from i-shaped to t-shaped, pi-shaped and nowadays comb-shaped.

Are you building your teams according to the happy evolving engineer or are you falling for the full stack fallacy?

Organizing for customer success means aligning teams to value streams and demands cross-functional teams with comb-shaped players. These are the type of players who have both an incredible breadth of knowledge as well as depth of knowledge. Some of you might know them as full stack engineers but in all fairness these are unicorns.?

An implementation like this is not sustainable. Lower order tasks should be made available to be consumed as services via the self-service platform,?or internal provider as Gartner calls it, allowing your cross-functional team members to focus on the differentiating tasks.

General knowledge nowadays dictates that high performing organisations are also very effective and skilled in bringing forth high quality software to drive these positive business outcomes.

This means you can not distract your product teams building all these great services with enablement on all kinds of platform stuff you build which increases their cognitive load. On the contrary you want to make sure that your platform services are there to make them more effective and allow them to increase the end-customer experience. This means understanding what your users value, what their perception is of how things work or should work and what the real numbers show and improve on all of this.

Enabling your product teams is essential but do not enable them to bring them to you. Enable them to make their cognitive load more manageable and introduce platform services that support this goal.

Keep in mind that success of the platform is measured by the success of the teams using the service. If you are not helping your product teams to accelerate in end-customer value delivery you are cutting them and your end-customers short!

As mentioned earlier we will now spend a bit more time on the metrics mentioned earlier.

Nicole Forsgren, the author of the book Accelerate (not to be confused with the book with the same name from John Kotter) did, together with a couple of others, additional research around the core dimensions of developer experience but even more interesting the gap between the hard and soft measurements.

Research shows that improving flow state, having a manageable cognitive load and short, quality feedback loops are mandatory for a great developer experience. Most of the time a gap exists between what we can gather from our workflows and tools, the hard metrics and the actual experience of the users, the actual developer experience, the perception. Measuring both (examples provided in the image above) will provide us with valuable insights into where to improve and what to prioritize. Keep in mind that happy engineers produce happy code!

Being at Red Hat for almost 7 years I believe I understand quite well where and how Red Hat’s products and services differentiate in the market. On top of that I believe I understand the business as well as the challenges of my customers quite well.?

Combining these two allows me to provide insights to my customer and allows us to move the needle together. Getting to this point I need to understand many things and all of this is a continuous process; the organizational context, IT strategy including prioritized initiatives with objectives and key results and well as key stakeholders but also current state and challenges, future state and a lot more.

Similar to what I described just now this interaction also exists within your organization. You need to sell others on your initiatives. To get them prioritized and approved.

Being able to confidently identify what is needed and being able to quantify the value of achieving the outcome is essential.

Everyday I interact with multiple customers and learn about their many, great initiatives.

Prioritization of these initiatives is often a challenge resulting in sometimes an almost standstill of the customer organization because of too much work in progress.

At Red Hat we regularly run workshops with our customers via which we help the customer build their story for their organization. These sessions provide insights to all parties involved of what initiatives bring most value.

It's critical to understand what initiative adds the most value, achieves positive business outcomes, improves X,Y,Z, etc. to know what to spend time on over something else.

Start at the end is a great practice to use to discuss the next 3, 6 and 12 months, for example:

• If everything went to plan what would you like to have achieved?
• What are the challenges; blockers, impediments?
• Be careful! The enemy of good is perfect!

Lightning talks can be great when you are running these workshops for example to create a level of knowledge parity around relevant topics.?

Metrics Based Process Mapping is a process mapping practice that captures process steps, responsible actors, and key time and quality metrics and together with short-term, mid-term and longer-term goals a great source of insight for process improvement.?

This can also be used without the metrics to gain quick insights into bottlenecks and areas of improvement.

These learnings will help you understand where to improve for maximum gains but also sell the improvement internally and get buy-in of users and stakeholders.

The critical element is the understanding of the path to production. In the above image you see an example output of the simple process mapping exercise. This example shows the various? manual interventions & handoffs needed which are impacting the flow of change, slowing the organization down specifically referring to time to market. But also negatively impacting developer happiness.

Such a map together with other learnings helps to identify the biggest Pains and Gains.

At Red Hat we love to run these workshops with our customers. We know all parties will benefit from such a session and gain insights. Facilitating workshops is not easy and with all the stakeholders involved from management to hands-on, business and tech you can expect some pain if not handled correctly.?

Some elements to take into consideration:

• Use an ice breaker, no fluffy ice breakers because engineers might freak out! Make sure it is effective and contributes to what you want to achieve. For example if you want people to speak up then allow them to speak for the room. If you want people to use sticky notes involve those.
• “Kill the HiPPO”, the Highest Paid Person Opinion. They are allowed to be in the session but we want to get rid of the authority bias! Make sure the room is safe to share. You can approach this by, as a facilitator, asking the HiPPO a question, let the person respond and invite others to chime in asking questions as well, kick starting the discussion.
• Avoid Rabbit Holing: Use a practice like Stop The World if people are dominating and conversations get derailed.
• Assume positive intent and no stupid questions, they do not exist.
• Make sure Tech or Architecture Leads do not go HiPPO valley! “Kill the HiPPO”!
• Consider building a Social Contract, a great practice to capture and agree on how the group wants to engage with each other.

Remember: The hands-on people are the ones feeling most of the pain. Make them feel heard!

In summary:

• Developer experience and platform engineering are very much connected
• Platform teams can make the difference regarding developer productivity and happiness
• To measure is to know, make sure to measure both the hard metrics taken from workflows and tools as well as the perception
• Happy engineers provide happy code which directly contributes to your time to value

A user-centric approach to achieving positive outcomes starts with:

• Understanding where you want to go
• Understand what you do today as well as understanding the challenges
• Figure out what good would look like
• Define, prioritize and execute using the tools discussed above.

And please keep in mind: It is always a product for someone: happy selling!

Please let me know what your thoughts are. Any questions, comments or concerns you have are very much appreciated and I would love to hear from you in the comments or via a direct message.?

Bibliography:

• Fowler, Martin. “Foreword,” Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018
• Drawing by Stefan illustrating flow distribution as described by Mik Kersten in his book: Project to Product
• Gartner: What is platform engineering - https://www.gartner.com/en/articles/what-is-platform-engineering
• DevEx: What Actually Drives Productivity - https://dl.acm.org/doi/fullHtml/10.1145/3595878
• Red Hat Value Accelerator workshop - https://red.ht/value-accelerator
• LinkedIn post containing the Slides: https://www.dhirubhai.net/posts/stefan82_red-hat-summit-connect-2023-the-power-activity-7115964211217723392-Teo0