There is a revolution under way. It’s about time. We in technology have been proselytising it for over two decades. But, as in the history of past predicted social revolutions, the ‘inevitable forces’ that we believed would catalyse fundamental change were diluted, dissipated & dissolved by an everyday ‘good enough’ cartel of protected industries, careerist “I’ve always done it this way” workers and risk averse leaders.
What is the change that we have been clamouring for? The simple idea that building and shipping real working software and improving it incrementally through feedback from users is the best way to deliver value. Those who build something should run it and fix it too. large designs (or intentions) up front anticipate features useful to customers rather than actually eliciting them. We eliminate waste by shipping what we know is needed (although our solution may be novel) with as small a team as possible (minimising handoffs) and iterating from there. It’s all in the original ‘Agile Manifesto’ and the Lean / TPS canon.
All organisations wanted these benefits, but most interpreted the reduction of waste (muda in TPS terms) as increase in delivery velocity. And so a narrative grew around how to ship faster, not ship better. Methods like SAFe, took the commercial gap and offered an approach to this that was coherent with existing organisational structures and ways of working. The ceremonies of stand-ups, release planning etc didn’t actually change how an organisation saw and planned value, it just created an organisational interface between technology delivery and a business operating model that goes all the way back to Frederick Winslow Taylor. It is worth noting that not a single practicing software engineer or architect I know has any truck with SAFe. The point is not to criticise SAFe per se (it was a good commercial opportunity), but rather to point out that it is a symptom of which we speak… commercially successful new methods of working were adapted to existing ways of running a company not the other way around, and in so doing were blind to the inputs of those actually doing the building.
The same thing happened with DevOps. And it’s mutant marketing cousin, DevSecOps1. The reduction of handoffs between development and operations, and the creation of smaller end to end accountable teams was replaced by ‘DevOps’ teams. Who were basically operations teams. The much vaunted ‘shifting left’ of security did result in some security testing and other ‘policy as code’ initiatives but usually was throttled by the capacity of security teams to advise earlier. In both these cases, existing organisational structures in technology functions proved hard to change. We became the problem. The SRE (site reliability engineering) movement attempted a rear-guard action to bring visibility to the results of poorly managed change on production, but again we ditched things like failure budgets that defined the trade-off between change and stability, and created SRE teams.
None of this was helped by the fact that management consultancies with no actual experience building and running systems produced strategies inferred through top-down observation of many clients. Most of what was proposed withered in implementation - their recommendations were usually an extension of the idea of increasing differentiation of labour - separating change from run being a favourite - and this further entrenched the creation of specialist teams like devOps, SRE etc. So we’re back to Frederick Winslow Taylor or perhaps Henri Fayol.
Of course, firms did also look elsewhere for help. They looked at the hyperscalers and frontier software companies like Google, Amazon, Facebook, Netflix etc. These players, especially those selling services, were keen to share how they did things. But when asked how to get there from ‘here’… they were either silent or confused.
And yet… some companies did make the move. The so-called disrupters with the ‘tech’ suffix: Fintech, Regtech, InsurTech, EdTech… They were smaller, had less legacy process and technology to change, hired people with sector knowledge but less commitment to an established organisational career path, typically focused on a specific part of the market and, importantly, were less regulated. With a few exceptions (like Revolut) these ‘disrupters’ didnt change the market much. In banking for instance, they fought over the less sticky customers - generally more price sensitive and financially savvy. But the majority stayed where they were. Even, in the case of the UK, given a regulated guarantee enabling you to switch banks for free and open market initiatives like Open Banking and PSD 2. So much for the scrappy startups with amazing UX shipping changes every week and integrating a whole new financial ecosystem taking on the big banks. Even in the case of those that could move, it seemed that the threat to the big players was marginal.
There may not have been a serious threat but there was also significant inertia. And advantage in the inertia. The larger players, like global banks, pharma and retailers had huge amounts of customer data and well established channels that enabled cross-sell and up-sell. These barriers to entry were coupled with huge legacy estates and entrenched expert leadership mindsets. I characterise this kind of leadership as wanting to build a career (or more generously, a business) not a thing.
The entrepreneurial drive that seeks to build something truly new was either missing or fatally constrained. So very few of them (uh, us?) took the risk to fundamentally change how they operated in order to produce something that was not possible given how they currently operated. Not many firms were willing to go to the public markets and talk about radical organisational change being necessary due to a bunch of heavy metal t-shirt wearing, ponytailed engineers talking about a new future… We all agreed to re-label what we did do - train a few thousand in ‘agile’, DevOps etc. - as radical, call it ‘digital transformation’, and declare a win.
All of this manifests in an attenuation of feedback:
When we ship software, feedback from users is very slow to feed back to those who built it, resulting in poor prioritisation of what to build or fix next. Customer feedback leaks and all the builders get is a trickle.
Once we have deployed software, feedback from production operations - performance, scaling, security threats - is diffuse and generally only happens when there is what we euphemistically call, ‘an incident’.
When we ship software, the signals that tell us if the software is generating the customer behaviour we wanted and therefore generating the value we planned the release on, are either missing or so attenuated when technology receive them that they don’t change our build behaviour at all.
The result of this is that to many firms, technology remains a valuable but rather flaky capability and letting its promises shape how you run the company is likely not a good idea.
In essence, for large established businesses where technology is not literally the core proposition it offers (e.g. Barclays, not Microsoft or Netflix) the critical barriers to organisational change, or the material cause of organisational inertia, has been threefold. Technology has revolutionised markets and it managed to do so without requiring fundamental organisational change. So why change?
Whatever new things we do, we still have to manage, integrate and run the old things and these old things typically need to be worked with in a certain way. That cost will always dominate in proportion to the size of the firm and what it has to lose.
Scale remains the single most significant protector of market position. When true innovators challenge the cost / value equation (as discussed by Schumpeter or Christensen) that new scale results in decay not change of the old order.
When we do a new thing in a new way, it is safer to compartmentalise it and apply it to a well defined but less critical part of the business, where success is exceptional - by definition - and therefore the lessons not applicable to the ‘core’ business.
So where does this leave us? Most large enterprises still ship infrequently, manually test with a 3rd party, have large projects that surprisingly fail at the last production hurdle and exhibit low trust between business and technology functions. It still takes ages to get anything done. That applies to everyone, so it’s OK. Even the hyperscalers now have huge legacy tech debt which slows them down. It’s a race to diminishing marginal returns unless we do something different. Must we?
In my view, AI is a revolution of translation. That sounds minor, but it isn’t. The word, translation is used because it entails a sender and a receiver actually achieving common understanding. A foment has been whipped up by AI code assistants and chatbots, but the furore over the ease and autonomy of AI obscures a deeper change under way of how we translate our requirements into reality and respond to feedback about how they fit with that reality. In other words, understand if we got it right. As the examples above show, we have always had not only a problem of translating requirements into specifications for building but also poor signals enabling the improvement of these specifications. Because the process has been so heavy, and organisationally so fraught, we figuratively went with our first draft translation almost every time.
What if translation were really cheap? It is this change that holds within it the motive power to restructure how every company builds, sells, ships and advises but more importantly, in the light of the comments above, force companies to do so.
We know that with AI, ‘making’ software is now cheap. You can argue all you want about its internal design decisions, how idiomatic the code is and so on, but the reality is that whatever fault you find with it, it can be iterated and improved in hours. The competence required has moved from (code) syntax to (business) specification AND improvement. In other words, writing the code and describing what you want the code to do is very rarely right first time. So, inherent in (rather than just described in, an SDLC) the approach we begin to take today is an efficient, fast and cheap feedback loop. This simple mechanism of real translation radically reduces the cost to change. Small incremental experiments are also safe.
The efficiency of this basic requirements feedback loop makes it cheap to allocate experts to the specification process. Instead of reviewing long specification documents, they can participate in the creation of solutions in parallel with the documentation of them. The issue of course, is whether this will actually happen. Will business experts continue to be pigeonholed in their part of the ‘legacy’ process? Probably yes - unless you follow our Crucible approach - but the probability of a breakout event is much higher than ever. The barriers to translation are now close to zero. All you need is a few examples of “… hey could you spend a few hours with me working on this project?” resulting in, “I can’t believe we got so close to what I wanted in just a few hours!”
Taken across whole industries, this will happen more and more - this dynamic and opportunistic counter-structural allocation of resources. Already we see it in ‘business’ led AI initiatives using chatbots like GPT, Copilot, Claude etc. Who are the ‘engineers’ in this scenario? Most of these improvements are fairly simple (but effective) productivity enhancers for processes and reporting but what happens when whole business capabilities are transformed at this speed and efficiency? A new archetype emerges, ‘The Builder’, to which I will return shortly. But first, consider the impact of these ‘breakouts’ where traditional business and technology staff start co-creating together. Compartmentalisation becomes very difficult to control. In Dromologue’s change model, “I can’t believe we got so close to what I wanted in just a few hours!” becomes an ‘event’ - an organisational truth (that the existing process is for the best) turned on its head and showing a new way of working. Events change organisations. Not townhalls. Not posters. Not insipid corporate emails. Events.
These organisational events will themselves become industry events and all of a sudden, the personal risk to leaders of making the changes needed to bring about more of these events is far outweighed by the successes of those already making those moves. Certainly, one of these moves will be the use of AI to rewrite, refactor and replace the legacy tech that has been such a handbrake to operational cost savings in large enterprises. As an example, most large enterprises migrated applications to the cloud without refactoring and in so doing created the illusion of a cloud oriented ecosystem while enjoying few of the scalability, velocity and cost benefits of native cloud applications. The reasons are the same as those above. It was risky to re-engineer for an unclear economic benefit, while ticking the cloud migration box was an easy win. Cloud was always a method and not a location, but it was easier to ride the industry orthodoxy wave and not be left out2. The metaphor of translation with respect to re-writing software is very apt: we suddenly discover how much waste there was in the original implementation and find - only through talking to those who use the application - exactly what needs to be provided in the newer version.
None of this changes the scale argument though. In this, I’m influenced by the economist, Joan Robinson; that demand in the major (non-technology) sectors will continue to be shaped by the major scale players and how skilled labour is applied will be shaped by them3 and in so doing fundamentally restructure how technology is used across many industries, including the disrupters. The question then remains: How do you scale from a few ‘breakouts’ to an organisation wide approach to building that maximises the translation benefits of AI?
Our view is that organisations configured to maximise these benefits will emerge at an increasing rate as the benefits of the smaller experiments start to turn into real bottom line value. The configuration of these firms will be based on a new archetype of ‘Builder’ and not engineer, business analyst, SME etc. Those skills will remain important (and will of course evolve) but the delivery of value will no longer be in the form of what we think of today as the project delivery lifecycle, with well defined organisational boundaries between business and technology. The modern enterprise will be comprised of teams of builders; comprising engineering, business domain, architecture and finance skills; aimed at delivering bottom line value for a well defined organisational capability that they own end to end. In other words, a small team owns the translation of value for a valuable part of the enterprise.
It is no small challenge to transition from having a 100 AI ideas, and a dozen in production, to the kind of organisation that ALWAYS works this way. It requires a change in how you organise, how you build and importantly, how you assure (the accuracy of your translation). Dromologue.ai is built on the simple idea that if everyone has AI technology your differentiation and ultimate success comes from how you configure your company to use it.
You don’t have to be the first to break out, but you do need to be ready to move when you need to, and the speed at which you will be required to move will be far faster than your current operating model allows.
Largely a marketing construction of the security and compliance sector, jumping on the successful (although largely ill-fated) narrative of devOps, to remind everyone that security was an important part of the deployment lifecycle. Security and compliance was the very foundation of early devOps practice.
With the growing cost of frontier LLM consumption, it remains to be seen whether there will be a return to running open sourced models on owned or managed dedicated GPU infrastructure.
This is my extrapolation of her thinking, rather than her own paraphrased statements on the matter.