The Sand Reckoner: Tech Leadership

The Product Mindset

Simon Fabri — Thu, 01 Jan 2026 15:35:17 GMT

Over the years, I have been lucky enough to have held engineering and product roles across very different companies. I have worked in industry sectors as diverse as energy, automotive, big tech, consumer devices, and most recently, government. If I have learned one thing in this journey is that context is everything. What works for one organisation may not be the best fit for a very different one. For example, the product and engineering practices required to produce a highly integrated product, such as a car, are very different to those required to create fully digital experiences such as a streaming video service.

So it is with this mindset that I have approached my most recent challenge, taking an organisation with a very strong engineering ethos operating within the UK national security space to become more of a product organisation. What works at Amazon does not transfer unchanged to a very different cultural and operational context. In this blog, I distinguish the core principles behind what I call ‘the product mindset’ from the practices and processes. The mindset should be applicable to most scenarios and contexts, while the practices and processes will vary according to the organisation. Many change programmes focus on the latter - talking about artefacts, ceremonies, roles, job titles and so on. They are all important, and indeed, essential. But let’s strip that all away and explore what really matters.

Also available as an (AI-generated) podcast. Give it a go!

Engineering Excellence and the Product Mindset

So, what is a ‘product organisation’? For people who have only ever worked in product organisations, including every tech company out there, this may feel like a self-evident question. A bit like a fish trying to imagine a world that is not full of water. This question does however provide useful a useful framing. One alternative to a product organisation is the engineering organisations, of which there are two main flavours.

The first are “the tasked builders”. These companies create engineering outputs to meet the designs and requirements of their customers. Typical examples include ODM (original design manufacturers) who create consumer products to specifications provided by well-known brand. Examples include suppliers to aerospace manufacturers who create components for use in an aircraft, or a software supplier creating a bespoke piece of case management software for a government application. These companies are characterised by a strong ‘specification’ based way of working and optimise for meeting specifications rather than for end-user outcomes.

The second are “the systems builder”. These are companies that own their outcomes, which they directly monetise. They operate in a largely linear fashion from a set of specifications defined at the outset. In these companies, uncertainty is managed through detailed up-front modelling, engineering design and specification rather than through customer feedback. Many such organisations follow the “systems V” approach. Here, top level specifications are first created. What follows is a typically one-way decomposition into smaller components which are implemented, and then progressively integrated and tested as the final product is realised. This approach is common in large engineering organisations such as nuclear power, defence contractors and large construction companies where the intended outcomes are typically well-understood.

Figure 1: The Systems V Model. Source: NASA [1]

What is the Product Mindset?

To be clear, I am not suggesting that there is anything intrinsically wrong with being an engineering organisation or following a ‘Systems V’. Often it is the right approach for the problem at hand. For example, creating a nuclear power plant does not lend itself well to an iterative ‘trial and error’ approach. These examples are however helpful as they help bring into sharp relief what I mean by a ‘product company.’

In my mind, a product organisation has two main characteristics. First, it wholly owns and is responsible for the entire lifecycle of its products. There is no doubt that most well-known tech brands such as Apple to OpenAI in the consumer space, to Shopify and Salesforce in the business tech space, as well as countless non-tech brands such as Coca-Cola, McDonalds, Zara and Nike fully own their products and related customer experience from cradle to the grave. However, ownership of the product, and all its implications upon a company’s brand is not enough. Product organisations are accountable for every stage of the product lifecycle — not just initial design or post-launch support, but from ideation through delivery, operation, evolution, and ultimately decommissioning. Customer experience is not a phase; it is a continuous constraint on decision-making.

Given this framing, let’s have a look at what I consider to be the main characteristics of product organisations.

1. A product is for life, not just for Christmas

The main units of delivery of engineering organisations are ‘projects’. Let’s dissect what these are. According to the Association for Project Managers, the UK’s professional body for project managers, a project is a “a unique, transient endeavour, undertaken to achieve planned objectives.” [2] Consider the word transient. This defines a project as having a beginning and an end, of interest only while the ‘endeavour’ is underway.

This contrasts with the product approach, which is to take responsibility for the product outcomes and customer experiences as a continuous process, from inception through to end-of-life. This lifecycle view is typically captured in a product roadmap – where all the products and experiences are mapped against a timeline. The product manager’s responsibility is to understand and manage today’s products, learning from them to create tomorrow’s experiences. They are always balancing whether to invest in new features or products or to enhance those products already in use.

The culture of the company often plays a strong influence in where priorities are applied. At Amazon, for example, “operational excellence” activities, aimed at making the service more robust, improving availability, were always at the top of product backlogs, reflecting a belief that availability is the most important customer feature.

Tesla represents a great example of this characteristic in action. Most car manufacturers traditionally took a product engineering approach – with distinct project teams responsible for designing and developing cars to the point of manufacture, as opposed to supporting them in-life. For Tesla, the software is always being updated and evolved, so that the car you experience today is different from the one you bought. It is always being kept up to date.

While the project ends at the point of delivery, a product manager’s responsibilities do not. At Tesla and Amazon, the in-life experience is not someone else’s problem, such as an outsourced operations team. Product managers remain responsible for the experience for as long as there are customers using their products. It is genuinely a responsibility for the entire product life.

2. Obsess about outcomes, not outputs

Project managers focus on outputs, often defined through the triangle of cost, quality and time. While these remain essential building blocks of any time-defined project, product organisations measure success against customer-impacting metrics.

Amazon, amongst other companies, distinguishes between input and output metrics [3]. Input metrics are things that you wholly control and can influence outcomes. They are ‘leading’ (i.e. ahead of the fact) indicators of success. Output metrics are the customer-impacting consequences. Taken together, metrics represent the ‘mental model’ behind each product, the hypothesis that links the thing you do (e.g. a slicker user interface) with the intended outcome (e.g. more customer usage and enjoyment).

For example, an input metric for ChatGPT could be the speed of response, or latency. This is (largely) controllable by OpenAI in terms of the design of the LLM, how many tokens it can input and process. Fast responses should result in a higher likelihood of continued usage, driving up their output metrics, such as the number of weekly users, number of subscribers, subscription renewal rates and app store reviews.

The focus on outcomes is crucial. It forces product teams to be close to their customers, not only during the initial concept and design time, but throughout the life of the product. Delivering a project on time, to spec and budget while important, is only a means to an end. What really matters is understanding if your product is being used and is delivering the intended benefits. Tracking and managing usage is used as an input to refine the product, thereby nudging the input metrics in the right direction, in turn improving the customer experience or enjoyment of the product. Designed well, your input and output metrics will provide a strong feedback loop by which to improve the product experience.

3. Iterate, Iterate, Iterate

If metrics are important signals on how well your product is doing, then equally important are the actions you take in response to those metrics. This is where feedback loops are critical. If you cannot take timely action in response to a metric that is not moving in the direction you hope for, then that measure is simply a ‘vanity’ metric.’

The use of rapid feedback cycles is one of the defining characteristics of a product organisation compared to the ‘systems builder’ organisation we described earlier. This approach is not limited to digital or software experiences, characterised by the “move fast and break things” stereotype. Take the satellite rocket launch industry. Typically, these were highly risk-averse companies fully adopting the systems engineering methodology. Their approach to risk reduction (a critical consideration given that a rocket engine is essentially a controlled explosion) is through the detailed and meticulous design and specification process. All engineering design takes place up-front, with extensive use of computer modelling and simulation. This leads to the specification of all the subsystems and components that comprise the rocket. The aim is to use rigorous engineering early in the design process to meet rigorous reliability and safety standards.

SpaceX on the other hand, optimised for a much more frequent launch cadence, aiming to use each launch as a means for optimising and improving the experience [4]. By accepting the possibility of failures as part of the learning process, SpaceX engineers are able to get real-world product data much earlier in the development process than engineers in legacy contractors. Over the longer-term it is able to converge to the same level of reliability as its competitors. SpaceX’s philosophy is to simplify the design, focus on the essentials, and learn by doing. The Falcon 9, developed according to this approach suffered some early mission failures, but went on to have close to 600 successful launches since its introduction in 2010 [5]. By comparison, its competitors Lockheed Martin’s Atlas V Arianespace’s Ariane V managed just over one hundred launches each.

Figure 2: Rapid product iteration – SpaceX booster re-entry

The key learning here is to treat each product iteration as an experiment, with the expected impact upon chosen metrics as the hypothesis being tested. The feedback frequency determines the learning rate. Even an unsuccessful product iteration can then lead on to success. The earlier you can get real world data, the quicker you learn and produce products that delight your customers.

4. Focus on problems, not specifications

Perhaps the biggest cultural difference in moving to a product way of working is the change in role of product specifications. Consider the ‘systems’ approach described earlier. This is optimised for ‘complicated’ problems – i.e. problems where there is a known relationship between cause and effect – where problems can be analysed and decomposed. Creating many sophisticated engineering products falls into this category – for example bridges, power plants. In this model, risk is reduced by specifying the solution up front.

Product approaches are optimised for complex problems, where it is difficult to predict the impact of your actions in advance. Often this is because the end-user has a say in how they react to your product, in other words, the outcome is influenced by end user adoption and behaviour. Many national security problems fall in this category as they are influenced by the behaviours of adversaries or threat actors. For this reason, product management shifts the emphasis away from up-front specification to back-end learning. Through a probe-sense-respond cycle, you are reducing risk through controlled experimentation.

Figure 3: The Cynefin framework of problem types

This is why user stories have become embedded in the day-to-day practice of product management. Describing intended outcomes as product statements, in the form of, “as a user, I want to … so that …” is designed to shift the engineering process to start with the end problem in mind. This may seem like a minor shift, but it is utterly fundamental to the whole product approach. First, it encourages the product manager to focus on the fundamentals. Having spent a fair few years as a systems engineer specifying complex consumer products, I have played my part in what I call the tyranny of specifications.

Consider the smartphone industry before the advent of the iPhone. Nokia were in pole position to be the dominant player. They had a fantastic supply chain, a dominant market position, Europe’s strongest brand, and all the right technology components, including, in Maemo OS, arguably a better operating system than either iOS or Android. [6] While there are many strands to the story of Nokia’s demise, one contributing factor was a lack of focus. Nokia was encumbered by trying to implement all the legacy requirements that all the previous generations of phones. So rather than exploit the characteristics that made the new touch-screen smartphones different, Nokia were constrained by thousands of requirements from mobile operators who bought their phones. Apple, on the other hand, under Steve Jobs’ visionary leadership, launched a phone with a very limited feature set, but with great user experience. By focusing on a clear vision for the end user experience, rather than what the mobile operators were asking for, Apple upended the mobile phone market.

SpaceX adopt a similar philosophy, which is referred to as their “first principles” approach [7]. Rather than asking themselves, “how are rockets usually built?” they focus on the fundamentals, which in the case of space rockets is the intersection of physics and economics. This way of thinking manifested itself in the design of their Merlin engine (no relation to the eponymous Spitfire engine) which was designed to be simpler, less complicated, but able to be manufactured at scale much more cheaply than existing engines. Similarly, by designing fully reusable rockets, they challenged the industry norm that reusability was too complicated a problem to be practical.

Focusing on the essence of the problem at hand allows product managers to identify what is essential, or core, to the product. Every requirement has a cost or requires a trade-off. Adding requirements that don’t improve the core user benefits will often undermine the product. In the case of space rockets, they can add so much cost that they undermine the business model, or in the case of smartphones, complexity can ruin the product experience and compromise reliability and launch timelines.

5. Innovate on behalf of the customer

For this principle, I will directly lift a phrase originally attributed to Jeff Bezos. [8] This is a belief that in order to meet customer needs, companies often need to innovate and create products or experiences that their customers are not expecting. To me, the philosophy is that the accountability for coming up with the best solutions for customer needs lies not with customers, but with product teams. As the probably apocryphal story goes, Henry Ford once said, “If I had asked people what they wanted, they would have said faster horses.”

Let’s consider a few examples. We are all familiar with the Dyson bagless vacuum cleaner, but when James Dyson invented the use of bagless cyclonic tech [9] to capture and manage dust, customers were preoccupied with having cheaper bags and more constant suction. No-one was asking to dispense with bags altogether. Similarly, Netflix, when still a DVD rental company, recognised that the underlying customer need was not for cheap and efficient DVD delivery but for convenient home entertainment. As broadband internet was rolled out across the US, Netflix created a streaming platform that transformed the global media landscape. And for a more personal example, when I led the team that created the Wiser Heat smart home heating system at Schneider Electric, our insight was that people control their lighting cheaply on a room-by-room basis, so why couldn’t they do the same for heating?

It is important to be clear that I am certainly not advocating that product teams ignore customers and work in an ivory tower. To the contrary, you can only innovate really effectively if you have a really intimate knowledge of the customer problem set. There are different ways this can be achieved. Palantir, which started off as a defence and intelligence software product company, achieves this through use of forward deployed engineers (FDEs) who are embedded with customer teams to help feed back customer needs into the core product development [10]. This approach contrasts with the traditional software integrator model where embedded teams create bespoke software solutions for their customers.

6. When platforms are products

Sometimes answering the question “what is the product?” and “who is my customer?” is not straightforward. Let me elaborate. Imagine you are designing a range of electric vehicles. You will need to bring together a whole host of complex systems together – the battery and charging system, the suspensions and ride control, the powertrain, the infotainment system and so on. If you are producing more than one vehicle, it would be prohibitively expensive to design each of these subsystems to be specific to the need of each vehicle model. Economic reality dictates that you will need to reuse some of these components. In effect, the subsystems I mentioned are now platforms, supporting multiple applications (in this case different vehicles), and your immediate customer is the vehicle programme.

Choosing when to create a bespoke solution for a single product, also known as vertically integrating your product, or whether instead to create a reusable (or horizontal) platform is one of the core challenges product teams face. Vertically integrated solutions can be tailored to the needs of a single customer but doing so can be prohibitively expensive. Additionally, solving similar problems many times over creates increasing complexity. On the other hand, horizontal platforms, whilst offering the opportunity of economic reuse, also come with the risk of creating excessively complex solutions that meet no problem well.

The spin-out of Amazon Web Services (AWS) is the archetypal story of a set of enablers becoming products in their own right. Originally developed to support Amazon’s online retail offer, it was spun out as the first public cloud platform. This effectively turbo-charged the mobile app industry, as start-ups no longer needed to make expensive capital investments in computing infrastructure. Similarly, Google’s internal cluster orchestration product, Kubernetes, became a de facto standard way for managing software containers across multiple industries.

However, platforms are not limited to the software space. For example, the EV electrical and software architecture of the EV manufacturer Rivian has been productised and is the basis of a partnership with Volkswagen. In turn, they are offering the EV platform to other manufacturers. Industry segments as diverse as smartphones, car architectures, aero engines, satellites all make use of shared platforms to support multiple products.

Entire volumes have been written on platform design, and I will not delve into that literature here. What matters from a product mindset perspective is recognising when a subsystem has become a product in its own right, with its own customers, trade-offs and lifecycle. The central challenge is not technical, but conceptual: understanding who the platform is for, what problems it is meant to solve repeatedly, and where reuse begins to erode rather than enhance customer value.

Be wary of transformation anti-patterns

When adopting a product mindset, there are some common pitfalls that need to be avoided. Here are three that stand out.

1. Product in name only

The first is to adopt the lean/agile artefacts and ceremonies such as standups, scrum teams, quarterly planning, roadmaps, job titles, and so on, while leaving the underlying product development philosophy unchanged. This is the “engineering remains the same” fallacy where an existing way of working is simply wrapped up in new language. There are a couple of hints that this is what may be happening. First, your budgetary responsibilities and cycles remain unchanged. True product organisations devolve key product decisions, including resourcing (money and people) to product organisations. If your financial planning cycles are unaffected by your move to product, and your accountabilities have not changed, the chances are that your transformation has been largely cosmetic.

2. Product ‘paint by numbers’

The second main pitfall is to adopt a product model straight out of a textbook, with no consideration of the context it is being applied to. Every context is different. The existing organisational culture, the nature of the relationships with customers, the network of partners and suppliers will all influence the transformation journey. Any product model that does not adapt to this reality will struggle to take root.

For example, consider applying this to an organisation with a strong engineering heritage. The product mindset offers engineering teams great latitude in applying their engineering judgement. This includes how best to defining platforms, where to innovate on behalf of their customers, or the opportunity to pare back a problem to engineering first principles. In other words it can place stronger emphasis on engineering fundamentals, further burnishing the engineering culture. Alternatively, where an organisation already has an established reputation of brand and product excellence, this can be further reinforced by the product mindset. The product way of working brings greater focus to the organisation’s core value proposition. It reinforces the discipline of prioritisation, distinguishes what is core from what is distracting, while at the same reducing the gap between user problems and development teams. Taken together, this approach further enhances the organisation’s existing offering.

3. Ignore the whole system impact

The final major pitfall is to consider the product teams as an isolated ‘bubble’ ignoring the organisation-wide implications. This is true for both ‘front office’ as well as ‘back office’ functions. For example, digital transformations that generate true value are those that substantially enhance the customer offering. Organisations as diverse as IKEA, HMRC, the UK’s tax office, Domino’s Pizza and the Spanish Bank BBVA all used product-led transformation to re-imagine their customer offering for the digital age.

Similarly, you will be unable to shift to more agile and experimental ways of working if your back-office services are not also reconfigured to be compatible with your new ways of working. If your commercial contracts are still based on up-front specifications with risks transferred to the suppliers, or if delivery lead times are measured in months. The same is true for your risk and financial governance. Do your oversight mechanisms reflect your new approaches to managing investment and risk?

A final thought – Context is everything

So hopefully this piece has given a sense of what I consider to be core to the product mindset. As a final thought, I’d like to reiterate that this is not a collection of prescriptive rules or a recipe book but is instead a set of guidelines that underpin the product way of working.

As I mentioned previously, context is everything. These principles should be applied sympathetically to the context and culture of your organisation. Most organisations are pretty heterogenous. They consist of a mix of different cultures, product offerings, functions (e.g. logistics, supply chain, manufacturing, professional services etc.), skillsets (specialists, managers, sales and business development, finance and so on), markets and customers. This heterogeneity requires considerable judgement to navigate. Different parts of your product portfolio may need to be treated differently. Similarly, the implications will be different across your different business functions. #

No-one said this was going to be easy!

References

The Fog and Friction

Simon Fabri — Sun, 16 Jun 2024 16:47:45 GMT

Military history and grand strategy have long offered sources of inspiration to business leaders. In a previous blog on the subject, I touched on how the insights of historical figures such as Sun Tzu remain relevant to those navigating the fast-moving tech space. In that blog I made no mention of Carl von Clausewitz, one of the most pre-eminent and well-known military theorists. Here I try to make up for that omission.

The Fog of War

Von Clausewitz [1] fought in the Prussian army early in the 19th century against Napoleon, taking part in the Battle of Borodino, which led to Napoleon’s ultimate failure to defeat Russia. His magnum opus On War brings together several complementary ideas and interpretations about the theory and practice of war. The best remembered of these concerns the relationship between military aims and political objectives (the former being subservient to the latter), known to day by the phrase “war is the continuation of policy by other means”.

In this blog, I will hone down on two concepts which I feel are as relevant to the tech space as they are to armies in the field. The first is what von Clausewitz called “fog”, or uncertainty. Popularised by the term “fog of war”, this describes the confusion and uncertainty caused by imperfect information. Von Clausewitz noted that commanders on a battlefield are simultaneously burdened with information overload as well as information scarcity. This makes it difficult to discern the essential from the irrelevant. This uncertainty is made more difficult by fast-changing events and the limitations of human judgement under conditions of stress, fear and fatigue. Von Clausewitz argued that successful commanders are those who act confidently despite this uncertainty.

The Fog of War as witnessed by Clausewitz who fought at the Battle of Borodino. Battle of Moscow, 7 September, 1812, Louis-Francois Lejeune, 1822

If fog impedes decision-making, then friction hampers the efficient execution of commands. Von Clausewitz states that “everything is very simple in war, but the simplest thing is difficult.” These difficulties, which he calls “friction,” accumulate in a way that is difficult to model in a carefully constructed plan. Sources of friction include weather, terrain, human responses, logistics, equipment failure and communications problems. Indeed, uncertainty itself is also a source of friction.

The expression “No plan survives contact with the enemy”, therefore really means that “no plan survives contact with the reality of the battlefield.” Like fog, friction affects all aspects of military operations, contributing both uncertainty and unpredictability. Taken together, fog and friction give lie to the belief that war can be conducted through the use of well-crafted plans. Instead, successful commanders need to rely on a combination of well-honed judgement “in the moment” and well-trained and disciplined troops that are better able to handle the unexpected.

Dealing with Friction

So let’s look at these two concepts as they apply to anyone leading or managing a team in uncertain times. No-one who reads this blog will have managed to avoid friction at work. Friction is not limited to the battlefield. It appears in our everyday lives. It may take the form of an unnecessarily cumbersome approval process, of requests for information that exceed what is needed for the decision at hand, of interminable meetings at which you are unable to add much value, the duplication of functions in different organisational siloes, endless reporting cycles and so on. Robert Sutton and Huggy Rao, organisational psychologists at Stanford University attribute much friction to this to “addition sickness” [6]. The root of this, they argue, is the human bias to solve problems or create new things by adding things, rather than subtracting them. This is further compounded by reward systems that recognise larger teams or new initiatives.

Wading through treacle, as imagined by ChatGPT 4o

Often, new initiatives are incremental rather than replacing pre-existing tasks. Whilst a process or initiative may have made sense when they were introduced, their relevance and usefulness often diminish with time. The net effect is that people find they are spending a disproportionate time on what I call “gunk”. We all have a word or expression for it, whether it is grit, “wading through treacle”, “making water flow up a hill,” and so on. These all convey a sense of the frustration and wasted effort experienced at spending much of your time doing stuff that is either not important, of low value, or simply more difficult than it needs to.

Sutton and Rao propose simple remedies in the form of “Subtraction Rules”. They describe how Google halved the number of interview stages in their interview process, challenging people to cut stuff by 50%, whether it is the length of an email, the number of emails, the duration of meetings or the length of topics in a meeting. Although people rarely manage to reduce the burden by 50%, it sets an aspiration and a trend. Above all, they recommend that the regular cadence and operational systems of the business must accommodate and reward subtraction activities.

Seeing through the fog

What Clausewitz called fog, we now call uncertainty. Most strategic decisions a tech company makes are riddled with uncertainty. When launching a new product or feature, you may not know in advance how well it will work, whether customers will like it, or how competitors will react. Whenever you are faced with a decision about what technology to use, be it a software stack, tech provider or so on, you are not only assessing whether it meets your needs, but you are also making a bet on its longevity. Will it evolve to continue meeting your needs for as long as you need it to?

Added to all the above are so-called Black Swan events that are rare and unpredictable, but can have a massive impact on your business or operations. The COVID-19 pandemic and the recent disruption of traffic in the Suez Canal are two of the most obvious recent examples of black swan events that have had large-scale impact across many countries. A quick scan of the UK’s National Risk Register [7] considers the likelihood and impact of a wide range of malicious and non-malicious events, including a broad range of cyber and terrorist attacks and catastrophic accidents.

Given this tapestry of uncertainty, what’s the best approach to be taken?

1. Don’t try to predict the future

The 2008 financial crisis took governments, financial institutions and much of society by surprise. Nassim Nicholas Taleb, author of “the Black Swan” [8] was highly critical of the false sense of assurance that sophisticated financial and econometric models provided. A model is only as good as how faithful it reflects the real world, including all the non-linearities, biases, emotiveness and herd dispositions of human behaviour. In the case of the 2008 financial crisis, the models used by financial institutions not only failed to characterise the inherent risk of their financial products but also completely omitted to take into account how markets and institutions would react to crashes [9]. Similarly, many machine learning models that underpin retail supply chains, misjudged the wild swings in customer demand and supply both during and after the COVID19 pandemic, causing many industries to yo-yo violently from over (and under) supply to the opposite. Learning models are only as good as the data they are trained on.

In an article called “6 Strategies for Leading through Uncertainty”, Rebecca Zucker and Darin Rowell encourage leaders to “embrace the discomfort of not knowing.” [12] They say it is physiologically normal to feel stress when faced with uncertainty, as our brains see it as a risk. Decision-makers should embrace the discomfort and make it part of their mindset, acknowledging that it is ok not to know what the future looks like.

2. Recognise Complexity

In a previous blog on Systems Thinking, I explored the tools and techniques for dealing with complex systems. A company operating in the tech space exists within complex and chaotic environments, meaning that it is constantly dealing with unknown unknowns. Many tried and tested structured planning techniques (e.g. applying a Gantt Chart, or breaking down into smaller components) are not of much use in these situations. Instead, a more “sensing mode” of decision-making, involving iterative approaches of trial and error are more effective. This requires a willingness to get things wrong (which is why it is called ‘trial and error’) allowing you to understand the impact of the decisions you are making and to adjust course accordingly

Adapted from Snowden and Boone, A Leader’s Framework for Decision Making, Harvard Business Review, 2007

3. Alternate between Zooming Out and Zooming In

In their book “The Practice of Adaptive Leadership”, Ronald Heifetz, Marty Linksy and Alex Grashow talk about “zooming out” from the operational challenges to gain a different perspective. They argue that this helps leaders see the context and patterns that occur over a longer timescale than can be identified while dealing with day-to-day challenges. For example, the practice of Wardley Mapping, where a company’s product offering can be mapped against trends in its ecosystem is an exercise in zooming out. Zooming out also facilitates systems thinking, understanding how things are connected to each other and applying different perspectives.

4. Be Bold and Focus on Execution

Uncertain times not only bring risks, they also bring opportunities. A paper by Michael Birshan, Ishaan Seth and Bob Sternfels in McKinsey’s digital journal [11] quotes Aryton Senna saying, “You cannot overtake 15 cars in sunny weather, but you can when it’s raining.” The authors argue that successful leaders are ambidextrous – they are not cowed by uncertainty. Instead, they are prudent about managing the downside while also thinking about the upside, often over a long-term horizon. Being bold, however, requires the ability to move fast and execute at pace. Where the environment is uncertain, the ability to spin on a dime in response to changing conditions makes the difference between success and failure. Pfizer, Moderna and Astra Zeneca were all able to create novel vaccines for COVID-19, a previously unknown disease at an unprecedented speed. This required a combination of technological rigour (i.e. execution excellence), technological advances that allowed them to scale their product, as well as cooperation with governments and health organisations to speed up approvals.

5. Lean on your values and purpose

In uncertain times, business-focused objectives, such as market dominance in given segments, don’t provide the clarity of purpose to act as a guiding North Star when navigating the shifting sands of tech change, geopolitical uncertainty and disruptive competition. When Satya Nadella took the helm of Microsoft, he realised that the existing strategy built on proprietary Windows PC software was not sustainable in a world built on ecosystems of partners built on open technology. He guided through change by not only shifting investments into Cloud and AI but by fostering a culture of humility and learning. He said, “from ancient Greece to modern Silicon Valley, the only thing that gets in the way of continued success, relevance and impact is hubris.” [12] Here he was making a marked shift from the Microsoft that bullied away competitors and anti-trust regulators. Instead, he fostered a culture where, in his words, “the best work happens when you know that it’s not just work, but something that will improve other people’s lives.” By emphasising the values he wanted to bring to Microsoft’s soul – a growth mindset, empath, inclusivity, collaboration and customer-centricity, Nadella has created a culture that leans on its sense of mission, providing the steadying influence of a keel in rough seas, whilst relying on a sense of humility and learning to keep adapting along the journey.

Conclusion – It’s all about execution

Coming back to where we started this post, it seems pretty clear to me that the dual challenges of friction and fog are as relevant to tech leaders as they were to field commanders in the 19th century. Now as much as then, having the correct strategy is essential to ensure that you compete on terms that give you the best relative advantage. However, leaders need to embrace the contradictions, confusion and sheer hard graft required while executing the strategy. The thought that there is a grand plan out there which you can stick to, is one for the birds. Instead, embrace the uncertainty, adopt a learning mindset, and be prepared to change directions many times along the way. Above all, make sure that your teams are as match-fit as possible. Just as a car’s build quality is only really tested when it’s driven the most demanding of terrain, it is only the best-drilled and most effective organisations that find they have the agility they need to thrive in uncertain times.

Creating learning organisations

Simon Fabri — Sun, 31 Dec 2023 16:46:15 GMT

These days, unless you happen to work for a tech-native firm, you will struggle to avoid being drawn into some form of digital transformation initiative. From manufacturing digitalisation to the creation of wholly digital customer interaction channels and everything associated with websites or mobile apps, digital transformation is a veritable cash cow of the management consultancy industry. Globally it is worth over $50 billion a year in revenues [1] and this is forecast to grow to over $200 billion by 2031.

Yet there is something that I find profoundly odd how these same consultancies are approaching digital transformation. Consider a definition of the term offered by McKinsey [2]. “A digital and AI transformation is the process of developing organizational and technology-based capabilities that allow a company to continuously improve its customer experience and lower its unit costs; and over time sustain a competitive advantage.” The crucial activity in this definition is the “process of developing organisational and technology-based capabilities“. Yet the provides only a cursory mention of skills development, and more words are spent on ‘machine’ learning and ‘training the user’! Yet how is it possible to develop new organisational capabilities without a cross-organisational focus on developing skills? In case you think that this is a rare misstep by a single consultancy, consider Accenture’s six action steps to digital transformation [3]. Although Accenture tells us that “companies often need to build new skills” (what do you mean by just often?), none of its six steps cover skills development, learning or training.

The interplay between transformation and learning

This leaves me to reflect that despite advocates of digital transformation framing it as a process of organisational change, the need to invest in an organisational-wide approach to skills development is under-played. A transformation journey that requires the reimagining of how technology is used, and the reshaping of processes, products and operating models is at its heart a collective learning journey. It is only by absorbing, embracing and embedding new skills, work practices and culture can these initiatives even have a chance of succeeding.

So how do you go about instilling mechanisms to institutionalise a learning culture within your organisation? Thirty years ago, in a seminal paper [4], the late professor David Garvin suggested that “A learning organisation is an organisation skilled at creating, acquiring, and transferring knowledge, and at modifying its behaviour to reflect new knowledge and insights.” Implicit in this definition is that transformation and learning are interdependent. Transformation cannot exist without learning, and learning without transformation has no impact. Garvin went on to outline how learning organisations are adept at five main activities: systemic problem-solving, experimentation with new approaches, learning from their own experience and history, learning from the experiences of others, and transferring knowledge quickly and efficiently throughout the organisation.

Transformation cannot exist without learning, and learning without transformation has no impact.

Research also suggests that taking a skills-based approach is even more important when dealing with culture change. A recent paper [5] shows that culture change programmes implemented through the commonly-used approach of short, standardised workshops give participants the false belief that they can assess the utility of the new skills after taking part in a single workshop or course. The embedding of change requires people not only to learn new skills but also to put them into practice on real problems and to experience their benefits. Without linking skills directly to outcomes, it is otherwise difficult to overcome scpeticism that either the change being proposed is not needed or would otherwise not work. Instead, transformational change should be approached as a skills development activity. It can be more effective to implement deeply within a single part of the organisation, seeing the skills being put successfully into practice, thereby acting as a powerful reinforcing and embedding mechanism. This provides “proof” that the skills work in the existing organisational context.

Having hopefully convinced you of the interplay between transformational change and organisational-wide learning, I will now explore some approaches to creating a learning culture.

Learning from your own successes and mistakes

All organisations hold a wealth of knowledge that is generated from their past activities, whether they are things that were done well, as well as from mistakes made. Although these successes and failures (or mistakes) provide invaluable intellectual capital, most organisations fail to maximise them. When something goes really well, it is all too easy to move on to the next project, ignoring what could be crucial lessons for other project teams. Similarly, inspecting mistakes is often equated with searching for someone to blame, and so is often avoided. Crucial learning is often hidden from the rest of the organisation, before being lost from institutional memory.

As team membership in most organisations changes quite rapidly, it is crucial to capture and disseminate this know-how, to allow the organisation to keep on improving. Agile cultures adopt retrospectives [6] within sprints or other cycles to understand what went well, what could be improved, and commitments to improve. Psychological safety is crucial. Acknowledging that mistakes are inevitable not only allows for employees to take risks in the first place, but also when something goes wrong, allows emphasis to be on identifying the root cause of the problem to prevent it from happening again. In other words, the focus is on why something happened, not on who is responsible. Prof Ben Laker [7] explains that companies need to provide the means to help employees capture and share best practices and learnings with colleagues right across the company, whilst ensuring failure or problems can be raised without fear of punishment or other career-impacting consequences. Amazon has a deeply embedded culture of using a Correction of Error (COE) process [8] to understand the root cause of issues, be it a technical, operational or process problem, and then make these assessments available for everyone to access. Learning is further embedded through periodic reviews by broader teams of COEs that are considered to have pertinent findings or have relevance to a wider part of the organisation.

Learning from others (1) – Benchmarking

No matter how valuable insights are gained from learning from your past experiences, the knowledge held within your organisation will always be dwarfed by that available in the outside world. For this reason, bringing in insight, experience, practices and know-how from outside your organisation is essential if you are to avoid progressively losing your edge. There are several ways to achieve this. You can, for example, recruit new talent from within or outside your industry to inject new ideas, but this is often more expensive than training your current staff and can take time.

One approach I have used several times is to identify appropriate benchmarks, examples of best practices to which to inspire products my teams were building or ways they were working. Often, the best benchmarks are to be found outside of the industry you are working in. For example, most car companies assiduously compare their vehicles to those of their competitors. However, when it comes to digital infotainment systems (encompassing voice, mobile apps, and in-car entertainment), customers are not particularly bothered by how good another car may be. Instead, their expectations are set by the likes of Netflix, Alexa and social media apps. It is only by learning how these tech-native companies produce their digital customer experiences, can car companies stand a chance of creating digital experiences that delight their customers.

Learning from others (2) – Open Innovation

Where the depth and complexity of skills required to succeed in your market exceed your ability to retrain your teams, particularly where time is a critical factor, then you have few options but to bring in external know-how. Corporate venturing and acquisitions are popular routes for companies to rapidly build expertise in potentially-disruptive technologies without building internal capabilities from scratch. For example, corporate venturing in the AI space this year exceeded global venture investment as large tech companies scrambled to hoover up as much AI talent as possible and accelerate their products to the market. [9]

However, simply buying access to external expertise is not a feasible approach for most organisations. This is where open innovation comes into play – the collaboration with external companies, often start-ups on a win-win basis to gain access to their know-how and technology at low cost, while at the same time providing the start-up with improved routes to market. Done properly, Open Innovation can help companies build and extend their own innovation capabilities, but only if knowledge is allowed to flow into and across the organisation.

This month, Henry Chesbrough, the professor who introduced the concept of Open Innovation twenty years ago, wrote a reflective piece [10] on its impact over the past two decades. Chesbrough explicitly describes open innovation as a process of organisational learning, “an innovation process involving knowledge flows across organisational boundaries.” While he claims that organisations with more external sources of knowledge achieve better innovation results than those that don’t, he added that the main barriers come from internal silos. A recent study of open innovation practices at NASA showed that although crowdsourcing allowed NASA to significantly improve their ability to predict solar flares, engineers within NASA’s Johnson Space Centre were troubled by this. They felt that their sense of identity, the way their expertise was valued and their very roles within NASA were threatened by this outside innovation.

Chesbrough argues that organisational structures designed around functional specialism act as boundaries to the flow of information between different functions. Intel solved this problem in its New Business Initiatives (NBI) unit that worked with startups by placing team members from the business unit tasked with commercialising the innovation. Another approach is to create an internal and external market where products and services can be procured from both within and outside the organisation, replacing the monopoly of internal silos. This can also create the sense of urgency, that I feel is essential to inject pace into your organisational learning.

Embrace urgency

The COVID-19 pandemic, whilst causing unspeakable human suffering, also demonstrated the rallying and galvanising power of an emergency. Too often, business processes, designed for business-as-usual operations and incremental change create an organisational pace that is simply at odds with the demands being made by the outside environment. The large-scale, life-or-death crisis ushered by the pandemic forced governments, regulators and businesses to tear up their rulebooks. Patient care systems were digitalised at a breakneck speed, introducing vaccine passports linked with patients’ health records, numerous companies threw themselves at creating alternatives to expensive medical ventilators, and above all, vaccine development took place at an unprecedented pace, with the first patient receiving the vaccine only one year from when the virus was first sequenced. The war in Ukraine is demonstrating the same effect, where technologies and tactics are rapidly evolving on both sides. Arguably, the new forms of aerial and maritime drone warfare employed have had a greater impact on armoured warfare and naval warfare than arguably any other change in the past few decades.

The lesson here is that where the need for change is urgent, you should ask yourself whether your business-as-usual processes are serving you well, and whether the cadence, rhythm, and collective bureaucracy will deliver the organisational capability you need to meet your goals. If the answer is no, then it may well be time to tear up (at least part of) the rule book, or at least change it to allow you to create the innovation capability you need in the time you need it. In doing so, you be cautious to create a positive sense of urgency, and not fall into the trap of creating a culture of fear associated with expressions such as ‘burning platform’. [11]

The role of leadership

Learning is only going to be effective if people are given the space and time to learn away from the operational pressures of their day-to-day responsibilities. Equally, they will only really be incentivised, if they are allowed to put their learning into practice. The role of leadership is to provide staff with this time and space. Greg Satell [12] recommends companies adopting what he calls a 70/20/10 learning model, where 10% of learning is through formal instruction such as in-person and online courses, 20% on social learning such as mentoring, coaching or peer-to-peer interactions such as communities of practice, with the remaining 70% on in-work experience. This can include retrospectives and lessons learned mechanisms described above, but crucially through the feedback from colleagues and managers.

To be successful, managers need to embrace their role as coaches and not simply be a taskmaster. Like many other aspects of providing direction, there is a balance to be had. Kelly Palmer recommends [13] that managers and leaders should be “hands-on” enough to build cultures that support learning for their employees, whilst being “hands-off” to allow employees to choose the method and content of learning that suits them best. Finally, like with any initiative that is driven from the top, organisational learning only has credibility if leaders practice what they preach, and make that visible, by sharing what they have learnt.

The role of the individual – knowledge sharing

Organisations with a strong culture of learning place responsibility for knowledge-sharing on everyone, not just on a cadre of experts. Knowledge-sharing is an activity that should be undertaken deliberately, as otherwise barriers to the flow of information emerge, ranging from the creation of information islands in different silos to situations where critical knowledge is held by a single individual.

Any tech company that has scaled successfully has managed to grasp the challenge of knowledge sharing. Google, for example, [14] places a strong focus on creating a culture of psychological safety both within a person’s team as well as in large groups. This is intended to encourage Googlers to be willing to learn from others, be they individual coworkers or group forums where no question is “too simple”. Likewise, everyone has a responsibility to share their knowledge. This takes place through creating and maintaining clear documentation, holding tech talks and classes, participating in code reviews as well as mentoring and coaching peers and more junior staff. Crucially, Google’s compensation mechanisms encourage and reward knowledge-sharing through performance reviews and promotion criteria. These expectations are codified in Google’s role descriptions, with the requirement to have influence beyond your area of responsibility increasing in line with seniority.

Learning as a collective responsibility

Although there is a clear individual responsibility towards one’s own learning plan, organisations with effective learning cultures recognise that learning is more effective when people learn together and from each other over time, creating shared beliefs that are more likely to embed within the organisation’s fabric. A paper by the Spanish Business School IESE [15] argues that workplace rituals such as shared chat channels, communities of interest and of practice can help create the shared realities and social bonds that are “the glue that holds organisations together”. As an example, Greg Satell [8]describes how executives from Wipro, an Indian-headquartered multinational IT services firm went to a literary festival to learn storytelling. Each night they attended a structured workshop, after which they received peer mentoring. By supporting each other, they not only helped create the skills but also created the shared reality described above. I have found this approach particularly effective. In agile transformations that I have shaped, I deliberately ensured that entire leadership teams of the business units involved also participated in the training, so as to create the ‘shared mindset’ necessary to embed the required change.

Some final thoughts

When I started writing this blog post, at first I thought I was exploring approaches on how best to instil a learning culture in an organisation. It instead became clear to me that organisational change, innovation, and skills development are intrinsically interlinked, even more so in high-skill environments. No digital transformation initiative can take root without embedding new ideas, ways of thinking and working practices, which together constitute the outcome of a cultural change programme. At the same time, none of this is achievable without learning new skills (both technical as well as ‘soft’ skills) at an organisation-wide scale, which requires a systemic approach to skills development. We have seen that while the responsibility for creating a learning culture lies with an organisation’s leadership, everyone has a role to play, whether it is to further their own knowledge, or to codify, share and disseminate their know-how. Finally – and most pertinently to any organisation in the technology space – anyone who believes that knowledge and ideas creation can be a solely internally generated activity is severely deluded. Ideas, expertise and know-how can often be found where you least expect them, meaning it is essential to implement means of bringing in ideas, expertise and innovation from outside the organisation.

References and Further Reading

The post A rising tide – creating a learning organisation appeared first on The Sand Reckoner.

Breakthrough Innovation - The role of collective intelligence

Simon Fabri — Fri, 02 Jun 2023 08:23:52 GMT

These days you cannot browse a tech website, read a management magazine or browse your LinkedIn feed without mention of the latest AI-related news, be it the latest Generative AI model, some new demo that looks like magic, or some luminary forecasting doom or a bonanza of riches. As if out of nowhere, artificial intelligence is everywhere. Henry Kissinger is talking about its use in warfare, Bill Gates thinks it can help reduce inequality and offer better healthcare to the poor, the European Commission is sharpening its regulatory pencils, while in the meantime, Elon Musk is warning that machines will take over the world. Looking at the number of searches on Google for the term “AI” over the past five years shows that the launch of ChatGPT triggered an inflection point in interest in AI.

Google searches for “AI” in the UK 2018-2023

Artificial Intelligence as a Result of the Collective Brain

So what happened? Why did AI suddenly burst into the public consciousness? It is not as though computer intelligence is a new idea or concept. Just consider HAL, the self-aware, and ultimately murderous computer from 2001: A Space Odyssey, penned by Arthur C. Clark way back in 1968. The answer to this sudden snowballing of innovation can be explained through the theory of the “collective brain”. This posits that just as an individual’s thoughts emerge from neurons interacting as a whole, our can societies and social networks can be modelled as a collective brain. In this analogy, each person is analogous to a node, a neuron, that is interconnected with all the other people in their direct or indirect network, resulting in the emergence of collective, or societal intelligence. In the case of innovation, connections are made through formal and informal networks, through the publication of journals, attendance at conferences, ad-hoc discussions (those famous watercooler moments), writing of blogs, and debate on social networks.

HAL 9000 as imagined by Stanley Kubrick

In a great paper published in the splendidly-named Philosophical Transactions of the Royal Society, Michael Muthukrishna describes [1] how breakthrough innovations are the result of cultural recombination, where different elements of culture are recombined in new ways, giving the appearance of inborn genius. He says that these innovations are born “at the social nexus where previously isolated ideas meet.” Muthukrishana argues that it is no coincidence that great scientific discoveries have often been made by multiple people at around the same time. Newton and Leibniz separately invented calculus, while Charles Darwin and Alfred Wallace came up with remarkably similar theories on the role of natural selection as a driver of evolution. In both cases, the scientific and cultural building blocks were already there, ready to be adapted, evolved or recombined into something new. As many people had access to the same collective intelligence, it is therefore unsurprising that multiple people made the same breakthroughs at similar times in history. This is exactly what is happening in the AI space, where a combination of sophisticated deep learning models across multiple domains (natural language processing, image synthesis), massive training sets and large-scale computing have collectively provided a tipping point in capability.

The iPhone – Result of Steve Jobs’ Genius or Recombinant Innovation?

Look at any number of technology breakthroughs, and you see a similar pattern emerging, with the same invention emerging multiple times at the same time. The motor car, for example, is attributed variably and separately to Karl F Benz, Gottlieb Daimer and George Seldon [2] in the 1880s, but this built on prior innovations such as the carburettor and the spark plugs in the previous two decades. Similarly, there were 22 prior inventors of the incandescent lightbulb before Thomas Edison’s commercial success. As a more recent example, the invention of the smartphone is attributed to Steve Jobs’ undoubted product genius, the epitome of the “great man” theory of innovation. This (gender-biased) theory posits that visionary individuals with unparalleled insights are responsible for sparking major changes.

The theory that the iPhone results from Steve Jobs’s genius however does not stick up to scrutiny. At its inception in 2005-06, Jobs was not keen to become a phone maker and was concerned that it would distract from the iPod, which already had a touchscreen and was a cash cow for Apple. Jonny Ive saw the potential of using multi-touch displays as the primary interface for a mobile phone. This stood in stark contrast to the Blackberry, which was the leading smartphone of the time, and had a full physical QWERTY keyboard.

The building blocks for a revolution in mobile phone technology were coming together from all over the world. Semiconductor companies, including Samsung and Qualcomm, were building high-performance processors based on an architecture by the UK company ARM that was capable of running slimmed-down versions of the Linux operating system that was previously limited to full-fledged computers. In the meantime, the advent of 3G technology made the mobile internet a reality rather than a pipe dream (though the first iPhone made use of 2G), while thin-film transistor technology and multi-touch capacitative displays allowed Jonny Ive to realise his ambition for a fluid touchscreen UI. None of these technologies were invented by Apple, but Apple was the first to package them together in a form factor that persists to this day. As the ‘collective brain’ was available to anyone with the financial and commercial resources to exploit them, Google, who were already working on Android devices, launched their own touchscreen smartphone within one year and the world wasn’t the same again.

First Generation iPhone (2016) and Android Smartphones (2017)

Characteristics of Recombinant Innovation

So what is recombinant innovation? In my view, there are two stand-out considerations. First, it creates new solutions or products by pulling together the capabilities already existing in different, unrelated fields. As described above, the smartphone is the talismanic example of recombination of our age, but look deeply at most recent tech innovations and you will see similar recombinant patterns: smart home (cloud connectivity, low-energy wireless networks, energy-efficient, low-cost IoT processors), social media (ubiquitous high-quality smartphone cameras, graph databases, low-cost cloud storage), ecommerce (web browsers, payment networks, fulfilment networks, secure internet communications) and streaming media (smart devices – TVs, smartphones, speakers, low-cost cloud compute and storage, machine-learning recommenders, low-cost high-speed internet connectivity).

Secondly, recombinant innovations are much more likely to be disruptive than those created by a single function. If we refer to this alternative as incremental innovation, not because it is intrinsically focused on delivering small improvements, but because it optimises or improves existing products. Increasing the resolution of a smart TV from HD to 4K is an incremental innovation, as are the progressive improvements to an electric vehicle’s range. Incremental innovation may be the result of breakthroughs in screen technology, but from a customer perspective, it simply provides a better version of what came before. Disruptive innovations can instead up-end existing markets (e.g. ride-hailing apps, dating apps, streaming media, messaging apps). They are nonlinear because their adoption and performance follow the bottom left of a traditional S Curve. You’d be hard-pressed to find a disruptive innovation that was not the result of recombining many existing solutions.

The Innovation S-Curve. Source LSE

Consider the advent of electric cars. In my opinion, the launch of Tesla’s Model 3 was the key disruption point in the auto market. For the first time, an electric full-sized saloon (or sedan, for US readers) was available for cheaper than the average price of a new car (around $48,000). This marked a tipping point, as for the first time a ‘no-compromises’ family fully-electric car was available for a comparable price as other diesel or petrol vehicles. Tesla brought in numerous technologies from battery providers such as Panasonic, compute units from AMD and Nvidia, as well creating in-house technology (such as the drive units) to produce a vehicle architecture that was significantly simpler and cheaper than that of any incumbent car manufacturer.

I wouldn’t like you to leave this blog post thinking that recombinant innovation will always lead to disruptive outcomes. The opposite is true, as only a minuscule fraction of innovations will be disruptive. Nevertheless, recombinant innovation is highly likely to be more impactful than incremental innovation, be it at a team level or across an entire industry.

Creating a culture for recombinant innovation

Given all this, how can companies and teams set themselves to be best placed to create a culture that encourages the recombination of ideas?

1. Encourage networks within your company – Break down silos

The most obvious means of fostering recombination is to encourage teams to connect with other teams, both within and outside the company. Within a company, organisational silos are the enemy of recombination. Whether the silos are the result of functional specialisation (e.g. different teams creating and operating different parts of the systems – apps, databases, tools etc) or whether they instead arise from having separate business lines with their own P&L lines, siloes inevitably act as barriers towards the type of collaboration and networking that are essential for recombination to thrive.

There are a number of approaches to help teams work across silos. One is to explicitly create multi-functional or multi-disciplinary teams, focused on solving a given outcome. Not only is this team topology more likely to result in a successful outcome, but the greater diversity within teams lowers the cultural barrier between different teams. It will thus be easier to make meaningful connections with people in other teams.

Where companies are organised along functional lines, this often creates a mindset that focuses on getting the best outcome for one’s own team, even at the expense of encouraging new ideas or win-win outcomes. A paper by Edmundson et al. [5] neatly summarises this problem as follows: “You know you should swim farther to catch a bigger fish, but it is a lot easier to swim in your own pond and catch a bunch of small fish.” As an antidote, the authors suggest that functional teams should seek to include people who excel at creating connections. They call these cultural brokers who reach outside their silos, building relationships between teams. These brokers can either act as a go-between or help develop different teams’ abilities to work with each other.

For the rest of the team who are not intrinsically brokers, team members can still benefit from different perspectives by engaging their more limited networks frequently and with purpose. In a Harvard Business Review paper, P. Leonardi describes [6] how when SpaceX engineers were tasked with radically reducing the cost of the Falcon 1 rocket, they engaged with other engineers within the same company, who had different ideas on approaches to cost reduction. By combining and triangulating these approaches, they achieved a per-unit cost of $7m compared to the alternative

2. Focus on the outcome, not the means

One common trap that tech teams fall into is to become more focused on how best to apply their existing tools and knowledge rather than focusing on the nature of the problems to be solved. In many ways, this is a natural human behaviour. Highly-skilled knowledge workers are aware that they provide value through their specialised knowledge so are more likely to look as to how they can apply that knowledge to solve different problems than to look outside their comfort zone. This is, of course, a trap as it easily leads to a place where over time a gap will emerge between the teams’ skills and the company’s objectives. This is never more true than when an industry is undergoing severe disruption. Imagine the predicament of being a photographic film chemist in the early 2000s or consider the impact that electrification and digitalisation are having upon the skills required in the automotive industry. By focusing on outcomes, or by relentlessly focusing and working backwards from the customer’s needs, to use Amazon’s terminology, [7] teams can ensure that they are driven less by what they know today, instead focusing on the knowledge and skills they need to acquire (i.e. have a growth mindset) to achieve their customers’ desired outcomes.

3. Avoid over-specialisation

As technology has become ever more complex and as the breadth of scientific knowledge has become unfathomable, there has been a corresponding tendency for individuals to specialise in ever-narrowing fields of expertise. David Epstein, in his wonderfully sweeping tribute to the under-appreciated importance of generalists in helping navigate today’s complex environments [8], describes how academic publications are hyper-specialised and increasingly narrow. This is particularly true in fields like medicine, where specialisation means that the holistic care of a patient becomes ever more challenging, as practitioners often focus on “small pieces of a larger jigsaw puzzle in isolation.”

Ensuring that your teams contain generalists can go a long way to encouraging the recombination of ideas. Epstein states that many great innovators are systems thinkers (see a previous blog post here), who have an “ability to connect disparate pieces of information from many different sources.” Bill Gates supports this view and attributes Microsoft’s success to the fact that they hired people who had real breadth within their field and across domains [9]. It is therefore important to not only hire for breadth but also to encourage the generalists among you to meander across different areas, bringing their systems thinking approach to solve your trickiest problems. This is tougher than it might appear. For example, Epstein explores the impact of multi-disciplinarity in the publication of research papers, a space for which data is publicly available. Papers that draw on inputs from different areas are less likely to be published in prestigious journals and more likely to be ignored in the short term, though in the long run will accumulate more citations and have a greater impact. It appears that not being able to fit into a pre-conceived category is an obstacle to publishing a research paper.

4. Encourage networks outside your company

Research [10] suggests that it is 30% more costly to successfully discover and utilise ideas created in another firm other than your own. There are numerous frictions that can impede intra-company recombination, including framing contracts that encourage the pooling together of ideas, resolving the thorny issue of who owns what intellectual property concerns, as well as a multitude of strategic considerations such as whether a collaborative relationship can evolve into a competitive one. Open Innovation [11] is the over-arching term which describes how companies make use of external sources of ideas, expertise and technology to complement their internal capabilities. There are a variety of approaches to achieve this. Large companies, such as banks, automotive manufacturers and even government organisations are increasingly engaging with start-ups through Open Innovation Platforms (see here for a list) to help them discover start-ups, engage in crowdsourcing, and find new approaches to the challenges they are facing. Such platforms help reduce the speed, size, technology and cultural disparity that exists between multi-billion dollar automotive behemoths and much smaller and nimble startups, without tying down two parties in relationships based on equity investments.

Open Innovation however only really works if there is a genuine internal commitment to the concept that the space outside the company is as valid and valued a source of innovation of ideas, technology and components as internal teams. This is anathema to many large organisations, for whom “we can do it better” is a source of (often misplaced) pride. The stronger the technical credentials of the organisation, the deeper runs a “not invented here” culture.

5. Make the most of technology building blocks

In the digital space, we are living in a golden age of recombination opportunities. By definition, recombination involves putting together disparate building blocks, as if creating a Lego model. Extending this analogy, the builder’s digital Lego set has never been so big, nor as easily available or cheaply accessible.

Developers have long relied upon open-source software for their undifferentiated software needs. However open source is no longer limited to software. For example, open-source AI models and training data sets are easily available on platforms such as huggingface.co. Governments and companies alike are making data sets available through APIs, either freely or through subscription, with data sources as diverse as geolocation, satellite, demographic, healthcare and environmental data. Governments are beginning to regulate some sectors to make data available in order to foster greater competition. In the UK, the competition authorities have mandated that the largest banks implement open standards for Open Banking to allow customers to securely share their data with other financial providers. Software-as-service (SaaS) which provides technology as a subscription service, from anything from payments to communications services, is now an industry generating in excess of $250 billion / year. The big three cloud providers (AWS, Google and Microsoft) all offer extremely extensive software and platform-as-a-service offerings to builders. When taken together, all these modules, SDKs, models, services and so on, greatly reduce the friction of recombination and will likely continue to be a driver of disruption of innovation.

Conclusion

Hopefully, this rather meandering post has articulated why I believe that combining different ideas and technologies lies at the heart of innovation and why siloed thinking is the enemy of creative innovation. I have built on an earlier post on cognitive diversity, but I have only scratched the surface of this topic. I have deliberately steered clear of debates about when innovation is truly disruptive, and have only skimmed the surface of how to reduce intra-organisational silos or facilitate open innovation. Nevertheless, I hope it has given some food for thought, and it will certainly act as a springboard for further related musings, at least when I next get time to put pen to paper.

Many Points of View – Why Cognitive Diversity Matters

Simon Fabri — Thu, 30 Mar 2023 19:44:58 GMT

Equity, Diversity and Inclusion (EDI or DEI) programmes have rightfully become a key priority of all reputable organisations. These seek to ensure that everyone has fair opportunities to succeed, irrespective of their differing needs. While I will not even attempt to scratch the surface of the importance of EDI programmes, in this post, I’ll explore an aspect that is often missing when discussing diversity. The Chartered Insititute of Personnel and Development, a professional body of HR professionals, defines EDI as consisting of age-diverse workforces, disability, gender equality, race inclusion, religion and belief, as well as sexual orientation and gender identity. Whilst inclusion and equity programmes should account for all of these personal characteristics to ensure everyone is able to thrive at work, these miss out on one fundamental dimension – differences in how people think.

Neurodiversity and Cognitive Diversity

The concept of neurodiversity has often been framed as relating to people with medicalised definitions of brain function and behavioural traits, such as autism, dyspraxia and ADHD. This approach however requires the existence of such a thing as a ‘normal brain’ modelled around a standardised way of behaviour, measurable along a linear IQ scale. Recent studies such as “The Power of Neurodiversity” by Thomas Armstrong instead argue that there are a large variety of dimensions of intelligence, including visual-spatial, interpersonal, logical and kinaesthetic, and that neurodiversity is simply the reflection of this infinite variation in human thinking and behavioural style.

One way of characterising neurodiversity is described by Simon Baron-Cohen, a Cambridge professor of psychology. In his book The Pattern Seekers, Baron-Cohen argues [2] that thinking styles can be mapped against two categories, systemising and empathising. People who are good at systemising can spot patterns and understand the underlying mechanisms of how things work. Empathisers on the other hand are adept at intuitively understanding other people’s thought processes and reacting appropriately. All of us fall somewhere on a scale describing these two cognitive abilities.

This leads us to the concept of cognitive diversity, the idea that people with different backgrounds, training, experiences and perspectives, as well as thinking styles, will approach solving problems in different and often complementary ways. This post will explore why cognitive diversity is a critical consideration to any team tasked with dealing with creative and challenging problem-solving.

Team Dynamics and Performance

Managers have long known that effectiveness comes from getting the best of a team as a collection of individuals, rather than managing performance solely at the individual team member’s level. Matthew Syed’s excellent book, Rebel Ideas [3] explores the impact of cognitive diversity on decision-making, and equally crucially, what are the consequences of its absence. He discusses how during the Cold War years, recruitment in the CIA focused on individual excellence from a small set of universities, resulting in homogeneity in its personnel – mainly white, male, middle-class, Anglo-Saxon. (For disclosure, I score 3 out of 4 on this CIA homogeneity test!). Syed argues persuasively that this homogeneous group overestimated the size of the Soviet economy in its dying days due to ‘perspective blindness,’ where all team members shared the same blindspot, or viewed a problem with the same lens. Similarly, Syed argues in the run-up to the September-11 attacks, American intelligence agencies, despite being staffed by patriotic, committed, bright individuals all shared the same blind spots, missing, for example.

Syed illustrates the importance of cognitive diversity very effectively by representing a problem space as a rectangle, and the perspective of an intelligent individual team member as a circle within it. Cognitively-similar teams consist of a clustering of people with the same perspective and problem-solving space. This means that this team of ‘clones’ has an unconscious predisposition towards a single way of solving problems, and consequently significant blind spots. Such teams are prone to reinforcing the same perspectives and mirroring prejudices. These are exactly the conditions that lead to GroupThink, a topic I explored in a previous post.

Cognitive diversity and a Problem Space – from Matthew Syed

Applying measures to ensure demographic diversity (age, gender, social background) in your teams can go some way to improving cognitive diversity. In particular, I have found demographic diversity to be essential in teams creating products for mass-market adoption. For example, a team of relatively young male engineers may struggle to relate to the usability concerns of a mass-market customer base. However, whilst there is an overlap between demographic and cognitive diversity, the simple act of hiring demographically diverse teams will not in itself ensure cognitive diversity. For example, recruiting five graduates from the same business school will likely provide five very similar viewpoints, irrespective of their race, gender and socio-economic background. In other words, superficially-diverse people can be very homogeneous.

Syed describes an intelligent team as a team of rebels, consisting of people who are individually no smarter than those in cognitively-similar teams, but, taken together, bring a diverse range of perspectives and problem-solving styles to the problem space. Individuals in these teams challenge each other, diverge, disagree and consider contradictory proposals. In doing so, they collectively improve the intelligence of the team. For diversity to raise the overall level of intelligence of the team two things must be true. First, the experience and skills being brought to the team by each member must have some form of relevance to the problem space. Second, the team leader must foster a culture of constructive dissent, scrutiny and curiosity in order to allow different viewpoints to emerge and be considered. You may have the most carefully selected and assembled team, but if one viewpoint dominates, then the diversity of viewpoints will go to waste.

In a Harvard Business Review article [1], Alison Reynolds and David Lewis described a problem-solving exercise they ran over a number of years with teams consisting of senior execs, MBA students, managers, teachers, scientists and teenagers. Traditional measures of diversity (gender, ethnicity and age) did not account for the variability in results. Some groups fared very well, while others did very badly, irrespective of their demographic make-up. To try and understand whether there were any other factors at play, they classified participants according to the AEM cube, a psychometric tool that assesses people according to how they approach change. This measures knowledge processing, the extent to which people prefer to generate new knowledge or use existing knowledge when solving a problem, and perspective, the extent to which individuals prefer to use their own expertise or orchestrate the ideas and expertise of others. Their study showed that teams that completed the problems quickly had diversity of both knowledge processing and perspective, while those that failed the test were homogenous across those dimensions. In other words, cognitive diverse teams greatly outperformed cognitive homogeneous teams.

The importance of cognitive diversity has not just been recognised in tech companies, it is also rapidly being embedded as a core cultural value in modern militaries. The US Army teaches its officers [6] about the importance of cognitive diversity in achieving greater organisational performance. Officers are encouraged to learn how their subordinates think and process information and encourage different viewpoints. The guidance for junior officers in to let people question assumptions, and to lead with humility, both approaches that go against the stereotype of a top-down command and control culture we expect to find in military organisations. A recent book by Jason Lyall, Divided Armies: Inequality and Battlefield Performance in Modern War, examines the relationship between diversity and battlefield victory across 250 different wars. He finds that over the past 200 years, inclusive armies have outperformed their opponents and states that “meaningful inclusion creates lethal armies; military inequality divides them, destroying them from within”. For Lyall, “bigotry and racism are threats to national security.”

Optimise for the best team, not the best individual

Cognitive diversity puts to bed the fallacy that there is a trade-off between hiring the best individuals and meeting diversity objectives. This approach was famously summarised by the late US Supreme Court Justice Scalia, who said you can “choose diversity or to be super-duper.” This is a false choice as it uses the individual, rather than the team as a frame of reference. Filling a team with identical clones, even if all are ‘super-duper’ will result in a team of lower collective intelligence than one chosen with cognitive diversity in mind. Indeed, the more complex and uncertain the problem space, the more essential it is to bring different problem-solving approaches.

So what practical steps can you take to foster cognitive diversity? Here are some of my thoughts on approaches.

Cross-functional teams. Probably the default organisational setup in most companies is to group people by specialisation or function – lawyers reporting to lawyers, software engineers to engineers and so on. Being grouped with people who share your profession provides an environment for sharing and developing your expertise further, and having a manager with the same professional background can help in your personal development. However, building problem-solving teams from people from the same background and discipline is also a surefire way to create an organisational silo as well as to create a discipline echo chamber where opinions are reinforced. Wherever possible, the simple act of grouping people into cross-functional teams self-evidently injects diversity of thinking approaches into the team.

Psychological safety. Grouping people from different backgrounds, in and of itself does not guarantee that the different viewpoints and contributions will be heard. A while back, I described how a multi-year study at Google showed that psychological safety was found to be the greatest predictor of team performance. The concept is simple, the safer people feel about taking risks, making mistakes, and suggesting ideas that may be quirky or ‘out there’, the more likely they are to explore a problem from all angles. Equally importantly, they are also more likely to be cohesive.

Unity of purpose in execution. Whilst creativity is a time for divergence, debate and exploration, once a route is chosen, the team needs to stick with the chosen direction. Unless someone feels strongly that unacceptable risks are being ignored or overlooked, all team members must rally around the decision. The transition point between ideation and execution is a critical juncture and one that can be difficult to navigate in teams with a strong ‘rebel’ culture. One of the leadership principles at Amazon is called “Have Backbone; Disagree and Commit.” It encourages leaders not to pursue agreement for the comfort of social cohesion. Nevertheless, once a decision is made and the team pivots to delivering on the decision all members are expected to commit to it, whether they agree to it or not.

Why things break

Simon Fabri — Wed, 17 Aug 2022 10:16:37 GMT

I vaguely recall reading a few years ago a survey that claimed that engineers believed that Murphy’s law was the fundamental physical law that was most relevant to their profession. Often quoted as, “If something can go wrong, it will,” the engineers surveyed indicated that Murphy’s law was more important to them than, say, Newton’s equations or the laws of thermodynamics. At the time, I took it to be an amusing piece of trivia that said more about the sense of humour of the engineers being questioned than about the engineering discipline. Some years later and hopefully wiser, I have since developed a healthy appreciation for Murphy’s adage.

Some claim that Murphy’s Law has its underpinning in the laws of physics, specifically in the law of thermodynamics, which states that “for isolated systems, the entropy, a measure of disorder, can only increase.” This means that the state of things naturally gravitates from order to disorder. This is why it is possible to break a vase, but not to unbreak it without inputting a lot of energy, effort and patience. Whilst interesting, I believe that the association with the second law of thermodynamics is wrong. Most human-made contraptions, be they as simple as a garden swing, or as complex as a spacecraft, are not isolated systems. They are all localised engineering systems, to which energy is added in order to ensure that entropy is reduced. The answer to why such systems must therefore lie elsewhere.

Failure as a product feature

When applied to systems, be they man-made or otherwise, Murphy’s Law stands as a law in its own right. If it is possible for something to go wrong, then failure is a possible, valid state of the engineering system being created. Given enough time, and a large enough number of inputs, a system or product can occupy all possible states, including those where failure occurs. If something can fail, then it stands to reason that eventually, it will fail. Failure should not be considered as an aberration, a freak or unlucky event, but rather an inherent characteristic of the system as designed.

Although failure is a fundamental characteristic of complex systems, there are different ways in which systems fail. Equally, not all failures have the same impact. Some can be contained, having no or negligible human or economic impact, while others fail with catastrophic consequences, with economic repercussions in hundreds of millions of dollars, impacting millions of people. In this post, I try to cast a light on what makes the difference between failures that hit the headlines and those we don’t even notice.

Failure to test – the loss of Ariane 5

The Ariane 5 is the European Space Agency’s successful heavy lift rocket launcher, used to send payloads of around 10 tonnes into orbit or beyond. It made the headlines on Christmas day 2021 when it successfully dispatched the James Webb space telescope towards its final orbital destination between the sun and Earth. However, the start of Ariane 5 program was not particularly auspicious. On 4 June 1996, 37 seconds into its maiden flight from its launchpad in French Guiana, the rocket started to veer off its intended flight path before self-destructing by its flight termination system.

The loss of flight V88 has been described as one of the most expensive software bugs in history. The investigation report into the loss of flight V88 found that the system for measuring the rocket’s position and motion, known as the Inertial Reference System (SRI) failed after 37 seconds. This was caused by an arithmetic overflow when a 64-bit floating point number couldn’t be accommodated by a 16-bit integer. (Don’t worry, I won’t mention number systems any further.)

How could such a number formatting issue result in such a catastrophic failure? Ariane 5 did, in fact, have two independent SRI systems. However, as these were to protect primarily against hardware failure, they ran identical software. When one failed due to a design error (i.e. a bug), then the other failed at the same time for the same reason. Any software engineer would then ask why wasn’t this bug picked up in testing. Surely such mission-critical software must meet exacting quality standards? It turned out that although the software function that failed served no purpose once the rocket left the launch pad, it was left running. Moreover, as this was carry-over software from Ariane 4, the previous generation of rocket, it was considered as highly reliable. However, the Ariane 5 trajectory was significantly different from that of Ariane 4, so this software was running considerably outside the operating envelope it was tested for. The bug caused the arithmetic overflow when following a valid Ariane 5 trajectory, but not in the Ariane 4 flight envelope, which is for which it had been tested. The rather startling conclusion of the board of enquiry was that the software simply hadn’t been tested within the flight parameters of the Ariane 5 rocket.

Worrying about the wrong problem – United Flight 173

In his rather excellent book Team of Teams, Gen. Stanley McChrystal tells the unfortunate story of United flight 173 heading to Portland, Oregon from New York on 28 December 1978. On approaching its destination at 5:00 pm, the landing gear was lowered, resulting in a loud thud. An indicator light that should signal a successful deployment of the landing gear failed to illuminate. The landing was immediately aborted, and the captain led the crew in planning for a rough landing. Although the control tower confirmed that the landing gear had in fact appeared to deploy correctly, the crew worked their way through their preparations, including how to exit the plane, what to do after they have landed, and even tidying up the cockpit. So focused were they on running through the entire checklist of dealing with the aftermath of an emergency landing, that they forgot their number one priority – to keep the aircraft flying. After 70 minutes, they ran out of fuel, and crash landed six miles away from the destination, suffering ten fatalities.

The US crash investigators determined that the captain, in line with common practice at the time, had adopted a command and control approach to managing the incident, issuing instructions to the crew and communicating with the control tower. His crew, in return, took their guidance and instruction entirely from their captain. Therefore, as the captain was completely focused on the entirely survivable landing gear issue, so was the rest of the crew. His fixation on a non-critical problem created a blind spot that the crew could not uncover. The captain, as the only empowered decision-maker, ignored an immeasurably more critical issue that threatened the safety of all passengers and crew.

In this case, the crew were not a team, empowered to share the cognitive challenge of landing the plane safely. In the aftermath of this failure, United Airlines, and most of the airline industry revamped their pilot training to improve communications between crew members and share the cognitive load in order to make better decisions in emergencies.

The single point of failure – Facebook disappears from the Internet

The online services that we use every day from our smartphones and computers, be they searching the web on Google, buying goods on Amazon, or chatting to your friends on your favourite social network, all rely on large-scale distributed computer systems, referred to simply, as ‘the cloud.’ Each large tech company has its own ‘cloud’ consisting of data centres across the world (Google, for example, states to have 103 zones), each hosting thousands of servers, and connected to each other by their own private fibre networks. The largest applications are in fact comprised of hundreds of smaller applications, that are often interconnected and distributed across the cloud infrastructure. Although their scale is less visible than, say a large naval vessel, these systems constitute some of the most complex engineering undertakings today.

On 4 October 2021, Facebook stopped working world-wide. It was as though ‘it disappeared from the Internet.’ For five hours that day, Internet service providers across the world were unable to connect to Facebook, meaning that the service was inaccessible to its users. In a blog post published the day after the outage, Facebook explained how it relies on a backbone network to connect its data centres to each other and to the Internet. A command issued as part of its routine maintenance procedures unintentionally caused a complete disconnection of this backbone network. In turn, the DNS services which are used to convert facebook.com to individual Facebook server addresses were automatically disconnected, as they were no longer able to talk to the Facebook servers. This made it impossible for the rest of the internet to find Facebook. To make matters worse, most of the tools, that Facebook engineers use to debug and fix problems were now also out of action as they used the same backbone network was down. Engineers needed to physically go to each of the data centres and restart systems from there. As data centres are designed with high levels of physical security, engineers struggled to gain access to the hardware required to fix the problem.

Traffic volume for Facebook services during October 4, 2021 global outage. Source: Kentik Blog

Despite having apparently well-drilled plans for dealing with failures of individual services, and tests to ensure that changes are safe, a bug in the systems that check for the safety of maintenance jobs failed to stop the incorrectly formed command from being run. Whilst it is tempted to focus on this as the root cause of this failure, the Facebook outage is a classic example of a single highly complex system being vulnerable to a single point of failure. Much like the Death Star in Star Wars which was destroyed when the Rebel ships shot directly at the reactor core, Facebook, and all its customer-facing services and internal tools were dependent on the system that manages their global backbone network. When that system failed, there was no failover capability to take over, and Facebook simply stopped working.

Silos – Left hand not knowing what the right hand is doing

On 23 September 1999, NASA engineers in mission control were observing the last stages of re-entry of the Mars Climate Orbiter, a spacecraft which was in the last final few minutes of a 10-month journey to Mars. Communications with the spacecraft were lost, and it slowly dawned on the assembled team that they would not be celebrating the culmination of a multi-year project, but instead try to figure out why the craft was lost on re-entry. The mission planners had intended for the probe to enter the Martian atmosphere within a given altitude, a Goldilocks zone where the atmospheric density was high enough to slow it down, but not damage it.

It turns out that rather than entering the atmosphere 110km above the surface, the spacecraft entered around 57 km, in a denser-than-expected atmosphere, causing it either to be destroyed or to bounce off, damaged into space. Post-failure investigations exposed that one piece of software, supplied by Lockheed Martin, a NASA contractor, produced results in Imperial Units of measurements, while a second system, designed in-house at NASA’s Jet Propulsion Laboratory, used the metric system. A NASA review board determined that the software that controlled the orbiter’s thrusters calculated the force in pounds, while NASA’s software assumed it was the equivalent metric unit, newtons per square meter. Two different teams were in effect working to different, incompatible standards, and although the contracting documentation did require Lockheed Martin to ensure that the interface to other systems used metric units, NASA failed to make th necessary checks and tests to ensure that the system worked.

Planned and Actual Trajectories – Mars Climate Orbiter

This is a very common failure scenario, where different parts of a project team fail to recognise that their constituent parts are incompatible, perhaps making incorrect assumptions, misinterpreting specification documents, or simply, as in this case, not designed to an intended specification. There are a whole host of mechanisms that can be used to prevent such issues from the catastrophic consequences suffered by the Mars Climate Orbiter, most of which involve a combination of verifying the intended designs, and testing that the integrated system works well. What was ironic in this case, is that NASA practically invented modern Systems Engineering in order to deliver the Apollo moon programme. An often inefficient approach, this requires project teams, to methodically and exhaustively decompose systems into progressively smaller systems with all functionality and interfaces between components comprehensively documented in advance. Had NASA followed its own practices (see its 275 page handbook here), then this accident would have been avoided.

Failure Cascade – America’s largest Blackout

Given that complex systems are interconnected networks of smaller components or subsystems, the impact of a failure of a component on other connected components is a crucial consideration in understanding how robust that system is to failure. Failure propagation occurs when a failure in one part of the system leads to other failures in other parts of the system, which in turn can propagate onwards. For example, the human body is an interdependent system that relies on all organs and physiologic systems working well. For example, a failure in the circulatory system can quickly impact the brain and nervous system, in turn causing failures to other organs.

When power grids and distributed computing systems (e.g. cloud platforms) often fail due to cascading failures. Typically, one relatively small part of the system fails, causing the load to be shifted to other, healthy parts of the system. In the case of power grids, this load consists of electric current, while for distributed computing systems, this will be computing load to service (for example) customer applications. This shifting of traffic is often required to maintain healthy operation, bypassing failed components, but can sometimes be the driver of catastrophic failure.

On 14 August 2003, a high-voltage power line in Ohio, USA brushed against some overgrown trees and shut it down. Normally, this would trip an alarm in the control room of FirstEnergy Corporation, the energy company operating that part of the grid, but the alarm failed. Over the next hour and a half, other lines sagged as the increased load heated them up. This caused them to soften and sag into trees. These were automatically disconnected, in turn shifting the load to yet other power lines, which had to carry even more load. Two hours after the original failure, the entire segment of the power grid failed and switched off, triggering a cascade of failure across much of north-east USA and southeastern Canada.

Satellite image of the United States on Aug. 14, 2003. (NASA). See the corner of darkness in NE US

50 million people lost power for up to two days in the biggest power blackout in American history. This was a classic case of failure propagation with positive feedback. What should have been an isolated failure instead resulted in a progressive shifting of increasing load levels on those parts of the grid that remained in operation, driving a very wide-scale failure. A lack of instrumentation meant that FirstEnergy’s technical staff were unable to identify what was happening and isolate the problem while it still could be contained. Like in an avalanche, it took a relatively small movement to trigger a much larger event.

Misunderstanding the Problem – A wobbly bridge

June 2000 saw the opening of the first new pedestrian bridge across the Thames in London for over 100 years, when to the consternation of its designers, the bridge began to sway to the extent that it was called ‘the wobbly bridge’ by Londoners. Initially, the bridge’s architects said that it was designed to have some movement as it was a suspension bridge, but pedestrians were unimpressed. “I think you need to take your sea sickness pills before crossing,” said a woman after crossing the bridge. Although initial theories focused on pedestrians walking in synchronicity, amplifying any slight wobble until it started swaying to an uncomfortable extent, more recent studies showed that this was not the case. In fact, walkers were compensating for slight wobbles by adjusting their gait, so as to keep stable. This caused a positive feedback effect that amplified any sideways wobble, even before they started to walk in synchronicity.

Although the bridge’s designers applied the commonly-established standards of the time and presumably modelled the design accordingly, they simply didn’t understand the interaction between the bridge and pedestrians. The knowledge of the biomechanics of how people adjust their stride to retain their balance and the consequent interaction with swaying platforms did not exist until a retrospective study was published in Nature magazine half a decade later. The models used by the designers simply did not reflect the forces the bridge would experience in real-world use.

Conclusion

In this post, I have aimed to take a relative broad look at how human-made systems fail. While this is nowhere near being a comprehensive analysis, hopefully, the diversity of examples used gives a sense of the fundamental systems-level concepts at play that transcends the actual application or system. Although the component-level failure is often technology-specific, be it the failure to trap a software exception or the material properties of the infamous Space Shuttle booster rockets’ O-rings at low temperature, it is systems-level design that makes the difference between a catastrophic failure and a mere blip.

Taming Chaos – the art of managing software projects

Simon Fabri — Mon, 02 May 2022 19:26:01 GMT

This post is a work-in-progress.

If you were asked what picture you associate with the term ‘project management’, you’ll probably imagine a shallow set of steps heading downwards and inexorably towards a successful project completion milestone. This is the ubiquitous Gantt chart and is as closely associated with project managers as a wrench is to a plumber. You’d be hard-pressed to find a tech manager who has not drawn many a Gantt chart, that staircase down which teams will march towards project delivery. Or will they?

Gantt Charts – The shallow steps to success?

The constraints of traditional project management

Project management evolved from operational research and systems engineering and is based on a reductionist philosophy. In other words, a complex problem can be progressively broken down into smaller and smaller constituent parts, with clear definitions, hard boundaries and clear relationships. The underlying assumption is that uncertainty within a project can be eliminated by breaking it down into parts that are small enough to be modelled with confidence. Based on this, a linear plan can be put together, including a prediction of how long the project will last and the time it will take to deliver.

Despite all the best efforts of the project management profession over decades to instil predictability in project delivery, few people who have worked in software or IT will not have experienced projects that have significantly overrun in cost or time. A study by the University of Oxford and McKinsey of around 5,400 projects, found that cumulatively, these had a cost overrun of $66 billion. For projects with a budget in excess of $15m, software projects over-ran their budgets by 66% and their schedule by 33%. 17% of these projects went so bad that they threatened the very existence of the company.

Performance of IT projects. Source McKinsey – University of Oxford

Software development is intrinsically unpredictable

So why is keeping software projects on track so difficult? The 19th century Chief of Staff of the Prussian army, General von Moltke the elder stated that ‘no plan of operations extends with any certainty beyond the first contact with the main hostile force.’ General, and later US President, Dwight Eisenhower built on this by saying “plans are of little importance, but planning is everything… The very definition of ’emergency is that it is unexpected, therefore it is not going to happen the way you are planning.’

These military leaders knew that any strategy or plans that failed to accommodate or to adapt to the unknown and the unpredictable is doomed to failure. Whilst hopefully most software projects are not faced with an adversary aiming to disrupt and destroy their progress, much like military operations, they operate in environments of high unpredictability. Most complex software projects do not follow a fixed template, which makes the estimation of effort in software pretty challenging.

In the first instance, when forecasting the trajectory a project may take, any estimate depends upon the intrinsic complexity of the required solution – i.e. how hard the problem is to solve. Often you are dependent on other systems and software, of which you will only have an imperfect understanding at the outset, which may well turn out to be wrong. Even if the project manager’s understanding is perfect, the project forecast also relies on the ability of the teams building the solution and any dependent components to implement it correctly. This may well include mastering new software tools, languages or environments. Even if all is well-known and understood, external factors often come into play – such as the reliability, quality and timeliness of dependent teams or services.

Even if all the above factors are well-controlled, you are then faced with what is often considered the number one enemy of any developer – changing requirements. The ephemeral nature of software products means that it is often difficult to predict with certainty the impact a software product has on a business’ output. You may deliver a piece of software on time and to budget, but your customers may ignore it, or even have a strong negative reaction to your carefully-crafted creation. Perhaps the market moves on, or a new feature from a competitor has shifted your customers’ expectations. Being on time and on budget does not on its own make a successful project. Your customers will be the arbiter of that.

So what to do about it?

Luckily there are a number of techniques and tools at the modern project manager’s disposal for dealing with this uncertainty. Most of these form part of the Systems Thinking toolkit, a somewhat amorphous collection of techniques, all of which are grounded in understanding a problem as a whole, rather than breaking it down into its constituent parts.

A previous post explored the characteristics of complex systems, and how systems thinking could aid in dealing with them. The Cyefin framework was used to classify problems into chaotic, complex, complicated and simple. Any software project that involves a number (say more than ten) inter-dependent teams may be considered to be complex. In other words, there are unknown unknowns. In addition to all the sources of unpredictability described above, large scale projects are often highly interdependent. Generally, dependencies are a good thing in software, as they allow teams to stand on the shoulders of giants (or at least of colleagues, partners or suppliers) and use software that is already in existence or that someone else has decided to build.

Probabilistic Modelling

One approach that can bring rigour to project management forecasting is probabilistic forecasting. As the name suggests, this uses statistical techniques to forecast the range of likely project outcomes, using the same principles of weather forecasting. So if a weather app forecasts that tomorrow there is a 64% probability of rain, probabilistic techniques can also give a similar indication of when a project or part of a project is likely to complete.

Consider its use in projects being carried out by a number of scrum teams of software engineers. Each scrum team will have a track record of how long it takes to implement work items, be they new features or bug fixes. These can be plotted as a scatter diagram of cycle times (time to implement). Given enough samples of work items, these will eventually begin to form a distribution of a discernable shape when plotted as a histogram, often in the form of bell shape. This track record can then be fed into a Monte Carlo simulation. Named after the casinos of the eponymous principality, a Monte Carlo simulation seeks to predict the range of likely outcomes by carrying out a large number of individual simulations according to the known characteristics of a model. This is akin to throwing a dice a thousand times and counting the number of times it lands on each of its sides. When applied to project management, the past behaviour of a team can be used to create a mathematical model, and then this model is simulated thousands of times to understand what are the likely outcomes.

Example Monte Carlo project simulation – How many tasks can be carried out in 30 Days. Source: ActionableAgile

Causal Loop Modelling

While statistical modelling can provide a certain degree of mathematical rigour to project forecasting, its main weakness is that it is fundamentally a static model. It does not take into consideration the changes in the human and environmental factors that influence how fast work can get done. It predicts the future based on past performance, assuming nothing changes. However, very few organisation is static, and most projects will experience all or some of the following: team members joining, leaving, organisational stress levels rising as key deadlines approach, money being thrown at problems in order to accelerate delivery dates, budgets being cut or diverted, experienced team members spending time to train and mentor new joiners and so on. Off course, much of this can be planned for, but the crux is that there are interactions that impact the overall project velocity in ways that are difficult to predict.

One way of visualising and understanding these factors is the use of system dynamics – drawing out the feedback loops at play within an organisation and the assumptions being made by the organisation’s management. These loops, known as causal loops, aim to make visible the positive and negative relationships between factors (or variables) that can influence the success of a project. For example, a fairly safe hypothesis is that a higher feature velocity can result in a larger number of defects, simply because more code is being created. However, what is the impact of increasing the number of developers on feature velocity? The answer is, “it depends.” It depends upon the related experience and skills of the new developers and the ease within which they can be integrated into the project. The LeSS (Large Scale Scrum) framework website shows a great example causal model of the factors at play in a typical software organisation. The aim of this approach is to dive deep and understand what are the fundamental dynamics that are constraining or driving development velocity. Crucially, it seeks to get to the root cause behaviour of your project and challenge assumptions, which may be deeply ingrained.

Systems Optimisation

In my opinion, the most fundamental task of a leader of a complex project is to keep a holistic (i.e. a systems-wide) view of the entire project – understanding how and when value will be delivered to customers. This means keeping their eyes focused on doing what is necessary to deliver this goal. A corollary of this is to ensure that individual contributing teams do not optimise their activities in a way that makes sense from their local point of view, but which may be detrimental to the overall success of the project. This is the over-optimisation trap.

Consider the example where a development team is creating the mobile app that is part of a wider project creating that is building a new online food delivery service. This team may focus its efforts on automating the testing of its user testing. This is a technically sound endeavour, but if the project is behind schedule due to constraints in the development of its back-end services, then this local optimisation is not only irrelevant but is also setting back the overall project. All project activities have an opportunity cost associated with them. By choosing to invest in one part of a project, you are by definition, redirecting resources from elsewhere in the project. Successful project leaders need to ensure that investment is directed to where it makes a difference and that organisational silos don’t get in the way of delivering what really matters.

Learn to Love your Dependencies

Ask anyone managing a software project what their biggest challenge is, and after the inevitable mention of resources, chances are that they’d mention dependencies – in other words, any item of work where their deliveries or success depends on others, be they other internal teams, external partners or suppliers. Dependencies are typically considered as problems to be mitigated – indeed the 2020 Scrum Guide makes no mention on how to work with other teams, while a previous version said that “cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” Not only is this nonsense, as anyone who has any experience of managing software projects of more than a modicum of complexity will recognise, but it treats dependencies as inherently bad.

It is certainly true that you should create as self-sufficient teams as possible, and iterate and self-inspect to achieve independence. Nevertheless, don’t assume that all dependencies are a bad thing. If you are dependent on other existing systems or services, be they external libraries, APIs, or any other software component, then that is fantastic news, you don’t have to build it yourself! Even if such services are paid-for, either as a one-off or licensing fee, there are many reasons why you may still be better off by using these services. If these services are built by experts in that field, then you are likely to be better off using these services.

More challenging is the case when you are dependent on other teams to do work before you can deliver your output. This could be either because you lack the resources, time or expertise to build the capability yourself. The first task is to see the extent to which these can be reasonably reduced. E.g. through architectural design practices, or by grouping as much of the expertise required to build your software in one team. Once this is done, you are left with the task of tracking and managing throughout the project. So critical is dependency management to the success of multi-team agile projects, that most agile scaling frameworks focus their coordinating efforts on managing dependencies. Scrum@Scale assigns the task of inspecting and managing cross-team dependencies to the Scrum of Scrum Master. The Scaled Agile Framework (SAFe) makes use of a program board to track dependencies, both during planning phases as well as during individual sprints. In fact, one criticism of SAFe is that it is more focused on keeping track of dependencies than on encouraging teams to be as self-contained feature teams. Whatever techniques you use, stop wishing you didn’t have dependencies, and instead embrace them. You, and your projects, will be happier for it.

References

The post Taming Chaos – the art of managing software projects appeared first on The Sand Reckoner.

Why Scaling Agile is not Easy

Simon Fabri — Wed, 08 Sep 2021 07:50:11 GMT

Ever since the Agile Manifesto was penned twenty years ago, the agile practices it inspired have slowly taken over the world. You will be hard-pressed nowadays to find a software development organisation that would not profess to follow some form of agile approach. According to the latest State of Agile Report, 94% of software organisations across a broad range of industries claim to do so.

The word ‘agile’ itself is now a core part of the modern management lexicon, forming part of MBA curricula and endorsed by the bible of modern management, the Harvard Business Review, in a 2016 article entitled “Embracing Agile.” The digital and transformation divisions of companies large and small all got on the act, cheered on by armies of consultants, and slowly but steadily, all undertook some form of agile transformation. You will thus find agile programmes in organisations as diverse as General Electric, Walmart, the UK Home Office, BP and Barclays Bank.

However, while agile slowly ate the world, something strange happened. As agile spread beyond the software team, many of its practitioners became concerned that many companies were no longer practising ‘true’ agile. Derogatory terms such as “wagile”, short for “waterfall agile” and “Fake Agile” began to be used by agile evangelists, enthusiasts and practitioners concerned about how agile principles were being diluted as they were adopted by an increasingly diverse range of teams and companies.

Not agile practitioners with different viewpoints, but 16c France wars of religion

Many of these tensions arose from the fact that ‘Agile’ had strayed far from its home territory of the individual software development team. As an example, the first principle of the Agile Manifesto, the founding charter of the agile movement states that “Individuals and Interactions should be valued over Processes and Tools.” It stands to reason that you’d value a person more than a tool, if for no other reason than common decency. But what does this principle mean in the context of an organisation of 1,000s of employees?

This raised an even more fundamental question. Does Agile even scale at all beyond the individual software development team?

The question. Does “Agile” even scale at all?

Let’s consider the crux of the problem.

Agile (with a capital ‘A’) was developed as a means to allow a single team of software developers to work cohesively, efficiently and creatively together to solve problems that were difficult to predict and to plan. From a business, or enterprise perspective, being agile (small ‘a’) is all about being highly responsive and adaptable to a changing business environment. This could include anticipating or reacting to changes in customer needs, attitudes, social norms or technology-driven disruption.

So we have two different definitions of agile – one in a team context, and another that is enterprise-wide. And these two contexts operate to very different principles, trying to achieve different aims. Team-level optimisation, efficiency and innovation on one side and business success on the other side. So when considering the question as to whether agile scales at all, there are two problems that need to be solved. First, how to scale the software development effort beyond a single team to potentially hundreds of teams, and secondly on how to align an ‘agile at scale’ technology organisation with a wider agile business.

1. Coordination – Like herding cats?

When looking to scale a development organisation, you need to consider two dimensions. The first dimension, rather obviously, is to increase the number of teams, possibly to hundreds of them. The more teams you have, the more complex the challenge of coordination is. As agile is built on self-organising teams, how do you coordinate tens or hundreds of self-teams without top-down control or coordination?

The principal two dimensions of agile scaling

Irrespective of what model you follow, unless your business can be delivered by fully autonomous and independent teams, each determining their own direction, priorities and technical strategy, you will need to find some means of providing coordination. This is one of the main aims of what many agile scaling frameworks, such as the Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) and Scrum@Scale try to achieve. For full disclosure, my personal experience in scaling agile has been with SAFe. If on learning this, you are tempted to stop reading, I invite you to persist a bit further with me.

Harnessing the joint effort of multiple teams often requires various forms of coordinating efforts, including:

Product Backlog. Ensuring that there are means for the teams’ individual product backlogs come together to meet bigger or complex needs
Architecture. Where different components and services need to work together to solve a complex problem, pulling together a common design or plan. This may take the form of an overall architecture or system design.
Portfolio. Where the teams need meet different and often competing business needs, then some means of prioritising these activities are required.
Delivery. If a business output is only achieved through the effort of more than one team over a number of iterations or sprints, then it is likely that the business will expect some form of delivery or progress reporting to give confidence that the teams activities are on track and that they are provided with any support they may require.

The most common criticism by many agile advocates against these centralising activities is that all these coordinating mechanisms can stifle agility and innovation. This is something I rather agree with, and great care should be taken to put in place the ‘minimal viable’ amount of coordinating overlay so as to maintain team-led innovation and problem-solving.

2. Longer Horizon Planning

The second dimension is the time axis. Many software teams do not belong to pure digital businesses. They exist in a context that involves physical goods, operations or people – think of a consumer product company, a travel company, an insurer, a bank, an online delivery company. All of these will need to meet fixed deadlines that are multiple sprints away, often beyond the planning horizon of an individual team, and often with fixed requirements, as for example when needing to meet regulatory and legal obligations.

While it is well and good to release software on demand, or at least with every sprint, any software development team in such companies will need to meet external deadlines. A toy company cannot miss its Christmas deadlines, a TV company must meet the broadcast date for its hit show. For complex projects, such deadlines may be many months, or even further, away. Where such deadlines exist, product development leaders are often required to provide confidence that a shippable product can be released with a given set of features by a given date multiple iterations away. This is often driven by non-digital go-to-market obligations, such as getting catalogues printed, making commitments to customers or ensuring regulatory sign-off.

SAFe makes use of bottom-up team-based planning over multiple sprints, a period called a Programme Increment, which in most implementations takes place over a three months’ period. SAFe proposes that the teams make commitments over the current Programme Increment and predictions or forecasts over the following 2 or 3 quarters, thereby providing business leaders with a view of what can be possibly achieved and committed to over a 1-2 year horizon. While this is just how SAFe addresses this topic, most scaling approaches propose some means for planning over significantly longer intervals than individual iterations or sprints.

3. Optimise the System, not the Team!

Team-level agile seeks to optimise the efficiency and optimisation of the team, by maximising the rate of innovation and development. However, where multiple teams are required to produce an output, Systems Theory dictates that by optimising the individual parts of the system (i.e. the teams), you will inevitably end up with a sub-optimal system.

I explored the principles and applications of Systems Thinking in a previous post. The key consideration is to understand the interdependencies, not just at the outset, when creating a plan, but also in terms of the dynamic positive and negative feedback loops inherent to most complex systems. This requires a holistic view of the intended design, which if spans multiple teams, cannot simply be done at the individual team level. Crucially, the aim is to optimise the experience and performance of the whole, even if it means slowing down or creating inefficiencies at the team level.

The design does not necessarily need to be done ‘top-down’ by an architect. Representatives of different teams can self-organise through design workshops or other forms of collaborative design to come up with proper systems-led designs. Indeed, the unpredictability of inherently complex systems (think autonomous driving systems in cars) are best solved collaboratively between teams, rather than to the design of a single architect or technical authority.

Not Systems Thinking – The Parable of the Blind Men and the Elephant

4. Organisation – You are not Spotify

One of the issues faced by many companies when establishing agile development of scale is how to organise the teams. One model that is gaining traction is the so-called Spotify model. Well publicised in a video on the Spotify Engineering Culture by Henrik Kniberg, the agile scaling approach adopted by Spotify has been quoted by many agile consultancies as a model that can be applied to many other companies. One characteristic of the approach is dividing a development organisation along product-oriented teams (or squads) grouped together into tribes. The was effectively a traditional matrix cloaked in goofiness.

Most definitely not a Scaling Framework – Something from Spotify

After all, if it works for Spotify, why not for your company? First of all, by all intents, this is not the way Spotify work today. For a more detailed, and somewhat opinionated assessment, read here.

But crucially, Spotify did not choose their way of working in isolation. They evolved an approach to scaling that not only matched their culture of empowerment and trust, but was also compatible with their software architecture. Spotify was born as a digital company in Sweden in 2006. Its product is streaming digital music, which is delivered globally through software. So the “Spotify Model” was a way how Spotify applied agile principles to meet a given business need in a given stage of their development of the company. It certainly wasn’t intended to become a template to be adopted far and wide by companies large and small. Simply relabeling your existing product structures into squads, tribes and chapters is not only lazy, but it will also be unlikely to work.

5. Portfolio Management

The final consideration when seeking to harness the effort of a large development organisation is the question of “what” to do and “where” to invest. I cannot even think of scratching the surface of this topic in a couple of paragraphs. This is the realm of business strategy, product roadmaps, investment planning, budgeting, and resource planning, all grouped together into some form of portfolio management discipline.

Portfolio management is often the most overlooked part of many agile transformations as it is often conflated with visions of Gantt Chart-wielding project managers and large programme offices. However, the task of ensuring that the resources invested by a company are put to good use and deliver the intended business benefits do not go away simply because you’ve ‘gone agile’. Indeed for any organisation to truly consider itself agile requires very high levels of transparency and visibility. For how can you steer course and change direction if you don’t even know where you are?

The approach that has gained most traction recently is that of Lean Portfolio Management, a discipline aimed at applying lean management principles to link business strategy with execution. There are several different flavours as to how this (see here for a good summary of the key principles), but all have the following characteristics in common:

Transparency – Make work and initiatives as visible as possible, creating as much transparency as possible
Business Value – Prioritise work ruthlessly on business value
Maximise Throughput – Reduce the work in progress in order to maximise throughput
Maintain Agility – Embrace the fact that things change, and adapt according to what works and what doesn’t

Some tips on easing scaling pains

So given all this, how can one avoid all the pitfalls in making an organisation more agile?

1. Be clear about the expected business benefits

First, unless you simply want to slavishly follow the latest management fad, ‘becoming agile’ is not a means in itself. Determine what your business objectives are and whether they would benefit from greater business agility. By example, you may define your objectives as making better use of online and mobile channels as part of a digital transformation, reducing your time to market, reducing risk by improving business agility or simply improving the efficiency of your development organisations. The starting point for any agile adoption is being crystal clear on these objectives. This is the only way you’ll be able to determine if you’ve been successful or not.

2. Determine your ‘agile’ success metrics. How agile do you want to be?

Once you’ve settled on your business goals, it is necessary to figure out whether adopting agile practices in your technology or IT departments will indeed help you meet those goals. In doing so, it is worthwhile establishing some hypotheses. For example, if your main goal is to improve your time-to-market, this may be based on a hypothesis that this will ensure an improved competitive position or reduced development costs.

In this example it is essential to put in place metrics that measure characteristics such as velocity, development predictability, rate of business value generation, release frequency etc. This will allow you to determine the effectiveness of your agile operation. This on its own does not guarantee success. This will depend on whether your hypotheses on the impact ‘going agile’ will have on your business was indeed correct.

The key point is that at the outset of an agile journey you have two unknowns. The first is whether you will be at all able to improve your development effectiveness at all. The second is that even if you do, will it have any meaningful impact on your business performance? In other words, does agility matter in your context.

3. Be honest as to the level of team empowerment you are comfortable with

As mentioned above, one of the principal sources of tension in any agile transformation is that between the centralising and control bias of most leaders and the decentralised, self-empowered ethos that underpins agile. Depending on the nature of your business, you may wish to confer different extents of ownership and accountability to your agile teams on areas such as your feature roadmap, your architectural design, your go-to-market strategy, budget ownership etc. There are often good and valid reasons why certain decisions need to be taken away from the agile teams. Being clear and honest about these can help reduce tensions within your teams. The levels of decentralisation that are appropriate for a Software-as-a-Service company built on scalable and decoupled cloud technology will be very different to achieve in a safety-critical, highly co-dependent aerospace company.

4. Understand the limits to ‘agile practices’

It is important to be crystal clear on what is meant by ‘Agile.’ In this context, I am referring to teams working together, iteratively to some recognised agile methodology, such as Scrum. The reality is that while you can apply many agile principles to other functions, such as finance, legal and compliance, customer service, procurement, logistics etc, their operational reality is that you will be unlikely to apply Scrum or any other recognised agile approach. Rather, for those parts of the business where predictability, efficiency and repeatability are sought after, then approaches such as Six Sigma are probably more appropriate.

Having defined the boundaries of the Agile organisation, attention should then shift to all the other functions and operations to identify what is causing waiting times. Typically, these will include annual and quarterly budgeting cycles, procurement and legal processes, marketing and go-to-market strategies, supplier lead times and so on. The key point is that if lead times in all the ‘non-agile’ parts of the business are not addressed, it is irrelevant how efficient or nimble your scaled agile implementation is. You would have simply optimised a sub-system and had minimal impact on the system as a whole.

Final Thoughts

In this post, I have sought to organise my thoughts on what I believe is required when running agile transformations beyond a few teams. There is no such things as ‘true’ or ‘fake’ agile. Likewise, the endless debates about which scaling framework are not only tedious, but they miss the nub of the problem. There are simply successful transformations that meet business goals, and unsuccessful ones which don’t. Nothing else matters. Hopefully, this post has provided a few pointers that will improve the odds of being in the right category.

Diversity of Thought – How to Avoid Groupthink

Simon Fabri — Sun, 28 Feb 2021 19:09:19 GMT

In 1960, shortly after being elected, John F Kennedy was approached by the CIA to approve a plan to train, equip and support an invasion of communist Cuba by Cuban exiles opposed to the government of Fidel Castro. The invasion that ensued at the Bay of Pigs became one of the major US foreign policy fiascos of the 20th century. It entrenched Fidel Castro as leader of Cuba with communism persisting in Cuba to this very day.

President Kennedy with advisors – 1962

A decade later, a social psychologist from Yale, Irving Janis coined the term Groupthink to describe the failure in decision-making that resulted in this disastrous outcome for the US. Why did some of the smartest people in US government set the country on a course that would result in such a spectacular failure? Irving found that while a number of Kennedy’s advisors harboured doubts about the course of actions being proposed, they kept them to themselves. They all knew that Kennedy wanted to overthrow Fidel Castro, and this knowledge conditioned their behaviour. As commander-in-chief and president, Kennedy had a distorting influence on the debate, with his advisors consciously or unconsciously aligning with positions that were likely to curry favour. Moreover, a ‘consensus’ culture meant that not only did his advisors feel pressure to conform but they mutually reinforced their biases, a process known as confirmation bias and ignored information that did not fit the intended outcome.

The irony is that Kennedy did try to inject an opposing view, and invited Democratic Senator William Fulbright to present an opposing perspective on the plans. However, despite clearly articulating weaknesses in the proposed plan, Fulbright was an outsider. His interventions simply galvanised Kennedy’s inner circle, who closed rank, and effectively shut down the debate.

Industry-Think and Fads

Groupthink does not occur solely in political decision-making. Whenever there is a consensus opinion in a company or an industry that is flawed but remains unchallenged, that is often an indication of groupthink at work. Consider the 2008 financial crisis. The common wisdom was that combining low-grade debt instruments associated with sub-prime housing in the US could effectively lower the risk sufficiently for them to be sold as investment-grade products. There was little consideration of the systemic risk that was being generated, not only within the banks dealing in these instruments, but also in the regulators, whose very function was to protect the economy. The Bank of England said that there is “some latent risk in relation to individual banks getting into difficulty.” That must go down as one of the greatest understatement in the over 300 years of the Bank of England.

So how do you go about avoiding groupthink?

1. Assemble a diverse group

If the cause of groupthink lies within the shared perspectives, backgrounds and expectations of the group of decision-makers, then the most obvious antidote is to ensure diversity of the group. This is not only about ethnic, gender or social diversity, but also about the diversity of background, outlook and experience. A group of accountants will take a monetary and financial outlook to a problem, so educational and professional diversity is important. When all the participants share different perspectives, then the range of options that will be considered will be broader, and the quality of the decision better. [4]

However, group diversity on its own will not prevent groupthink. As seen in the Bay of Pigs example, there is a strong human urge to conform, so members of the group who have misgivings may find it difficult to push for diverging or dissenting options. This brings us to the next antidote, to deliberately explore unpopular options.

2. Deliberately explore unpopular options

In 1973, Arab states led by Syria and Egypt launched a surprise attack on Israel on the feast of Yom Kippur, resulting in a war that brought Israel closer to defeat than it had ever been. Although overwhelming evidence was available indicating that an attack could be imminent [5], this was ignored. It did not conform to existing pre-conceptions within Israeli intelligence that given the heavy defeat suffered by the Arab states in the 1967 war, they would be unwilling to risk another war.

Following this near-catastrophe, the Israeli Intelligence Agency (AMAN) established the Devil’s Advocate office. This was tasked with providing an alternative explanation of available intelligence and challenge the established assessments. Crucially, the staff in the Devil’s Advocate Office was made up of very highly-regarded officers and analysts, and therefore couldn’t be easily be dismissed or ignored. It was intended to act as safeguard against institutional groupthink and prevent the blind spot that nearly proved so fatal to Israel in 1973.

A wrecked Israeli tank during the early days of the Yom Kippur War (Wikimedia Commons)

The lessons from Israel’s Devil’s Advocate office is not only should dissenting opinions be proferred in decision-making, but they should be done from a position of credibility, authenticity and authority. There is no point in having a Chief Sustainability Officer or a Chief Risk Offer on a company’s board if that person’s view is always in the minority and ignored. A contrarian opinion is only really useful if it is offered in a culture that both allows and encourages dissent. If the dissenting view is constantly raised from the same individuals, then it is easy to ignore and will have next to no impact on the quality of the decision.

3. Apply Divergent Thinking

Having a culture that encourages diversity of opinion is not solely valuable at a board level, but within every team in the business. One technique that can be valuable is to engage in divergent thinking. Unlike convergent thinking, the step-by-step logical process that takes you to a solution, divergent thinking is designed to generate creative ideas by exploring many possible solutions and options. Brainstorming is an approach often associated with divergent thinking, and the aim is to identify as many starting points as possible, to minimise the chance of overlooking what may be an effective way of solving the problem. Once these options are identified, the task then shifts to whittling down the options to the most appropriate for the problem at hand, using traditional analytical techniques.

Divergent Thinking – Source Divergent Thinking .Design

4. Beware the pitfalls of DataThink

You would be hard-pressed to to find any modern management handbook, consultant or tech company to want anything other than a data-driven approach. This is because, properly used data on how a company’s customers behave, their preferences, where revenue and profits are generated can bring a scientific rigour to the practice of management. However, although use of metrics can indeed be a powerful means for bringing objectivity in decision-making, it is easy to be blinded by numbers.

After all, the banks in 2008 did not lack for numbers and data. Indeed the financial instruments that proved to be the downfall of many venerable institutions were created specifically to mean certain numeric criteria. The problem was that they were all looking at the same data and drawing the same conclusions. Overly-relying on data is subject to numerous forms of bias, which if not challenged robustly results in a form of groupthink. Most data sets can be selected, analysed and presented to support radically different interpretations. As Kennedy found out, Confirmation Bias occurs when the person carrying out the analysis looks to prove a given outcome, (e.g. that their actions have resulted in improved customer engagement) rather than dispassionately testing different hypotheses. Selection Bias is when the dataset is selected subjectively, again to support a given interpretation.

The Sand Reckoner: Tech Leadership

The Product Mindset

Engineering Excellence and the Product Mindset

What is the Product Mindset?

1. A product is for life, not just for Christmas

2. Obsess about outcomes, not outputs

3. Iterate, Iterate, Iterate

4. Focus on problems, not specifications

5. Innovate on behalf of the customer

6. When platforms are products

Be wary of transformation anti-patterns

1. Product in name only

2. Product ‘paint by numbers’

3. Ignore the whole system impact

A final thought – Context is everything

References

The Fog and Friction

The Fog of War

Dealing with Friction

Seeing through the fog

1. Don’t try to predict the future

2. Recognise Complexity

3. Alternate between Zooming Out and Zooming In

4. Be Bold and Focus on Execution

5. Lean on your values and purpose

Conclusion – It’s all about execution

Further Reading

ChatGPT 4o on Satya Nadella’s take on Leadership

Creating learning organisations

The interplay between transformation and learning

Learning from your own successes and mistakes

Learning from others (1) – Benchmarking

Learning from others (2) – Open Innovation

Embrace urgency

The role of leadership

The role of the individual – knowledge sharing

Learning as a collective responsibility

Some final thoughts

References and Further Reading

Breakthrough Innovation - The role of collective intelligence

Artificial Intelligence as a Result of the Collective Brain

The iPhone – Result of Steve Jobs’ Genius or Recombinant Innovation?

Characteristics of Recombinant Innovation

Creating a culture for recombinant innovation

1. Encourage networks within your company – Break down silos

2. Focus on the outcome, not the means

3. Avoid over-specialisation

4. Encourage networks outside your company

5. Make the most of technology building blocks

Conclusion

Further Reading

Many Points of View – Why Cognitive Diversity Matters

Neurodiversity and Cognitive Diversity

Team Dynamics and Performance

Optimise for the best team, not the best individual

Further Reading

Why things break

Failure as a product feature

Failure to test – the loss of Ariane 5

Worrying about the wrong problem – United Flight 173

The single point of failure – Facebook disappears from the Internet

Silos – Left hand not knowing what the right hand is doing

Failure Cascade – America’s largest Blackout

Misunderstanding the Problem – A wobbly bridge

Conclusion

Further Reading

Taming Chaos – the art of managing software projects

The constraints of traditional project management

Software development is intrinsically unpredictable

So what to do about it?

Probabilistic Modelling

Causal Loop Modelling

Systems Optimisation

Learn to Love your Dependencies

References

Why Scaling Agile is not Easy

The question. Does “Agile” even scale at all?

1. Coordination – Like herding cats?

2. Longer Horizon Planning

3. Optimise the System, not the Team!