Nottingham University Hospitals Maternity Services – Home Birth Risk Assessment

In December 2022 I requested a copy of the NUH Trust’s risk assessment and associated decision making evidence showing how the restriction to women’s individual rights and the benefits to home birth, in terms of clinical outcomes, was weighed up against other safety concerns to come to a decision not to provide a full time home birth team.

In April 2023 they responded with the attached NUH maternity home birth risk assessment document.

 

Leadership vs Management

management and leadership

Or is it Leadership *and* Management?

 

Tom Geraghty
Speaking at CIO Event in London, 2019

I created this graphic in 2019 as part of a presentation on High Performing Teams for the IT Leaders Conference.

management and leadership

Inspired by Grace Hopper’s “You manage things, you lead people” quote, I wanted to make the point that great leadership also requires great management skills. You can be a great manager of things without leadership skills, but you can’t be a great leader without good management skills. Without those management skills, you may be able to lead people, but your lack of direction, effectiveness, and capability could lead to failure.

You manage things, you lead people" quote by grace hopper

Sometimes management and leadership are presented as a binary, or worse, that “management” is bad and “leadership” is good. Neither is true: we should resist “leaderism“, and instead concentrate on the actual capabilities and skills required to manage things, and lead people. Both can be learned, taught, and always improved. We dive into this much deeper over at psychsafety.com, where we examine the capabilities and skills required for both excellent management and leadership.

tom geraghty psychological safety

(Since 2019, this graphic has gone a bit viral on LinkedIn, Chegg, Twitter and elsewhere!)

The fabulous Elita Silva translated the management and leadership graphic into Portuguese!

management and leadership - Portuguese

 

And the fabulous Ana Aneiros Vivas has translated it into Spanish!

Spanish-version-of-Management-and-leadership

Filippo Poletti translated it into Italian!

management and leadership in Italian

 

And the folk at Solutions and Performances – Executive Search have translated it into French!

Platform Engineering and the Platform Operating Model

TL;DR: What is platform engineering? Isn’t that just old Dev vs Ops thinking? What is the Platform Operating Model?

A platform operating model is:

 “a business model that creates value by facilitating exchanges between two or more interdependent groups, usually consumers and producers.”

Applying DevOps thinking, we can adopt that model internally to organisations, by considering a platform team as the producers of the platform service to a range of consumers – the value-stream oriented product teams.

Value stream-aligned teams focus on a single value (or revenue) stream, because that singular laser focus on the success of their product maximises the return on investment. However, it’s not efficient or effective for each stream-aligned team to use and maintain all the underlying technology beneath it.

In the old days, we might have addressed this with a separate Ops team who provided the infrastructure, but that (as we know) caused inefficiencies, bottlenecks, and created “walls of confusion” when applications were thrown over from Dev to Ops in order to run in production. Instead, modern platforms allow stream-aligned teams to consume platform services in order to run their own workloads. The stream-aligned team “pull” services from the platform team, instead of “pushing” the application over to an operations team.

An effective platform engineering capability achieves an economy of scale by allowing multiple stream aligned teams to consume the same platform, but primarily aims to improve *flow*, and reduce the cognitive load of developers using the platform.

So, what is a platform?

“A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.”

From Evan Bottcher, 2018

https://martinfowler.com/articles/talk-about-platforms.html

 

And what is a product?

A product simplifies something for the consumer, solves a market problem and/or addresses a customer’s need or desire. In the case of an internal platform, the market is an internal market, and the customer is the stream aligned team(s). This is also why an organisation may create multiple platforms and platform engineering teams: different stream aligned teams have different needs, and to meet all those needs, a platform would end up being too large, cumbersome and bulky, like a huge swiss army knife with a hundred features when you only need a knife. 

Amazon’s founder, Jeff Bezos, once said, “Your goal should be to create value for everyone you interact with.

 

A product is: 

  • Coherent
  • Evolving
  • Long lived
  • Supported
  • Owned
  • Designed with the user (customer) in mind
  • And it’s worth noting that all products also have *names*

 

In most organisations, a product also requires a Product Owner, who is responsible for translating business strategy, product vision, customer needs and preferences, and balancing these priorities against non-functional requirements, proactive preventative maintenance etc. A platform should be no different in this respect: without a product owner, the platform may drift away from what is most valuable for the business and the users of the platform, costs of running it may increase beyond the ROI of its utility, and it may suffer from feature sprawl, technical debt, poor reliability and unplanned work.

Let’s draw out some of those words from Evan’s definition.

APIs, tools and services:

This means that it’s not just “one” technology. A single platform may possess multiple options for use, multiple optional features and functions. One user may use a completely different suite of features than another, but they’re both consuming the same product.

Knowledge and support:

A product doesn’t just get given to the consumer without any support or guidance about how to use it. Of course, it should be as usable and fit for purpose as possible without extra instructions or guidance, but just as you should be able to get into a modern car and drive it without referring to a manual, it still comes with a manual to help you realise the maximum benefit of the product. And more than that, a product come with a support team – who you can reach out to for help when you need it. A support team isn’t just there to process support tickets – they work with users of the product to help them make the most of it *and* gain essential and valuable feedback to drive the evolution of the product.

A “compelling internal product”

A platform is “A curated experience for engineers.”

Thanks to Matthew Skelton and Manuel Pais for this term.

There are two key points to make here – one is that the product consists, as we described above, of tools, APIs, documentation, services, alongside support and advice on how to use it. It consists, essentially, of everything required to make that experience as positive as possible for engineers to get their job done. 

One of the primary goals of platform engineering is to reduce the cognitive load of the engineers and developers using it. Users of the platform are solving complex problems, and the more that any of their attention is taken in working out how to access something, how a feature works, what the API specification shows, or anything else, the less of that cognitive capacity is spent on addressing the business problems that they’re tasked to solve. The more that the platform can allow people to maximise their *germane* cognition, reducing extraneous cognitive load, the better the end result. The safest cars are also those that are easiest to drive, because we can spend more of our attention on the actual task of driving safely.

The best platform therefore, provides just what the stream aligned team needs, nothing more, and reduces the cognitive load of the people using it. It evolves according to feedback from the users of the platform, “competes” with other platforms in the organisation to be the best one to use (the compelling internal product), is owned by the platform team, and has a cool name. 

Funding Models:

Funding for platform engineering typically falls into two categories: operational funding and project funding. Operational funding is used to maintain the existing platform and deliver continuous service to users. This includes the costs of hosting, licensing, monitoring, and supporting the platform. Project funding, on the other hand, is used for new developments and expansions of the platform. This could include the development of new features, integrations, or scaling efforts.

In many organizations, funding is often allocated based on the value a platform brings to the business. This means that a platform that supports high-value or high-revenue generating teams might receive a larger slice of the budget. However, it’s crucial to ensure that funding decisions consider the long-term sustainability and evolution of the platform, rather than just immediate revenue potential.

Organisation Structure:

In terms of organisation structure, platform engineering usually sits at the intersection of technology and business, providing a bridge between technical and non-technical teams. The platform team is often composed of cross-functional roles such as product owners, engineers, architects, and designers, each with their own specialities but sharing a common goal – to build and maintain a robust, efficient, and user-friendly platform.

This team often works closely with other teams in the organization, known as the stream-aligned teams, to understand their needs, deliver the necessary platform services, and gather feedback for future improvements.

Overall, the organization structure, governance, management, and funding models for platform engineering all aim to foster a collaborative, customer-centric environment. The goal is to provide an effective platform that reduces the cognitive load on its users, allowing them to focus on delivering value to the business, and evolves in response to feedback and changes in the business environment. It’s a dynamic, ever-evolving process that requires a commitment to continuous improvement and customer satisfaction.

Summary

Platform engineering, under the guidance of a strategic leadership team, functions as a bridge between technology and business in an organisation, aiming to provide robust, efficient, and user-friendly platforms. This is achieved by a cross-functional team, including a product owner, who is responsible for the platform’s evolution, balancing operational maintenance, and prioritising feature development. Funding is typically bifurcated into operational and project-based categories, with allocation decisions influenced by the value a platform brings to the business and its long-term sustainability. The organizational structure promotes a collaborative environment, with platform teams working closely with stream-aligned teams to understand their needs and provide necessary platform services. The ultimate goal is to reduce cognitive load on users and allow them to focus on delivering value to the business while ensuring the platform evolves responsively to feedback and business environment changes.

The State of DevOps Report 2022

This year, the Google / DORA State of DevOps Report dived deeper into information security. In 2021, the report highlight the importance of Secure Software Supply Chains – building in security throughout the software development cycle and supply chain.  The research leveraged the Supply Chain Levels for Secure Artifacts (SLSA) framework in conjunction with NIST’s Secure Software Development Framework (SSDF) to explore technical
practices that support the development of software supply chain security.

You can see from the chart above that this year’s results show a clustering in the medium performer group. The authors consider that this may be a result of not having data from the elite performers this year, or an effect of the pandemic restricting the ability of teams to innovate practices. It’s also worth noting that the floor has risen: this years low performers perform better than last year, so whilst the ceiling is lower, the floor is higher.

This year’s report showed that high-trust, low-blame cultures focused on performance were 1.6x more likely to have above average adoption of emerging security practices than low-trust, high-blame cultures focused on power or rules.  This reflects the difference between Safety I and Safety II approaches, originally coined by Erik Hollnagel. Cultures that focus largely on avoidance of risk, and implementing rules or procedures to prevent risk actually perform worse over time than cultures focussed on looking at “what went well”, not just “what went wrong”.

The report showed that generative organisational cultures, as described by Westrum’s Cultural Typologies, tend towards being higher performing. Alongside that, other drivers of high organisational performance were:

  • Team stability and longevity
  • Transparency and confidence in funding
  • Opportunities to work more flexibly

From a technological perspective, the capabilities that contribute most to high performance are version control, continuous integration, continuous delivery, and loosely coupled architecture.

Interestingly, less experienced teams who implemented trunk-based development actually have less positive results around
trunk-based development and see:

  • Decreased overall software delivery performance
  • Increased amounts of unplanned work
  • Increased error-proneness
  • Increased change failure rate

However, more experienced teams show significant benefits and the presence of trunk-based development shows a positive impact on overall organisational performance. This is likely both an effect of the J-Curve effect and the additional practices required to successfully implement Trunk-based development. The lesson for teams: keep going!

An interesting key finding is that the State of DevOps 2022 evidence suggests that healthy, high-performing teams also tend to have good security practices broadly established. This is reinforced by evidence from other industries that guardrails of any kind help to reinforce psychological safety on teams. Last year’s (State of DevOps 2021) report showed that Secure Software Supply Chains that integrate security practices into pipelines and processes, enable teams to deliver secure software quickly, safely and reliably.

An important aspect to consider is that technical capabilities have a positive impact on SLSA-related practices and through this positive impact on SLSA related practices have a positive impact on both software delivery performance and organisational performance.  That is to say that SLSA practices and continuous integration, version control and continuous delivery capabilities are a virtuous cycle: the capabilities built through CI, CD and version control are the same capabilities that enable teams to adopt and improve SLSA practices.

Finally, a point on SRE and the “error budget” framework: the report shows that software delivery performance alone does not predict organisational success. Excellent software delivery combined with high reliability (high DORA Metrics in this case) correlate with organisational success. Which makes sense: when a service is unreliable, users won’t benefit from pushing code faster into that
fragile context.

 

There is no such thing as a “functional organisation”.

Organisations are complex sociotechnical systems. And all organisations exist in various states of dysfunction all the time. Some parts of the organisation may briefly reach a “functional” state where everything works effectively, and everyone knows what is happening. But those states don’t exist for long. We can think of this as the organisational entropic force – the constant introduction of external and internal forces and changes mean that a functional state is rapidly drawn back to dysfunction.

We can constantly strive to reduce this dysfunction, and we should, but we must remember that there is no such thing as a truly, completely, consistently “functional” organisation, and there never will be.