In Part 1 of this blog, we saw how Claude Code, despite its somewhat intimidating front-end, makes it feasible to create pretty compelling and useful software products, even by someone with pretty limited software experience. I built an AI bookmarking and research app, which I am now using in writing this blog. But what are the wider lessons? If Claude Code represents the state-of-the-art in AI coding assistants, what are the implications for software development going forward? And more broadly, what does this suggest about the way we will interact with AI agents in the future.

In this blog, I argue that as execution costs collapse, we will not be constrained by our ability to build stuff. Instead, I suggest that we will see the emergence of four key human roles that will shape the AI-augmented workplace of the future.

The 100x Economic Advantage

The cost structure of the software industry has been characterised by high up-front costs [software development costs and infrastructure], but very low marginal costs. Unlike physical products, which have per-unit material costs, there are practically no incremental per-unit costs associated with software. Replication is basically free, so the cost of adding incremental customers is largely driven by the cost of hosting and operating the software.

As a result, software and tech companies have been driven to rapidly scale the number of users to cover their high up-front costs. If, however, software can be created by AI, this no longer holds true. For example, the original team that created the Pocket app I tried to re-create was about 20 strong [1], and worked on a new version of the app for about a year. Thanks to Claude Code, I created my app over a couple of weeks for the cost of under $100. Of course, Pocket supported over 20 million customers - but the economics of software have truly been turned on its head.

It is now feasible to create curated experiences for a single customer! From a purely cost perspective, you are swapping a £100,000 per engineer salary with an approximately $50-100/month AI license. This is not an argument about the rights and wrongs of replacing human workers. It is about recognising that there is the potential to reduce the cost of creating software by a factor of one hundred.

The 10x engineering advantage

In my case, Claude Code created in excess of 11,000 lines of typescript code to create Weavify. (Yes, I know number of lines of code =/= quality or usefulness!) But what of its impact beyond hobbyists? Jensen Huang said that Nvidia uses it “all over” and “Anthropic made a huge leap in coding and reasoning, ” [2] while, reports claim that Microsoft engineers are using it in favour of, or together with its own product, GitHub Copilot. [3] By all intents, Claude’s Opus 4.5 represents a qualitative shift in the efficacy and reliability of AI code generation. Boris Cherny, the head of Claude Code, states that he uses it for all the code he creates. [4]

This shift is attributable to the way AI agents are now used. Unlike chatbots, they work on your behalf, and come back to you when it needs clarification, direction or to ask for permission to go to the next stage. They are no longer merely personal assistants. They are instead teams of co-workers. But what is the productivity advantage conferred by such systems?

It is not surprising that the AI frontier labs and Big Tech are at the front of the pack when it comes to the use of AI coding agents. Back to Cherny, he estimates that 95% of Claude Code is written by Claude Code - the tool literally building itself. The impact is difficult to quantify, and given that Opus 4.5 was only released in November, there is not a lot of data. But to get some sense, a team of 12 engineers was releasing 60-100 releases a day, including almost one external release a day. [5] The effectiveness can be seen in Anthropics’ Cowork tool, which was built “entirely” by a small team (around 5 engineers) with Claude Code within a week and a half. It is pretty unthinkable to go to a releasable preview in less than the time for a standard two-week sprint. This is pretty amazing. [5]

This step change is driven by AI coding tools shifting from being useful “auto-complete” tools and providing coding advice on point questions to being able to operate more autonomously. In an Ars Technica article, [6] a software engineer who worked extensively on the Linux kernel, said that he “now expects to tell an agent that ‘this test is failing, debug it and fix it for me.’ These are high-trust activities that have been traditionally very time-consuming. Not only can you ask an agent to do this, but you can also organise several agents to work in parallel, fixing, refactoring and optimising different parts of the code. A review of discussions on Reddit shows that engineers are increasingly confident in shifting to “refactoring large codebases” and taking over “upgrading libraries, fixing bugs, and performance improvements, freeing up time for innovative features.”

What can be achieved in small teams can be more difficult to achieve at scale. In their Q4 2025 financial report, Meta claims that since 2025, development teams have seen output increase by 30%, with power users seeing output by 80%. Looking across many tech firms, year-on-year productivity improvements in the order of 20-30% seems typical. But how can teams reach the productivity gains claimed by Claude Code?

“Syntax coding is dead” - bridging the human-machine gap

The most obvious takeaway from the latest evolution in AI coding is that the ability to write code syntax is no longer a useful skill. As Andrej Karpathy, former head of Tesla AI, put it, he now codes in English. Programming languages were always designed to act as a bridge between a programmer's intent and mental model and instructions interpretable by machines. The bridge was always incomplete; humans had to learn a “computer language” to give it instructions.

Now the bridge is complete. Humans can give instructions in English, and they can be confident of a good outcome. The Ars Technica report quotes a developer: “I still need to be able to read and review code,” he said, “but very little of my typing is actual Rust or whatever language I’m working in.” Coming back to Reddit, some developers are beginning to say that AI is now generating between 50-90% of code, and Anthropic’s own report into how AI is transforming work at Anthropic says that work has shifted “70%+ to being a code reviewer/reviser.” [7]

Looking to the future - the new categories of AI work:

I am not convinced that the role of humans as reviewers of AI output is durable. I think it is more representative of where we are today in AI maturity. As the AI agents become more reliable, I fully expect this role to be also be carried out more effectively by AI agents.

So what enduring roles will humans have in this new agentic world? My view is that there will be four key roles that will always have a strong human dimension. Let’s explore them.

1. Humans as Intelligent ‘AI Commissioners’

One thing we can be reasonably certain of is that AIs will never own assets. They will not own monetary resources, nor will they be accountable for what people do. Of course, human workers will take on tasks from AI systems, much as Uber drivers or workers in Amazon fulfilment centres do, but at the end of the day, the AI will not be the manager or ‘boss.’ The key point is that humans will remain accountable to their stakeholders (e.g. shareholders, taxpayers) for the conversion of resources into outcomes.

Humans will remain responsible for “how” AI is used. Consider a software example, where an AI coding agent is tasked to build a highly transactional social network feature in Python. It may then turn out, for example, that using Python for such applications is inefficient and consequently consumes too much cloud compute to be efficient. The service would have been profitable, had it been built in Rust, then it would have been profitable. Yes, the AI agent may have made the recommendation to use Python, but the decision rests with the person who commissions the task, the ‘AI Commissioner.’

So while many state that roles are “abruptly pivoting from creation/construction to supervision,” [6], I feel that this shift is more nuanced. A key enduring human role is to task AI systems intelligently, maintaining human accountability for the outcome. In software engineering, this means understanding the technical architecture choices that best match your needs. Are you building for one customer or 100 million customers? What is your business model? What are your per-unit costs? How will you market it? What will be your distribution model?

The Intelligent AI Commissioner role can be applied to all industries. In customer service roles, how do you specify and build systems of AI agents that create a great customer experience? If you create inconsistent, poor experiences, that is not the fault of the AI system, but of the people who commissioned, supervised and validated it. Think of law firms: their rules-based, document-based ways of working are natural territory for LLM disruption. However, despite how automated the system is, the legal accountability for the advice given will remain with a human. So, whether you are running a traditional law firm, where LLMs are used to help review and draft documents, or building a fully AI-based legal practice, it will always remain to humans to set the parameters of the service being built, and take legal accountability for the outcome.

2. Humans as ‘Human-AI Orchestrators’

One evening, while building my app, Claude Code got stuck in a rabbit hole. It was trying to debug a problem in the deployed version of the code, and kept to-ing and fro-ing, consuming tokens and failing to fix the problem. It was only when I established (with the help of Claude.ai) a clear workflow (see the Annex in the previous post) and mandated that Claude Code follow it, that we were able to fix the problem.

As I mentioned, much of the literature states that humans should be supervisors of AI. I don’t think that the term ‘supervisor’ does it justice. In this case, I was setting up the rules and the guidelines that I wanted my AI agents to follow when carrying out their tasks. As the person paying the monthly Anthropic bill, I am accountable for that spend. If Claude Code burns through tokens in ways I do not understand, then that is on me. By creating and enforcing a workflow and deployment strategy, I was taking ownership of the problem. I was not simply supervising; I was orchestrating the behaviour of my AI agents.

The orchestrator roles become critical when coordinating humans and agents within a single workflow. For example, the Claude Code team documents and maintains a workflow document (CLAUDE.md) that sets the rules by which the coding agents need to follow. Implicitly, this also guides the human software developers - thereby acting as a glue, a common playbook for the human-AI workforce. In software applications, this means understanding and owning your software development pipeline, ensuring that your development tools (CI/CD, repositories, test automation, etc., collaboration, documentation etc.) are designed and set up to work well for mixed human-AI teams.

The complexity of this orchestration is what is currently holding back the rollout of agentic AI systems. In a previous post on the future of work, I wrote how less than 10% of firms were scaling AI systems outside of a single functional silo. This is not a problem that is restricted to the digital domain. A recent McKinsey report [8] describes how most human jobs consist of automatable and non-automatable tasks. The non-automatable tasks may include those that require physical activities (e.g. in construction), human-to-human interaction (e.g. in healthcare) or have a level of accountability that is difficult to delegate to an agent or robot (e.g. regulatory tasks, or human supervision). The orchestration role will involve creating workflows that work across humans, AI agents and robots.

The McKinsey report describes some imagined scenarios, including a buildings materials depot. This is very much in the ‘physical’ world end of the spectrum, but you can see how the workflow will include AI agents managing inventory and ordering materials, providing tailored customer advice, humans building customer relations and supervising the store, and robots transferring and loading materials. In another example, Jason Lemkin, the founder of SaaSTt, the largest community of SaaS (Software as a Service) events, describes how his company replaced a team of approximately 10 human sales and business development staff with a team of 2.5 people supervising 20+ agents. [9]

So irrespective of whether your workflow is fully digital or crosses into physical or human interactions, Human-AI Orchestrators will be key to your success. The AI orchestrators will be responsible for designing, integrating, managing and maintaining these complex systems. These are very much the CIO and CTO teams of the future.

3. Humans as ‘AI Validators’

We now close the “accountability cycle” by validating the output of AI or hybrid human-AI teams. I am not talking here about the act of carrying out the review and testing of AI outputs. Although we have seen how software engineering teams are now spending more time reviewing output, I believe that this is a transitory step, and before long, we will be relying on AI agents to test and validate outcomes.

I am instead referring to the socio-technical process by which an organisation ensures that its outcomes, and the processes used to create them, meet its customer expectations as well as its regulatory and compliance obligations. Customer expectations cover a broad range of considerations. In an aerospace components company, it is ensuring that the component you are creating meets the needs of the broader system (be it an aeroplane or a spacecraft), and is compliant with all the applicable and typically rigorous regulations. In this context, AI Validation is therefore an intrinsically human (and organisational) function. It ensures an AI-enabled outcome is acceptable and lawful for its intended use—i.e., it meets safety, regulatory, ethical, and customer obligations—and that there is contestability and redress when it fails. In healthcare applications, the medical professional responsible for your care remains accountable for your well-being, even if they may be using AI-supported diagnosis and treatment tools.

The key limitation of the current crop of generative AI algorithms are optimised to give statistically ‘most likely’ outcomes, which are not necessarily technically correct. There will therefore always be a role for humans to act as a person responsible for the outcome, and often this will have legal implications. I will certainly not offer any legal analysis, as I am not qualified or experienced to do so. That said, most jurisdictions, including the UK [10] and the EU, do not recognise AI or IT systems as being legally accountable entities. Instead, named individuals typically are expected to hold the role of the named “Validator”, being responsible for the outcomes of automated systems, whether it involves personal data, financial outcomes, safety-critical systems or healthcare outcomes. For example, the UK’s Information Commissioner’s Office sets the standard of “meaningful human review” when personal data is processed in a way to have significant outcomes. [11]

To be clear, people involved in AI Validator roles are not just the people who hold accountability for the systems, but those designing, maintaining and operating the systems that ensure the correctness of outputs and acceptability of outcomes. Examples are the chief engineer signing of declaration of conformity, or the Clinical Safety Officer in a healthcare setting. AI Validators are responsible for classifying risk, defining acceptance criteria, designing and maintaining verification tests, maintaining audit trails, and managing governance, including potentially review and rectification mechanisms.

4. Humans as ‘AI Innovators’ - A golden age of innovation?

AI tools are having two major disruptions on knowledge work. First, they are “work displacement” actors - replacing tasks previously carried out by humans with AI agents. Secondly, as described above, they are radically reducing the cost of producing complex outputs, such as software systems. As AI technology advances, there is no reason to believe that other fields of engineering, biotechnology, materials science, medicine, and the creative arts will not also see a collapse in the cost of ideation.

In all engineering and tech organisations that I have worked for, output has been constrained by engineering capacity. This, increasingly, is no longer the key constraint, and I believe we are entering a golden age of invention. Let me explain. The product development process is an iterative process. These can range in scale from Apollo Moon launches to the Build-Measure-Learn cycles popularised by Eric Ries’ Lean Startup methodology. The speed of product development has been traditionally constrained by the time to build and test systems. The “learning” bit - the act of figuring out what changes, pivots, optimisations, experiments to carry out to create a better outcome has, in my experience, rarely been the limiting factor. But remove that constraint, as I experienced when creating Weavify, teams can now innovate without the handbrake on.

This opportunity is largely overlooked, as most discussion on AI adoption appears to focus on the productivity and efficiency gains that hybrid human-AI systems can produce and the sheer difficulty of creating reliable human-AI workflows and systems. Even Google is focusing on metrics such as developer velocity, reducing toil and enhancing code quality. It is therefore not surprising that the prize of all this, an explosion of human creativity, is being missed. As the cost of running experiments falls, so does the cost of failure. You start to run out of reasons not to be ambitious in your ideation.

Your constraints shift “left” and “up” in the product development cycle. You are now limited by “early-stage” activities - such as product ideation, creativity, access to data, and the ability to carry out experimental A/B testing on real customers. Additionally, as the ability to move fast increases, then so does the importance of having a coherent strategy and what your core proposition is. Otherwise, it is too easy to get lost in the “noise” of multiple iterations. The risk here is not so much a lack of ideas or number of development cycles, but a lack of coherence. This makes strategic clarity, and human judgement, more, not less, critical.

AI Innovators will therefore be entrusted with the responsibility of steering these faster development cycles. Today, we typically call these roles product designers, product managers, scientists or innovators. I suspect that these roles will remain particularly well suited to human intuition for two main reasons. First, they operate in a space where there may be a lot of data about existing and previous products or iterations. However, innovation is the act of envisaging imagined futures, something on which little data exists, and consequently, prediction algorithms may struggle with. Secondly, these roles rely on understanding human needs, both expressed and unexpressed. Again, AI tools can help, but I am not sure they will be in the driving seat.

In a blog on the Product Management in the Age of AI, Brian Balfour, CEO of Reforge, an AI customer analysis company states, “The yearly strategy cycle makes no sense in this environment anymore, given how fast things are changing and speeding up… Leaders will be steering ships moving at 10X the speed before.” [13] I couldn’t put it better. If your velocity is 10X higher, then this must be matched by strategic clarity and rapid decision-making.

Conclusion

In this blog, I have tried to extrapolate what this inflection point in the performance of AI coding means for the future of work more generally. The most commonly used lenses - namely analysing which tasks cannot be automated, misses the mark. Additionally, the oft-used paradigm of humans as supervisors and AI as builders, while true, is somewhat simplistic.

What I have tried to do is ask an altogether more useful question. As the act of “building things” becomes cheaper, where will the uniquely human attributes of human connection, intuition and accountability continue to have enduring value in a world dominated by AI. My argument is that these attributes become more, or less valuable, and will be concentrated in four types of roles.

While we are seeing the first signals take shape in software development, I suggest that these four roles, or versions of them, will emerge across multiple sectors and industries. This is not a prediction on what specific jobs will emerge in the future. It is a framework of how to think about the reshaping of the workforce and the roles of humans within it

Further Reading

1. METR, Measuring AI Ability to Complete Long Tasks, Model Evaluation & Threat Research (METR), March 2025

2. Haider M., Nvidia CEO Jensen Huang Calls Anthropic’s Claude ‘Incredible,’ Says Every Software Company Needs To Use It, Yahoo Finance, January 2026.

3. Anthropic, “How Anthropic teams use Claude Code”

4. Wired Staff, Claude Code Is a Big Success—and a Test of Anthropic’s Business Model, Wired, 2025

5. Orosz G., How Claude Code is built, The Pragmatic Engineer, September 2025

6. Edwards B. Developers say AI coding tools work—and that’s precisely what worries them, Ars Technica, February, 2026

7. Anthropic, How AI is transforming work at Anthropic, December 2025.

8. Yee et al., Agents, Robots, and Us: Skill Partnerships in the Age of AI, McKinsey & Company, November 2025

9. Saastr Staff, Stop Learning AI, Start Doing AI: The 20+ Agents Running SaaStr, SaaStr, 2025–2026

10. UK Department for Science, Innovation & Technology, Implementing the UK’s AI Regulatory Principles: Initial Guidance for Regulators, February 2024.

11. UK Information Commissioner’s Office, How do we ensure individual rights in our AI systems?

12. Langley H., An internal Google project is trying to supercharge employees with AI. Codename: Project EAT., Business Insider, 29 January 2026

13. Belfour B. et al., Moving To Higher Ground: Product Management In The Age of AI, Reforge Blog, March 2025.

14. Morrone M., Anthropic’s viral new work tool wrote itself, Axios, January 2026

This will be a two-part blog. This post will run through my experiences with Claude Code, getting a sense of what it can do today. In Part 2, I will consider Claude Code says about the state of AI more broadly and what it means for the work of the future. Let’s go!

What others are saying

The excitement about Claude Code feels somewhat breathless. Andrej Karpathy, part of OpenAI’s founding team and previously director of AI at Tesla, said, “Given the latest lift in LLM coding capability, like many others I rapidly went from about 80% manual+autocomplete coding and 20% agents in November to 80% agent coding and 20% edits+touchups in December.” Jaana Dogan, a principal engineer at Google, claimed that her team built a distributed agent orchestrator in one hour, a problem they had been working on for a year. Similarly, Boris Cherny, the head of Claude Code at Anthropic, said, “Pretty much 100% of our code is written by Claude Code + Opus 4.5. For me personally it has been 100% for two+ months now, I don’t even make small edits by hand. I shipped 22 PRs yesterday and 27 the day before, each one 100% written by Claude.”

So clearly something is afoot. Whilst these claims cannot be independently verified, the excitement feels real, somewhat reminiscent of what happened when ChatGPT was launched in 2022.

The project - introducing Weavify

So how difficult would it be to build something genuinely useful? I settled on an AI bookmarks and research assistant app. Until a year or so ago, I used to use Mozilla’s Pocket bookmarks app to tag web content that was interesting to read later. Mozilla then discontinued this product last summer, and I had not been able to find a suitable alternative. How about if instead I ‘vibe code’ my own app?

I started by having a think of what I’d want. Yes, I’d want bookmarking capabilities and the usual features to organise content according to projects (e.g. blogs I was thinking of writing), tagging, etc. But why not add AI-enabled features? So I started to scope an app that would allow me to add bookmarks (using a Chrome extension initially). It would auto-categorise, suggest tags, and create Twitter-like summaries. Once collated, it would also create summaries of my collated bookmarks, extract key themes, suggest topics and articles for further reading, and organise the bookmarks as neat citations. Yes, I know that Google’s NotebookLM already does much of this.

First Impressions

Well, Claude Code is initially a bit intimidating. Its text-based CLI is somewhat reminiscent of the 80’s TV Teletext service. At times, however, first impressions can be deceptive. As it is a CLI, accessible through your computer’s terminal, it effectively operates on your behalf, accessing and changing files, installing software and so on. It very much looks like a programmer’s tool, because it is indeed a programmer’s tool.

Anyway, what did I learn from working through this?

1. AI chatbots - your trusted advisors

Claude Code is optimised for “doing” stuff. All the coding, building, testing and so is carried out by Claude Code. So, given that I wasn’t quite sure where to start, Anthropic’s AI chatbot, Claude.ai can provide a great starting point. It will help you through coding and deployment options, explain how to use Claude Code etc. By having these speculative conversations about pros and cons in a separate ‘sandboxed’ chatbot, I felt confident that I was not driving Claude Code down unintentional rabbit holes.

2. Documentation over Code

The Agile Manifesto, the seminal set of principles of modern software development, famously recommends prioritising the creation of code over documentation. I’d suggest that when working with AI coding agents, the reverse is true, at least for the human supervisor. Let me explain. First, the success or failure of AI coding is driven by the quality of its inputs. Bad inputs give bad outputs, with all code generated being predicated on the quality of its inputs. I learned that it is essential to get these right. In my case, I used a Product Requirements Document and an Architecture Specification. This helped ensure that Claude Code and I were on the same page. It uses the code produced and the associated documentation as their input context. The documents effectively act as a signal of intent, and the principal way I could steer the direction of travel of my app.

3. Slop is a Human Artefact, not an AI Artefact

Much has been said, with reason, about how AI slop is taking over the world. Whether it is all those inane videos on TikTok, AI-generated self-promotion on LinkedIn, AI-generated E-books and so on. However, in coding, it is the human who is responsible for slop. Here’s why. Give Claude Code, or indeed any generative AI tool a vague, generic question, then you will get a generic output. Generative AI algorithms are designed to create outputs most likely to elicit positive feedback from humans, so they tend to create statistically “average” outcomes. They can be fluent, polished, and coherent. But they are rarely distinctive.

The same is true for AI coding. Give it a vague input, and the tool will create a middle-of-the-road, “best fit” answer. It will have no implicit understanding of the nuance of your needs nor of your customers’ drivers, and so it will create something that works, but that is also pretty generic. In other words, slop. The more specific you are, the more context you can provide Claude Code, the better it can help you, and the more distinctive and useful the output can become.

4. Planning Mode - who is the intelligent being in this relationship?

Claude Code offers three modes of operation: Ask, Plan and Code. In Planning mode, you are guided through the process of creating the input artefacts, primarily the requirements document. This is where it becomes really interesting, as you can ask Claude Code to ask you clarification questions. Claude will refine its understanding of your intent by asking you several questions, asking for your preferences, or instead to suggest alternatives. It is designed to specifically surface trade-offs. Some may be architectural - e.g. what is the authentication strategy for the app, some may be usability related -e.g. do you want a ‘one-click’ bookmark feature for the app.

This is where your fundamental user insights come in. Here you are firmly in the role of product manager, working with a product development team, guiding them through the implications of what you are asking for, whilst asking probing clarification questions. Sometimes I did not understand the implications of the tradeoffs being proposed, but a quick chat with Claude.ai quickly solved that problem.

What ensues is a very involved back-and-forth with Claude Code, where you are iteratively refining and clarifying intent. Again, this is the heart of what’s been described as “coding in English.” I must say that I found this experience pretty spooky. It is somewhat of a role reversal compared to using a normal AI chatbot, where the user is the one asking the questions and guiding the conversation. Now, the AI is the interviewer. It patiently figures out the detail of what you have failed to articulate clearly, as well as surface implications or considerations that you have not yet thought about. This was probably the most impressive aspect of the Claude Code experience, but also somewhat chastening, providing a glimpse of what interacting with truly agentic systems might feel like.

5. Plan and Iterate - Your “house rules”

As I mentioned, while getting a great plan in place is essential for success, all the principles on how to approach creating a viable piece of software remains valid. For example, Claude.AI suggested how best to chunk up the development, starting with the architectural fundamentals - getting the Google Authentication system working, creating the databases for storing the content, establishing the secure storage for secrets, and so on. This allows you and Claude Code to take controlled, incremental steps towards your intended outcome. Yes, many people indeed claim that you can create an app in a single shot, and I have no reason to doubt it. It can, however, be an expensive and time-consuming exercise to undo, refactor etc. Better, in my mind, to take it step-by-step, and build from the ground up.

And this brings us to a key point. With Claude Code, you are in control of the development approach. Detailed planning up-front or step-by-step iteration and experimentation? It is up to you. Effectively, if you wish, you are in control of how you carry out the development. The tool for doing this is claude.md, which are effectively the “house rules + how we work”. This lets you shape what effectively is your personal or organisation-wide methodology, covering how you will document your work, the approach to testing the code, how to commit code to your git repository, your approach to security etc.

6. Fast creation, slow fine-tuning. Don’t talk about cost!

My experience creating this one-off app has been that getting the functionality off the ground was really quick. Once you have clear requirements, Claude Code can make really quick progress in generating a pretty decent first stab of your product iterations. It feels like you are flying, and quite mesmerising, seeing Claude deploy multiple agents in exploring and shaping different parts of the plan, as well as seeing it go through the process of creating code, building, testing, debugging, fixing, etc. In practice, there are different subagents working on different tasks, but there is nothing stopping you from creating different agents manually.

And so all is bliss, until you get to the point where the product is nearly right, but not quite perfect. So you start fine-tuning, implementing small corrections, going back-and-forward, and then you see your token count rise. And this is where time and cost, gets burned. Not only in fine-tuning your product, but in working through the edge-case defects that stop it from being truly production-ready. Granted, this was only my first attempt, but I got to 80% to where I wanted to be in 2 or 3 evening sessions, and then spent more than that amount of time doing final debugging. My $20/month Claude Pro plan was not quite sufficient to meet my desire for progress, particularly when, in the depths of debugging, I found myself occasionally topping up, rather than waiting for my next quota of usage.

In conclusion

Here’s the web version of Weavify. It also renders quite nicely in a mobile view, though that is something I only thought of later, and so had to refactor the UI. The app works really well, and is now genuinely useful. I will reflect on what I think this means more broadly in Part 2 of this post, but for now, I feel equally excited and anxious. The experience has felt like working with a team of really-enthused expert engineers. Engineers with the tenacity to keep going and persist through errors, patiently seeking alternative approaches, and with the empathy to ask sensible questions, curious, but never sneering.

It therefore feels really invigorating. For all the talk of AI leading to cognitive laziness, I feel I have learned a lot more about the practicalities of building real-world apps in a couple of days than I have in a long time. It is empowering. Anyone, be they engineers, product managers, founders, or senior execs, can now experiment with ideas in a fraction of the time it would otherwise have taken. This is doubly true for anyone who hasn’t got the hands-on skills to create useful code themselves - much like yours truly. Yet, at the same time, I feel a slight sense of unease. Claude Code is giving glimpses of what the future of work may be, and it’s not something I believe we are prepared for. For more of that, wait for Part 2.

Further Reading

1. Mollick, E., Claude Code and What Comes Next, One Useful Thing, January 2025

2. Beck, K. et al., Manifesto for Agile Software Development, Agile Manifesto, February 2001

3. Yip, C., Claude Code: Ask User Question Tool Guide, AtCyrus, 2024

4. Anthropic, Claude Code Best Practices, Claude Code Documentation, 2024

AI-Generated Annexe: The Technology Stack behind Weavify.

Author: Claude.ai Opus 4.5

Note, this section is completely AI-generated from the Weavify project documents. It describes the technology stack and the build workflow used to create the app.

Summary 1: The Technology Stack Behind Weavify

Weavify is a full-stack web application that combines modern frontend frameworks with AI capabilities to transform how users organise and understand their saved web content. Here’s a look at the technologies that power it.

The Foundation: Next.js 14 and TypeScript

At its core, Weavify is built on Next.js 14 using the App Router paradigm. This choice enables server-side rendering for optimal performance while maintaining the flexibility of React 18 components. TypeScript provides end-to-end type safety, catching errors at compile time rather than runtime. The styling layer uses Tailwind CSS for rapid, utility-first development.

Data Layer: PostgreSQL with Prisma

The application uses PostgreSQL as its database, hosted on Supabase for managed reliability. Prisma serves as the ORM, providing type-safe database queries that integrate seamlessly with TypeScript. This combination ensures data integrity through foreign key constraints while maintaining developer productivity with auto-generated types.

Authentication: NextAuth.js v5

User authentication is handled by NextAuth.js v5 (beta) with Google OAuth. The system uses JWT session strategy for Edge Runtime compatibility, storing sessions in secure httpOnly cookies. This approach balances security with the performance benefits of serverless deployment.

The AI Engine: Multi-Provider LLM Support

One of Weavify’s standout features is its multi-provider LLM architecture. Rather than being locked into a single AI provider, the system supports OpenAI, Google Gemini, and Anthropic Claude. Users can configure their preferred provider and even select different models for different tasks—using a cost-efficient model for categorisation while reserving more capable models for summary generation. API keys are encrypted at rest using AES-256-GCM, ensuring security without sacrificing flexibility.

Layered Architecture

The codebase follows a clean four-layer architecture:

• Presentation Layer: React Server Components by default, with Client Components only where interactivity is essential

• API Layer: RESTful routes with Zod validation and consistent error responses

• Business Logic Layer: Pure service classes containing domain logic, decoupled from UI concerns

• Data Access Layer: All database operations flow through Prisma, maintaining a single source of truth

Cross-Platform Reach

Beyond the web application, Weavify extends its reach through a Chrome Extension (Manifest V3) for one-click bookmarking and PWA support for mobile devices. The Android share target integration allows users to save bookmarks directly from their phone’s share menu.

This technology stack prioritises developer velocity for solo development while maintaining the architectural patterns needed for future scalability—a practical balance for ambitious side projects.

Summary 2: From Code to Production: Weavify’s Development Workflow

A Three-Tier Testing Strategy for Reliable Deployments

Deploying a full-stack application with AI integrations, database connections, and authentication flows requires careful validation at every step. Weavify uses a structured three-tier testing strategy that catches issues before they reach production.

Tier 1: Local Development

The first line of defence is the local development environment. Running npm run dev starts the Next.js development server with hot reload for rapid iteration. At this stage, developers can work with local environment variables and either a local PostgreSQL instance or a development database branch. This tier is optimised for speed—making changes, seeing results immediately, and debugging with full access to the runtime environment.

Tier 2: Vercel Development Environment

The second tier simulates the production serverless environment locally. Running vercel dev spins up an environment that mimics Vercel’s serverless functions, using production-equivalent environment variables. This catches issues that only appear in serverless contexts—cold starts, function timeouts, and environment variable loading. If something works in Tier 1 but fails in Tier 2, it’s almost certainly an environment or serverless-specific issue.

Tier 3: Preview Deployments

Every pull request automatically generates a preview deployment with its own unique URL. This full cloud deployment allows testing in the exact production environment before merging. Stakeholders can review changes, integration tests can run against real infrastructure, and edge cases that only appear in production can be caught early.

The Mandatory Workflow

Before any code reaches the main branch, a strict checklist must be passed:

1. Build Verification: npm run build must complete with zero errors

2. Lint Check: ESLint and TypeScript validation must pass

3. Database Verification: If schema changes are involved, Prisma migrations must apply cleanly

4. Local Testing: Manual verification in the development environment

5. Vercel Dev Testing: Serverless function validation

6. Documentation Updates: Any architectural or API changes must be documented

Only after all checks pass does the code proceed to commit and deployment.

Deployment Automation

PowerShell scripts standardise common operations: deploy-preview.ps1 handles preview deployments with pre-flight checks, while deploy-production.ps1 runs full validation before production releases. Environment variable synchronisation is handled by sync-env.ps1, ensuring local and cloud environments stay aligned.

GitHub Actions provides CI/CD automation—linting and building on every PR, posting preview URLs as PR comments, and enabling automatic production deployments on merge to main.

Rollback Strategy

When issues slip through despite all safeguards, the rollback procedure is straightforward. Vercel maintains deployment history, allowing instant promotion of any previous working deployment to production. For code-level rollbacks, git revert creates a new commit that undoes problematic changes while preserving history.

The Philosophy

This workflow embodies a simple principle: never leave the codebase in a broken state. Each tier catches different failure modes, and the mandatory checklist ensures no steps are skipped under deadline pressure. For a solo developer managing a complex application, this structured approach transforms deployment from a source of anxiety into a reliable, repeatable process.

Niels Bohr famously said that making predictions is hard, especially about the future. So I am definitely not going to set off on a fool’s errand and try to figure out what lies ahead in 2026 from an AI perspective. I will, however, consider the themes that may be significant as the world navigates the implications of wide-scale adoption. These views are, as always, my own, although I will draw on observations made by others, adding links for further reading.

Now with an (AI-generated) companion podcast. Give it a try.

In this post, I explore what may happen to AI demand (a rather obvious outlook) and the resulting implications for the evolution of AI compute and data centres. I then touch on a favourite topic of mine - AI interpretability and explainability (and their limits), and whether this will have any impact in the roll-out of properly autonomous agentic workflows.

1. Jevons Paradox. A model for AI demand?

In a recent blog, Aaron Levie, the CEO of Box, argued that AI adoption will follow the pattern known as Jevon’s Paradox. William Stanley Jevons was an English economist at the time of the Industrial Revolution. He noticed that improvements in the efficiency of coal use drove up demand for coal, rather than decreasing it. Where output is constant, the use of more efficient technologies should reduce the demand for raw materials (e.g. making cars more fuel efficient). However, it also reduces the cost or barriers to entry of using technology, and hence demand instead increases.

We have seen this pattern numerous times, such as the transition from mainframe computers to PCs, the adoption of faster Internet connections and the availability of cloud computing. All these technologies not only made existing processes more efficient, they were also intrinsic drivers of brand new ways of using the technologies. Faster Internet did not just mean quicker email; it created the online gaming and streaming industries.

Levie is highly likely to be right that looking at AI demand through the prism of existing use cases is to miss the point. AI agents will dramatically lower the barrier to entry to the automation of non-deterministic tasks. Earlier this year, Stanford economist Erik Brynjolfsson explored the implication of Jevons Paradox. He argued that for some professions, productivity will be transformed, which will result in lowering the cost of their output, which in turn will increase the demand to the lower prices offered. It is the last point that is critical. Take the case of software developers. If their productivity increases 10-fold, will this result in an explosion in demand for more software development? Time will tell. What it certainly will do is shape how AI compute is structured.

Read more:

Levie, Aaron. “Jevons Paradox for Knowledge Work.“ LinkedIn, December 28, 2025.

• Rosalsky, Greg. “Why the AI world is suddenly obsessed with a 160-year-old economics paradox.” NPR (Planet Money), February 4, 2025.

2. What Training / Inference Mix are we heading towards?

The growth in AI data centre construction is straining industries as diverse as construction, energy supply, AI chips, networking equipment, and most recently RAM. Much of the attention has been focused on the demand required by frontier labs such as OpenAI to develop and train the latest generation of AI models. However, AI model training is only half of the AI compute mix, with the other half being inference - i.e. using AI models to solve the tasks assigned to it.

The mix of AI workloads matters -a lot. Training of large frontier models makes use of enormous data sets (at least hundreds of terabytes) and several millions of compute hours of high-end GPUs to create models with trillions of parameters. This is what has been driving the adoption of the highest-performing GPUs, as faster processors and larger clusters shorten the model training, experimentation, development and validation time. These workloads are large, complex, and require a lot of orchestration. They are typically bursty as the AI labs pass through different phases of their development.

However, as the AI industry begins to mature, the compute requirements for AI usage (i.e. inference) will overtake the demand for training. Already, reports by McKinsey and Deloitte estimate that global AI compute usage is roughly split 50/50 across compute and inference. The dynamics of inference compute are very different to training. When solving an AI task, what is important is latency (i.e. the round-trip time to process a query) and cost. Therefore, inference workloads are characterised by billions of small requests, creating a lot less bursty traffic profiles, optimised for user experience.

So what are the implications of this? As companies will seek to shift from growth to sustainable profits, cost and latency will be the two driving factors to enable them to scale as more efficiently as possible. We are therefore likely to see a split in hardware towards GPUs optimised for large-scale training loads, and hardware optimised for real-time, low-latency inference loads.

The early stages of the generative AI boom has been optimised for development speed - how fast can the frontier labs develop, train and optimise their models and gain an edge on their competitors. Training clusters are therefore optimised for very high levels of parallelism and cluster-scale efficiency in order to train very large models, with networking and memory capacity also optimised for highest bandwidth operations possible. Similarly, as training typically operates in very large batches, reliability is a key concern. On the other hand, inference fleets run continuously, as they pool together requests from a very large number of users. They are therefore optimised for cost per token, which means high concurrency, utilisation efficiency and optimising power consumption.

This mix matters as it will shape the compute mix in future AI data centres across NVIDIA-style GPUs or Google-style TPUs, and where the data centres are located - whether closer to where power is available or closer to where the user is.

Read more:

Stewart, Duncan et al., “More compute for AI, not less.” Deloitte Insights, November 18, 2025.

Arora, Chhavi et al., “The next big shifts in AI workloads and hyperscaler strategies.” McKinsey & Company, December 17, 2025

3. Will AI become more explainable?

At heart, modern generative AI models are non-deterministic ‘black box’ systems. In other words, the output for a given input (e.g. a prompt) will be different each time the model is run, and it is not possible to work through the internal reasoning. This is due to the inherent structure of the most generative AI models. Individual concepts or pieces of data are not localised in individual areas of the AI model, such as a neuron or parameter, but are instead spread in connection patterns across large numbers of parameters. Furthermore, modern AI systems are multi-layer (or multi-step) systems where the final output is produced by a long chain of intermediate non-linear steps. This means that it is intractable in practice to work backwards through the ‘reasoning’ process, or even to work back to the source training data that contributed to the response. In a nutshell, AI systems are typically “emergent” rather than designed, so that their inner workings are difficult to understand.

Why does this matter? First, for any high-stakes application, such as safety-critical applications, health applications or where there are large financial implications, even a small number of mistakes can be harmful. The very fact that you cannot explain how a system came to make a decision is a blocker to its adoption on legal, regulatory or ethical grounds. Similarly, the opacity of models means that there is no way to detect if the models or their training data have been tampered with maliciously, meaning that it is difficult to trust them. The core question is that as the capabilities of AI systems continue to improve, the risk implications of their lack of explainability will continue to grow. For example, how can we check if an AI is being devious?

In a way, we are beginning to make some progress. “Chain of Thought” (CoT) processing, which involves AI systems decomposing problems into a sequence of prompts, can give indications on the approach taken to solve a problem. e.g. “scope the problem, search for references, categorise and remove duplications, etc.” Howeve,r the inner workings of each individual step remain obfuscated.

Much current research focuses on mechanistic interpretability, in other words, mapping the internal connections of the model. Other promising approaches, such as the use of Sparse Autoencoders - i.e. decomposing groups of neurons that activate on many features to maps of neurons that activate on individual features- are starting to be applied to large LLMs. [see below for a description of how they work]. The third main category, called neurosymbolic reasoning, combines neural-network-based learning with logic-based reasoning. Whilst the neural parts remain a black box, these models have applicability in constrained, rules-based applications.

In a nutshell, while 2025 has seen some breakthroughs in interpretability and explainability, no approaches have yet made it into mainstream LLMs, due to a combination of intrinsic model architecture constraints and cost efficiency. It is clear however, that the demand for solutions in this space will only continue to grow, particularly as AI systems are allowed to act more autonomously

Read More:

Dario Amodei, “The Urgency of Interpretability”, April 2025

Hussein N. et al., “Mapping LLMs with Sparse Autoencoders”, People + AI Research (PAIR), Google, October 2025

4. How should we manage autonomous AI?

2025 has seen the first implementations of AI agents - where AI instances have some autonomy in the tasks they carry out. Probably the space where their use is most widespread is in software development, where tools such as OpenAI’s Codex software development agent and GitHub Copilot Workspace are seeing AI tools take on a greater share of tasks across the software development lifecycle. However, we are still in the very early stages. A survey published by McKinsey in November found that less than 10% of large firms are scaling the use of AI agents in any given function. So while adoption of AI is growing, it is predominantly driven by individual workers using it as an assistant to carry out their individual tasks.

To be clear, the direction of travel in the development of AI agents will result in AI-enabled systems that can observe, plan, act, respond and iterate over prolonged periods with limited human interaction. When AI is used as an assistant, there is, by implication, always a human in the loop. However, in agentic implementations, humans are no longer implicitly within the workflows, a shift from the Copilot Model to the Autopilot Model. This can have a number of implications.

First, coming back to Jevons’ Paradox, we truly enter the territory of exponential growth. We are already seeing implementations in systems consisting of easy-to-characterise rules such as customer support centres, enterprise workflow and finance operations. As the technology becomes more accessible, we will see agentic deployment in a broader range of business functions. The incremental cost of adding a new agent will be low compared to the potential benefits of adding one more agent - certainly a fraction of the cost of a human worker. Companies that manage to master multi-agent orchestration will gain a compounding advantage. They will therefore have a strong incentive to deploy as many agents as technically possible. The possibility therefore, exists of an explosion in size of agentic systems.

This will likely change the nature of work, with more roles dedicated to oversight and supervision of AI agents. We are all familiar with the “span of control” problem when managing human workers. How many AI agents can a human reasonably be responsible for? What about humans supervising AI agent supervisors? This will have significant implications for organisational design - teams responsible for managing interactions between agents, monitoring interactions with external systems, suppliers and customers, as well as teams responsible for oversight, monitoring and audit.

From my perspective, as human workforces are augmented by growing agentic AI work, there will be a corresponding shift to interactions and traffic being driven by AI systems rather than by humans. This means that APIs and endpoints designed for human interaction will instead be used by autonomous agents. We are already seeing web platforms being overwhelmed by AI use. The low incremental cost is already giving rise to “Agentic Sprawl”, and this will likely accelerate, both in terms of traffic internally within enterprises (e.g. between different enterprise applications) as well as with external parties.

Bringing it all together

I wasn’t quite sure where this blog post would lead me, but I feel that all themes here are interrelated. For all the talk about agentic AI systems, rolling out agentic workflows that span across multiple functions in a business will require a redesign of those workflows to be tailored around AI agents rather than human workers. This will be a non-trivial technical and workplace design challenge, not least due to the explainability limitations of current AI models. However, should these problems be solved, then we can expect a truly Cambrian explosion of AI agent adoption.

Read More:

1. Hosseini S. et al., “The role of agentic AI in shaping a smart future: A systematic review”, Array, July 2025.

2. Hale C., “AI is too big for the European internet”, Techradar.com, December 2017.

3. Kokotajlo et al., “AI 2027”, AI Futures Project, April 2025

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

1. Palantir Blog, “A Day in the Life of a Forward Deployed Software Engineer”

2. NASA Systems Engineering Handbook

3. Association of Project Management - Definitions

4. Bryar C., Carr B., “Working Backwards”, Macmillan, 2021

5. Berger E., “Liftoff, Elon Musk and the Desperate Early Days that Launched SpaceX”, Collins, 2023

6. Falcon 9, Wikipedia

7. The story of Nokia’s Maemo and MeeGo OS

8. Elements of Amazon’s Day 1 Culture, AWS Executive Insights

9. Clear J., “First Principles: Elon Musk on the Power of Thinking for Yourself”

10. European Patent Office – James Dyson, the bagless vacuum cleaner

A couple of weeks ago, I was lucky to spend some time in Cambridge, Massachusetts, attending seminars at MIT and Harvard. (That’s one off the bucket list). While there, we had the opportunity to attend a fascinating panel discussion on possible futures of how AI will shape the future of work. I was particularly thrilled that the panellists included Ethan Mollick, one of the best commentators on AI, and Daron Acemoglu, author of an incomparable history of technology. This blog post builds on that discussion…

The state of AI in the workplace today

Before considering the future of work, let’s briefly consider how generative AI tools are being used today. A recent review of the labour market by economists at Stanford University [1] shows that in most developed economies, between 20% and 40% of workers currently use generative AI tools.

What is more striking is the impact AI is having on carrying out individual tasks – something we can refer to as “micro-productivity”. This report highlighted the impact on tasks across many disciplines, from writing to technology design, management of personnel and many more. The time cut to carry out these tasks was reduced by between 2.5 and 5 times over their unassisted duration.

It is therefore clear that while AI may not (yet) be replacing most human jobs, it is certainly being used to automate individual tasks at a significant scale. The report states finds “limited evidence that Generative AI exposure significantly affects job openings or employment levels.”This is consistent with my findings in a previous blog, which showed that while there are productivity gains experienced by individual workers, most companies are not experiencing these gains at the enterprise level [2]. In the seminar, Mollick argued, quite convincingly, that practically everyone is quite clueless about how to capture value or productivity. The big Frontier AI labs are ‘simply’ in a headlong race to produce the largest models tasked at performing best across a range of AI benchmarks in the quest to be the first to achieve AGI. The premise is that this is a high-stakes, winner-takes-all race. Mollick claims that to these labs, how these models will integrate in the workplace is a secondary concern.

In the enterprise, there is no established playbook for achieving AI-powered success, although there is broad experimentation. Companies will need to be fundamentally rewired to benefit from AI agents forming a core part of their workflows, rather than simply automating workflows designed for humans. We are still in the infancy of this process, and it’s occurring in pockets, such as in support centres and in software development teams. A report by McKinsey [3] states that across most organisations, agentic AI adoption is still in the pilot phase, with less than 10% of firms currently scaling AI agents.

Stating the obvious – AI continues to get (much) better

As this blog is supposedly about the future of work, rather than its present, where are we heading to? I will start by stating the obvious – AI continues to get better. Most models are updated every few months, with generational changes (e.g. GPT-4 to GPT-5) roughly on an annual basis. Strikingly, these improvements currently continue to be exponential in nature. Although AI systems routinely outperform humans in specific tasks such as reading, this is not sufficient to fully automate a human job. In practice, the jobs carried out by humans consist of fairly complex tasks, each of which is a long chain of smaller steps. To be able to fully replace that human, an AI agent must be able to carry out this long chain of tasks at an acceptable error rate.

To give a sense of where we are with AI viably replacing a human workers, consider research [4] coming out of METR, an organisation that assesses AI frontier models. This suggests that the task length that LLMs can carry out reliably [i.e. with >80% success rate] is doubling approximately every seven months. In 2022, GPT 3.5 could only carry out tasks which would take a human software engineer ~10s to carry out (with 80% accuracy). By 2025, ChatGPT-5 had shown sufficient improvements to carry out 26min worth of work at 80% accuracy. If AI systems were to continue on the current improvement path, a somewhat speculative assumption, then by late 2027 to early 2028, AI systems can successfully complete tasks equivalent to a software engineer’s whole working day.

How AI changes the value of work

Given that AI is already replacing tasks across a wide range of professions, what is the impact on the value of (human) labour, and hence the likely effect on wages? A recent paper by Seb Murray [5] describes why automation is not always bad for workers. The key finding is that if automation removes the simpler parts of a job, the work that remains often requires more expertise, consequently demanding a higher premium. Conversely, where automation impacts the more skilled parts of a role, wages will fall. Consider accounting clerks and bookkeepers. As spreadsheets took over the more manual parts of their roles, they evolved into financial analysts. Over the period 1980-2018, the number employed in these roles fell by a third, while salaries rose in real terms by nearly 40%. On the other hand, taxi drivers used to rely on deep local knowledge to navigate urban areas. London taxi drivers needed to pass a test called “The Knowledge”, which typically took three to four years to master. Yet Uber’s navigation software has largely nullified the value of this know-how, seeing taxi wages drop by between 30-60%.

So applying this to the advent of generative AI, we can extrapolate that in the absence of policy interventions, there can be a broad range of outcomes for different professions, both in terms of the numbers employed, as well as upon their wages. We can postulate that, for example, customer support staff with deep technical know-how of their products can easily be replaced by AI agents that have ingested the technical datasets and knowledge base of their products.

Learning 1. Combine domain expertise with AI savvy

So what suggestions can I offer to whoever is worried that AI may replace their job? Once again, I will rely on the AI adoption within software development as a preview of AI’s broader impact on the workplace. Andrew Ng, a serial AI entrepreneur and expert, explains how the most effective software engineering hires are those who combine an understanding of software engineering fundamentals with the practices required to construct AI applications (such as prompting, RAG, agentic workflows, etc.) [6]. He says experienced software engineers who retain a pre-2022 way of working risk becoming obsolete. Similarly, less experienced engineers straight out of college who don’t have a strong understanding of computer programming fundamentals have limited utility. Whether this means that newly-minted graduates are over-reliant on AI is unclear. There is anecdotal evidence on X that startups are avoiding hiring new grads for this reason. As Ng puts it, “without understanding how computers work, you can’t just ‘vibe code’ your way to greatness.”

The general lesson for the AI-augmented workplace is that unless your job is fully automatable, then you need to understand how best to augment your job with AI. This means understanding how to combine your own domain-specific expertise with an understanding of how GenAI tools can help you. This is true whether your skills are in the creative arts, commercial skills or engineering. Whilst I am not qualified to comment on the likely macro-economic outcomes, if we look at the impact robotics and automation have had on manufacturing jobs in the US and Europe over the past twenty years, there are much fewer jobs, though better paid. As the rather tasteless joke about the two runners who bump into a bear goes, you don’t have to outrun the bear; you have to outrun your friend. Though this advice is clearly not conducive to teamwork!

Lesson 2. Optimise AI for problem-solving and skills development.

And in terms of advice for those designing AI-enabled workplaces, it’s worth returning to the MIT seminar I opened this blog post with. Much of the debate was on whether the nature of AI’s impact upon work is pre-ordained or inevitable. Zana Buçinca, a researcher at Microsoft, argued that there isn’t a single foregone conclusion on how AI will impact work and skills. [7] This, instead, will depend on how AI systems are integrated into the workplace. Buçinca suggested that systems that are designed solely to fully automate activities (i.e. simply to optimise for the immediate business outcome) can degrade the human operators’ expertise over time.

The risk of deskilling is a much-researched topic in the field of medicine, where an over-reliance on AI can see an erosion of clinical skills [7]. This mirrors what has been seen in aviation for many years. An over-reliance on autopilots and automation has been linked to a decline in pilots’ manual flying and monitoring skills. The US Federal Aviation Administration consequently issued guidance to ensure that pilots regularly practice manual control. The conclusion is that AI-assisted systems should be designed not only to best automate and optimise the task at hand, but also to optimise the human experience, particularly cognitive engagement. For example, she suggested that systems that offered an AI recommendation together with a contrastive option as an alternative resulted in better outcomes than systems that made single recommendations. They also stimulated better and deeper human engagement with the AI assistants, indicating that chatbots do not offer a one-way trip to deskilling.

In my view, organisations’ long-term interests lie not only in the most effective short-term optimisation, but in nurturing and developing the bedrock of skills required to maintain the integrity of the profession. As professions such as law and management consultancy now rely on AI systems to carry out research previously assigned to junior associates, AI tools in the workplace must therefore be designed to help the professional development of workers. The alternative is a world where the integrity and know-how of entire professions risk being eroded in the long term.

Conclusion on the Future of Work

In a nutshell, I am really not quite sure what the future holds, and please accept my apologies if you feel let down by the lack of a bullish oracular prediction. I am fairly confident about a couple of things, though. First, as companies figure out how to design their workflows to integrate autonomous AI agents as well as AI-augmented workers, they will eventually see the productivity gains that have eluded them so far. As these changes take place, many jobs will go the way of bookkeepers, typists, and many office jobs of decades gone by. Those that remain will be AI-augmented in one way or another. The key discriminator for each job will be whether AI will replace the most complex tasks we carry out, or whether it will relieve us of the burden of the mundane and repetitive parts of our jobs. As AI systems become more deeply integrated into organisations’ workflow, the only way for organisations, and indeed society, to sustainably maintain and build the human skill base is to design AI systems that optimise the human experience, as well as the business outcome. While this may sound obvious, this does not appear to be the state of play today.

References and Further Reading

1. Hartley, Jolevski, Melo & Moore, The Labor Market Effects of Generative Artificial Intelligence, SSRN #5136877, working paper, last revised Oct 2025

2. Mollick E., “Making AI Work: Leadership, Lab, and Crowd”, One Useful Thing, May 2025.

3. Singla A., “The state of AI in 2025: Agents, innovation, and transformation”, QuantumBlack AI, McKinsey, November 2025.

4. METR Blog, “Measuring AI ability to complete long tasks”, March 2025, updated on October 2025.

5. Murray S., “A new look at how automation changes the value of labor”, MIT Management Sloan School, August 2025.

6. Ng A., “AI skills are redefining what makes a great developer”, Deeplearning.AI, September 2025.

7. Buçinca Z, “Contrastive Explanations That Anticipate Human Misconceptions Can Improve Human Decision-Making Skills”, ACM Symposium Proceedings, October, 2024

The post AI and the Future of Work appeared first on The Sand Reckoner.

We should treat these words with caution. It is well-known that experts tend to over-emphasise the importance or impact of their space. Nevertheless, you’d be hard-pressed to find any serious technologist or economist suggesting that AI will be anything other than disruptive. Like many parents, I wonder how to prepare my teenage kids for the uncertainty that lies ahead. More specifically, in this blog, I have a look at how well the UK higher education system appears to be preparing our young people for this change. Note that I am not an educator, nor claim any expertise in pedagogy, so treat these musings with healthy scepticism.

A Tale of Two Time Horizons

We can apply two very different horizons to explore the disruption AI will have on our economy. If we were to take a very long view, AI offers to radically bring down the economic cost of productive output, particularly amongst knowledge workers. In itself, this is nothing particularly novel. The advent of agriculture displaced foraging (so-called hunter-gatherers), bronze and iron tools displaced stone tool-making, the invention of the printing press made the skills of monastic scribes largely redundant, the invention of steam-powered weavers saw the onset of the industrial revolution, while mass-production in the 20^th century saw skilled artisanal labourers replaced by less-trained factory workers. In all these transitions, overall economic output increased, though at the cost of (often significant) hardship for those workers who lost their jobs.

If we then zoom into the onset of generative AI, we can see that timescales of change collapse to a handful of years. It is the speed of change, rather than its impact, that is truly revolutionary. For example, ChatGPT (based on GPT 3.5) was launched in November 2022. This year’s cohort of computer science graduates were already well into their first or second year of undergraduate studies when ChatGPT launched AI into mainstream discourse. At the time they were selecting university courses, the majority of these students would have been oblivious to the pending arrival of gen AI, yet by the time they graduated, they were facing a very different job market.

Graduate hiring in the UK and US has plummeted over the last three years [2]. A separate study by McKinsey, shows that the reduction in hiring was twice as acute in jobs more exposed to AI compared to those with low exposure [3]. The point is that the displacement in occupations took a couple of generations at the time of the Industrial Revolution. This time round, that disruption may take as little as five years. Yes, we have seen this seismic disruption before (or at least, humanity has). What is new is the speed at which it is taking place.

The hollowing out of entry-level jobs

A paper [4] by researchers at Stanford University, helpfully titled ‘Canaries in the coal mine’, studied payroll data of 50 million workers in the US. The study found that employees aged 22-25 in AI-exposed occupations were 13% more likely to lose their jobs than others in less-exposed jobs. As I explored in my previous blog, entry-level software engineering jobs, which involve component-level programming, debugging, testing and documentation, can easily be replaced by generative AI tools such as coding copilots. The study attributed much of this job loss to areas where AI can automate work (i.e. replace a human worker), rather than augment (i.e. help a human worker) the work. In an op-ed in the New York Times, the Chief Economic Opportunity Officer (what a job title!) at LinkedIn describes [5] how the bottom rungs of the career ladder are disappearing. Outside tech jobs, legal firms, consultancy companies, retailers and so on are all now looking towards AI to take on duties once carried out by entry-level roles.

Looking Ahead – what does this mean for graduate jobs?

Dario Amodei, the CEO of Anthropic believes this trend will accelerate. In an interview with Axios [6] he explained that Anthropic research shows that while AI models are primarily being used for augmentation, he believes that over the next two years, their use will tip more and more towards automation.

So just think about it for a moment. This will happen 1-2 years before this year’s university undergraduate intake enters the job market. At the beginning of the year, Mark Zuckerberg said that in 2025, “AI will be effectively a sort of mid-level engineer that you have at your company that can write code.” Coming back to Amodei, he believes that AI will replace half of entry-level white-collar jobs in the US within five years, increasing unemployment to 10-20%.  For context, a shift of 10% in unemployment represents a loss of 17 million US jobs, which dwarfs the approximately 6 million manufacturing jobs lost in the US through globalisation of manufacturing.

UK Universities Spring into Action. Or do they?

As I mentioned previously, I have a busy autumn ahead, visiting a host of Russell Group Universities (supposedly the best universities in the UK) with my son who is hoping to start an engineering degree in a year’s time. Surely, these august, world-leading institutions, home to the country’s best technology thinkers dedicated to moulding and nurturing the technologists of the future would have this challenge in hand?

You will therefore understand my surprise that, having sat through about ten “introduction to engineering” courses, covering mechanical, aerospace, automotive and electronics disciplines, not once did I hear anything about AI. Of course, they were all happy to talk about their wonderful facilities, their co-curricular opportunities, their partnerships with industry, and the sheer excellence of their academic credentials. But with the notable exception of a talk on a B.Sc. in Artificial Intelligence course, not a peep on AI.

So, given that AI is undoubtedly going to transform most technology roles, does this feel adequate? My previous blog suggested that all engineers will effectively become supervisors of AI, be they by using AI tools as part of the design process, optimisation, prototyping, experimentation or validation. All engineers will need to be adept at their domain of expertise, as well as in the use of AI and data. Yet none of these universities sought to mention anything about it.

I then headed over to the undergraduate prospectus web pages of the same universities and asked ChatGPT to assess the curricula for engineering degrees for subjects related to data science and AI. I selected mechanical engineering-related courses as these are technology specialisms where data and AI do not traditionally feature heavily. On looking at the data, you can see that AI typically appears as a ‘specialisation’ subject in the latter years rather than a foundation for the course. This takes the guise of subjects such as control theory, machine learning, robotics and mechatronics. For this reason, 4-year MEng courses tend to have nearly double AI/data content of 3-year MEng courses. There are exceptions, though. Southampton offers a compulsory Data Science and Computing for Engineers in year, while Cambridge unsurprisingly offers a host of rigorous-looking options, with an early focus on Computer Science, followed by later options such as Probabilistic Machine Learning.

Protecting Academic Integrity and the Learning Process

UK universities seem to prioritise the integrity of their qualifications above all else. This can be seen in “Russell Group principles on generative AI in education” policy paper [7]. This paper focuses primarily on addressing the risks associated with the use of Gen AI in higher education. Privacy, bias, inaccuracy and misinterpretation of results, ethics, plagiarism, and exploitation are all (quite rightly) highlighted as concerns. However, most universities provide thoughtful guidance on how AI tools (particularly Gen AI) can be used in to support learning as well as where and how they can be used to help create assessed work. Some even use these policies to ensure that students are ready for life in an AI-enabled world.

So what should Universities learn from this?

1. A University Degree is not a guarantee of anything.

Universities need to wake up and smell the coffee. Evidence is mounting that employers are increasingly not relying on a University degree or formal qualification as evidence that candidates have the required skills to compete in the new jobs market. A recent study [8] showed that while AI roles grew by 21% between 2018 and 2023, mentions of university requirements for these roles actually decreased over this period. Employers are prioritising skills over qualifications, clear evidence that universities have work to do to remain relevant.

2. Data, Statistics and AI as core subjects for technical disciplines

Especially for technical subjects, data science, statistics, and learning models should be treated as foundational subjects and not as specialisation options. There will be no technical field where some form of AI will not be part of the toolkit used by practitioners. Coding assistants as used by programmers represent just the tip of the AI-assisted revolution, which will reach all technical fields. Progressively, AI agents will take on the tasks of individual knowledge workers, so that each practitioner will effectively become a supervisor of AI agents. As such, they will need to be fluent in the language of AI – namely, data and statistics, as well as in the structure and methodologies used by the learning models. Key skills will be orchestration of models, managing multiple agents and being able to take professional accountability on their behalf through robust validation, particularly for high-stakes outcomes such as in health and safety-critical applications.

3. Basic AI Model Literacy for all disciplines

Some of the most professions most exposed to AI are those that traditionally fall into the humanities. A report by Microsoft into the most exposed professions sees interpreters at number 1 (perhaps unsurprisingly) and historians at number 2 (more surprisingly). A paper by researchers at Harvard Law School describes how AI can see productivity gains for lawyers in excess of 100 times, in one example, reducing associate time for preparing for litigation from 16 hours to 3-4 minutes. [9] Yet, reviewing the course material for five of the UK’s top law degree courses sees AI treated as part of “technology and law regulation” subjects, rather than a core part of the lawyer’s toolkit.

All knowledge workers should be equipped with an understanding of the characteristics, structures and limitations of AI models, particularly generative AI and other deep learning models. Their inherent non-deterministic nature combined with their propensity to hallucinate means that you’d have to be foolhardy to rely on the models without a thorough understanding of how they operate, at least conceptually.

4. Reinvent the value proposition

It is difficult to make predictions about such a fast-moving space, other than to say that such changes will continue for a while and will at times feel overwhelming. This means that Universities’ once-in-a-lifetime model of learning seems increasingly ill-equipped in today’s world. Just as the Open University pioneered distance learning fifty years ago, it is time again to be radical. Universities should shift towards offering long-term part-time learning models that accompany their students throughout their professional lives. Online learning providers such as Coursera, Udacity and Deeplearning.ai, all offer content from many providers. Universities should expand their partnerships with these providers – both making use of external content, as well as using these platforms to distribute their own lifelong educational offerings. Some Universities are already doing this. MIT has long been a leader in open AI programmes, and offers free online courses as well as certified qualifications through its MicroMasters programmes, with other top-tier universities also making courses available on platforms such as EdX and Coursera.

Predicting the future is hard

When assessing technologies close to the peak of the hype cycle, it is difficult to make predictions as to the extent of the disruption they will bring and how quickly they will be adopted. I wrote a piece back in 2018 on the inevitability of safe-driving cars, proof of the pitfalls of getting carried away with the excitement of ‘revolutionary’ technologies. Nevertheless, AI will very likely replace large chunks of what knowledge workers do today, radically reshaping their jobs in ways that are hard to predict. Ignore this at your peril.

References and Further Reading

1. C. Criddle, “Hinton: ‘AI will make a few people much richer and most people poorer’, Financial Times, 5 September 2025.

2. C. Murray, “Is AI killing graduate jobs?”, Financial Times, 24 July 2025.

3. Allas T., Goodman A., “Not yet productive, already disruptive: AI’s uneven effects on UK jobs and talent”, McKinsey & Company Blog, 14 July 2025.

4. Brynjolfsson E., et al., “Canaries in the Coal Mine? Early Employment Effects of Generative AI”, Stanford Digital Economy Lab Working Paper, August 2025.

5. Giridharadas A., “AI and the Vanishing Entry-Level Job”, The New York Times, 19 May 2025.

6. VandeHei J., “Behind the Curtain: A White-Collar Bloodbath,” Axios, 18 May 2025.

7. Russell Group, “Principles on the use of generative AI tools in education”, July 2023.  

8. Bone M. et al, “Skills or Degree? The Rise of Skill-Based Hiring for AI and Green Jobs,” Cornell University, December 2023

9. Couture R., “The Impact of Artificial Intelligence on Law Firms’ Business Models”, Center on the Legal Profession, Harvard Law School, February 2025.

The post What does AI mean for university education? appeared first on The Sand Reckoner.

In this blog post, the professional and personal coincide for the first time. As an engineer and leader of tech teams, I am very interested in understanding what the advances in artificial intelligence mean for how tech products will be built. On the personal front, I am currently visiting universities with my son, who is looking to start an engineering course. So the question as to what engineering will look like in five, ten, or twenty years is particularly pertinent. This blog is my attempt to explore that question.

A spotlight on software engineering

Software engineering is the technical discipline that to date has been most impacted by AI. At one level, the introduction of AI is simply extending the developer’s journey away from the native execution of assembly code, providing greater levels of abstraction, just as progressively higher-level languages have done today. However, LLM-based code assistants also fundamentally change the nature of coding. For the first time, they introduce a non-deterministic element, as LLMs do not create repeatable outputs. In effect, we are outsourcing control of the logic, the very essence of our intent, to machines.

So what’s the impact of AI coding assistants upon the developer experience and overall productivity? Early research shows a mixed picture. A recent report [3] by DORA, the DevOps Research and Assessment team, describes benefits as seen by developers, including flow, job satisfaction and a reduction in burnout. However, the gains at an organisational level appear to be modest, with a 25% increase in a user’s AI adoption increasing productivity by only 2.1%. While the quality of documentation, code quality and code review time improved significantly, this came at the cost of an increase in technical debt and code complexity. These gains in productivity are mirrored by a randomised control trial of 96 developers at Google, which showed a 20-25% increase in productivity in coding tasks attributable to AI.

Overall, the real-world impact on productivity at the enterprise level appears to be mixed. The DORA report suggests there is negligible, if any, improvement in software delivery effectiveness. Another paper by METR (Model Evaluation & Threat Research), a body assessing frontier AI capabilities, found that for developers working in a large, mature open-source repository, task completion time increased by around 20%. It appears that improvements in coding productivity at the developer level are, to date, offset by increased load on oversight, review and integration.

Some insight into what’s going on can be found in the recently released, and rather excellent, annual developer survey by Stack Overflow [15]. Although 84% of developers now use AI assistants, only 3.1% of them highly trust them, and 46% actively distrust them to some extent. The two main bugbears are that “AI solutions are almost right, but not quite” (66% of respondents) and “debugging AI-generated code is more time-consuming” (45% of respondents).

Even though we are still in the early days of AI adoption in software development, some things stand out:

1. AI is fundamentally changing the nature of software engineering. AI tools are here to stay, and they are changing the nature of coding and of the software that is created. For example, AI tools create non-deterministic, ‘fuzzier’, less predictable codebases. They are lowering the cost of building code from scratch, reducing the perceived benefit of creating reusable, modular code. These are pretty fundamental shifts in what developers have traditionally valued.

2. New skills are required to master software engineering in the age of AI. Software engineers now need to master a blend of traditional software skills and AI competencies. These include prompt and context engineering, AI-assisted code review, AI output evaluation, integration into AI APIs, an understanding of AI model behaviour, and a new security and compliance paradigm. Successful developers and organisations will be those who invest in learning to take on these new skills.

3. This requires a mindset shift. As Gen AI models become more tightly integrated into coding tools, development pipelines and documentation systems, the boundary between human and machine contribution will blur, requiring developers to increasingly work with AI tools as a co-contributing partner, rather than as a traditional coding tool.

4. Organisational effectiveness gains are currently lower than expected. The use of AI is leading to higher overall coordination costs, as AI-generated code tends to require more discussion, review or coordination across different developers. Additionally, the current unreliability of AI systems requires greater investment in security, validation and compliance oversight.

5. The AI benefit is not consistent across all developers. Most of the research indicates that junior engineers, working on smaller components, can benefit most from AI assistants. This mirrors the way they would ask senior colleagues for help [5]. However, these are the tasks most easily automatable, so AI appears to be disproportionately impacting developers who are just starting their careers. For more senior engineers, with responsibility for a large, complex codebase, the opportunities AI provides are more limited. For example, randomised trials show larger gains in productivity for junior engineers (~27-39%) than senior engineers (~8-13%) [6]. The greater the scope, the more complex the problem, the more difficult it is to solve a problem without creating knock-on effects elsewhere.

6. AI does not (yet) offer tech leadership. Yes, AI can help with coding, but it does not yet act as a substitute for non-coding tasks expected from senior engineers, including the creation of complex design documentation, technology roadmaps, arbitrating with other teams, or simply providing your teams with the vision of the way forward.

And the broader learnings for other engineering disciplines?

Having cast a spotlight on software engineering, what are the learnings for other engineering disciplines? Software engineering lends itself particularly well to the use of AI, as it often operates in a ‘fully digital’ space, where all the inputs and outputs are digital. There are often (though not always) fewer safety implications than for physical engineering applications. How will this be different for real-physical applications such as manufacturing, semiconductor design or aerospace?

First, let’s not forget that AI has been used in engineering design for well over a decade. Be it in the form of image recognition and robotics on an automated assembly line, the use of machine learning to optimise engineering designs or carry out predictive maintenance, and in the use of digital twins to model real-world systems, learning systems are not new. The question is rather, what will be the effect of generative AI, and its inherently non-deterministic nature?

1. AI for initial concept generation

Let’s start at the beginning of the engineering process. Much as AI co-pilots can help blog authors suffering from writer’s block, generative AI is already being used successfully by many engineering firms in the meandering and seemingly random process of creating initial exploratory designs. The integration of LLMs into physical CAD software already allows for design concepts to be generated from natural language prompts at a much higher level of abstraction. For example, a paper by Byrne et al shows how LLMs can be used to provide CAD designs for multiple concepts for consumer products, in this case, headphone stands, by giving it instructions in natural language [10].

FlecheTech, a Swiss startup, uses a fine-tuned LLM to produce PCB [printed circuit board] prototypes for hobbyists, small companies and anyone who requires prototype designs, but lacks the in-house expertise to design it from scratch. FlecheTech claim that this reduces the time to create a working board from around 8 weeks to one week [15]. These are both examples where generative AI’s non-repeatability and variation are actually a strength, as it can produce multiple variations as designers explore early concepts.

2. AI for design automation

Early ideation occupies only a small proportion of the overall engineering development effort. If AI is really going to transform engineering, it is going to be in the more structured design and development phases. Consider semiconductor design, which for decades has relied on Electronic Design Automation (EDA) software as the only way to deal with the extremely high complexity of modern processors. Semiconductor design includes processes such as design specification, front-end design, physical design validation and test and analysis. NVIDIA estimates that up to 60% of a chip designer’s time is spent in debug or checklist-type tasks [11]. In fact, the hardware design process is not dissimilar to software development, as the chip designs are fully described in software. LLMs therefore have the same potential to design and optimise code and synthesise information as they do in the software development space, with leading EDA providers such as Synopsys already building generative AI capabilities into their tools.

There are several other examples of companies using AI to automate engineering processes. CloudNC, a British startup, is using AI to automate the process of programming CNC (computer numerical control) machines, which are the mainstay of precision manufacturing [14]. These machines cut metal to precise specifications required by industries such as aerospace and medical devices. Although CloudNC don’t disclose how their algorithms work, it appears to use a combination of AI-based training and physical geometry to determine the optimal cutting strategy. These examples show that, whilst not yet as pervasive as for software design, generative AI solutions are beginning to appear across multiple technology areas.

3. AI for complex engineering optimisation

One area where AI is already having a big impact in engineering design is in engineering optimisation – the process of developing and testing different designs to see which operates best in a given set of conditions. Traditionally, this has been a fairly manual process, and even when reliant on simulations, it is very computationally-intensive. Neural Concept, a Swiss engineering software company, has developed neural-network-based software to help Formula 1 teams create the most effective aerodynamic designs possible [12]. Formula One car development is a race in itself, with each team racing to create the most effective car package possible before and during a season. Neural Concept’s software helps create outcomes in seconds rather than hours, conferring a clear competitive advantage. Similarly, Airbus is making use of AI to create 3D printed structural components using generative algorithms mimicking organic structures. [17]

Recent research has also shown that the combination of reinforcement learning (RL) and LLMs can outperform engineering design as carried out by a human expert. A recent paper explored the use of commonly available LLMs, such as OpenAI’s GPT-4o and Anthropic’s Claude 3.7 to design a rocket that met a given set of performance criteria, such as achieved altitude, structural integrity and landing accuracy. The combination of LLMs and reinforcement learning was found to exceed the performance of an expert who has carried out similar rocket design tasks over many years.

So what does all this mean for the future of engineering?

Given what we have seen from how generative AI is being used in software development, and the examples in other engineering areas, some themes begin to emerge.

1. We have not even begun to scratch the surface. First, a caveat. We need to consider that it has been barely three years since LLMs emerged from their research labs, and their capabilities are evolving at breakneck speed. For example, this blog hasn’t considered the impact of agentic systems, or indeed of artificial general intelligence (AGI). That said, I am pretty confident that the lessons below will hold true.

2. Data really matters. AI-assisted systems can only work with whatever data they are provided with, be it in the form of data to refine or pre-train models, or feedback to guide their systems through reinforcement learning in tight verification loops. Therefore, no matter the engineering discipline you are involved in, you will need to be fluent in capturing, managing and processing data, not just design files, but real-world physical data, and ensuring that it is available for use with your AI-assisted platforms.

3. Understand the black box. When we use generative AI models, we are, for the first time, outsourcing the logic to a machine that we currently don’t fully understand. This issue, called the interpretability problem, means that it is critical that engineers at least understand the underlying limitations as well as the benefits of using such models. These characteristics include the tendency to hallucinate, difficulty in repeatedly creating consistent outcomes and an excessive sensitivity to how the prompts are crafted. The list goes on. They are undoubtedly incredibly powerful tools, but they come with significant downsides.

4. Oversight is critical. The time spent ‘engineering’ outcomes will shift away from developing and designing individual components or subsystems. These are tasks that, with the right instructions and data, can easily be outsourced to AI assistants. Instead, AI-assisted engineering will require greater emphasis on shaping and crafting the requirements, contexts, specifications, and other input data to be used by AI-powered tools. Similarly, it will be critical to invest in the oversight of outcomes, in other words, validation. This is to ensure that the system as a whole still works well (i.e. the system integrates correctly as a whole) and to ensure that safety, security and compliance requirements are not compromised. In other words, each engineer will effectively become the supervisor of their AI team.

5. Finally, domain expertise remains key. As I hope this blog has made clear, AI systems are only as good as the context that they are provided with. Without a specific and clear context, AI systems can produce great outcomes that either don’t solve the problem at hand or fail to work in their intended environment. This means that the engineer’s insight into what is really needed to succeed in a given context is critical. This engineering input, or tasking, could take different forms. It could be the requirements upon a component or sub-system for it to work well in a broader system, or the features or capabilities will meet the customer’s needs.

Finally…

Writing this blog post has been a bit of a journey, and the key learning for me is that engineering is becoming simultaneously more complex, but also much more exciting. Used well, AI tools can turbo-charge the creative potential of individual engineers. However, human engineering judgement will remain as critical as ever. Engineers will need to be multi-disciplinarians, mastering both their domain of specialism as well as the fundamentals of the AI models they use.

Finally, while I tried to write about the future of engineering, what I ended up exploring was, in effect, the present and near future. I have not even begun to consider the implications of systems of AI agents interacting with each other has upon how technology development is carried out. That, my friends, is a topic for another day.

References and Further Reading

1. Sergey Tselovalnikov, The LLM Curve of Impact on Software Engineers, February 2025

2. Martin Fowler, LLMs bring new level of abstraction, June 2025

3. DORA, Google Cloud, Impact of Generative AI on Software Development, v.2025.2

4. DORA Research, Helping developers adopt generative AI: Four practical strategies for organizations, March 2025

5. Becker J, et al, Measuring the Impact of Early 2025 AI on Experienced Open-Source Developer Productivity, July 2025

6. Walsh D., How Generative AI affects highly skilled workers, MIT Sloan School of Management, Nov. 2024.

7. Anthropic.com, Anthropic Economic Index: AI’s impact on software development, April 2025

8. Neural Concept Blog, AI in Engineering: Applications, Key Benefits, and Future Trends

9. Rizwan Patel, The Future of Engineering belongs to those who build with AI, not without it, VentureBeat, May 2025.

10. Byrne et al, Application of Generative AI technologies to engineering design, 12th CIRP Global Web Conference, 2024

11. Singh K. et al, Generative AI for Semiconductor Design and Verification, AWS Blogs, March 2024.

12. Stevens T., How Neural Concept’s aerodynamic AI is shaping Formula 1, TechCrunch, April 2024

13. Simonds T., LLMs for Engineering: Teaching models to design High-Powered Rockets, arXiv:2504.19394v1, April 2025

14. Kahn J., Can AI help America make stuff again?, Fortune, June 2025.

15. Tucker M., When Generative AI meets Product Development, MIT Sloan Management Review, Fall 2024.

16. Stack Overflow, 2025 Developer Survey, July 2025

17. Autodesk Press Release, Autodesk and Airbus Demonstrate the Impact of Generative Design on Making and Building, November 2019
    

The post How AI is changing engineering appeared first on The Sand Reckoner.

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.

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.

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

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.

Further Reading

1. Wikipedia, “Carl von Clausewitz”, retrieved 26 May 2024.

2. D Sukman, “Human Fog, Human Friction, Human Chance”, The Strategy Bridge, 2015

3. Z. Hughes, “Fog, Friction, and Thinking Machines,” War on the Rocks, 2020

4. Carl von Clausewitz, “On War”, Book 1, Chapter 7

5. Garard O., “Reconsidering Clausewitz on Friction,” January 2023

6. R. Sutton and H. Rao, “Rid your Organisation of Obstacles that Infuriate Everyone”, Harvard Business Review, Jan-Feb 2024.

7. HM Government, “National Risk Register”, 2023 Edition.

8. N. Taleb, “The Black Swan: The Impact of the Highly Improbable”, February 2010

9. Brooks D., “The Behavioural Revolution”, New York Times, 27 October, 2008.

10. R. Zucker and D. Rowell, “6 Strategies for Leading through Uncertainty”, Harvard Business Review, April 2021

11. M. Birshan, I. Seth and B. Sternfels, “Strategic Courage in an Age of Volatility,” McKinsey Quarterly, August 2022.

12. I. Nonaka and H. Takeuchi, “Strategy as a Way of Life”, MIT Sloan Management Review, Fall 2021.

13. T. Tawadros, “Being Uncertain Might Make you a Better Leader”, Bayes Business School Blog, July, 2022.

ChatGPT 4o on Satya Nadella’s take on Leadership

Satya Nadella’s approach to leadership at Microsoft has been transformative, centering on several key principles that have not only revitalized the company but also influenced the broader tech industry.

1. Growth Mindset: Nadella emphasizes a “learn-it-all” mentality rather than a “know-it-all” one. This growth mindset encourages continuous learning, experimentation, and adaptation, fostering a culture where innovation thrives and employees are empowered to take risks and learn from failures

2. Empathy: Central to Nadella’s leadership philosophy is empathy. He stresses the importance of understanding the perspectives, needs, and challenges of customers, employees, and stakeholders. This empathetic approach has helped build stronger relationships and a more inclusive and collaborative work environment

3. Inclusivity: Nadella is committed to fostering a diverse and inclusive workplace. He believes that diversity drives innovation and has implemented initiatives to increase the representation of underrepresented groups within Microsoft. This focus on inclusivity has not only improved workplace culture but also enhanced the company’s ability to serve a diverse customer base

4. Collaboration: Nadella values teamwork and partnerships, both within Microsoft and with external entities. He promotes cross-functional collaboration and has forged strategic partnerships with other industry leaders to enhance Microsoft’s offerings and value to customers

5. Customer-Centricity: Under Nadella’s leadership, Microsoft has adopted a customer-centric approach, focusing on deeply understanding and meeting the needs of its customers. This shift has driven product innovation and improved customer satisfaction

6. Technological Innovation: Nadella has steered Microsoft towards the forefront of technological advancements, particularly in cloud computing, artificial intelligence, and quantum computing. His strategic vision and willingness to invest in emerging technologies have positioned Microsoft as a leader in the tech industry

By incorporating these principles, Nadella has not only propelled Microsoft to new heights of success but also set a new standard for leadership in the digital age, emphasizing empathy, inclusivity, and continuous learning【67†source】【69†source】.

The post Fog and Friction – The limitations of strategy when dealing with uncertainty appeared first on The Sand Reckoner.

Some AI Forecasts for 2024 (1)

Alberto Romano, who maintains a thoughtful blog called Algorithmic Bridge, observes that the benchmark LLM at the end of 2023 was GPT-4, which was built in 2022, and other models, including Gemini, Llama or Claud have not come close yet. He therefore speculates that we may be reaching the limit of what is possible with current technology. On the other hand, he muses at what is next from Meta, who have invested $20 billion on AI compute(!) while Sam Altman hints that GPT-5 will be a lot better than GPT-4.

Some AI Forecasts for 2024 (2)

In a paper for VentureBeat, Gary Grossman notes that AI is at the peak of the hype cycle. For example, you’d be hard-pressed to find a CES announcement that didn’t include some form of AI spin. Nevertheless, despite headwinds in the form of concerns about compute cost, environmental implications, training and data bias, security, copyright and hallucination, AI advancements are likely to continue to build upon one another. Grossman believes that Amara’s Law applies: “We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.”

How to Rank LLMs like Chess Grandmasters

With advances in large language models improving so quickly, it is quite a challenge to rank them against standard benchmark tests. The most useful ranking system is maintained by Hugging Face, who use an approach called Elo ranking, more commonly used to rank players in zero-sum competitive games such as chess to rank LLM-powered chatbots. The current ranking, dominated by GPT-4, is put together by crowdsourcing 200,000 preferences.

AI as a National Strategy

A couple of weeks ago, an interesting article in The Economist explored how different governments are pursuing AI industrial policy – a blend of scientific, investment and geopolitical strategy. Unsurprisingly, the USA dominates VC investment, whilst China and the United States are neck-and-neck when it comes to government investment, primarily for chip fabs. Cash-rich petrostates are ploughing money into GPUs and building their own models (such as Abu Dhabi’s Falcon LLM), though analysts are sceptical of the potential for government-sponsored AI models. (subscription required, though article may be downloaded for free)

The post Artificial Intelligence Good Reads (Part 2) appeared first on The Sand Reckoner.

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

1. “Digital Transformation Consulting Services Market Report Overiew”, Business Reports Insights, , Dec. 2023.

2. “What is Digital Transformation?”, McKinsey & Company Featured Insight, June 2023.

3. “Digital Transformation”, Accenture Insight Report.

4. D. Garvin, “Building a Learning Organisation”, Harvard Business Review, July 1993.

5. P. Hugander, “Take a Skills-Based Approach to Culture Change,”, MIT Sloan Management Review, May 2022.

6. “What is a Sprint Retrospective?”, Scrum.org

7. B. Laker, “Embrace Mistakes to Build a Learning Culture”, MIT Sloan Blogs, January 2023.

8. L. Caro et al., “Why You Should Develop a Correction of Error”, AWS Blog, February 2022.

9. “Big Tech outspends venture capital firms in AI investment frenzy”, The Financial Times, 29 December 2023.

10. H. Chesbrough, “Twenty Years of Open Innovation,” MIT Sloan Management Review, December 2023.

11. “It is time to extinguish the ‘burning platform’ for good”, The Financial Times, 28 June 2021.

12. Satell G. et al, “Help Your Employees Develop the Skills They Really Need”, Harvard Business Review, October 2023

13. K. Palmer, “The New Role for Managers in Workplace Learning”, MIT Sloan Management Review, August 2019.

14. T. Winters et al., “Software Engineering at Google – Lessons Learned from Programming over Time,” O’Reilly, March 2020.

15. “Next-level learning: Capabilities to take your organisation higher”, IESE Insight Reports

16. T. Chandele, “The Journey to Becoming a Learning Organisation”, Society for Human Resources Management

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

As I have mentioned before in the preface to a similar collection of books, I remain embarrassed by the “Digital Transformation” title of this little series of book reviews, as it really conjures images of management consultants selling snake oil. Nevertheless, having started with this moniker, I will stick with it, and hope that the title doesn’t put you off too much. Here is a collection of titles I have read over the past year or so. It is somewhat of an eclectic mix, but I think covers some of the key skills required to successfully navigate the choppy waters of tech.

How Leaders Become Strategists

Richard Rumelt

The first book is by Richard Rumelt, the author of my favourite strategy book of all time, a book, which in a parallel life, I wish I would have written myself – “Good Strategy – Bad Strategy”. Rumelt started off as a systems engineer (like me, which is why I flatter myself with the comparison), and so brings a systems-approach to deconstructing and framing strategic choices. In his latest book, “The Crux – How Leaders become strategists”, Rumelt tries to get to the heart of what makes good strategic decision-making. He argues that rather than focusing on lofty visions, goals or ambitions, leaders should dwell on the structure of the problem at hand, what he calls the ‘crux’. Drawing on examples from multiple industries he shows how focusing on a problem, rather than a goal, can give the insight required for success. Therefore we learn of how Marvel pivoted from licensing Spiderman and X-Men to third-party studios to creating its own studio to maximise the value of its other superhero franchises, or how the Louvre’s glass pyramid emerged from a problem defined as creating an entrance to the museum without obscuring the museum’s historic façade. Given this insight, Rumelt goes on to give examples of how organisations build on this insight, such as how Nvidia invested big in adapting its GPU architectures for AI training and inference ahead of the ChatGPT hype explosion or how Google launched its AdWords programme by creating a clear delineation between sponsored ads and its search results. This is a book that requires periodic re-reads.

Scaling People: Tactics for Management and Company

Claire Hughes Johnson

I came across the next book through a review in The Economist, an unlikely source for this type of title. Whilst many business books focus on fleshing out a single idea or concept, “Scaling People: Tactics for management and Company” by Claire Hughes Johnson is something very different. Drawing on her experience as a senior executive at Google and Stripe, Hughes Johnson provides a useful, if somewhat hefty, hands-on, one-stop shop for the operational toolkit for running an effective tech company. It can read as a COO’s handbook, covering the essential building blocks of operational excellence. From Creating a cadence that works, through all the practices required to establish and develop high-performing teams, this book is a great reference for benchmarking your own company’s practices. In line with its practical bent, the Hughes Johnson provides several examples and templates that can be copied or adapted to your context. Although clearly not all prescriptions will be applicable to your reality (e.g. the American approach to managing people out of a company would not sit well in most European contexts), this is a book that I come back to time and again.

The Habit of Excellence – Why British Army Leadership Works

Lt Col Langley Sharp

On first consideration, a book on leadership based on an organisation more than 350 years old does not intuitively seem to be the most obvious place to look for inspiration on how to lead modern tech organisation. It was the endorsement of Matthew Syed which however brought me to read this, and can say I am really glad I did. Over the years, the British Army has been beset with all sorts of practices and issues that are anathema to modern management practice. From the regressive purchasing of commissions to the reputation of ‘lions led by donkeys of the first world war’ to the ethical quagmire and allegations of cover-ups of the conflicts of the last forty years. It is however this challenging context, coupled with the unique situation that, unlike other organisations, all the army’s top brass are recruited from within. For the army to succeed and thrive, there is therefore no alternative to effective leadership development. Lt Col Sharpe takes us on a journey on some of the key principals, explaining how leadership is important at all ranks, how it is instilled in the concept of servant leadership, the role of continuous learning and the importance of intelligent disobedience. This is underpinned by running thread of role played by empathy, emotional intelligence and resilience. On the topic of distinction between officer and non-commissioned officer or soldier leadership, this book is perhaps less useful to the rest of us, but otherwise on a manual on how to instil a culture of service-based leadership, this book is certainly worth your while.

How to be an Inclusive Leader

Jennifer Brown

As a white, middle-aged, middle-class (in the British definition) man, whose career thus far has been spent largely surrounded by people who are not too dissimilar to me, I must admit that I often find it difficult to find an authentic and indeed, credible, voice when it comes to speaking about equity and inclusion. This fairly short book by Jennifer Brown provides a very practical framework to help create a more inclusive culture. Whilst there is nothing particularly earth-shatteringly surprising in the four-step framework she proposes (spoiler alert, it’s unaware –> aware –> active –> advocate), the book is particularly helpful in providing the language and tools to engage with people, whether they are diversity sceptics or enthusiasts in an empathetic way. Brown explains the intersectionality of identity and privilege, how we all have a complex mosaic of characteristics and experiences, many of which we choose to keep hidden, and hence inclusion activities help everyone as a rising tide, and not a zero-sum gain. She does so in a book that manages to provide powerful examples, whilst avoiding being ‘preachy’. Once again, a book that I do dip in and out of quite frequently.

Rebel Ideas – The Power of Diverse Thinking

Matthew Syed

If there ever was a book that resonated with my thoughts on how to bring teams together, it is Matthew Syed’s Rebel Ideas. Earlier this year I wrote about cognitive diversity, the power of bringing different viewpoints, perspectives and experiences to solve problems. The nature of the problem is key here – the make-up of a team solving a pre-defined, well-understood problem does not have a particularly strong bearing on outcomes. However, for complex problems, particularly those with unclear paths to success, being able to provide a range of different viewpoints provides a clear edge, and can act as an antidote to GroupThink or the emergence of echo chambers. Syed explains how having a diversity of viewpoints is not sufficient, you also need a culture and mechanisms to enable different ideas, often contradictory ones to surface. Syed warns that, particularly where a problem space is particularly complicated, it is easy to get lost in its intricacies, as if ensconced within its walls. This is why an outsider mindset is essential to escaping this trap, and can open up awareness of impending seismic changes, as illustrated by the fact that most of the steam-based powerhouses of the early industrial age completely missed the transformative effects that electricity would have on industry. I cannot recommend this book highly enough.

Working Backwards – Insights, Stories and Secrets from Inside Amazon

Colin Bryar and Bill Carr

Including this book in this list is a bit of a cheat, as I haven’t properly read it from cover-to-cover. Allow me to explain. I recently left Amazon after a fairly brief stint of just under two years. Although I didn’t spend too long there, I have found that my experience has fundamentally rewired the way I work, and I suspect for the long-term. It certainly has had a more profound effect on me than the MBA course I undertook over a decade ago. Amazon’s secret sauce lies not in its technology prowess (which of course is considerable), but rather in what it describes, quite openly, as its ‘peculiar’ culture. Underpinned by its leadership principles, the Amazon way of working consists of a set of non-negotiable practices, from working ‘backwards from the customer’ to using documents as the basis for all significant decision-making. Coupled with an approach to data and metrics that is simultaneously rigorous and sceptical, an organisational structure designed from the ground-up to scale, and a series of practices designed to help navigate the most gnarly of problems, the Amazon culture is what makes the company. This book provides as good an overview of how these practices work at Amazon as you’ll get without enduring its gruelling multi-stage interview format, as well as describing how to be Amazonian outside of Amazon. Its certainly worth the effort.

The post Even more Digital Transformation Must-Read Books appeared first on The Sand Reckoner.

December ’23

EU agrees new AI legislation

The EU Commission and European Parliament this week agreed the outline of an EU-wide AI Act that aims to provide safeguards on the use of advanced AI models. The proposed legislation forbids the use of AI algorithms in a number of application, including the use of tracking people through facial recognition (except for law enforcement) or for the purposes of ‘social scoring’. Companies will also have transparency obligations on the inner-workings of advanced models and the data that was used for training, and will be required to comply with a number of safety mechanisms including risk assessments, benchmarking and adversarial testing. It is notable that companies such as OpenAI and Google’s DeepMind have so far resisted calls for this sort of disclosure.

Google announces its Gemini family of multimodal AI models

Just last week, I wrote about Mirasol3B, a multimodal AI model, and this week that news is already old hat, as Google announced their flagship generative AI model, Gemini. This will be available in three flavours. The most performant of the three, known as Ultra, is said to outperform GPT-4 on most benchmarks. It is however not available for public use, and the version that is currently integrated into Bard is based on a less performant Pro version. (See here for the full technical report, and a critique here). Having played around with Gemini Pro on Bard, the experience is fairly similar to ChatGPT (based on GPT-4), but it clearly has a more up-to-date feature set. Looking forward to the general availability og Gemini Ultra.

MLOps – A primer

Whilst everyone involved in tech will be familiar with DevOps, the set of software engineering practices that span coding through to operation, its equivalent in the AI space, MLOps (Machine Learning Ops) is not as well known. The behaviour of machine learning and AI models is less predictable than traditional software, as it depends on the data used for training, the model structure and its parameters, the inputs used in production, as well as the software that hosts and interacts with the model. As such productising machine learning in a way that is safe, reliable and repeatable requires a structured approach to how data, models and software are managed, based very much on DevOps principles. Databricks provides a nice summary of the key elements.

Older posts…

Google’s new multimodal AI model

As AI models become ever more sophisticated, one of most challenging problems is how to combine different media types together. Video, audio and text data all have very different characteristics in terms of how they are represented in data as well as the AI models used to process them. This means that creating an AI model that can manipulate all forms of media is proving to be a big challenge. A couple of weeks ago, Google DeepMind announced a new model, called Mirasol3B that implements multimodal learning across audio, video and text in an efficient way. The draw for Google is obvious – how can it combine its vast YouTube catalogue in a meaningful way with its enormous largely text-based search engine. Although benchmarking indicates that this model may have broken new ground, researchers have criticised it for the opaqueness on how it works.

Using the Human Brain as a template for more efficient AI models

Although it is often claimed that neural netwrorks are modelled on human brains, the vast amounts of material that generative language or image models consume during their training bears little resemblance to how humans learn. Humans are clearly much more constrained in terms of the energy they consume when learning or problem solving. In a recent paper in Nature Machine Intelligence magazine, scientists from the University of Cambridge have sought to model an artificial neural network that contained constraints similar to those found in a human brain. The research showed that these constraints influenced the model to seek more efficient ways of solving problems. This obviously has very interesting implications for the development of AI models, particularly in designing systems that are both adaptable as well as efficient.

Anthropic’s ChatGPT rival sets an important benchmark

Anthropic, the startup backed by Amazon and Google, announced that Claud 2.1, its Large Language Model can process inputs with up to 200,000 tokens at once, equivalent to 500 pages of text. For comparison GPT-4 supports a token length of 8,000 or 32,000, depending on the model used. Token length, also known as the context window, is important as it represents the quantitiy of input information that it can consider when generating text. For example, this sets the upper limit on text it can summarise, or sets a limit before it can no longer ‘remember’ the previous context.

The hidden manual effort in creating AI models

Many generative AI systems, such as OpenAI’s GPT family of Large Language Models make use of human labelling to fine-tune and improve the prediction models, in a technique called “Reinforcement Learning from Human Feedback” (RLHF). A Wired article last month explored who carries out this data labelling. The article described how workers in places such as Venezuela, Colombia, east Africa, the Philippines and Kenya manually label images, outputs from large language models as part of their training process.

The Open Source vs Proprietary AI Models Faultlines

A row has escalated in the past few weeks over the relative threats to public safety of open-source and proprietary AI models. Meta, who famously released the inner workings of its Llama 2 models has come under criticism by some safety advocates who claim this lowers the bar for malicious third parties to use LLMs for nefarious purposes such as cybercrime or developing harmful biological or chemical agents. Unsuprisingly, OpenAI and Meta are on opposite sides of these faultlines, with Sam Altman, OpenAI’s CEO claiming that its closed proprietary model provides the best safeguards against exploitation. Yann LeCun, Meta’s head of AI and one of the godfathers of AI development, strongly makes counter-arguments that the very nature of closed AI systems makes their risks unknowable and can create a monopoly that concentrates humanity’s knowledge into black boxes is a threat to democracy and diversity of opinion.

AI’s Regulatory Outlook

As big tech argues about the merits of open-sourced vs proprietary models, governments around the world are trying to figure out the best way to keep their citizens safe. Some AI luminaries such as Geoff Hinton, Elon Musk and Sam Altman are warning against the existential risks of artificial general intelligence (AGI), while others, including Meta, are more concerned about the more prosaic risk to competition of ‘winner takes all’ economics and the cost of regulatory compliance on open source models. Last week, the US Government issued an Executive Order which places requirements on the establishment of guidelines and best practices, carrying red teaming exercises on large models and requiring disclosure on how large-scale computing clusters are used. This was folllowed by the ‘Bletchley Declaration’ at the AI Safety Summit hosted in the UK that outlines an international consensus on the need for scientific and policy collaboration in the face of AI risk, but was somewhat short on practical measures.

Dealing with Prompt Hacking

Despite their size and sophistication, large language models (LLMs) are particularly sensitive to the instructions, or ‘prompt’ used to generate an outcome. In its benign form, this is sometimes called ‘prompt engineering’ and a quick scour of the web throws up prompt templates for anything from creating a CV to answering a high school essay question. The darker side of prompt engineering is ‘prompt hackingexploits’ which uses carefully constructed prompts to work around safeguards and bypass protections in the model. This includes ‘indirect prompt injection’ which exploit the ability of many LLMs’ to ingest data as part of the query. The combination of LLMs’ inherent opaqueness of their inner workings, plus their ability to make use of data of potentially concerning origins, means that they should always be treated with caution, following the cybersec principle of least privileges.

State of AI 2023

Nathan Benaich, of Air Street Capital, a VC focused on AI ventures, issues an annual “State of AI report”. The 2023 issue was published a couple of weeks ago and highlights that although GPT-4 currently sets the benchmark in terms of large language performance (it is actually a multi-model model, as it was trained on text and images), efforts are growing to develop open source models that match the performance of proprietary models. Interestingly, the largest models are running out of open human-generated data that can be used to train them. The report provides a nice summary of the key research highlights of the year, where industry is investing, the political and safety implications and predictions for 2024. At 163 slides, it is a fairly hefty read.

October ’23

Towards AI Safety (1) – On Mechastic Interpretability

One of the (many) challenges in understanding how neural networks really work is that there is no easily-observable logic to how they actually work. They are not governed by simple mathematical relationships, making them very difficult to diagnose problems, or explain why they predict certain outcomes. The same is true for neuroscientists, who struggle to understand the function of individual neurons in the brain. Anthropic recently published a paper that describes how a large language model can be decomposed into more coherent features, e.g. describing themes such as legal language or DNA sequences, and then use another LLM to generate short descriptions of the features, through a process called “autointerpretability”. This work is aimed to provide a mechanistic model of how neural networks work in order to overcome concerns about their use in safety or ethically-sensitive applications.

Decomposing Language Models Into Understandable Components

Towards AI Safety (2) – Watermarking AI Images

In July, the White House announced that the main large tech companies had agreed to deploy watermarks to determine in a robust way whether they have been generated by their generative AI models. Watermarking involves adding patterns that are difficult to remove from the image that attest to their origin. The Register however reports that a team at the University of Maryland demonstrated that they were able to attack such schemes, both degrading the watermark (i.e. allowing an AI-generated image to skip detection) as well as making non-watermarked images appear as though they are AI-generated. It seems that there is way to go until we have robust systems to identify deepfakes.

Towards AI Safety (3) – Tackling Algorithmic Bias

As AI models, including generative AI models such as ChatGPT, Stable Diffusion, as well as other tools such as classifiers, fraud detectors, credit scoring algorithms and so on are trained on large sets of data, often from the Internet and other public datasets, they contain and reflect the biases contained within them. So, we have seen how a recruitment tool used by Amazon a few years ago showed bias against women as it was trained on the male-dominated applicant pool, while more recently AI-generated barbies displayed all the national stereotypes you might fear (including a German SS officer Barbie!) . An Article in Vox recently provided an overview on why fixing AI bias is so difficult, why it is everywhere, who is most negatively impacted (no prizes for guessing!) and some of the initiatives underway to tackle the problem.

AI’s Environmental Impact

A recent article in the NY Times quoted an analysis that predicted that by 2027 AI servers would use between 85 to 135 TWh annually, equal to the entire electricity consumption of Sweden, and 0.5% of the world’s electricity. For context, all data centres in 2022 consumed between 1 and 1.3% of the world’s electricity (excluding crypto-mining), and in 2021 was already responsible for 10-15% of Google’s electricity consumption. As many AI training techniques are at their infancy, as AI scales further, a paper by MIT predicts that the algorithms will be optimsed for efficiency and not only for accuracy, for example by stopping underperforming models or tracks early. There is definitely a sense that so far, in the race for AI headlines, all secondary considerations have been put aside. Even if companies and cloud providers are not driven by environmental concerns, the likely constraints on GPU supply will be sufficient motivation to push for algorithmic efficiency.

Previous articles

Generative AI copyright gets thorny

While Hollywood actors and writers are on strike, partly trying to protect themselves against AI-created derivatives of them and their work, a US federal court has rules that generative AI work will not be protected under US copyright law. In the ruling, the judge stated that although “copyright is designed to adapt with the times… (it) has never stretched so far, however, as to protect works generated by new forms of technology operating absent any guiding human hand.” In a related development, Microsoft have decided that they will underwrite and defend any customer of its Copilot AI services (which includes its generative coding tools) from any copyright infringement suits.

A closer look at Meta’s Open-Source alternative to Chat GPT

We have already looked at the impact of open-source large language models as an alternative to ChatGPT. These have the clear advantage that they can be used and trained on domain-specific data and thus be optimised to solve specific tasks, as exemplified by Bloomberg’s financial analysis model. Moreover, as the underlying model and training approaches are public, their strengths, limitations, biases and vulnerabilities are open to inspection. This article provides an overview of Lllama 2 as well explaining how to get your hands on the model and have a play with it yourself. The open source nature of LlaMa2 has stimulated an industry’s worth of activity tailoring it for specific applications, such as Colossal-AI’s large-scale training solution.

Exploring an LLM software stack

An article describing Colossal AI’s large-scale LlaMa 2 model training solution also provides a pretty clear outline of a typical software stack for training and operating large language models. Worth reading just for this.

Artificial Intelligence at the Edge – Looking at TinyML

Much of the discussion relating to the future of machine learning and generative AI models focuses on how future applications will require larger, more computationally-expensive models, with more parameters and much larger training sets. There is however an alternative approach, which instead considers how best to distribute algorithms on cheap low-power edge devices. The advantages are obvious. If AI algorithms can be run on end devices, be they cars, home sensors, health monitors, agricultural sensors and so on, they do not need to be hosted and processed on a server somewhere. For large systems, this has a significant impact on system resilience, responsiveness and privacy, as devices can be intelligent themselves, rather than sending all data for processing elsewhere. Light-weight models such as TensorFlow lite are designed to operate on the smallest, most power-efficient chipsets to bring AI processing out of the data centre to the real world.

Updated 2 July

A dissenting view. Why AI may not be as revolutionary to the world economy as we are assuming.

This essay takes a number of steps back and frames AI in the context of its likely long-term societal impact. In other words, where will it sit compared to the inventions, say, of agriculture or the steam engine? The authors, including The Economist‘s economics correspondent, take a refreshingly dissenting view. Challenges that will limit its impact include: drowning in information and content generated by AI, legal constraints of getting computers to make decisions impacting humans, the not insignificant issue of physical world interactions, and the challenge of mimicking human expertise. I don’t agree with everything that is said here, but as a counterpoint to AI hype, this is a fantastic read.

Will we survive the flood of AI content?

In a previous release of this list, we referenced a paper that touched on the value of human work where AI-generated content is assessed by other AI models. An essay this week by Alberto Romano asks what happens when AI-generated content increases to the point where most content is created by statistical models designed to mimic human coherence. Only this week an author of fiction observed that 81 out in a top 100 chart of self-published Kindle content were AI-generated. Search engines and social media algorithms were tuned to identify an promote content people will find more useful. How will this work when most content is computer generated?

Meta’s Transparency Quest

Meta, is in many ways a surprising AI pioneer. No only is it making some of the more interesting forays into open-source models, (see links below), but it is also in explaining how all the relevant recommender and ranking mechanisms work across Facebook and Instagram. While the algorithms themselves are not described in any detail (assume Meta consider these to be their ‘secret sauce’), you can find all the input signals that are used to rank content. This is a lot more than we have learnt from the likes of OpenAI. See here for an interview on Nick Clegg, Meta’s VP of global affairs (and former UK deputy PM).

Not so Massive. Device-optimised generative AI

Large language models and large diffusion models for image generation, are, well, large, and are typically limited to server-based deployments. This week Google published a paper that describes how they have optimised the memory needs for large diffusion models, such that they can support image creation from text input in under 12 seconds on a high-end smartphone GPU. While it still requires 2GB of RAM to hold the model parameters. Whilst this paper speaks to the optimisations required for generative adversarial networks, I suspect, we will see a greater focus in reducing the size of inference models to allow for deployment on devices.

Operationalising Machine Learning

With most of the discussions online focusing on AI models, their applications and real-world impact, it is easy to ignore the engineering discipline required to keep an AI product maintainable, reliable and secure. Just as DevOps principles allow software engineers to reliably and frequently release code that works, MLOps (Machine Learning Operations) are essential for creating an auditable, testable, end-to-end ML/AI pipeline from data ingestion, through to model training and tuning, and deployment and management. The AWS blog site provides an overview of how AWS supports MLOps, while Google describes how to implement an automated AI pipeline on their Google Cloud platform.

AI Security Models

The OWASP (Open Worldwide Application Security Project) Foundation is a community producing open-source tools and best-practice for application software security. Recently it has published a guide on AI security and privacy, tying into broader software good practice and then tying into AI-specific attack surface areas and vectors. A good place to start exploring privacy and security considerations relating to AI models.

How self-learning models can outperform much larger LLMs

LLMs are often characterised by the size of the model (parameters) and their training data, with the presumption that bigger is better. Large models however come with the obvious disadvantages of computational cost and privacy protection. However a paper by an MIT professor describes how implementing self-training model, where the AI model uses its own prediction (via a process called textual entailment) to teach itself without human intervention. The resulting 350m parameter model outperformed models such as Google’s LaMDA and GPT models.

The secret inside GPT-4

OpenAI has kept the inner workings of GPT-4 well under wraps, maintaining their aura as leaders in generative language models, with much speculation as to how GPT-4 is able to outperform its predecessors. A blog post this week says that there isn’t an underlying algorithmic or model breakthrough or a much larger model. Instead, GPT-4 connects 8 different models together in an unspecified way. It feels to me that OpenAI is now moving towards keeping the fundamental model structures to itself, presumably to maintain the edge in real-world performance it appears to have over its competitors.

The thorny issue of copyright and generative AI

The implications of the use of intellectual property being used in training sets of generative AI models, first arose with image-generating AI and has spawned a number of lawsuits, including one by Getty Images against Stable AI for copyright. It is however virtually impossible to tell with certainty whether a work was including in the training of a Large Language Model. For this reason, the EU are proposing to require companies to disclose the data used when training their models, so as to protect the creators of intellectual property, thereby creating licensing models for AI. We are beginning to see the beginnings of these commercial relationships, with Microsoft, Google, OpenAI and Adobe negotiating with media and information organisations such as News Corp, Axel Springer, New York Times and the Guardian.

GPT-4 is pretty good at Maths too (or Math, if you are American)

In a recent paper called “Let’s Verify Step-by-Step”, researchers at OpenAI describe how GPT-4 has improved the underlying model to solve maths problems. They applied a supervision model during training called “process supervision” in which feedback is provided on each step of the reasoning, and not simply on the outcome. The paper (see here) shows that this optimised model, based on GPT-4 can successfully solve 78% of problems in a test problem set, though does not provide information for vanilla GPT-4. Nevertheless, having experimented a bit myself, it is clear that GPT-4 currently is a lot more reliable at maths problems than GPT-3.5.

70% of developers aim to use AI

A survey by the developer chat site Stack Overflow released a couple of days ago showed that 44% of developers already use AI tools when coding, and a further 26% plan to do so soon. GitHub Copilot, a code completion tool is by far the most popular AI-powered developer tool, while ChatGPT is unsurprisingly the most used AI-enabled search tool. This clearly has implications for AI usage policies for companies, which are largely reticent to use such tools do the risk of IPR leakage.

Google introduces a framework for Secure AI.

Unimaginatively titled Secure AI Framework (SAIF), this initiative by Google brings good infosec practice into the artificial intelligence space. Its six pillars include building on established cloud and infrastructure security principles, implementing perimeter monitoring of inputs and outputs of AI models to detect anomalies, building the ability to scale to deal with automated attacks and creating fast feedback loops for vulnerability detection and mitigation.

GPT-4’s understanding of the world’s geography

There have been several studies exploring large language models’ ability to understand different categories of information, including software, exam curricula and literature. In a paper published on arXiv, scientists at a number of universities discover the remarkable geographic understanding within GPT-4, which is able to return basic geographic data such as socio-economic indicators, and physical geography such as topography. More impressively, it can carry out route planning and figure out routes, such as key transport routes (maritime, rail and air). Whilst subject to hallucinations and missing data, it is really quite impressive.

Bloomberg’s purpose-built finance large language model

We have already seen many papers and articles on how generalist LLMs such as GPT-3 can be applied to solve problems across a broad range of domains. A couple of months ago, Bloomberg announced BloombergGPT^TM , an LLM based on BLOOM with a 363 billion token dataset created from Bloomberg’s private archive of financial data, and augmented with a 345 billion token public data training set. In a paper published on arXiv, Bloomberg claims that this model outperforms larger, more-general purpose LLMs for tasks such as financial sentiment analysis, named entity recognition, and conversational reasoning of financial data. This is a remarkable case study for anyone considering creating a domain-specific LLM.

Introducing BloombergGPT, Bloomberg’s 50-billion parameter large language model, purpose-built from scratch for finance

Will incumbents’ moats see off the waves of AI start-ups?

A few weeks ago, I explored the much-publicised clarion call of a Google researcher who claimed that Open Source will eat Google’s AI breakfast. Alberto Romero, a researcher at Cambrian AI takes a dissenting view, arguing that open-source models are tuned against closed-source models, through a process called self-instructing and consequently without incurring the prohibitive cost of training an LLM from scratch, open-source models will struggle to compete. Secondly, incumbents have access to millions of customers, which gives them an unparalleled route to market. We have already seen how Microsoft is integrating GPT into GitHub and its Office suite of productivity software, while Adobe’s FireFly has been wowing Photoshop users. Watch this space.

AI-assisted Writing and the Meaning of Work

Ethan Mollick, a Wharton professor, is one of the most insightful observers of the implications of AI. As Microsoft prepares to embed GPT-4 within its Office suite, it is surely only a matter of a few weeks before AI-assisted ‘Word’smithing becomes commonplace. What meaning and value do we assign to work that has only taken a few prompts to a generative AI system to create? The efficiency gains will be amazing, but expect it to be a bumpy ride.

Meta’s Multilingual Model supports over 1000 different languages.

We have already seen below the strides Meta is making, including on multi-modal foundation models. The rate of innovation shows no signs of abating, having recently open-sourced a multilingual model that was trained on 1,162 languages. To overcome the dearth of labelled datasets for many of the world’s languages, the researches used textual and audio data from religious texts, including the Bible, before unsupervised learning was applied to a further 4000 languages. The model was made available through extensions to Facebook AI’s popular PyTorch library.

The genesis of ChatGPT

The MIT Technology Review has a great story on how ChatGPT was released. What really stands out is how surprised the team at OpenAI were by how it became a viral sensation, and how the importance of accuracy has increased now that it is acting effectively as a search engine.

Will AI veer towards open or closed-sourced models?

Although Meta (i.e. Facebook) has not quite been hitting the AI headlines, its team, led by YannLeCun, is very active. One of its most significant contributions has been the release of LLaMA, a large language model trained on 1.4 trillion parameters. By sharing the code, the Meta team is hoping to drive faster innovation, particularly in adapting it to different use cases. Likewise, Stability AI has open-sourced its text-to-image model in the hope of benefitting from innovation amongst developers. Although a researcher at Google claimed that fighting Open Source is a “losing battle”, the size of these models means that they are trained by large tech companies, and it is unclear for how much longer this openness will persist.

Updated 23 May

Meta’s Multimodal AI Models

Multimodal AI models link different content types (e.g. text, audio, video) into a single index or ’embedding space’ and are increasingly a subject of much research. For example, AI image generators such as Midjourney and DALL-E link text decoders with image inference models. (See here for a good overview). Meta has announced an open-sourced AI model called ImageBind that brings together text, image, video, audio and sensor data (including depth, thermal and inertial measurements). For example, Meta claim that the model could create an image of a rainy scene from the sound of rain, or conversely add appropriate audio to a video sequence.

Updated 22 May

Large Language Model Landscape

With all the attention being heaped upon OpenAI’s ChatGPT, you’d be forgiven for thinking that GPT-3.5/4 was the only large language model in town. However, as a blog site maintained by Alan Hardman makes clear, this is an increasingly crowded space. The author helpfully also provides a list of LLMs, datasets , benchmarking and labs. An essential reference.

Updated 18 May

Annual Stanford AI Index Report

Not exactly a quick read, and I certainly have not yet been through it all yet, but if nothing else the key takeouts provide a quick snapshot of the state of AI. Points of interest are that industry has firmly taken over from academia in creating new AI models (not coincidentally the exponential increase in training compute continues), Chinese universities lead the world in AI publications and AI models performance continues to improve, with some categories out-performing the human baseline (such as language inference). A good long read.

Microsoft researchers make claims on Artificial General Intelligence

It is said that one way to destroy your credibility in the AI space is to claim that you have built a system capable of Artificial General Intelligence. This is generally taken as being an AI system that can be applied to a number of unrelated fields, achieving a level of capability similar or exceeding human capabilities. Cade Metz, who recently broke the news of Geoffrey Hinton’s AI concerns reports that researchers at Microsoft recently published a paper stating that GPT-4 is demonstrating ‘sparks’ of AGI that surprised the researchers. They describe a number of tasks that it was able to carry out including (rather incredibly) write a rhyming proof that there are an infinite number of prime numbers.

Updated 15 May

OpenAI Improves ChatGPT Privacy

Addressing concerns in many jurisdictions about the privacy impact of ChatGPT (such as Italy which temporarily banned its use), OpenAI has introduced features to allow individuals and organisations to request that they do not appear in answers via a Personal Data Removal Request Form. This is however only the opening gambit and is unlikely to satisfy regulators, as it has no bearing on whether data (correct or otherwise) can be restricted from training, and the risk of your chat history influencing the answers it gives other users.

Updated 13 May

How do Transformers Work?

Hugging Face, a company that provides AI models and datasets to developers offers a free online course on natural language processing (NLP) which contains a nice overview of the workings of the transformer, the AI architecture that underpins most modern large language models. For those of a more technical bent, you can read the original paper where Google scientists first described the transformer model and its attention mechanism. [Updated 22 -May] For further, more accessible, descriptions of the transformer model, see Transformers from Scratch by Peter Bloem, who also offers code in github and a few video lectures.

Updated 12 May

Size does not always matter

An article by the IEEE argues that there isn’t an inexorable correlation between size and model performance and that smaller models trained on larger datasets can outperform larger models. The cost of training between these two scenarios is unclear, but this may be the start away from a ‘number of parameters’ arms race, or “my model is bigger than yours” debate. Sam Altman, CEO of OpenAI made similar point at an MIT conference last month.

Updated 11 May

A look at ChatGPT’s Code Interpreter – A program that creates programs

The dystopian scenario that keeps AI pessimists alive is a future where AI systems are able to generate new AI systems, getting into a runaway loop of ever-improving capability which humans are powerless to stop. I am quite sceptical of this scenario, but GPT-4’s code interpreter, a sandboxed environment where GPT-4 can create, run and improve Python code is quite amazing, a preview of a world to come, and one that is particularly well-suited for complex data analysis.

Stanford University study on the impact of AI assistants on productivity

It has often been claimed that Artificial Intelligence can do for white-collar work what automation has already done for manufacturing. This is a viewpoint I subscribe to, and Stanford University’s Human-Centered Artificial Intelligence (HAI) centre has shown that call centre workers at a Fortune 500 software companies did indeed see an average of 13.8% productivity increase. Of particular note, the AI assistant was able to accelerate the up-skilling of workers, reaching productivity levels in two months that would previously have taken six months.

Updated 9 May

Google and OpenAI struggling to keep up with open-source AI

A Google researcher claims that the current generation of Large Language Models do not have any intrinsic insurmountable defenses, and that the threat/opportunity (depending on your vantage point) of open-sourced AI models was being overlooked. Following the leaking to the public of Meta’s open-sourced LLaMA model, a flurry of innovation has resulted in models being trained for as little as $100 worth of cloud compute.

WIRED, The Hacking of ChatGPT is Just Getting Started

An insight into what it means for a large language model to be compromised, the techniques being used to bypass ChatGPT’s safeguards, and how the field of Generative AI vulnerability and security research is still in its infancy.

Cade Metz, Genius Makers

For a fast-moving history of how a collection of doctoral students, researchers and academics persevered for years in relative obscurity before being suddenly cast into the spotlight as they became the most sought-after talent in tech. Charting the genesis of companies that are now household names such as DeepMind and OpenAI, Genius Makers tells the story of the multi-million tussle between Silicon Valley giants as they raced to assemble the best AI teams to build systems that can lay claim to human or super-human intelligence. Fascinating reading, especially as this book was written before generative systems exploded into the public consciousness.

The Economist – Special AI Edition

The Economist starts its special edition on artificial intelligence with an essay that takes the long view on the impact AI may have on humans’ sense of self and exceptionalism. Comparing it to the invention of printing, the dawn of the world wide web, and psychoanalysis, the essay posits that advances in AI will also lead to a reassessment of how humans understand the world. Are LLMs simply sequencing words, or is something more fundamental emerging? Less controversial but equally enlightening articles on how ChatGPT works (self-attention models), and whether they provide societal-level risks.

A paid-for

The post Artificial Intelligence Good Reads – Dec 23 appeared first on The Sand Reckoner.

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.

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.

Further Reading

1. Muthukrishna M., Henrich J., “Innovation in the Collective Brain,”, Philosophical Transactions of the Royal Society – Biological Sciences, March 2016.

2. “Who Invented the Automobile?”, Library of Congress Website.

3. Dieffenbacher S., “Types of Innovation: How the 4 Innovation Types Can Hep your Business”, Digital Leadership, March 2023.

4. Matthew Syed, “Innovation is not optional“

5. Edmundson A., Jang S., Casciaro T., “Cross-Silo Leadership”, Harvard Business Review, May 2019.

6. Leonardi P., Rhee L., “Finding New Ideas When You Don’t Have a Broad Network,” Harvard Business Review, Mar 2018.

7. Knee J., “What’s Amazon’s Secret?”, New York Times, February 2021.

8. Epstein D., “Range: How Generalists Triumph in a Specialised World,” Pan Books, 2019

9. Gates B., “We need more Rogers,” GatesNotes, December 2020.

10. Griffith R., Lee S., Straathof B., “Recombinant Innovation and the boundaries of the firm,” International Journal of Industrial Organization, Nov 2016.

11. Bettenmann D., Giones F., Brem A., Gneiting P., “Break Out to Open Innovation,” MIT Sloan Management Review, Dec 2021

12. Tsouri M., Hansen T., Hanson J., Markus S., “Knowledge Recombination for Emerging Technological Innovations: The case of Green Shipping, Technovation, Jan 2022

13. “Regulation and ‘Combinatorial Innovation'”, Open Data Institute, April 2020

The post Recombinant Innovation – the Importance of Joining Dots appeared first on The Sand Reckoner.

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.

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.

Further Reading

1. Reynolds A. and Lewis D., “Teams Solve Problems Faster When They’re More Cognitively Diverse,” Harvard Business Review, March 2017

2. Baron-Cohen S., “The Pattern Seekers – A New Theory of Human Evolution,” Penguin, 2020.

3. Syed M., “Rebel Ideas: The Power of Thinking Differently,” John Marray, 2021.

4. Chamorro-Premuzic T, Winsborough D., “Personality Tests Can Help Balance a Team,” Harvard Business Review, March 2015

5. Matthew Syed Consulting, “Diversity is vital to turbocharge innovation and drive better decisions,” June 2021

6. Saxton A., “The Power of Cognitive Diversity for our Military,” The Center for Junior Officers, US Army.

7. Lyall J., “Divided Armies: Inequality and Battlefied Performance in Modern War”, Princeton University Press, 2020. Reviewed in International Affairs, Oxford University Press, 2021

8. The Herston Project, “3 Ways You can Improve the Diversity in Your Teams,” July 2020

9. Smith M., “More than a Buzzword: Diversity can help defeat Disinformation,” War On The Rocks, 2021

10. Sunstein C., “Amazon is Right that Disagreement results in Better Decisions,” Harvard Business Review, August 2015.

The post Many Points of View – Why Cognitive Diversity Matters appeared first on The Sand Reckoner.

It has been impossible to miss or ignore the hype about ChatGPT in any of my LinkedIn and Twitter feeds or business magazines. Clearly at the peak of a hype cycle, much has been written about the transformative effect generative AI language models will have on industries as diverse as search, law, book-writing and software development. It was therefore time to understand a bit better the inner workings of Chat GPT, OpenAI’s language model underpinning Microsoft’s new foray into Internet Search. What better way, I thought, than simply asking ChatGPT to explain how it works? As I don’t yet have access to Bing’s AI Beta program, probably my just desserts for ignoring Bing for over a decade, I interviewed OpenAI’s ChatGPT bot.

A fantastic writing companion

The full, unedited transcript is shown below, but before diving into the interview, here are some of my own thoughts. First of all, this has been, by far, the easiest blog post I have written. Even were I not using whole sections of AI-generated text, these tools are fantastic for carrying out preliminary research. Rather than sifting through reams of Google pages, you get a neatly summarised, generally-accurate summary of what you are looking for. As the responses are structured to mimic human-generated writing, the research process feels more natural. To me, the biggest revelation was that it exposed the extent to which Google has rewired the way we think. We have learned how to think by parsing through lists, filtering out irrelevant entries, ignoring advertising, and learning how to write search queries that give you the best chance of landing the answers you are looking for. Generative AI models feel a lot more natural, and can clearly speed up the process of creating those first rough drafts of ideas, and I suspect that writer’s block (at least when it comes to blog writing) may become a thing of the past.

Give out Name, Rank and Number only

It feels like ChatGPT has been on a “Resistance to Interrogation” training course. While it is happy to give generalities on how the language model is trained and provides responses, it resists providing specifics. So any questions relating to the size of the training data set, what it included, the type of validation testing carried out, remained unanswered. ChatGPT, it seems, is a black box to itself too. We are clearly a way from introspective, sentient AI systems.

The Transformer

ChatGPT is based on a neural network architecture called a transformer, which was actually introduced by Google researchers in 2017. Explaining how this model works lies outside the ambition of this blog, though if you are interested, this article is a good starting point. Nevertheless, the strengths of the model lie in its ability to understand context, in other words, the meaning of a phrase depending on the overall phraseology. For example, humans make use of context when determining whether a jaguar is a large cat or a nice car. Context is extremely important both when training the model, in other words, taking in the large input data set it bases its responses on, as well as in understanding the questions being made of it. The second reported advantage of transformer networks is that they lend themselves to parallelisation, meaning that, given enough computing resources, they can be trained and generate responses quicker than other approaches.

Avoiding offence

In order to be viable in the real world, AI chatbots need to be reliable, providing fair responses that are free from bias, and have safeguards to prevent them from being used for harmful purposes. ChatGPT addresses this in three ways. First, the input training data set is selected so as to, as much as possible, be fair and diverse, whilst removing datasets that may be either discriminatory, offensive or biased. Although OpenAI has said that it is committed to being transparent about how the language model is developed, I was unable to find information on the training data set or training procedures used. It then applies checks on the responses it provides, including algorithms to detect “bias and toxicity” as well as human evaluation of the responses. Once again, no data is provided, so we have no way of telling how effective these guardrails are. Finally, there are checks that prohibit the chatbot from providing a response to a question that is “inappropriate and not in line with ethical and moral principles.” To figure out what these principles include, I had a look at OpenAI’s usage policies, which intriguingly also did not allow its use for “high-risk government decision-making!”

The Interview

Anyway, enough of my thoughts. Here’s what ChatGPT had to say about itself.

Good evening, ChatGPT. How would you describe yourself?

Good evening! As an artificial intelligence language model, I am a program designed to simulate human communication and generate text-based responses to user input. I was created by OpenAI using a deep learning architecture and trained on vast amounts of text data, allowing me to understand and generate natural language responses to a wide range of topics.

While I am not a sentient being and do not have emotions or personal experiences, I can use my programming to provide information, answer questions, and engage in conversations with users. My purpose is to assist and provide value to those who interact with me in a variety of ways, whether that be through entertainment, education, or problem-solving.

Nice to meet you. How does your artificial intelligence language model work?

It’s nice to meet you too!

At a high level, my artificial intelligence language model works by processing text input and generating a response based on patterns and associations learned from vast amounts of data. Here is a brief overview of how it works:

1. Training: To create my AI language model, OpenAI first trained me on a massive amount of text data, such as books, articles, and websites. This training data helps me learn the patterns and relationships between words and phrases in natural language.

2. Architecture: I use a deep learning architecture called a transformer, which was specifically designed for natural language processing. This architecture allows me to understand the meaning and context of text input and generate relevant and coherent responses.

3. Natural language processing: When a user inputs text, I use natural language processing techniques to analyze the input and understand its meaning, context, and intent.

4. Response generation: Once I understand the user’s input, I use the patterns and associations learned during training to generate a response that is relevant to the input and maintains coherence and context.

5. Iterative improvement: As I interact with more users and receive feedback, my creators at OpenAI use that information to continuously improve and refine my language model, ensuring that I remain up-to-date and accurate.

Overall, my AI language model is a complex system that uses machine learning and natural language processing techniques to understand and generate human-like responses to text input.

So let’s start off talking about training. What data sets, and how much data was used to train this version of ChatGPT?

Sure! The version of ChatGPT that you are interacting with was trained on a large and diverse dataset of text called the WebText dataset, which was compiled by scraping billions of web pages from the internet. The WebText dataset contains a wide variety of text, including articles, blogs, forums, and other web content, covering many different topics and styles of writing.

The WebText dataset used to train the largest version of GPT (GPT-3), which has 175 billion parameters. However, the version of ChatGPT that you are interacting with is a smaller version, and its exact size and training data may depend on the specific implementation or deployment.

Overall, the specific amount of data and the exact sources used to train ChatGPT may vary, as the model can be fine-tuned on additional domain-specific datasets depending on the intended use case. But in general, the training process for language models like ChatGPT involves using vast amounts of text data to train the model to recognize patterns and associations between words and phrases, allowing it to generate human-like responses to text input.

Aha, I thought I was interacting with GPT-3. Which version of GPT are you then?

I apologize for the confusion earlier. As a language model developed by OpenAI, I am not an individual version of GPT, but rather a separate AI language model that was trained using techniques similar to those used to train GPT. While I share many similarities with GPT, I have been specifically designed to provide assistance and generate text-based responses for a variety of use cases, ranging from entertainment and education to customer service and technical support.

The exact version of ChatGPT that you are interacting with depends on the specific implementation or deployment. However, in general, ChatGPT is a smaller and more lightweight language model than GPT-3, with fewer parameters and less computational resources required to run. This makes ChatGPT a more accessible and cost-effective option for businesses and individuals who want to incorporate AI language processing into their products or services.

So coming back to training data. Are you able to say how large the dataset was that was used to train you?

As an AI language model, I am designed to be flexible and adaptable, and the specific dataset used to train me may vary depending on the implementation and deployment. However, in general, the dataset used to train my base architecture is likely to be similar to the WebText dataset that was used to train the GPT models, which contains billions of words.

That being said, the exact size and composition of the training data used to train me may depend on the specific implementation or deployment. In some cases, I may be fine-tuned on additional domain-specific datasets to better suit a particular use case or application.

Overall, the size and quality of the training data used to train an AI language model like me can have a significant impact on the model’s performance and capabilities. The more diverse and representative the training data is, the more likely the model is to generalize well to new inputs and generate coherent, contextually appropriate responses.

Ok, so I see we are not going to get a straight answer on the size of your training dataset. How do you ensure that your training data does not include information that is discriminatory, biased, illegal or simply likely to cause offence?

As an AI language model, I do not have direct control over the training data that I am provided with, as this is typically handled by my creators at OpenAI. However, OpenAI is committed to ensuring that my training data is diverse, representative, and ethically sourced, and takes steps to address issues such as discrimination, bias, and offensive language.

To ensure the ethical use of AI language models like me, OpenAI has implemented a set of ethical guidelines and principles, which include a commitment to promoting safety, transparency, and fairness in the development and deployment of AI. These guidelines also include specific measures to mitigate the risk of bias, discrimination, and offensive language in AI language models, including:

• Data selection: OpenAI takes care to select training data that is diverse and representative, and avoids datasets that contain discriminatory or offensive language. In addition, OpenAI may use techniques such as adversarial training to identify and remove biased or discriminatory patterns from the training data.

• Bias monitoring: OpenAI actively monitors the performance of AI language models like me to detect and mitigate instances of bias or discrimination in the generated output.

• Transparency: OpenAI is committed to being transparent about the development and capabilities of AI language models, and may release information about the training data and testing procedures used to create and evaluate these models.

Overall, while AI language models like me are not perfect and may still contain biases or errors, OpenAI is committed to ensuring that I am developed and used in an ethical and responsible manner, and takes active steps to address any issues that may arise.

Let’s move on from training. You mentioned earlier that you use a deep learning architecture called a transformer. What can you tell us about it and how it works?

Sure! The Transformer is a deep learning architecture that was first introduced in the paper “Attention Is All You Need” by Vaswani et al. in 2017. The Transformer was designed to address some of the limitations of previous sequence-to-sequence architectures, such as Recurrent Neural Networks (RNNs), that struggled with long-term dependencies and suffered from slow training and inference times.

The Transformer is based on the concept of attention, which allows the model to focus on specific parts of the input sequence when generating output. This attention mechanism is what allows the Transformer to process input sequences in parallel, rather than sequentially as in RNNs.

The Transformer architecture consists of an encoder and a decoder, which are connected by multiple layers of self-attention and feedforward neural networks. The encoder takes in the input sequence and generates a sequence of encoded representations, which are then used by the decoder to generate the output sequence. The self-attention mechanism allows the model to compute attention weights for each input element based on its relevance to the current output element, allowing the model to focus on the most relevant parts of the input when generating output.

The Transformer has been widely adopted in natural language processing tasks, including machine translation, text generation, and question-answering. The GPT models, including the version of ChatGPT that you are interacting with, are based on the Transformer architecture, and use self-attention to process input sequences and generate human-like responses.

Is this an example of a Generative Adversarial Network (or GAN)?

No, the Transformer architecture is not an example of a Generative Adversarial Network (GAN). GANs are a type of deep learning model that consists of two neural networks: a generator and a discriminator. The generator produces new data samples, such as images or text, while the discriminator tries to distinguish between the generated samples and real samples from the training data.

The Transformer, on the other hand, is a type of sequence-to-sequence model that is used for tasks such as machine translation, text generation, and question-answering. It uses the self-attention mechanism to process input sequences and generate human-like responses.

While both GANs and the Transformer are based on deep learning techniques, they have different architectures and are used for different tasks. GANs are used for generative tasks, such as image and text generation, while the Transformer is used for natural language processing tasks that require a model to generate coherent and contextually appropriate responses.

Ok, thanks. You have corrected my misunderstanding. So now coming to response generation. Can you provide some more details as to how you generate a response that best answers the question posed by the user?

Sure, I’d be happy to provide some more details on how I generate a response that best answers a user’s question.

The process of generating a response starts with the user’s input, which is first tokenized and transformed into a sequence of embeddings. The embeddings are then fed into the Transformer, which uses self-attention to encode the input sequence and generate an internal representation of the input.

Next, the internal representation of the input is used by the Transformer to generate a sequence of output embeddings, which are then transformed back into human-readable text. The output sequence is generated one token at a time, with each token being generated based on the previously generated tokens as well as the internal representation of the input.

During the generation process, the Transformer uses a combination of heuristics and learned knowledge to select the most appropriate response. This includes factors such as the semantic meaning of the input, the context of the conversation, and the likelihood of the response being grammatically correct and fluent.

In addition, the Transformer may use a variety of techniques to ensure that the generated response is relevant and informative. For example, it may use information retrieval techniques to search a large corpus of text to find relevant information, or it may use knowledge graphs or other structured data to provide more precise and accurate responses.

Overall, the process of generating a response is a complex and iterative one that involves a combination of heuristics, learned knowledge, and natural language understanding. The goal is to provide a response that is both relevant and informative, and that accurately reflects the user’s intent and the context of the conversation.

That’s been really helpful. Can you now explain how OpenAI monitors the responses you generate for accuracy, correctness and bias. Is there any data on this you can share?

OpenAI has several approaches to monitor the responses that models like mine generate for accuracy, correctness, and bias. Here are a few examples:

1. Human evaluations: One way to evaluate the quality of the responses generated by a language model is to ask human evaluators to rate them on various dimensions such as relevance, coherence, and fluency. OpenAI often conducts such evaluations to assess the performance of its language models.

2. Intrinsic evaluation metrics: OpenAI also uses several intrinsic evaluation metrics to assess the quality of its models. These metrics are designed to measure specific aspects of a model’s performance, such as its ability to generate diverse responses or to produce syntactically correct sentences.

3. External evaluation metrics: In addition to intrinsic evaluation metrics, OpenAI also uses external evaluation metrics to assess the quality of its models. These metrics involve comparing the performance of a model to a benchmark or a human baseline on a specific task, such as question-answering or text summarization.

4. Bias and toxicity detection: OpenAI uses several methods to detect bias and toxicity in the responses generated by language models. For example, it may use heuristics or machine learning models to detect offensive language or discriminatory content in the model’s output. Additionally, OpenAI has developed a tool called the “GPT-3 Data Poisoning Detector” that can help detect and prevent the use of biased or malicious training data.

5. Real-world testing: Finally, OpenAI also conducts real-world testing of its language models to evaluate their performance in realistic scenarios. This involves deploying the models in production environments and evaluating their performance based on real user interactions.

While I don’t have access to specific data on the performance of my model, I can tell you that OpenAI takes evaluation and monitoring very seriously and is committed to developing models that are both accurate and unbiased.

You mentioned external evaluation metrics. Is there any specific data on these that you can share with us?

I don’t have access to specific data on external evaluation metrics for my model, but I can provide some general information on how OpenAI evaluates its language models.

One commonly used external evaluation metric is the General Language Understanding Evaluation (GLUE) benchmark, which consists of a set of natural language understanding tasks such as sentiment analysis, question-answering, and text classification. The goal of the benchmark is to evaluate a model’s ability to perform a range of language understanding tasks, and to compare the performance of different models on the same tasks.

Another external evaluation metric is the SuperGLUE benchmark, which is a more challenging extension of the GLUE benchmark that includes a wider range of tasks and requires models to have a deeper understanding of language and reasoning.

In addition to these benchmarks, OpenAI also evaluates its models on specific real-world tasks, such as language translation, summarization, and conversation generation. The performance of the models is evaluated based on various metrics such as accuracy, fluency, and relevance.

It’s worth noting that while external evaluation metrics are useful for comparing the performance of different models on specific tasks, they are not always a perfect measure of a model’s overall quality or usefulness. The performance of a language model can vary depending on the task, the data it is trained on, and the specific requirements of the application it is being used for. As a result, it’s important to use a range of evaluation metrics and to evaluate a model in a variety of settings to get a comprehensive understanding of its strengths and limitations.

One final question, we have spoken about language models, but how many languages does your model support?

As a language model, I can support a wide range of languages. However, my primary language is English, and I am optimized for generating responses in that language.

In addition to English, I can also generate responses in other languages, such as Spanish, French, German, Italian, Chinese, and Japanese, among others. However, my performance in these languages may not be as good as in English, especially if I haven’t been specifically trained on them.

It’s worth noting that different languages have different grammatical structures, vocabularies, and cultural contexts, which can affect the performance of a language model. Therefore, training a model to generate responses in a specific language often requires a large amount of high-quality data in that language, as well as careful consideration of the linguistic and cultural nuances of the target language.

Ok, so on the topic of languages, I hope you don’t mind one further question. Does your model, and indeed your responses, distinguish between US English or British English?

As a language model, I’m able to generate responses in different dialects and varieties of English, including US English and British English. However, my training data primarily consists of written text from a variety of sources, and as a result, my responses may reflect a more general form of English rather than a specific dialect or accent.

That being said, I can take into account regional differences in vocabulary, spelling, and grammar when generating responses, and I can adapt to different styles of language use based on the context and the user’s input. For example, if a user inputs a question using British English spelling or vocabulary, I can generate a response that reflects that style of language use. Similarly, if a user inputs a question using American English spelling or vocabulary, I can generate a response that reflects that style of language use.

In short, while my responses may not always reflect a specific dialect or accent of English, I can adapt to different styles of language use and take into account regional differences when generating responses.

Thanks for your time. It has been very insightful.

You’re welcome! I’m glad I could help. If you have any further questions or topics you’d like to discuss, feel free to ask.

The post ChatGPT according to ChatGPT appeared first on The Sand Reckoner.

Ukraine Drone Operations as Open Innovation

Much has been talked about the Ukraine war being dominated by drones. Whilst some of the attention is a case of visibility bias driven by the very social media-friendly footage of artillery strikes and tanks exploding captured by drones, it is clear that these are having a big impact on the battlefield. Ukraine has developed this capability organically by coopting volunteer groups of drone and software specialists that have been originally outside Ukraine’s traditional military structures. One such group, called the Aerorozvidka (aerial reconnaissance in Ukrainian), is an NGO that has worked to customise commercial off-the-shelf drones. Established in 2014 [2] to support the fight against Russia-backed separatists in the Donbas, Aerorozvidka is at the forefront of providing drone technology to complement and support the Ukrainian armed forces, using them to guide and correct artillery fire beyond the line-of-sight, using thermal imaging to spot enemy troops and vehicles and attack Russian tanks and vehicles by dropping cheap, armour-piercing grenades fitted with 3D-printed fins.

Aerorozvidka is not the only organisation innovating in the operations of drones. The Kyiv-based Dronarnia workshop produces drones to order for military units via an online ordering website, while the Dnipro-1 unit of the National Guard runs a workshop customising explosives for use on drones.

This is a classic case study of Open Innovation [3], where when an organisation is faced with a competitive environment for which it hasn’t got the capability to compete effectively, it co-opts the innovation potential of outsiders. Companies and militaries alike develop the organisational capability to compete in a given context, be it by producing a particular product, or fighting a certain type of war. Where the context changes faster than the organisation’s capability to adapt or assimilate the new skills required, then bringing in external know-how can be the fastest way in closing this knowledge gap. The Russian invasion of Ukraine was an extreme example of a rapid change in a competitive environment.

Networked Organisations and Bottom-up Innovation

Open Innovation is however only possible if the organisation is prepared to make its boundaries more permeable, allowing the flow of information and ideas into and out of the organisation. Such ‘permeability’ runs counter to the military’s culture of operational security, or OpSec, which is considered crucial to maintaining tactical and strategic surprise, ensuring that your enemy remains unaware of your intentions. In his book ‘Team of Teams’ [4], Gen Stanley McChrystal showed that top-down hierarchical organisations, such as traditional militaries, are too slow to react to a rapidly-changing environment that requires rapid response and shift of tactics. Instead, he advocates for empowering decision-making as close to where the action is, whilst simultaneously providing as much operational visibility across teams as possible to allow teams to make the best decisions.

Gary Kasparov, the former chess champion and Russian dissident frames the Ukrainian approach as a contest between Ukraine’s lateral networks and Russia’s vertical hierarchies, and explicitly makes the analogy with how tech start-ups can disrupt legacy companies using agility, speed bottom-up innovation. The comparison is particularly apt, as it highlights that much like start-ups, Ukraine has to operate in a different way to its adversary as it hasn’t got the depth of resources, strategic capability and willingness to waste human capital as Russia has. Ukraine does however have the skills and culture to be particularly effective in this space. Unlike Russian IT companies which relied on a large internal market, and so focused on working with Russian companies, Ukrainian software companies had to seek customers overseas, particularly in Europe and so they become adept at working in English, adopting the best practices used by the tech industry. For example, the Financial Times [5] tells the story of a Ukrainian IT engineer, who after 2 decades working for large western companies, established a tech hub associated with a Ukrainian motorised brigade to come up with tech solutions to the problems being faced in the field. Connected to the Internet via Starlink terminals, this team created a series of hackathons, whereby different teams competed and collaborated in rapid fashion to come up with solutions as to how to protect Ukraine’s comms equipment in the field or how to incapacitate Russia’s drones.

Drone Warfare as Disruptive Innovation

The theory of disruptive innovation was introduced by Clayton Christensen in 1995 [6]. In the seminal book, The Innovator’s Dilemma, Christensen showed how disruptive innovations often start addressing problems in less valuable market segments that are ignored by incumbents. They do however benefit from steeper performance improvement curves than existing technologies, meaning that they sooner or later disrupt the business model of existing mainstream products. A classic example of disruptive innovation was Netflix’s launch in 1997 as a niche mail-order DVD service targeting niche under-served segments – movie buffs and online shoppers.

Many aspects of Ukraine’s response is following this classic model. For example, typical commercially-available drones such as those from DJI only cost around £2000-3000. However, their limited range and payload and lack of protection against electronic countermeasures meant that they were not considered to be viable in a military context by most armies. What these drones lacked in capability, they made up for in availability, cost and adaptability, with Ukrainian software engineers customising the software to make them more difficult to detect. Such systems show great cost asymmetries, with these low-cost drones able to destroy or incapacitate Russia’s tanks, which cost several hundred thousand dollars each, to around $2-3m for the most modern variants.

However, vulnerability remained an issue, and with an average life expectancy of about three flights, Ukraine’s drone operators adapted quickly. As predicted by Christensen’s disruption theory, Ukraine’s engineers are iterating rapidly, both by creating more capable devices, including the R18 octocopter that can survive the loss of one motor, and carry a load of 5kg. Similarly, Ukraine has managed to deter the Russian Navy’s Black Sea fleet from venturing too close to its waters through a mix of home-grown anti-ship missiles (an example of sustaining innovation) and a fleet of remotely controlled explosive drones (disruptive innovation).

Scaling – Army of Drones

Having established this highly agile and responsive drone operations capability, Ukraine faced the challenge of scaling it to cover the 1000km front line it is fighting on. The Ukrainian Ministry of Transformation established a programme, called Army of Drones [10], a crowd-sourcing initiative, supported by a number of celebrities such as Star Wars’ Mark Hamill (of Luke Skywalker fame) to purchase both commercial off-the-shelf drones as well as more capable reconnaissance drones that can fly for up to 24 hours. This form of crowdfunding driven by social media can be considered as the 21st century equivalent of the War Bonds that were used to purchase Spitfires in the Second World War.

Real-time Networked Intelligence

The existential threat posed by the Russian invasion required a societal-wide response, not solely from Ukraine’s existing military structures, but also through a myriad of affiliated and non-affiliated volunteer groups. This created a big coordination challenge. To address this, the Ukrainian ministries of defence and digital transformation created a digital situational awareness system, which allows personnel equipped with appropriate applications on their laptops, tablets or mobile phones to share information about the enemy. [11] This system, called Delta, even makes use of chatbots to simplify the process of submitting information. When combined with the Starlink satellite communications system, this allows the Ukrainian military to create a near real-time aggregated view of enemy activity, annotated with data, UAV imagery and satellite pictures allowing it to respond to threats as they evolve.

What is telling is that although Delta predates the Russian invasion, its development has been accelerated by software engineers from the private sector who have joined the Ministry of Defence’s Innovation Centre. [12] The approach is typical of any agile development centre worth its name. “You develop, test, launch” said a member of the team. To allow the data to be best used by battlefield commanders, Delta is operated by a number of situational awareness centres that are set up close to the different fronts. This contrasts with the structural weakness of the Russian Armed Forces as described in a report [13] by the Royal United Services Institute (RUSI), a defence think tank, which describes how their failure to rapidly fuse information impacts their effectiveness. The lack of up-to-date information leaves Russian forces vulnerable to deception and sees them wasting resources attacking targets that had since moved on or had been dispersed.

In October this year, the Ukrainian military further crowdsourced its intelligence by releasing a smartphone app [14] for reporting drones and other aerial threats. This app, called ePPO, is intended to allow any Ukrainian national to report the presence of incoming threats, particularly the slow-flying Iranian-made Shahed drones. As these fly at only around 115 mph and emit a loud and distinctive sound (it has been compared to a motorcycle), this can give enough time for air defence systems to react to notifications reported by the app and intercept the threats. To reduce the risk of impersonation, the ePPO app only works in conjunction with a signed-in official Diia government app, preventing, in theory, non-Ukrainians from using the app. What is particularly remarkable is that this app was only released one month after the first Iranian-made drones were used in attacks on Ukraine’s power infrastructure, highlighting the agility with which Ukraine is conducting its digital warfare.

Open Source Intelligence as Open Data

In the weeks ahead of the invasion, the world’s media was awash with images from satellite companies such as Maxar and Planet showing the accumulation of Russian troops on Ukraine’s border. Once the sole preserve of a handful of countries, high-resolution satellite imagery, up to a resolution of 30cm, was now available to everyone. It meant that operational surprise was becoming exceedingly difficult to maintain, not only for other governments but also for any media organisation willing to pay the fee for images.

40km-long Russian Armed Forces Convoy heading towards Kyiv in February 2022 – Source: Maxar

This use of commercially-available satellite imagery is an example of what is known as Open Source Intelligence (OSINT), the use of publicly-available sources of insight and data that are accessible to civilian observers such as journalists, academics and insights. For satellites, it is not just imagery that is providing useful insight. For example, FIRMS a NASA satellite used to monitor forest fires is being used by analysts to detect where the front lines are shifting in Ukraine [15]. Other sources and applications of OSINT include social media postings of troop movements posted by bystanders onto TikTok or Telegram, the use of Russian facial recognition platforms to identify individual Russian personnel suspected of war crimes and analysis of geo-tagged images and social media commentary posted by active personnel.

Open Source Intelligence is akin to the way commercial organisations use a mix of data to operate their online services. This includes open data sources (i.e. free data), commercial data services, as well as Internet and social media scraping. Tech organisations are adept at discerning when creating and using their own data provides a valuable company asset or competitive advantage, and when it is more cost-effective or quicker to use data from third-party sources. The former head of British Defence Intelligence, Gen Sir Jim Hockenhull, recently said [17] that open source currently contributes 20% of current intelligence, but going forward he expects that the metric will be inverted.

Defence in the Cloud

Although we have looked at digital initiatives aimed at providing an edge on the battlefield, Ukraine’s first digital defence activities were aimed at securing the very essence of Ukraine’s digital identity as a country, namely its government’s digital records. In the weeks ahead of the invasion, the Ukrainian parliament amended legislation to allow government and specific private data to be stored on servers outside the country. This was the first step in what was certainly the first cloud migration project carried out under fire. Ukraine’s Digital Transformation ministry worked with Amazon Web Services (AWS) to transfer critical government information to the cloud [18][19]. The joint teams used ruggedised data storage devices, called AWS Snowball, effectively a “cloud in a box” to transfer data directly from Ukraine data centres. As of June, 10 petabytes of information had been transferred, preserving nationality records, land registration information, tax payment records, education registries and so on. This was an initiative that covered 27 Ukrainian ministries, 18 universities and dozens of key private companies, including the country’s largest bank. In this way, by transferring its digital records to the ‘cloud’ physically hosted in datacentres outside its borders, Ukraine was able to secure the very notion of its own statehood and the relationship it had with its citizens. As Mykhailo Federov, the Ukrainian minister for digital transformation put it, “Russian missiles can’t destroy the cloud”.

Conclusion

Although this post has focused on Ukraine’s ability to innovate and learn in the first ten months of the war, the Russian Armed Forces have been adapting too. They make extensive use of Unmanned Aerial Vehicles, to direct artillery, many of which are of indigenous design, such as the Orlan-10 fixed-wing UAV. The introduction of Iranian-made Shahed long-range kamikaze drones is inflicting heavy cost asymmetries on Ukraine, as well as degrading its energy infrastructure. At a cost of $20,000-$50,000, these are significantly cheaper than the sophisticated missiles that are often used to shoot them down, estimated at around $400,000- $1m reported for a modern western missile, and raise questions on the sustainability of using these air defence systems if Russia ramps up the supply of these drones. The Russian Armed Forces have also become more adept in using electronic countermeasures against drones, and at one point were using radio interception features intended for law enforcement monitoring of commercial drones to locate the drone pilots and attack them.

Nevertheless, while clearly both sides are able to learn and adapt from the experiences on the battlefield, in the digital domain, it is clear that Ukraine has an edge. Ukraine is clearly successfully mobilising its in-country and diaspora tech-savvy workforce and tapping in expertise for technology companies in the west, while Russia, is suffering from a brain drain of its best-qualified and most-experienced knowledge workers. Moreover, more fundamentally, Ukraine has succeeded in co-opting and assimilating innovations from both within and outside the traditional military structures. Combined these provide Ukraine with an important edge, allowing it to not only learn faster than its adversary, but also putting these learnings into practice more quickly. On its own, this advantage will not allow Ukraine to win, but it may provide a decisive edge.

Further Reading

1. “Moscow’s Continuing Ukrainian Buildup”, Center for Strategic and International Studies”, October 2021.

2. Muravska J., “Drones and defence innovation in Ukrain: consolidating wartime ingenuity”, Kings College London, November 2022.

3. Dahlander et al, “Why Now is the Time for Open Innovation”, Harvard Business Review, June 2020.

4. Broberg, “General Stanley McChrystal: Team of Teams”, AgileLeanHouse, June 2019.

5. Tett G., “Inside Ukraine’s Open Source War”, FT.com, July 2022. (Behind paywall)

6. Clayton Christensen et al., “What is Disruptive Innovation?”, Harvard Business Review, December 2015.

7. “What is New Market Disruption?”, Harvard Business School Online

8. Julian Birkinshaw, “How Incumbents Survive and Thrive”, Harvard Business Review, February 2022

9. O’Reilly C., Binns A., “The Three Stages of Disruptive Innovation: Idea Generation, Incubation, and Scaling”, California Management Review, Vol 61(3), 2019

10. Hawser A., “Ukraine’s Army of Drones crowdfunding campaign”, Defence Procurement International, October 2022.

11. Borger J., “‘Our Weapons are Computers’: Ukrainian Coders aim to gain Battlefield Edge”, The Guardian, December 2022.

12. Ukraine unveiled its own Delta situational awareness system, October 2022.

13. Zabrodskyi et al, “Preliminary Lessons in Conventional Warfighting from Russia’s Invasion of Ukraine: February-July 2022”, RUSI, November 2022.

14. “Ukrainians use phone app to spot deadly Russian drone attacks”, The Guardian, October 2022.

15. Gonzales C., “Scorched Earth: Using NASA Fire Data to Monitor War Zones”, Bellingcat, February 2022.

16. Ballinger O., “Radar Interference Tracker: A New Open Source Tool to Locate Active Military Radar Systems”, Bellingcat, February 2022.

17. Gen Hockenhull, “How open-source intelligence has shaped the Russia-Ukraine War,” gov.uk, December 2022.

18. “Safeguarding Ukraine’s Data to Preserve its Present and Build its Future”, aboutamazon.com June 2022.

19. Mitchell R., “How Amazon put Ukraine’s ‘government in a box’ – and saved its economy from Russia”, Los Angeles Times, December 2022.

20. Rogoway T. “The Common Missile NASAMS Uses Is Its Biggest Advantage for Ukraine”, The Drive, October 2022.

21. https://www.cigionline.org/articles/russias-war-on-ukraine-is-a-test-case-for-future-conflict/

22. https://www.americansecurityproject.org/osint-in-ukraine/

The post How Ukraine is fighting and winning the digital war appeared first on The Sand Reckoner.

This post is a work-in-progress, and is still a bit rough around the edges…

Do 1.5°C matter?

In 2021, at the UN Climate Change Conference (COP26) held in Glasgow, the world reaffirmed its ambition to limit the increase in average global temperatures to 1.5°C above pre-industrial temperatures. This goal, first set at the Paris UN conference (COP15), aimed to prevent the world’s most vulnerable countries from the worst impacts of climate change. For example, at above 1.5°C, it was estimated that 80% of the Maldives’ surface area would find itself below water. Since then, this target has largely been considered as being unachievable, with the UN estimating that this temperature will already be reached in the mid 2030s (i.e. in only 10-15 years’ time), [1] and the UK government estimates that at the current rate, temperatures are due to peak at 2.5-2.7°C above pre-industrial temperatures. [2]

So why the gloomy output? Essentially, the forecast peak warming temperature is a direct consequence of additional net carbon that is added to the atmosphere. The UN estimates that +1.5°C requires no more than a further 500bn tonnes of additional carbon dioxide to be added to the atmosphere. Considering global emissions are running at around 40bn tonnes/year, this leaves only 12-13 years of emissions at the current rate, after which all emissions will have to stop. Clearly, global emissions will not cliff-edge from the current rate to zero. Instead, a pathway to an acceptable peak temperature will require a glide path to reducing global emissions, while at the same time introducing mechanisms to remove carbon from the atmosphere. When carbon emissions and removals balance out, we will have reached ‘net zero’, and global temperatures will stop rising.

The Climate Tech Landscape

So how does the ever-burgeoning set of companies calling themselves a Climate Tech or Clean Tech company fit into this outlook? Any company describing itself as being a climate tech company should be directly or indirectly contributing towards the reduction of net emissions. There are two principal ways in which it can be achieved. The first is to directly influence the amount of carbon in the atmosphere, either by improving the carbon efficiency of existing processes, by providing a non-carbon alternative, or alternatively by removing carbon from the atmosphere. We shall call this the carbon reduction category. Then there is then a swathe of companies that provide climate or carbon intelligence, all of which provide insight into the emissions and climate impact across companies, territories or industries. Whilst these companies are not directly involved in carbon reduction, the insight is critical for appropriate targeting of efforts, auditing their impact, and pricing the cost of carbon. There is also a third category of companies aiming to help organisations adapt to the impact of climate change. Whilst crucial in coping with the impact of warming, these companies do not offer direct or indirect means to lower the peak temperature increase and so I will not consider them further in this post.

Carbon Abatement

PWC, the accounting and consultancy firm, publishes an annual ‘State of Climate Tech’ report [3]. This report looks at individual emission-generating sectors and assesses the climate tech funding attracted by each sector. These sectors are transport & mobility, energy, food & land use, industry & manufacturing, the built environment and financial services. Additionally, it classifies carbon capture, removal and storage as its own category. This categorisation is pretty common in this space, so I will use it for the remainder of this blog post.

Mobility and Transport is probably the sector that receives the most attention across the tech industry, predominantly through the activities to provide an infrastructure to electrify private and commercial road transport, though also includes efforts to decarbonise sea and air transport. Tesla is the poster child for the electric vehicle (EV) industry, but the entire automotive industry is being electrified, with VW predicting to shift more EVs than Tesla by 2024-5. Companies in this sector are involved in the entire supply chain, from batteries, their supply chain, through to in-home and public charging infrastructure. Indeed, the PWC report indicates that although mobility and transport are responsible for 15% of all global emissions, they receive 48% of global climate tech venture investment. Now, of course, VC funding is only part of the financing available, as SPAC funding, corporate venturing, innovation agencies and other forms of finance are significant contributors, but this figure is indicative of the interest that this sector provides.

Energy generation is going through a wholesale transition towards renewable generation, with 40% of the UK’s electricity now being produced from renewable sources. Although this is, by definition, zero-emission, many renewable energy sources have irregular generation patterns, dependent on when the wind blows or when the sun shines. This provides challenges in the creation of a steady, predictable source of electricity that matches demand, especially as gas, oil and coal power stations are progressively taken offline. In other words, they are not ‘dispatchable’ sources that can be dialled up and down to meet demand. Most climate tech companies in this space aim to address how to bridge this gap, either by (1) providing new, more controllable or predictable energy sources, such as green hydrogen or geothermal energy capture, or (2) by better managing energy generation, distribution and consumption, or finally by (3) introducing energy storage solutions, to help balance supply and demand.

Energy management is attracting a lot of attention from the tech scene, as it is the space most suited to be solved by software solutions. In a nutshell, these involve integrating consumers of energy, such as commercial premises, home heating systems, vehicle charging and so on with energy distributors and producers to adjust demand to better match the supply patterns. Examples include using electric cars to return energy to the grid (Vehicle-to-Grid) or to the home (Vehicle-to-Home), making use of smart home integration to manage electricity demand to better match supply, and introducing price signals to consumers of energy so that they can shape consumption around when energy costs are lowest. Octopus Energy, a UK-based energy utility, offers an electric vehicle tariff called Intelligent Octopus that integrates with the EV’s cloud-based charging APIs to schedule charging when demand is lowest and cost lowest. Amongst the companies supported by Y Combinator is Enode, a Norwegian company that provides energy companies, utilities and grid operators with access to a broad range of smart energy devices such as home chargers, electric vehicles, solar inverters in order to help match demand to their supply.

However, software solutions to match supply and demand will only go so far in compensating for the erratic power output patterns of renewable energy. To bridge periods when the wind stops blowing or the sky is overcast, cost-efficient long-duration storage is required. One, slightly unconventional approach is the use of gravitational storage towers that use surplus energy to lift concrete blocks, and return the energy back to the grid by releasing the blocks back down in a controlled fashion. Unlike battery storage, there is no energy loss over time (unless the blocks fall!). Other solutions being developed include solid state batteries, such as lithium-ion tech as used in EVs, flow batteries, and green hydrogen storage.

Agriculture and food production is an often under-recognised source of atmospheric carbon, and is responsible for 26% of global carbon emissions. This is largely driven by the inefficiencies of converting plant protein to animal protein, the large land areas required for livestock and its associated methane emissions. (yes, I mean flatulence). Alternative foods led much promise, but these are dropping off the menu. Even when scaled, cultured meat is estimated to cost more than $63 a kilo to produce, compared to US wholesale prices of $4 and $6 a kilo for pork and beef respectively. This has had an impact on the sector’s outlook. Beyond Meat, one of the stock markets’ darlings in this space has seen its share price drop by 95% since its peak shortly after its NASDAQ IPO in 2019. Vertical and urban farming has long been seen as the future of agriculture, as it is significantly more land-efficient than its conventional counterpart. Infarm, a European vertical farming company that had raised $600m in venture capital, laid off half of its workforce in November, largely due to the increase in energy costs triggered by Russia’s invasion of Ukraine, which has exposed a very high susceptibility to energy prices for these businesses. In truth, it does seem counter-intuitive that the future of farming should dispense with the free solar energy available on tap.

Energy used in commercial and residential buildings contributes to over 17% of greenhouse gas emissions, primarily for heating and cooling (HVAC) as well as lighting and other electricity consumption. Although a lot of attention is brought to creating green buildings, it is clearly more efficient to improve the emissions of the existing building stock built up over the past hundred-plus years. This is the space where the Internet of Things comes into its own, bringing sensors that monitor occupancy, temperature, humidity, solar irradiation, and air quality and coupled with machine learning models to reduce the energy burden of operating buildings. In countries where the pandemic has resulted in hybrid work patterns, utilisation of both offices and homes is now a lot more variable, leaving a lot of optimisation potential in how energy is used. Furthermore, the recent increase in energy costs has improved the return on investment for smart building management systems (BMS).

To be continued. Coming up next

This post has looked at how Clean Tech companies can directly help add or remove carbon from the atmosphere. Part 2 will consider the impact of carbon capture and storage technologies, as well as the role carbon and emissions analytics companies have in targeting efforts to the right area and auditing their impact. I will also touch on the contentious topic of greenwashing and the impact the increasing energy costs are likely to have on the overall Clean Tech Sector.

Further Reading

1. Analysis: What the new IPCC report says about when world may pass 1.5C and 2C

2. UK Climate Change Committee, “COP27: Key outcomes and next steps for the UK”

3. PWC, State of Climate Tech 2022

4. Y Combinator, “Request for Startups: Climate Tech”, December 2022

5. David Rusenko, “Proposal: A founder-focused climate tech taxonomy”, December 2022

6. TechCrunch, “Climate tech is not doomed, despite climate doom”

7. CBI Insights, “The Race for the Electric Car” (paywall)

8. Why lab-grown meat may never be on the menu

9. Wired, Vertical Farming has found its fatal flaw, November 2022

10. Energy Storage News, “Long duration energy storage to scale in second half of 2030s”, October 2022

The post Climate Tech – Is it all Greenwashing? appeared first on The Sand Reckoner.

The history of computing has been a multi-decade case study of network effects. When a product benefits from a network effect, its value to its customers increases as the number of buyers or sellers using it increases. The dominance of the Windows PC operating system was a classic case. By providing a ‘compatible platform’ for personal computers, software developers could reach millions of users, and the personal computing revolution took off.

Network effects came to play in the current generation of the Web, sometimes referred to as Web 2.0. The first incarnation of the web, which was built on open standards, including HTML, SMTP email, this iteration was basically an interoperable global noticeboard, making information available over the Internet. There were a plethora of search engines, each quickly making its predecessor obsolete. Remember Alta Vista, HotBot, Ask Jeeves? There was no ‘stickiness’ inherent to any of these services, which meant that the moment one search engine out-performed the previous, users would immediately shift. Then the early 2000s then saw the advent of Web 2.0, sometimes referred to as the ‘Social Internet’, where many new companies such as MySpace, LinkedIn, DropBox, Blogger, Facebook, Twitter etc. began creating web experiences that were interactive and personal. By holding information about their customers, they were able to create and tailor experiences that were personal to them, thereby creating stickiness. Google then showed the world how to create a very valuable advertising business using the personalisation it was hoovering up from its customers. This marked the return of network effects, and increased market concentration and centralisation. A platform was now valuable to its users only if their friends and colleagues were on it, and was valuable to other businesses only if it could link to enough customers.

Blockchain and Web 3.0

So why this quick ramble through the Internet’s potted history? Well, the next purported evolution, referred to unoriginally as Web 3.0, or simply Web3, promises to make use of crypto technologies to break the stranglehold of concentration of the big tech players. So is this the next big thing, or simply pie in the sky?

For an outsider, the numbers relating to cryptocurrencies are somewhat bewildering. From the capitalisation of the cryptocurrency market (it reached $30 trillion at the end of 2021), to its high volatility (it has since lost two-thirds of its value), it is difficult to get one’s head as to what is really going on. Despite being variously compared to a modern-day Ponzi scheme that would make Bernie Madoff blush, smart people are still betting big money on crypto tech.

In a previous post, I looked at the applications of blockchains, the technology that underpins cryptocurrency, showing how clever cryptography can provide a single version of a ‘truth’ that does not rely on the data or certification being provided by a single party, but instead is based on a decentralised network of several parties, all of whom have a stake in the system.

The Case for Web3

Andreessen Horowitz, also known as a16z, is a legendary Silicon Valley venture capital firm, whose founders were early investors in Facebook, Twitter, GitHub, Stripe, Waymo, AirBnB and Roblox. In May, it announced that it raised $4.5 billion for a crypto fund. Chris Dixon, who leads a16z’s crypto investments says that decentralisation and crypto are the new frontiers for 16z investment, as it fuels entrepreneurship, and pushes back away from the intrinsic centralisation of Web 2.0 companies. As an example, he explains how the proceeds of virtual goods in Fortnite go to the company behind the game. Instead, the sale of Non-Fungible Tokens (NFTs) is a means for creators to sell assets directly to a fanbase, in order to monetise that fanbase. According to Dixon, Web3 allows creative people, businesses and startups to reach audiences directly and have a relationship “that is not mediated by algorithms and advertising.”

The likes of a16z and other investors are fueling a burgeoning ecosystem of tech companies that are working to provide the building blocks to deliver on the Web 3.0 vision. Some of these are busy creating the building blocks of a Web3 infrastructure, including the blockchains themselves, including their crypto algorithms, the nodes that host the ledgers, and tooling and services that interconnect between blockchains and provide a variety of crypto-as-a-service applications. On top of these are the Web 3 applications, including Circle, which provides companies with the ability to transact financially with multiple cryptocurrencies, Sky Mavis, who provide the building blocks for creating decentralised online games, where all users can transact and sell game items, and OpenSea, a market place for peer-to-peer NFT transactions.

The Opportunities

When looking at Web3, a couple of key opportunities stand out. Decentralised Finance, also known as DeFi, whilst in its infancy, clearly will act as a spur to innovation in the broader finance industry. and possibly reconfigure the finance industry. Banks, wire transfer companies and payment networks all act as centralising conduits, extracting rents of anything between 1-4% on the value transacted, with operating margins in the order of 60-80%. These fees mean that established institutions are vulnerable to disruption by lower-cost crypto networks. Already in 2021, the value of transactions underpinned by Ethereum, one of the largest blockchain networks was $6 trillion. By comparison, Visa handled $10.14 trillion worth of transactions that year. The use of smart contracts, agreements that are automatically enforced and cannot be tampered with can be used to support a wide range of transactions, the crypto equivalent of shares, loans and ‘stablecoins.’

Non Fungible Tokens are unique records of digital assets that can be exchanged or sold, usually using cryptocurrencies that prove ownership of that digital assets. As they live on open blockchains, normally Ethereum, their transaction history is visible to all. Moreover, digital creators can retain a stake in their work, for example by retaining a share of the proceeds on any future resales enforced by smart contracts. Digital assets range from tweets, digital football trading cards, magazine articles or video game assets. Although the market for NFTs has tanked recently, for as long as artists continue to create digital content, be they music, visual, or gaming content, then it is likely that NFTs, or something like them, will be used to create a market where they can be bought and sold.

The Challenges to be Overcome

Having seen a fair few tech cycles, the extent of fragmentation of the Web3 landscape means that it feels a few years at best from going mainstream. Despite a16z’s enthusiasm, the computer industry does appear to have a tendency towards centralisation, rather than decentralisation.

Consider online music. Decentralised peer-to-peer services such as Napster and Kazaa provided listeners the world over with free, nearly limitless music, shared through PC applications across the world. Although these p2p applications provided access to music, the experience was poor. Slow, unreliable, with a clunky user interface. It was almost as though there wasn’t a single product development creating the experience! Then, in 2008, Spotify demoed their fledgling PC application to Universal, based on a tech stack that they developed with the sole purpose of cloud-based music streaming. Not only had music streaming made the jump from a hacky tech enthusiast’s tool to an application that anyone could use, but the music labels now had a partner with who they could set up contracts and hopefully build a sustainable business model.

The centralised services that Web3 advocates say get in the way between creators and their fans, such as recommendation algorithms and advertising, are what generate awareness in the first place. For example, Sam Ryder, who sang his way to a run-up position in this year’s Eurovision, could certainly drive up a sustainable business through selling access and digital assets as NFTs. But would that have been possible without TikTok’s recommendation algorithm which catapulted him from being an unknown artist singing covers from home over lockdown to a viral sensation with nationwide name recognition?

Similarly, for all the decentralising architecture of DeFi, there remain centralised control points. For example, online wallets that allow users to buy, sell and manage crypto assets manage passwords and logins on their users behalf, just like traditional online services. So what does Web3 need to achieve if it is truly to become mainstream?

Energy Efficiency

This is one area where there has been significant progress lately. Until recently, the Ethereum blockchain required approximately 4.8kWh for its ‘proof of work’ algorithm, which is more than the UK’s daily household electricity consumption. Think about it. A single online transaction requires more electricity than the domestic appliances, lighting and varied electricity needed by a family for a whole day. Particularly as much of the world faces an energy cost crisis, this was unsustainable. Ethereum claims that this was addressed in an upgrade called ‘The Merge’ which took place on, moving its verification algorithms to a system called ‘proof of stake’ which is a lot more efficient (Ethereum claims that energy consumption will decrease by 99.95% per transaction). For a comparison between these two algorithms, see here.

Be accessible to a non-tech customer base

First crypto transactions need to become more user-friendly, particularly for people who don’t care about the underlying tech. You don’t for example need to care how a car works, to want to drive one. The Verge quotes an example where some NFTs priced at $198,000 sold for $1,800 because some older online listings were still active. As blockchain transactions are irreversible, there was no way for the sellers to recover or reverse the transaction. As there was no intermediary in place who would guarantee or underwrite the sale, the asset was gone. Similarly, crypto wallets that allow users to hold their own private keys have no dependency on an online service, but if the user loses them, they are gone forever, much like cash under the mattress. This leads to the question, “Who do customers go to when things go wrong?” As anyone involved in creating consumer experiences knows, you can only really delight customers if you are able to deal with all the range of ways in which your service can go wrong. In this case, blockchain immutability is a challenge.

Prevent Abuse and Harassment

As blockchain platforms effectively provide exchanges for often anonymous users, there are currently few ways by which illicit, discriminatory, offending or otherwise illegal material can be revoked. The immutability of the transactions, the anonymity behind crypto wallets, the ability to obfuscate the source and destination of funds, plus the intrinsic openness and visibility of the ledgers cause all sorts of problems. A blog on the topic explored the ramifications of the transparency of public transactions, looking at the risks from abusive partners, harassment, revenge porn and so on. There seems to be little thought across the industry on how these issues will be addressed. After all, one of the strongest advantages of centralised systems is that it is clear who legislators and law enforcement authorities can go to in order to put things right.

Interoperability

Any financial asset that has a realisable value must be ‘liquid’, in other words, it should be able to be converted to another form of asset. For example, a house can be sold for cash. If it cannot be sold, it is illiquid, and hence has no financial value. For this very fundamental reason, all financial products and transaction platforms, allow for the transfer or conversion of assets. This is the financial equivalent of interoperability in the tech world. While the Web was built on a fully standardised set of technologies that we take for granted, (albeit with limited interoperability between, different platforms – Facebook, Tiktok etc), the blockchain networks on which Web3 is built are completely siloed. A digital asset such as an NFT held on one blockchain, say Ethereum, cannot easily be transferred onto another one, such as Solana. Similarly, the applications that run on given blockchains are also their own islands. Today this is being addressed through specific bridges between different applications, but this is a non-scalable solution that also introduces intermediary choke points that undermine the decentralised vision. Until protocols and asset formats become standardised, just as emails can be sent seamlessly across different email providers, then anyone using a Web3 application will be locked-in to whatever application or platform they selected.

Conclusion

While cryptocurrencies will likely become an increasingly important part of the fintech fabric, and blockchains will continue to find a diverse range of applications, decentralisation is something that will happen by degree. Bringing creators and consumers together requires often requires multi-sided platforms and companies to operate them. The scale that TikTok, Facebook or Google provide, also provides convenience, as it makes it easier for people to find the experiences, content or people they are looking for. Fully decentralised networks are also, by definition, fragmented, which will create significant usability issues that would likely be too high a barrier for mass market adoption. As the tech improves, as networks and blockchains become increasingly interoperable, regulators will also insist that there are legal entities who can take accountability for what takes place on a blockchain. For these reasons, I think it is more likely that the crypto tech underpinning Web 3.0 will be embraced by both existing and emerging tech companies as a way of providing customers with greater control and ownership over their own data, more transparency on how it is used and allowing faster and cheaper transactions. Along the way, we also doubtlessly see existing business models perishing and new ones emerging.

Further Reading

1. Harvard Business School Online, What are network Effects?

2. Boyd, Ellison, “Social Network Sites: Definition, History, and Scholarship”, Journal of Computer-Mediated Communication

3. Carroccio B, “The Stickiest, Most Addictive, Most Engaging, and Fastest Growing Social Apps – and How to Measure Them”, a16z Blog

4. The Future According to Andreessen Horowitz, CB Insights (registration required)

5. Newton, “Three things Web3 should fix in 2022”, The Verge

6. Katwala A., “NFTs are conquering soccer”, wired.co.uk

7. Engineering at Spotify, “What we learned from creating Spotify’s desktop app”

8. Worb J, “How does the TikTok algorithm work?”

9. The Verge Podcast, “Chris Dixon thinks Web3 is the Future of the Internet – Is it?”, April 2022

10. The Economist, “Adventures in DeFi-land.”, September 2021

11. R3 Blog, “How Efficient is your Blockchain?”

12. ArsTechnica, “Ethereum completes The Merge”, 21 September, 2021

13. The Verge, “Three Things Web3 should fix in 2022,” 28 Jan 2022

14. “The Crypto World Can’t Wait for ‘the Merge'”, New York Times, 26 August 2022

15. Ethereum, Proof-of-Stake (POS)

16. M White, “Abuse and harassment on the blockchain”

17. VentureBeat, “Interoperability must be a priority for building Web3 in 2022”, 12 February, 2022

The post Web3 – The promise of a decentralised web appeared first on The Sand Reckoner.

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.

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.

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.

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.

Further Reading

1. UCL Science Blog – Murphy’s Law

2. How Complex Systems Fail

3. ESA, Ariane 501 – Presentation of Inquiry Board report, July 1996

4. Engineering at Meta – More details about the October 4 outage

5. NASA, Mars Climate Orbiter Report, 1999

6. NASA Systems Engineering Handbook, Version 2

7. Valdez et al, Cascading Failures in Complex Networks, Journal of Complex Networks

8. Minkel, The 2003 Blackout – Ten Years Later, Scientific American, 2008

9. New study sheds more light on what caused Millennium Bridge to wobble

10. Emergent Failures: Rethinking Cloud Reliablity at Scale

The post Why things break appeared first on The Sand Reckoner.

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?

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.

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.

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

1. Association of Project Management – Systems Thinking – How it is used in Project Management

2. Systems Thinking – the Theory behind Agile

3. The Flow System: Leadership for Solving Complex Problems

4. Actionable Agile Jira Plugin

5. Create Faster and More Accurate Forecasts using Probabilities

6. Factors Affecting On-Time Delivery in Large-Scale Agile Software Development

7. Delivering Large-Scale IT projects on Time, On Budget and On Value

8. Choosing a Development Model: Predictability vs. Velocity

9. Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation

10. Large Scale Scrum – Systems Thinking

11. Dependency Management – the Good, the Bad, the Ugly

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