Great CTO - Dedicated to helping CTOs thrive.

Black Box Validation: What Ops Can Teach Us About AI Development

Daniel Walters — Fri, 10 Oct 2025 22:35:44 GMT

I haven’t posted for a coule of weeks; school holidays meant a driving holiday with the family, and I’m now back finishing up a range of engagements. But I’ve been mulling over an interesting pattern I noticed before I left.

Operations and security engineers seem to be adapting quickly to AI-augmented development. The reason why suggests something interesting about where this field might be heading.

The Ops Advantage

Ops and security professionals are comfortable working with code as a black box. While they dig into implementation details when needed, they routinely operate without understanding every line. Their confidence comes from external validation: monitoring systems, security scanners, test results, performance metrics. These feedback loops signal when something’s wrong.

This comfort with validation over comprehension translates directly to AI-augmented development. Instead of inspecting every line of AI-generated code, we can rely on the same validation approach. Linters, static code analysis, dynamic analysis, and other inspection practices verify code automatically. Humans still review code, but tools provide adequate confidence that a generated function performs as expected.

The Psychological Barrier

For many software engineers, this shift is uncomfortable. They’re trained to understand and own every line of code they ship. Letting go of that deep comprehension feels irresponsible.

Ops and security professionals don’t carry this burden. They’ve already made peace with validating systems they don’t fully understand internally. This removes a psychological obstacle that can slow traditional developers from adopting AI-augmented workflows.

Recognizing this barrier is why we’re helping to create time, space, and a safe environment for software engineers and leaders to learn AI-assisted software development through our course: [From Assisted to Agentic AI Development](https://hyprinnovation.io/training/from-assisted-to-agentic-ai-development).

The Tight Inner Loop

Here’s how the validation approach works in practice:

The AI agent operates in a tight inner loop, taking small, targeted, self-contained actions guided by specs and context documents. After each action, it validates against multiple quality attributes: Can it handle load scenarios? Does it comply with standards and regulations? Are there security issues? Does it meet product and business goals? Are coding standards met?

The feedback loop serves dual purposes. It enables the AI to iterate and run longer, addressing issues as they arise. And it gives us confidence that the software meets our quality requirements: security, performance, reliability.

The agent keeps rolling forward, with validation tools providing continuous feedback on each incremental change.

The Outer Loops

Human oversight operates at a broader scale. When validation feedback reveals deficiencies in the spec itself, indicating the current approach won’t produce the necessary architecture, you discard what’s been generated, improve the specs, and rerun.

Production environments create even broader feedback loops. User feedback, observability data, and business metrics flow back into the development cycle. These signals inform not just the code, but the specifications and requirements themselves: multiple layers of validation feedback, just as ops teams have always used to refine their systems.

Why This Matters

The pattern suggests something: you don’t need humans to inspect every line to build reliable systems. You need robust validation mechanisms and the discipline to trust your feedback loops.

The ops and security mindset of validating complex systems through external signals rather than internal inspection might point to where AI-augmented development is heading. As AI tooling becomes more capable, the professionals who’ve already internalized this approach may have a natural advantage.

It raises a question worth considering: are your validation loops strong enough to work this way?

Leave a comment

The Double Standard: Why Is AI Welcomed But Not Diverse Humans?

Daniel Walters — Wed, 10 Sep 2025 20:00:28 GMT

Photo by Bernd 📷 Dittrich on Unsplash

Hi everyone,

Thank you for reading Great CTOs Focus on Outcomes. I publish weekly and have an archive of over 150 posts, each packed with valuable insights on various topics relevant to CTOs and the issues they face, distilled from my career experience.

I strive to make each post a helpful resource on the topic it focuses on so that when a CTO has a need, they can reference an atomic nugget of insight. To this end, I regularly revisit and refine posts, ensuring you always receive the best and most up-to-date information with the most clarity.

This is an early draft of a post that I'd love feedback from paying Great CTO subscribers. Diversity, Equity and Inclusion has catalyzed dialogue that is at once heartfelt and contested, reflecting the complexity of the issue. 

The intent of this post has been to contrast the decline in advocacy in the boardroom for altogether human endeavours, that of creating more opportunities for people, and it feels like that fervour has been replaced by advocacy for the advancement of non-human intelligence. Let me know if this contrast helps put AI hype into context or simply adds to the confusion. 

If you'd like the opportunity to see my posts early and provide feedback to help improve them, consider becoming a subscriber.

Subscribe now

In boardrooms globally, a curious phenomenon is unfolding. Companies are racing to integrate AI agents into their most critical processes: hiring, lending, strategic planning, and customer service, despite these systems' well-documented biases, unpredictable failures, and opacity. Yet many of these same organisations express scepticism about diversity, equity, and inclusion initiatives (DEI), citing concerns about merit, fairness, and performance.

This isn't simply a case of irony; it’s a fundamental inconsistency in how we think about intelligence, capability, and risk and reflects biases in our expectations of systems versus humans.

A Review of The Different Philosophies of AI Coding Tools

Daniel Walters — Sun, 10 Aug 2025 20:30:32 GMT

Photo by Aubrey Odom on Unsplash

Hi everyone,

I strive to make each post a helpful resource on the topic it focuses on so that when a CTO has a need, they can reference a self-contained and referenceable nugget of insight. To this end, I regularly revisit and refine posts, ensuring you always receive the best and most up-to-date information with the most clarity.

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

This post is an active draft. I am sharing it early so I can improve it as a resource with your feedback. I will continue to refine the descriptions, terminology and the table of tools so it can be the best possible reference for understanding the different philosophies of these tools and choosing which may best fit your needs.

There’s an explosion of tools in the sphere of AI-assisted software development. It’s frankly overwhelming.

As I've shared in previous posts, if you want any hope at all of learning these tools, I suggest you don’t try to keep up with the news announcements. It’s too easy to fall into the trap of trying to start with a tool and then look for a problem to solve with it, and before you do, see the next bit of news and start something new and so on… Something better always seems to come along.

What I will attempt in this post is to give you a framework of some choices when selecting tools for types of problems and where you are on your learning journey.

The Different Philosophies of AI-assisted Software Development Tools

There are several different dimensions by which the various AI-assistance tools differentiate themselves. There may be more, but some of the most material differences I’ve identified are as follows:

Who is providing the tool
Form Factors
Model Selection
Agents / Modes
Sub-Agent support
Task decomposition and orchestration
Opinionated Practices & System Prompts

Who is providing the tool

Who provides the tool and how can significantly impact the capabilities available and the nature of integrations available.

There is a wide array of ways in which the creation and improvement of these tools are being supported:

As open source (a collective effort from individuals and companies - note, many of these are quickly co-opted by a dominant organisation that is monetising the tool in some way)
By a company focused only on that tool (Cursor, Kilo).
By a more general software development tool company (SourceGraph, Cognition)
and other cases, it's backed by a “FAANG“ Company (Amazon, Google, etc.) or a Foundation model provider (OpenAI, Anthropic, etc.).

Form Factors

Integrated Development Environments (IDEs) - Forks and Extensions
Command Line Interfaces (CLIs)
Ambient (Event-driven)
Other

Integrated Development Environments (IDEs) - Forks and Extensions

The most obvious starting point for developers is to begin with either extensions to their IDE, whatever they are using, whether it be VSCode, Jetbrains, NeoVim, Zed, Emacs or something else.

Some of the most popular options are forks of popular IDEs - Cursor and Windsurf both being forks of VS Code (an obvious candidate as a very popular Open Source Software option from Microsoft), which has the benefit of parity with most modern IDE capabilities that are expected, as well as support for compatible extensibility options such as plugins and extensions that those ecosystems support.

Command Line Interfaces (CLIs)

More recently, there has been an explosion of CLI options following the lead of examples such as Claude Code. These tools anticipate the post-IDE era, where the way that people interface with AI-coding models is sufficiently different from how they have been interfacing with code previously.

Ambient (Event-driven)

The popularity of Devin suggests there is another mode of interaction with coding models, and that we could describe as a ‘virtual teammate’ or, as we have in this post, as Ambient.

Other

I will use a catch-all category to describe some other options I have observed, which are present but less common.

Use of Desktop Assistants such as Claude Desktop with tools such as Model Context Protocol Servers (MCPs), which have access to local filesystem or remote repositories for delivering code. I wouldn’t recommend it, but I also can’t say I haven’t done it. As I wrote previously, there’s something powerful about being able to interface across many systems in one interface layer, so yes, I have, on occasion, edited files through Claude Desktop.
Programmatically. Yes, you can call your model directly through code you write and instruct it to make changes to code, so at times, I am sure this happens.
Through AI workbenches, studios and other tools designed for working with models, for fine-tuning, for evaluations, etc.

Model Selection

Whether the tool is built around the idea of supporting a Model Switcher or not can be a significant difference maker in terms of the effectiveness of the tool.

Model Switching can be great for cost management, flexibility, taking advantage of new models or remaining productive when there are shifts in reliability.

Tools focused on a few specific models for particular responsibilities can fine-tune system prompts and patterns specifically for the capabilities of those models and often correlate with improved developer satisfaction with the tools, even when models rate worse on benchmarks (e.g. Claude Code, Amp)

Agents / Models

Another philosophical difference that’s worth noting is the choice of some tools providing different modes, while others deliberately choose not to.

At one end of the spectrum is the excellent Cline - a VS Code extension which features just two modes - ‘Plan’ and ‘Act’. These modes, as well as features such as its excellent MCP support, make Cline a fantastic tool to start learning and practising AI-coding with.

To be explicitly planning because you are in the ‘plan’ mode can give you some confidence that the tool is building up good context on what you are trying to achieve. You can explicitly switch to have it generate code once you are confident in the plan that you have developed, with the assistance of the model. The model you use for each mode in Cline can be different.

Roo Code, which happens to be a fork of Cline (as its open source software - OSS), expands the number of modes to be more like different types of activities you might undertake, such as an architect, asking a question, debugging, etc. Roo is very configurable and allows for specific models and settings to be defined per mode.

Some tools may not have implemented any modes. That could be because they are simpler tools, or in some cases, it’s a deliberate choice. A case in point is Amp. Amp has chosen to provide agent functionality, which the model can choose to use or the user can encourage the model to use with their prompt. It creates some additional learning for the user, but in practice it’s a powerful paradigm.

Sub-agents & Tool-calling

Amp, Claude Code and other tools also support the concept of sub-agents. This is likely calling another model with fresh context. One of the most significant issues with tools output matching your intent is the issue of Context Rot, where the context window is filled, and the performance of the model worsens.

The model the user is interacting with, being able to pass a smaller amount of context to another model with its context, allows for less context being consumed by the master model, and the sub-agent model uses only a small amount of its context to complete the task it’s been set. These can run in parallel, so that particular tasks that could be implemented independently may be delegated to several sub-agents to do, and they pass back the result once they are done.

I refer to tool-calling because one way you can achieve something similar is to have a tool call to another model. The main model passes a prompt to a tool, which provides it to a separate model.

Task Decomposition & Orchestration

I haven’t included Task decomposition & orchestration on the table, as most of the tools include an approach to this now. What I mean by the phrase ‘Task Decomposition & Orchestration’ is the capability of the tools to break a plan into smaller tasks and work through those tasks systematically. This allows content to be much more focused on specific tasks, reducing the likelihood of triggering Context Rot.

Some of the tools apply this approach during a specific planning mode (e.g. Cline). Others have the model under the direction of the system prompts and what is interpreted from the user prompts to determine when it’s planned adequately and when to start executing on that plan (e.g. Amp).

Opinionated Practices & System Prompts

Another differentiator in these tools is the degree to which the creators have strong opinions on the way the tools and models should be applied in development and how these translate into the system prompts (i.e. prompts that the tools have defined to give the models direction on how to behave).

The models are very capable of producing code even without being wrapped in a tool, so a tool at its simplest could exist without a system prompt contributed by the tool developer. It would just operate with the user prompt provided. This marks one end of the spectrum, with the tools listed at various points along the spectrum.

It’s hard to assess this dimension without extracting all the system prompts, so I haven’t featured it on the table at this stage. Nonetheless, it's a dimension the tools could be evaluated on, and one you will get a feel for when using various tools and comparing the experience.

Weekly Livestream on AI's Impact on Work

This post is an active draft. I am sharing it early so I can improve it as a resource with your feedback. I will continue to refine the descriptions, terminology and the table of tools so it can be the best possible reference for understanding the different philosophies of these tools and choosing which may best fit your needs.

What were the factors that influenced your tool choices? Which of these factors will influence your decisions? What did I get wrong in my table or the descriptions of the different facets? Sound off in the comments.

Leave a comment

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

Paid Subscribers Only: How executives can help achieve positive change and greater impact

Daniel Walters — Tue, 22 Jul 2025 20:01:00 GMT

Photo by Fatemeh Eghbalpour on Unsplash

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Originally posted on the HYPR website by Daniel Walters, March 5 2025

There are always more opportunities to improve the effectiveness of an organisation. You are never done with this work. It's easy to get too busy or feel the change involved with some of these opportunities is too complicated, and when there’s an opportunity to grow through hiring, some of these may stay on the back burner.

If that option is limited or cannot be used sparingly, you must look elsewhere for a more productive capacity. This will lead you to examine where you can improve within your existing workforce.

From our survey of opportunities in my previous post on amplifying software engineering impact, we can summarise the following strategies we identified, which can be applied to help us reduce wasted effort and increase our impact:

See inflight work through to completion
Identify what to subtract
Tackle the riskiest assumptions first
Identify organisational constraints differently
Establish new ways to determine progress
Better time and meeting management
Improve decision-making throughout the organisation
Identify and invest in learning opportunities
Systematise bringing in new organisational changes
Prioritise problems the organisation is experiencing

Let’s explore how each can help us and what might be involved in bringing this change to reality.

The Rapid Evolution of How We Interface with Models (And The Elephant Paths We Tread)

Daniel Walters — Tue, 08 Jul 2025 20:30:18 GMT

Photo by Nazym Jumadilova on Unsplash

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

Observing My AI-Model Client Usage Patterns

In running my business, I have a lot to do to ensure it is viable. In addition to the direct value contributions, such as coaching and consulting, there are also marketing and sales activities, accounting, and other services.

Unsurprisingly, given the nature of my business, much of the value my business provides relies on my knowledge, experience, and content. I utilise AI models to assist with various activities, but at the same time, I must be mindful of using tools that enhance rather than diminish the value I bring. I also don’t want models to replace my thinking, as this would provide my clients with less value and also atrophy my own thinking and learning capabilities in the process.

I’ve adopted a range of practices for using models where I am either using the models to remove toil, such as repurposing something I’ve already created or leaning on the models to help improve my thinking by critiquing my work or providing different lenses over my work which I can use to expand my thinking and improve the robustness of the work.

I started using LLMs more frequently when Bing integrated OpenAI’s models, along with some search capabilities. I had, of course, used LLMs before this, but it hadn’t become habitual until this point. So, I guess it was from the early days that I recognised the power that the combination of an LLM and tools presented - in this case, an LLM with access to more up-to-date information via search.

I graduated to ChatGPT as the clients for this became more user-friendly, and also aggregators such as Poe, which had both text and image models in one place. Over time, I found more and more opportunities to help do the other tasks of running my business so I could focus on value delivery (and maximising the hours of work I am paid for).

Writing Aesthetic and Later, MCP support: Enter Stage Right, Claude Desktop.

I used to use Claude Desktop a lot - it was front and centre during the period when I increased my use of models the most. However, change moves quickly in this environment of technological evolution, and my usage changed just as fast.

I eventually shifted more of my use towards Claude as colleagues started to recommend it, particularly for its writing capabilities. Claude's models had an aesthetic to the prose they generated that I preferred over alternatives such as ChatGPT. I might have even been influenced by Claude's website and desktop visual aesthetics as well - non-threatening and homely earthen pottery tones that I am sure were well-researched as being calming to users coming to terms with what, in the early days, seemed akin to magic.

Once MCP Server capabilities were added to the Windows Desktop client, my use of Claude over ChatGPT increased manyfold. There have been swings back and forth since. For instance, the significant improvement of ChatGPT’s image models has made it possible to create serviceable images with readable text for use in social media posts, birthday party invitations, or many other practical applications.

I also started introducing models into my orchestration tools, such as Rabbit Remix, Zapier and n8n. But most ideas start with something that can be experimented with, such as the Claude or ChatGPT web interfaces or their respective Windows desktop clients.

As My Use of AI-coding IDEs Increased: Exit Stage Left, Claude Desktop.

After I started using AI-assisted software development tools, I found that I could accomplish many of the tasks I used to perform in Claude Desktop using those tools instead.

As I wrote in a recent post, I found that with the MCP-wrapped APIs of many of the services I use regularly, I was able to interface with many of my day-to-day SaaS tools through this interface rather than directly through their web interfaces. This may prove disruptive to SaaS products over the long term.

One of the key reasons for the switch was that I found it quite brittle to configure the MCP Servers in Claude Desktop. You could get it done with a bit of patience, but it always took a bit longer due to syntax issues, copy-paste errors, human error, and so on.

The experience with VSCode-based editors, such as Cline, an AI-assisted software development extension for VS Code, revealed that many of these have a very resilient approach to installing MCP servers, as they utilise AI models to assist with the installation.

CTO Life Line is a monthly Livestream conversation dedicated to helping CTOs move from barely surviving to thriving.

Co-hosts Daniel Walters and Noah Cantor stream episodes on LinkedIn and YouTube. Each episode delves deeply into a topic important to CTOs and has entertained a range of informative guests from around the world.

Check out CTO Life Line

Suppose it encounters an error in the syntax or identifies another issue, such as a permissions problem. In that case, it will attempt to resolve the issue and continue making changes and testing them until it has a proven working setup. That almost always results in a working MCP Server. The hit rate is thus much higher, and the time spent setting up a new MCP Server is much lower.

Additionally, you have access to all the other tools available in modern IDEs. So, if the model had made file changes, you could examine diffs, run linters and other verification tools, and utilise all the various other available tools.

For many of these tasks, an IDE may not be the ideal interface - it’s got a lot of chrome you don’t need; however, it does provide some hints about the capabilities a modern interface for interacting with models should feature.

Desire Paths - From Bane of the Urban Planners to Useful Tool

In urban planning, there is the concept of desire paths, also known as elephant paths, which is presumably derived from the fact that elephants are considered some of the heaviest trampers of grass (despite humans having them well-covered in blades of grass).

This concept has been well-publicised in design and later product circles, so I won’t spend too long rehashing what has been shared many times. You can read more about them here: https://en.wikipedia.org/wiki/Desire_path

Example from Wikipedia's Desire Paths page.

In the example above, it’s pretty apparent that the advantage people experience for this path over the concrete paths is one of a more direct route and one that’s a bit softer underfoot, to boot.

It reminds me of my earlier career, when I worked at Hitwise, an online consumer behaviour data analytics company. We could see user internet behaviour through anonymised taps on internet traffic. One trend we noticed was that many Google users used the search engine to navigate the internet, bypassing the URL bar in their browser. Initial responses to this observation were critical of these users, suggesting they were ignorant, as they didn’t even know how to use their browser.

But it occurred to some of us that these users weren’t stupid; they were pragmatic. The Google search box was positioned in the middle of the page and was large, not outside the main eyeline and competing with a smaller target, such as the browser bar. If you made a typo, Google would usually correct it and get you where you intended to go, anyway, thus being more resilient. Sound familiar?

What is interesting is that it’s a typical response to fight these emergent behaviours rather than to embrace what they represent in terms of information. I recently saw this brilliant example courtesy of Joaquín Peña Fernández

It looks like there’s been a progressive battle between the local council and the ‘elephants’. One wonders if there are even more bollards there today.

So What Has This Got To Do With AI-models?

It’s interesting that, while the Claude Desktop client has progressed in terms of capability quite rapidly overall, it has been a few months without much significant improvement in how MCP configurations are managed. Additional debugging tools were added, but the configuration itself remains reliant on the manual editing of YAML files. You uttered the wrong incantation in the secret language of YAML formatting and invocations of npx and uv… but we will help you work out what you did wrong with developer-level tooling. It’s a world away from the core of the interface, which is chat.

This has left the usage of tools, via the explosion of MCP Servers which provide your AI assistant with access to thousands of tools and almost certainly many of the tools you use daily, primarily in the domain of more technically confident users and many less technically confident or time-poor individuals likely became discouraged by early attempts that resulted in error messages rather than successful tool configuration.

What Does the Future Hold?

What does this mean for the future of interfaces such as Claude Desktop? Oddly, some of the most potent and accessible capabilities of LLMs are currently more usable in a development IDE than in the consumer-facing tool. Maybe the Desktop tool evolves. Perhaps it has reached the end of its life and needs to be replaced. Possibly, it remains a handy platform that allows for experimentation on how we best interface with the models.

The Role of Foundational AI Providers such as Anthropic and OpenAI

Let me elaborate on that a bit further. I believe, with some evidence and application of strategic analysis, that the business model of the foundational AI providers is predicated on creating platforms for all of us to test and discover an adequate number of use cases to justify their astronomical investment levels and growth.

While I am convinced that AI-assisted development has changed software development forever, I am less sure about how all the other applications of generative AI models play out. There’s certainly utility - I am using them in a variety of ways in my business, as I mentioned, and I'm sure many others are. However, that doesn’t mean that the aggregate of these use cases and their revenue balances the massive scale of investment being deployed towards these companies by investors.

To extend this further, I am also reasonably sure that these companies do not necessarily believe the user interfaces in these AI models today are what we will be using, as use cases are discovered and commoditised. The prices they charge to support these services stabilise as a result. It’s also not written in stone that the path to how we consume models in the future is dependent on these companies. Sure, the scale of investment stacks the deck in their favour, but maybe our elephant paths take us somewhere else.

To my mind, I’d be pretty comfortable if the models became more open and more local and less of their management was consolidated into the hands of a few. Perhaps some capabilities will be impractical to manage this way, but many of today’s applications could be, with lower power draw and centralisation of data and IP. It remains to be seen what happens to tomorrow’s capabilities and use cases.

What could this Mean For Software Interfaces?

What is most interesting to me is what happens to the user experience of software. That’s the question that drew me into software over three decades ago. We interact with software in numerous aspects of our lives. Some things have become easier - we can engage services that enrich our lives much more easily. Some things have become worse - for instance, we seem to have reached a peak in the time spent authenticating into things, despite the rise of biometrics and other tools that should have made things simpler and faster. We use so many more software tools today, and some terrible choices in IT security theatre have meant that, in aggregate, it’s still worse.

Part of the user experience challenges that software has presented for decades is its static nature, where a paradigm is chosen for a given software package because, at least, it is learnable. Unfortunately, with many more discrete software packages in use on average by individuals, the cognitive load involved in adapting to understand how each piece of software needs to be interacted with to achieve the user’s goals has increased.

The mix of deterministic and organic properties in a stochastic model presents interesting possibilities for how people may interact with software in the future, potentially leading to more humane and adaptable systems that can accommodate the user's ergonomics rather than the other way around.

It’s equal parts intriguing and terrifying.

How are you currently interfacing with AI models, and how do you think this interaction may evolve in the future? Share your experiences and perspectives in the comments.

Leave a comment

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

When the AI Behemoths Stumble, AI-Assisted Development Will Still March On

Daniel Walters — Sun, 15 Jun 2025 21:43:44 GMT

Photo by Axel Antas-Bergkvist on Unsplash

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

There’s a market correction coming.

It might be sudden, or it might play out over quarters, but the trajectory is clear.

Foundational AI platforms—OpenAI, Anthropic, Google DeepMind—have ridden an extraordinary wave of hype, capital, and developer enthusiasm. But signs are emerging that this era of unchecked growth and influence is due for recalibration. Regulatory friction is rising. The cost of training and serving state-of-the-art models is ballooning. And we’re starting to see the limits of productisation across generalist LLMs.

Now here’s the key question: What happens to AI-assisted development if one of these giants stumbles?

Some people are quietly preparing for the end of the party.

They assume that if OpenAI or Anthropic were to drastically change their business model, or even collapse under the weight of their shareholder obligations, the AI development wave would recede.

But that’s a fundamental misunderstanding of what’s really happening.

AI-Assisted Development Isn’t Just About the Model

What’s emerging isn’t a dependency on a single API.

It’s a shift in how developers work, how teams reason about problems, and how software systems are built, refactored, tested, and extended.

We now write specs that double as prompts.
We chunk tasks not just for sprints, but for model comprehension.
We validate ideas in minutes rather than hours.
We scaffold entire subsystems using only interfaces and context files.

And much of this is model-agnostic.
It’s not dependent on GPT-4 or Claude 3 Opus.
It’s enabled by workflows, tools, plugins, and patterns—many of which can run on open weights, lightweight models, or even local inference.

Indeed, the foundational model providers accelerated the process. They made it accessible and exciting. But the shift in behaviour and expectations is now embedded in teams. Developers won’t unlearn the speed, support, and flow they’ve come to expect.

Even if a market correction hits hard—let’s say API prices skyrocket, or a major platform pivots behind enterprise firewalls—the methods of AI-assisted development are here to stay.

The Post-Correction Landscape: Decentralized, Specialized, Resilient

A correction might trigger an even more robust phase of evolution:

Smaller, purpose-trained models will gain more traction. Not every task needs an 800-billion-parameter generalist.
On-device inference will become more practical and desirable, especially in privacy-sensitive industries.
Open-source tooling will flourish as teams seek more control and lower latency.
AI agents and copilots will become increasingly fine-tuned to context—local codebases, bespoke rules, and domain vocabularies.

We’re heading toward a more decentralised and composable AI development ecosystem, one that is less dependent on a handful of mega-providers.

So What Should Leaders Do Now?

If you’re leading a software team, don’t tie your strategy to a single vendor’s roadmap.

Instead, ask:

What AI-assisted workflows are becoming core to how we ship software?
Where can we adopt model-agnostic tools and open standards?
How do we build resilience into our stack if today’s API terms change overnight?

Because when the correction comes—and it will—the teams that treated AI-assisted development as a capability, not just a product, will be the ones that thrive.

How dependent is your team on a specific foundational model today, and how easily could you switch if needed?

Leave a comment

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

Stop Pretending Your Code Is a Stradivarius

Daniel Walters — Sun, 08 Jun 2025 19:01:14 GMT

Photo by Stockcake

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

Some developers resist AI-assisted coding tools because they "prefer to code by hand." It’s a familiar refrain—often rooted in pride, sometimes in perfectionism, and occasionally in a romantic idea of the developer as artisan.

But let’s get real: if your software is IKEA-level functional, stop pretending you're shaping tonewood with a fingerplane.

The Stradivarius metaphor is seductive. A single luthier, guided by touch and instinct, carves resonant beauty into every curve of a violin. That’s admirable craftsmanship. But in software, most of us aren’t making symphonies—we’re building support systems, admin dashboards, and payment integrations.

Precision matters, yes—but not everywhere, and not all the time. Knowing where to be exacting is part of the craft.

What AI Can (and Should) Do for You

AI isn’t about replacing you. It’s about removing the friction from the routine. Boilerplate, scaffolding, doc generation, test stubs—these aren’t the bits that define your engineering legacy. They’re the IKEA instructions. Automate them.

The fingerplane moments—those are still yours. Architecture decisions. Tradeoffs. Security considerations. Domain modelling. Elegant error handling. That’s where you earn your keep.

Let go of the romanticism. Embrace the tools. Then reinvest your time in the parts of engineering that actually require your creativity.

How do you define where “craftsmanship” truly matters in your codebase—and where it becomes counterproductive? How can leaders model the adoption of pragmatic tools without devaluing engineering pride or quality? Share your perspectives in the comments.

Leave a comment

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

Should CTOs stop hiring and focus on AI?

Daniel Walters — Thu, 05 Jun 2025 19:30:24 GMT

Photo by Brian Patrick Tagalog on Unsplash

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

Over the past few months, several clients have posed similar questions regarding strategic decision-making related to AI, so I thought it would be helpful for others if I wrote up some of the information I’ve shared with them.

The key questions I’ve been asked (paraphrased):

Is AI a truly disruptive trend or a bubble?
Should I stop pursuing growth through hiring and instead focus on improving the efficiency of how we build software using AI?
What software development principles are subject to change in the AI-assisted software development era?
How can I encourage the development and data teams to explore the possibilities with new AI capabilities?
How should I think about spending on software developers and AI in the near future?

These same questions were discussed at several tech leader events I recently attended, and I’ve also seen some similar threads in the blogosphere. It appears these are questions in the Zeitgeist.

In this post, I will focus on the following question, and I have addressed the other questions in other posts:

Should I stop pursuing growth through hiring and instead focus on improving the efficiency of how we build software using AI?

Do AI-assisted software development efficiency gains mean smaller teams?

There appear to be several camps regarding whether AI will lead to job losses. Some analysts project large-scale job losses. Others argue that new types of jobs will replace the jobs lost. Another group I covered in a recent post suggests that AI is largely unproven, and the jury is still out on whether technologies such as generative AI will have a significant impact.

From my vantage point, through my career experience leading teams who built AI capabilities for competitive advantage, and through the visibility I have by working with the companies I am now, I think it’s safe to say that the evidence that AI is already starting to have the anticipated impact is discoverable by those who look for it.

The presence of a bubble is not evidence of a lack of value.

This doesn’t mean there isn’t an investment bubble. There certainly is - one can examine the economics implied by the astronomical investments in foundational model providers such as OpenAI and Anthropic, and then perform some back-of-the-envelope calculations to determine what would need to be true to support those assumptions.

As an industry, we seem to have developed a knack for inflating markets around opportunities. No doubt, many people have become skilled at profiting from such bubbles.

Corrections from such bubbles can often be painful and even introduce key risks. But the presence of a bubble does not refute the existence of underlying value.

What is important is what is changing, and especially what is changing not just because of the presence of investment but because of the fundamental changes in the technology landscape.

What components have evolved, and what effect has that had on other components in the value chain? Which ones are viable only with the current investment levels, and which ones are resilient to a correction?

AI-assisted development has already changed software development forever

A case in point is AI-assisted software development. There are changes across the entire SDLC that shift the software workflow to the point where it's almost unrecognisable from how software development occurred before.

There are, of course, still practices that are from the before times, but how you leverage these has evolved. For instance, unit testing was an early warning system, allowing you to detect issues quickly. Now it’s feedback for your assistant and a source of instantaneous fixes. Test-driven development is a source of signals for the intent of the software, which can help provide more reliable assistance and so on.

Often, when people refer to AI, they are talking about the current generation of generative AI systems, which are only a subset of what had previously been described as AI. There may well be an investment bubble in the impact that generative AI will have across all the industries where it could be applied. I am more sceptical that the effect in software development is quite as overstated.

Even if the foundation models spiked in price, it’s practical for companies to deploy models locally, providing an almost equivalent experience, which improves both productivity and the quality of the software developed. The genie is out of the bottle, and there is no going back.

Enquire about Coaching

The Advice I’ve Given CEOs

Most companies already overhire
Grow only when necessary.
AI-assisted development offers the opportunity to achieve more and better results.
AI-assisted development changes the assumptions, such as team size and composition.
Conclusion

Rethinking the Advice: When CTOs Should Stay “On the Tools” in the Age of AI-Assisted Development

Daniel Walters — Mon, 26 May 2025 02:05:38 GMT

Hi everyone,

Thank you for reading Great CTO. I publish weekly and have an archive of over 150 posts, each packed with valuable insights on various topics relevant to the CTO and the issues they face, distilled from my career experience.

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

This is an AI-assisted post based on brainstorming I did with one of my chatbots. It is intended as a thought starter on key issues CTOs are experiencing.

Introduction - CTOs Should ‘Get Off The Tools’, Right?!

One of the most repeated pieces of advice CTO coaches give is, “Get off the tools.” Focus on vision, people, and scale. Let the team code—your job is to lead.

Like any context-free advice, it’s good advice until it isn’t.

In a world where AI-assisted development redefines the relationship between humans and code, it’s time to revisit that assumption. What if staying close to the tools isn’t a sign of poor delegation, but a competitive advantage, when done with strategic intent?

* I can hear a gasp from 1000 CTO Coaches as they read this line *

The Classic Rationale for Stepping Back

CTOs are told to step back from hands-on coding for good reason. As teams grow, the demands on leadership shift. Your leverage comes not from the lines of code you write, but from the systems you architect—technical, operational, and cultural.

Writing code when you should be scaling culture is often a sign of avoidance or over-comfort. And when you're the bottleneck for decisions or pull requests, that’s a problem.

But the game has changed.

AI Tools Have Shifted the Leverage Point

The emergence of tools like Cline, Cursor, RooCode, and Windsurf is not just about productivity. It’s about cognition. These platforms act less like IDEs and more like thinking companions—collaborators that reason, suggest, and refactor alongside you. The working practices for individuals and teams shift, and all of a sudden, there are a lot of new concepts to learn, and they continue to evolve quickly.

Understanding how to ask and guide AI becomes as crucial as writing code in this new paradigm. That shift creates a new strategic surface for the CTO.

Three Strategic Reasons to Stay (Selectively) “On the Tools”

Pattern Recognition at the Frontier
When you're building in a fast-moving domain (e.g., LLM integration, agent workflows, multi-modal AI apps), your team is likely learning on the job. Being hands-on—even briefly—gives you context to spot emerging abstractions, brittle edge cases, or systemic inefficiencies early.

This isn't micromanagement. It's proximity to the edge of innovation. With some large shifts, such as the changes involved with AI-assisted development, it’s common to find some of your team's experienced members behind the curve. That makes it hard to delegate leading such a shift to them.

Empathy and Enablement
Many AI development workflows still have rough edges. Prompt strategies, tool ergonomics, integration quirks—these are lived experiences your team wrestles with daily. When you occasionally pair-program with AI or explore a new tool firsthand, you gain insight into where your developers are getting stuck, bored, or confused.

That knowledge enables better process design, onboarding, and toolchain selection. Most importantly, it helps you better understand what is involved in the change so you can lead it more effectively and know the team’s concerns firsthand.

Credibility and Thought Leadership
If you’re a product-led CTO in an AI-driven business, your credibility doesn’t just come from title—it comes from demonstrated understanding. Investors, customers, and candidates want to know: Does this leader understand the terrain they’re navigating?

You don’t need to be the best engineer in the room. But if you’ve explored the tools, you’ll speak with authority, grounded in experience, not hearsay. You won’t be driving your team into unsafe situations where the hype doesn’t match the reality.

📢 Join the inaugural ‘Humans In The Loop’ livestream - a weekly discussion of new practices emerging from the AI and software development frontier. ⤵️

All Technical Leadership is Situational

This doesn’t mean reverting to being the lead engineer. It means selectively engaging in hands-on work when it supports broader strategic goals:

To validate a new AI-assisted development workflow before rolling it out team-wide
To prototype and test ideas at the edge of what’s possible
To evaluate tools with a practitioner’s mindset, not just a buyer’s

CTOs who embrace this model aren't doing it to control. They’re doing it to sense, learn, and guide.

More on why doing real work with these tools is required to assess and understand them here properly:

Closing Thought

Being “on the tools” isn’t a binary choice—it’s a dial you adjust based on context. AI-assisted development gives CTOs a new kind of leverage: faster learning cycles, deeper insight into team pain points, and a sharper lens for strategic opportunities.

The larger the organisation, the more likely it is that you have people more than capable of delegating this to and other priorities that might outrank this one. But that isn’t all companies. Navigating this shift might be your top priority if you compete based on speed or technical capability.

So next time someone tells you to “get off the tools,” pause and ask: Is there a strategic reason for me doing this, and have I adequately communicated my intent?

Thanks for reading Great CTO - Dedicated to helping CTOs thrive.! This post is public so feel free to share it.

Over to you💬

Q1: In your context, where might a short burst of hands-on exploration unlock insight or unblock your team?

Q2: How might you evaluate new AI dev tools without becoming a bottleneck or reverting to individual contributor mode?

Q3: What rituals or rhythms could you introduce to stay technically literate without undermining your team’s autonomy?

Leave a comment

Reclaiming Focus: Why SaaS Fatigue Is Fueling the Rise of AI Agents

Daniel Walters — Sun, 18 May 2025 19:00:52 GMT

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

This is an AI-assisted post based on brainstorming I did with one of my chatbots. It is more intended as a thought starter. Nonetheless, it raises some interesting questions about whether the AI investment bubble will disrupt SaaS businesses.

If you’ve ever caught yourself juggling tabs like a circus act—CRM open in one, docs in another, code tools spread across monitors—you’re not alone. Today’s tech leaders operate in increasingly fragmented environments, where every function demands its own SaaS platform. We’ve added tools to gain efficiency, but in the process, we’ve lost something more valuable: our focus.

Now the cracks are showing. And AI agents might be the wedge driving the next wave of disruption.

The Hidden Cost of SaaS Sprawl

Narrowly focused SaaS tools do one thing well—and that’s precisely the problem. The more comprehensive your needs, the more tools you end up stitching together. For consultants like me, multiply that by every client relationship, resulting in a chaotic web of logins, interfaces, and subscriptions.

The time cost is real:

Authenticating into dozens of tools.
Managing credentials across clients.
Adapting to inconsistent UIs and workflows.
Constantly context-switching to perform basic actions.

Then there’s the pricing model. Per-seat subscriptions and bloated tiers often don’t reflect the value you extract. You pay full price, whether in the app all day or need it for one key function.

These inefficiencies aren’t just annoying—they’re structural. And that’s what makes SaaS ripe for disruption.

AI Agents as the New Interface Layer

Smart money is moving toward AI, not just because it’s shiny and new, but because it targets this inefficiency head-on. AI agents, like Claude Desktop, Cursor, or orchestrators like n8n and Zapier, are increasingly replacing the need to live inside every SaaS interface.

Sure, the integrations are still fiddly. You’ll spend some time up front setting up API keys or designing workflows. However, once configured, the payoff is significant.

I now spend far less time inside individual tools and far more time in front of intelligent orchestrators. I can pull client data, summarise documents, draft replies, and update systems—without touching half the SaaS platforms on which those actions depend.

That’s not just streamlining. That’s reclaiming agency.

For Tech Leaders, This Isn’t Optional

If you lead a team—or serve multiple clients—you’re likely feeling this friction already. The question isn’t if AI will change how you work. It’s how intentionally you’ll adopt it before it becomes standard.

With orchestration tools and AI automation:

You reduce authentication fatigue.
You escape per-seat pricing traps by minimising direct usage.
You adapt workflows to your rhythm, not the other way around.
You unlock insights across tools, without needing to check each manually.

It’s not about replacing SaaS—it’s about decoupling the function from the interface.

So, Where Do You Start?

Here’s a pragmatic path to get going:

Audit your toolset: Where do you spend time managing the tool, rather than using it?
Pick a high-friction workflow: What feels like “too many steps” every time you do it?
Design a lightweight solution: Use Claude, GPT, Zapier, or n8n to test an AI-driven interaction layer.
Iterate toward utility: Don’t automate everything—just the things interrupting your focus.

Over to You

Are AI agents a curiosity for your team, or are you already building your orchestration layer? What’s been your biggest blocker—technical, budget, or mindset?

Q1: What SaaS platform do you wish to use without logging in?

Q2: How much time are you losing to tool-switching and authentication across your week?

Q3: How different would your stack look if you could price SaaS based on actual value delivered?

Let’s talk. The SaaS stack is bloated, the interfaces are clunky, and the margins are wide. That’s not a recipe for sustainability—it’s a sign of coming change.

👀 Coming Soon…

Next week, I’ll continue my theme of AI-assisted development, covering all angles important for technology leaders to make informed decisions on leveraging this fast-evolving technology and what it means for other decisions, such as hiring and budgeting.

Subscribe to get it in your inbox.

If this idea sparked something, share it. Better yet, hit reply and tell me how you’re thinking about team design in the age of AI.

—Daniel

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

Has AI Finally Made Fred Brooks' Surgical Team a Reality?

Daniel Walters — Thu, 15 May 2025 19:00:50 GMT

Generated by ChatGPT

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

This is an AI-assisted post based on brainstorming I did with one of my chatbots. It is more intended as a thought starter than an academic exploration and re-examination of Brooks’ work. Nonetheless, I feel it raises some interesting considerations around why the productivity of AI-assisted development is more than just faster typing.

Has AI Finally Made Fred Brooks' Surgical Team a Reality?

Fred Brooks had a provocative idea.

Instead of growing software teams by adding more generalist developers, he suggested something radical: what if one elite developer—the “surgeon”—was surrounded by a carefully structured team of skilled specialists, each removing obstacles and supporting them to focus entirely on writing the critical code?

This was the Surgical Team model from The Mythical Man-Month. It was elegant, focused, and theoretically high-performance.

And for decades, it remained exactly that: theoretical.

Until now.

🧠 The Original Vision: A Developer with a Pit Crew

Brooks imagined a team where the lead developer was the high-leverage operator, and everyone else existed to remove drag.

The surgeon writes all the critical code.
The co-pilot shadows and can step in if needed.
The editor polishes documentation and code comments.
The toolsmith builds internal tools to increase speed.
The tester ensures quality and catches regressions.
The secretary keeps the machine running: meetings, reports, comms.

The idea? Reduce coordination overhead. Increase clarity. Let the best developer fly.

But in reality, few companies ever built teams this way. Why?

❌ Why It Didn’t Work—Until Now

Two reasons:

Too expensive. Assigning a team of six to support one person just didn’t make business sense.
Too human. Even if you could afford it, humans bring context-switching, fatigue, misalignment, and communication drag.

The model was brilliant on paper. It just didn’t scale with people.

🤖 The AI-Assisted Comeback

Fast forward to 2025, and the story is different.

AI tools have started quietly slotting into the exact roles Brooks imagined.

AI as Co-pilot – Code suggestions, error catching, pattern recognition, pair programming.
AI as Editor – Cleaner documentation, code formatting, and commit message writing.
AI as Toolsmith – Need a script? A CLI? A Slack bot? Done.
AI as Tester – Auto-generated test suites, edge-case identification, regression checks.
AI as Secretary – Summarised meetings, cleaned-up notes, ticket or project artifact generation.

What was once an elite human team can now be largely automated or augmented by intelligent agents working 24/7.

Suddenly, the “surgeon” isn’t just surrounded—they’re amplified.

💡 Rethinking the Role of the Modern Surgeon

The developer’s role hasn’t shrunk—but it has evolved.

The best devs are no longer buried in logistics, communication overhead, or repetitive tasks. Instead, they become:

System designers
Prompt architects
Decision-makers with AI support

The new surgeon isn’t surrounded by people.
They’re surrounded by AI.

It’s not just faster. It’s clearer. It’s quieter. It’s focused.

🔁 What This Means for Tech Leaders

If you lead teams, this raises important questions:

Do you still need five-person teams for every feature set?
What happens when one AI-augmented developer is more productive than three traditional ones?
Could you experiment with micro-teams where one senior dev is supported by fractional roles and intelligent automation?

This isn’t about replacing humans. It’s about designing around a new leverage model.

If you had one exceptional developer and a blank slate—would you structure their team the same way you do now?

🩺 The Surgical Model, Reimagined

Fred Brooks was ahead of his time.

He didn’t just anticipate the pain of coordination. He foresaw the power of focus. What he lacked was the infrastructure to make it viable.

Now we have it.

With AI in the support roles, the Surgical Team might be less of a metaphor—and more of a blueprint.

💬 I’d Love Your Take

Q1: What would you need in place to safely experiment with an AI-supported solo dev sprint?

Q2: If AI could reliably support your top devs, how would that change who you hire next?

Leave a comment

👀 Coming Soon…

Next week, I’ll continue on my theme of AI-assisted development, covering all angles important for technology leaders to make informed decisions on how to leverage this fast-evolving technology and what it means for other decisions, such as hiring and budgeting.

Subscribe to get it in your inbox.

And if this idea sparked something—share it. Or better yet, hit reply and tell me how you’re thinking about team design in the age of AI.

—Daniel

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

Wondering How to Support AI Adoption? A Guide for Leaders.

Daniel Walters — Sun, 04 May 2025 21:57:58 GMT

Photo by guille pozzi on Unsplash

Hi everyone,

Thank you for reading Great CTOs. I publish weekly and have an archive of over 150 posts, each packed with valuable insights on various topics relevant to CTOs and the issues they face, distilled from my career experience.

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

Over the past few months, several clients have posed similar questions regarding strategic decision-making concerning AI, so I thought it might be helpful for others if I wrote up some of what I’ve shared with them.

The key questions I’ve been asked (paraphrased):

Is AI a truly disruptive trend or a bubble?
Should I stop pursuing growth through hiring and instead focus on improving the efficiency of how we build software using AI?
What software development principles are subject to change in the AI-assisted software development era?
How do I encourage our teams to explore what is possible with new AI capabilities?
How should I think about spending on software developers and AI for the coming financial years?

These same questions were discussed at a few tech leader events I attended recently, and I’ve also seen some similar threads in the blogosphere. It appears these are questions in the Zeitgeist.

In this post, I will focus on the first, and I will address the subsequent question in a future post:

How do I encourage our teams to explore what is possible with new AI capabilities?

Should We Communicate an AI Mandate?

No doubt you’ve seen the mandate by Tobi Lutke, CEO of Shopify, on the use of AI:
https://x.com/tobi/status/1909252234455416902

As mandates go, it’s a well-structured, well-reasoned approach that reminds me of the Jeff Bezos API mandate, which appears to have delivered on its intent and more. The Jeff Bezos mandate is notable because it’s an exception regarding the success of mandates, which tend to introduce chaos, remove agency and ignore nuance that may be important.

Duolingo, a company whose product has successfully incorporated AI features, shared a similar company-wide memo this week.

This guide will provide ways to approach this without needing to resort to mandates, after all, AI coding mandates are driving developers to the brink

I wouldn’t rule it out completely, but it’s not where I would start. Given an adequate context of need and opportunity, the team will bring more energy to discovering value, retaining agency, and making choices.

Let’s look into where we should be starting.

How leaders can support the adoption of AI-assisted coding and the use of AI in product features

This brings me to the key question leaders have asked me recently. If AI is to become an essential component of efficient software development, how do leaders help their teams with this transition?

Here is where I suggest you start based on my experience leading other seismic changes, such as cloud adoption, DevOps practices, customer experience (CX) focus, and improving adaptability and responsiveness and various shifts over the past three decades:

Consider and address sources of friction for adoption.

To successfully foment adoption, we must first understand what contributes to friction and influences whether something is adopted. If we don’t do this, we are likely to put our teams in a position to overcome obstacles they may not have the agency or adequate support to overcome.

Here are some examples I’ve observed with productivity tools such as AI-assisted development tools:

Lack of clarity on where leadership sees the opportunity
Fear of burden from associated issues
Their Current commitments
Availability of collaborators
Lack of apparent opportunity to try and fail safely for learning
Consider and leverage the adoption curve.

This post provides details I have recently shared with CEOs and CTOs who have approached me on these issues. The majority of the content on this blog are free, with a small selection behind the paywall. For the price of a coffee a month, benefit from all the insights from my career experience and from working with top CTOs and support me helping technology leaders like you, globally.

Subscribe now

Lack of clarity on where leadership sees the opportunity

Many discussions about AI get bogged down quickly because AI can be applied to addressing many types of problems, so a great starting point is to get specific about which problem you believe it might help you address.

Making decrees about using AI without being particular about what types of opportunities you see and where they may be particularly relevant to your business can be frustrating or lead to excessive time-wasting.

Be specific about the use cases where you see an opportunity for AI

For example, distinguish between different applications of AI and how you see it benefiting your organisation. For example, here are some examples which highlight the aspect of AI, where it will be applied and the benefit:

We can use AI to solve our customers’ information problems for specific business processes where we have unique data for a competitive advantage.
AI product features for supporting additional pricing tiers.
AI-powered data cleansing for higher-quality data to improve the effectiveness of key business processes.
AI-assisted development for improving productivity.
AI tools for assisting research, automating reporting for shorter turnaround and reducing toil.

AI-assisted coding for improved efficiency with activities that distract us from value-adding work
Using “vibe-coding” for fast prototyping concepts for earlier validation with customers.
AI analysis and document formatting for better efficiency in reporting and research.
AI features for unique selling proposition (USP) - beware shallow moat!

Etc.

Of course, you could also replace all the mentions of AI with a more specific type of AI—is it generative AI, such as an LLM, Machine Learning, Deep Learning, Computer Vision, recommender algorithms, etc.?

You can leave space for your teams to assess which options best solve specific problems. The nature of the adoption curve and your business's existing demands can cause enough friction to delay adopting new technologies even when they may offer an advantage.

I am not a fan of starting with a solution and looking for a problem, but if you have a problem you know well and can see the opportunity for AI to provide a better solution than other options. It may be the only responsible thing for you to do: encourage and create the appropriate space for your team to explore these opportunities.

Fear of burden from associated issues

AIs are very good at solving problems they’ve seen before in their training. For example, if I ask a tool such as Lovable to build a brochure site to promote my coaching business, it would do a great job because it has seen thousands of examples. Similarly, with AI-assisted development tools such as Cursor, it will be strongest at problems it has seen examples of in its training.

The algorithms operate on probabilities, so sometimes the AIs will make suggestions that are flat-out wrong or, even worse, subtly wrong, such that they escape into production.

Your teams may hesitate to engage with tools that could result in unchecked interruptions to their time, due to potential out-of-hours production incidents and similar issues. Acknowledging these concerns can be beneficial, as it allows for collaboration in creating a plan to mitigate such problems, giving them a sense of agency rather than dealing with the consequences of leadership choices.

Their Current Commitments

Most people struggle to entertain new ideas when they are focused on the burden of their current commitments. Suppose they can’t see the current commitments changing, especially when they have a mix of new value creation and operational responsibilities. In that case, it may seem to them like there is never a time to invest in learning or experimentation.

Identifying opportunities within the current commitments can be powerful, where consideration of new tooling might be appropriate. By sharing with them, the leadership team is comfortable with the development team slowing down initially to operate at a higher pace later. The ideas in this post may help frame this concept with the team:

short term pace","publishedBylines":[{"id":314007,"name":"Daniel Walters","bio":"Daniel shares his experiences leading technology for top software-as-a-service (SaaS) companies through significant changes to compete and win against global behemoths. Daniel is a must-read for CTOs who aspire to be strategic and impactful.","photo_url":"https://bucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com/public/images/6a26c884-8101-49bd-a80c-3e91183a699f_1970x1447.png","is_guest":false,"bestseller_tier":null}],"post_date":"2020-09-23T10:27:40.962Z","cover_image":"https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Ff50853cb-dd03-4ee2-a6b9-d7282cbf6227_800x1026.jpeg","cover_image_alt":null,"canonical_url":"https://www.greatcto.me/p/long-term-average-pace-short-term-pace-2733c8e1d35b","section_name":null,"video_upload_id":null,"id":60359045,"type":"newsletter","reaction_count":2,"comment_count":0,"publication_id":null,"publication_name":"Great CTO - Dedicated to helping CTOs thrive.","publication_logo_url":"https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd09374a4-f0ad-4534-90e7-54aad90e6100_720x720.png","belowTheFold":true,"youtube_url":null,"show_links":null,"feed_url":null}">

Availability of collaborators

Timing is a critical factor in successful collaboration. It’s underacknowledged and appreciated how often a group may be interested in a common goal. Still, at the point in time when each person is ready to engage, it passes like ships in the night because maybe other collaborators are busy with other commitments or still dealing with particular concerns that cause hesitation.

Using a combination of time and space can help people to be ready at the same time, and thus be more able to support each other and work together. I cover some tactics that can help with this in the following post:

Lack of apparent opportunity to try and fail safely for learning

When someone has deadlines, a backlog of quality issues to fix, or other factors that limit the margin for error, they are operating in a space where it can be difficult for them to prioritise far more speculative time investments. This is likely how investing time in AI can feel.

At the very least, they know they will need to slow down to learn how to benefit from AI. Secondly, having witnessed many other hype cycles, they will naturally wonder if they exert that effort and get no benefit. Worse, they may even feel they will bear the consequences of compromises on current priorities.

Look for opportunities that allow people to try out new tools safely with time to explore and low stakes for failure. This might be fun activities such as hackathons or innovation days, dedicated learning time for everyone during the week, or helping them make a plan that prioritises experimentation.

Consider and leverage the adoption curve.

You’ve likely seen the adoption curve as a concept and played out in real life. It’s often considered when finding markets or how markets evolve, but it can also be a helpful lens in change management.

As an alternative to painful top-down mandates, I suggest finding your company's innovators and early adopters and offering everyone an opportunity to join a coalition of the willing to explore AI-assisted development tools and share what they learn.

In this way, you are recruiting people into the opportunity and creating opportunities for social proof, which opens the door for people in the next phase of the adoption lifecycle. This provides significant agency for everyone and helps put maximum wood behind the arrow to find the value with the tools, working out the issues and mitigations for these, which builds up the safety that the late majority and laggards are looking for.

As negative as ‘laggards’ sounds, there is always a change that is the threshold for an individual that would cast them as the laggard. It may be because you can’t afford the risk or the disruption, or because you have been burned before. Your laggards can be an asset - your solutions have the resilience and robustness required when the laggards are signing up. Maintaining the respect and empathy for this group is essential - after all, you hired them, and as a leader, the responsibility stops with you!

Many dated change management materials refer to the concept of ‘mindset’, particularly fixed versus growth mindset. It’s poorly framed and doesn’t have strong efficacy in terms of science or effectiveness when it comes to bringing about change.

It’s been popular because it feels like it describes positive attributes in ourselves and explains drivers of change resistance. Note that this framing pushes responsibility away from leadership and onto individuals, which plays into our classic cognitive biases for optimising for our convenience. I cover this briefly in a section of this post:

https://www.greatcto.me/i/141841122/weaponised-growth-mindset

This doesn’t eliminate people's personal responsibility for participating in change that is good for the collective. Still, it can change how you engage with people and provide them the support and information they need to participate successfully.

Recap: How to encourage the use of AI-assisted coding

Understand and communicate why it’s valuable

Be specific: Communicate what aspect of AI will be used, where it will be applied, and what the benefit will be.
Avoid generalities, e.g. “we are shifting to AI!”
Engage the team on the means to help realise the organisation’s purpose.
Help identify and remove obstacles.

Create time and space for it.

Hackathons
Regular learning time - each week or budgeted per initiative
Part of the process of defining an initiative

Management Systems - Show that it’s valued

Rewards for innovative experimentation - not just features delivered
Celebrate the process.
Document and share new practices.
Establish champions and communities of practice.

Acknowledge and listen to the limitations.

There are very real challenges and limitations with this generation of AI tools.
Acknowledge the limitations and listen to the risks they introduce.
Don’t punish people for sharing risks. Work the problem together.
“It’s okay to share the many challenges we face, but I challenge you to share some ways for how it might work or how we might overcome these challenges.”Strong Adoption Requires a Solid Foundation

Some final thoughts…

The ideas in this post are based on experiences introducing other significant changes in work practices, such as agile and lean ideas, DevOps practices, using data for evidence-based decision-making, improving incident response practices, adjusting team structures dynamically, and many other disruptive changes.

It's also informed through my regular conversations with clients, peers, and coachees about their experiences supporting the adoption of this current generation of tooling and stimulating adoption within the consultancies I am a part of. This unique vantage point helps me cut past the hype and engage with people, finding real value using AI-assisted development. It’s my responsibility to help technology leaders have a clearer view of what is happening.

The practices described in this post are predicated on an assumed foundation of psychological safety and values that encourage learning and growth within your team. If these foundations are shaky, I recommend this post on the same topic, which spends some more time on these foundations:

Engineering Leadership

Enforcing the use of AI in engineering teams - good or bad thing?

a year ago · 48 likes · 2 comments · Gregor Ojstersek

Or browse my archive of posts across leadership, goal-setting, AI and more.

Has your team adopted AI tools to support their software development significantly? If not, what are the barriers that you see? What approaches are you trying to encourage an openness to explore when it comes to AI-assisted development tools? Share your perspectives in the comments.

Leave a comment

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

Paid Subscribers Only: When Budgets Are Tight – A Leader’s Guide to Amplifying Software Product Engineering Impact

Daniel Walters — Tue, 29 Apr 2025 19:00:35 GMT

Photo by Daniel Malikyar on Unsplash

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

Originally posted on the HYPR website by Daniel Walters, Feb 25 2025

In the past year or so, changes in market confidence and higher interest rates have led to a much more cost-conscious environment. Many organisations need to achieve more to compete, but have fewer resources.

In such an environment, many have already ceased operations due to the higher standard for ongoing funding. For many, this means demonstrating a path to profitability. Those who remain are still at risk of failing and, at the very least, must find a new path to operate more efficiently and focus on delivering value.

To complicate matters further, simplification offers organisations opportunities and risks. On the opportunity side, bloat resulted from companies’ liberal spending when borrowing costs were low and inefficiency crept in. This provides opportunities to focus on leveraging existing resources.

On the risk side, there is an industry trend towards short-term or overly simplified solutions that do not address what is truly needed. Vendors and service providers will sell you quick fixes and silver bullets. The problem with silver bullets is that their effectiveness is limited to the realm of fiction.

In response to recent trends of high interest rates and lower market confidence, most organisations have made cuts and cost-management decisions, introducing new challenges to their operations.

From this position, it can be challenging to envision how to compete successfully when, in the past, during an almost unprecedented period of low interest rates and high confidence, the answer was to add new roles and other investments to do more. The good news is that an opportunity exists to improve the organisation’s impact.

For executives to identify opportunities to continue improving their organisation’s ability to compete, let's first explore where organisations waste time and effort that could be harnessed to do more.

Where organisations waste effort and capacity

In the past, you may have rationalised that the payoff for adding more people outweighed other improvements. Still, it’s a great time to explore different ways to increase productivity in this reduced investment environment.

There’s a range of common ways organisations habitually waste effort. Understanding where time is wasted and assessing how much time may be wasted by each of these aspects in your organisation provides the opportunity to prioritise improvement efforts.

Here are some common issues I’ve observed in organisations and are likely to be present to some degree in yours:

Politics
Too many captains, not enough crew
Context-free policies and decisions
Unchecked quality decline
Misalignment
Comfort with non-achievement of outcomes
Handoffs and delays
Failure to correct course
Trying to do too much at once
Realising predictable risks
False urgency

For each of these, we examine why this contributes to wasted effort and what we can do to address it. We then discuss how you can capitalise on these opportunities.

Is AI-assisted Coding About Augmenting or Replacing Devs And Does the Distinction Even Matter?

Daniel Walters — Sun, 27 Apr 2025 19:30:30 GMT

Photo by Dawid Kochman on Unsplash

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

There is a pattern of people distinguishing that AI is less about replacement and more about augmenting existing workers to enhance their effectiveness. A key driver for people raising this consideration is to alleviate concerns about AI code generation's potential disruption of software jobs.

This distinction may help us consider how we can utilise AI to benefit in the short term, but it doesn’t alter the equation regarding job losses. Over the longer term, the distinction becomes less critical due to the potential for entire business capabilities to be outsourced to companies that utilise AI effectively.

A second-order effect of more effective workers is job displacement—companies will be able to achieve more with fewer people. While there may be job creation elsewhere, the jobs gap leads to social disorder for the majority who couldn’t make the shift.

This post has another angle on the same question:

Platforms, AI, and the Economics of BigTech

The many fallacies of 'AI won't take your job, but someone using AI will'

In the years between the two World Wars, France built The Maginot Line - a line of fortifications stretching along its eastern border…

a year ago · 172 likes · 30 comments · Sangeet Paul Choudary

Another factor is the cost of using AI to assist coding. The price has yet to stabilise—while costs are coming down, capability is increasing, and the investment required to achieve the highest scale of return is significant. Multiple sources have reported that spending up to $500 daily on AI assistance for a single developer is not uncommon when pushing the limits of improved value throughput.

That may require businesses today committed to realising AI's full potential to budget over $100k in addition to each developer's salary. That leaves significantly less space for engineering talent in the budget, as this talent has shifted, in the big picture, outside the company to tooling and commodity AI vendors.

The gap in what must be learnt to leverage AI in different contexts to use it effectively is growing. For various reasons, many are not engaging with learning the new skills being developed as part of this shift in the industry. This is creating an interesting disconnect between business leaders and their technical teams.

A future with developers augmented with AI leads to a jobs gap.

Efficiency gains from considerable changes in industrial automation over the last few centuries also suggest the potential for a significant jobs gap. Developers must undergo substantial learning and personal development to realise the efficiency gains individually and in a team context.

A jobs gap occurs when the number of people taking on new jobs is less than the number of people who have lost their jobs, OR if the people who take on the new jobs are not the same as those who have lost their jobs. The size of the gap is influenced by the degree of difference in skills and the amount of investment in reskilling and retraining.

For people to transition to entirely new types of jobs with different skill expectations, they need the opportunity to acquire these new skills. When new kinds of jobs involve even more technical roles, the likelihood that people can make the switch decreases substantially.

Consider the heavy social consequences of the shift away from heavy industry at the turn of the century, which led to depressed towns and the ensuing social issues. Sure, it may have eventually led to feel-good films such as ‘The Full Monty’, ‘Brassed Off’, ‘Billy Elliot’, and others, but the reality of living in those places was much harsher for a very long time.

More recently, we saw the effects of technology advancements in the auto industry, which led to a reduction in overall jobs, with the most significant reduction being in lower-skilled roles:

Source

I share all of this to make the case that rapid change driven by automation can lead to job losses or, at very least, job displacement and the creation of a jobs gap. Either way, that’s a significant amount of hardship for those affected and the scale of the change underway, which could impact many of us. There’s not just the organisation's performance at stake, but the careers of the people you are responsible for.

What does this mean for leaders?

Recognising that there are opportunities to augment your developers and help them become even more productive may aid in planning how to support them. However, don’t let that make you complacent, assuming this won’t lead to a smaller workforce.

As I covered in my earlier post, a strategic CTO will need to be considering the implications over the longer term, and that includes the obligation to your people to ensure they are ready and employable not just with your organisation but also the expectations of their future workplaces as well:

What do you think the focus on AI-assisted development should be? What are the different implications of AI-development tools replacing developers versus helping developers achieve more? Does the distinction matter? Share your thoughts in the comments.

Leave a comment

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

You Can't Assess AI-assisted Development Through Theory Or Tyre-kicking Alone

Daniel Walters — Sun, 20 Apr 2025 19:30:26 GMT

Photo by Mike Swigunski on Unsplash

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

As a CTO coach, I work with numerous companies and see the whole spectrum of AI-assisted adoption. It's been interesting to speak to people across the spectrum and listen to why they hold their positions, especially for me, who started from a reasonably conservative viewpoint on generative AI and only got more engaged over the past few years.

I note a fascinating pattern from those recent conversations: Those who are more bullish tend to have more practical experience using AI-assisted development than those who are more bearish and tend to take a more theoretical approach.

This may seem unsurprising; you are less likely to engage if you are more sceptical, but it suggests where to seek informed views. Don’t ask those on the outside looking in; engage with those doing real work and seek to understand their experiences. Please don’t limit yourself to tyre-kicking, and by tyre-kicking, I mean a shallow appraisal of the tools by plugging in a few prompts, forming an opinion and then moving on.

There are people with a firm grounding in the theoretical context AND substantial practical experience with the latest generation of tools. Many concerns we can arrive at from theory or tyre-kicking have long been overcome or reduced by those who have more thoroughly engaged.

Note: For context, going back further in my career, as a senior technology leader and as a CTO, I've led substantial developments using ML and recommenders and other data science practices in the production of products I've been responsible for and for improvement of operational processes. 

The majority of my career has involved working with big data in some form, so I am not engaging with AI from a place of complete inexperience, but I do recognise a gap with where AI-assisted development has moved to in the past few years, especialy given my focus on leadership matters. I've been directly involved in the strategy of using these technologies as both a leader and a consultant the entire time.

Objection: AI hallucinates and can generate noise (but various strategies exist to minimise this)

The evidence fuelling the concerns of AI sceptics consists primarily of issues already addressed by the community of AI-assisted developers, who have been defining new practices and workflows.

I've seen enough to be confident of the impact AI-assisted coding will have on changing well-accepted norms of code development, including team sizes, roles, and skill mix (a post on this is coming soon).

Experienced technologists must be careful when looking for evidence supporting our natural scepticism. Scepticism is healthy and will lead to better-quality engineering, but it can also betray us.

Here's my mildly antagonistic post on the matter - written from a place of love, based on observations I’ve noted through self-reflection as I’ve overcome the hesitancy I had:

We can dig shallowly and convince ourselves that the impact of AI-assisted development is overstated and is a flash in the pan, or we can do what people on the frontier are doing: challenge assumptions, get hands-on and find patterns that accentuate the strengths of AI-assisted tooling.

I am seeing small teams have terrific results, and picking their brains on their patterns is eye-opening. They are well beyond the issues that people post about when they waste some time due to something hallucinatory from an LLM.

Patterns similar to this one are helping bring control and management of the devs’ cognitive load:

https://ghuntley.com/stdlib/

The model's capability can influence the effectiveness of any LLM, how it is trained and fine-tuned, the information it provides via methods such as RAG, the quality of the prompts it supplies, its context window, and various other factors. Fortunately, the tool providers are improving and managing some of these elements on our behalf. However, it's also relatively straightforward for your team to manage these factors for your organisation’s context for far more reliable results.

Objection: The main bottleneck in software development is not writing code.

Indeed, the main bottleneck in software development is not writing code. I’ve heard this rejoinder when talking with teams and leaders who are hesitant to experiment much with AI-assisted development. It’s been a valid objection to many suggestions for improving productivity that amount to helping developers type faster.

At first glance, AI-assisted development seems like another way to type faster. However, when I got more hands-on experience and did real work with these tools, I found that the most effective ways to work with AI involve much more than time-saving typing.

Writing specs can clarify thinking and design, and create a productive feedback loop when working with the assistant. There are many more points in the software development lifecycle where AI assistance can be massively helpful from both an efficiency and effectiveness standpoint. Typing is not the bottleneck, and AIs are not limited to helping with typing.

Still, AI-assisted development is not limited to helping write code, so this rejoinder, which I’ve heard frequently as an objection to using AI to assist with development, is not a valid reason not to engage. AI can assist with research, design, requirements analysis, observability, testing, product strategy, architecture and many other facets of software development.

Objection: The Benefits of AI-assisted development are all hype

Focusing on vibe-coding and AGI distracts from the practical use of AI-assisted development. More practical approaches receive less coverage but are far more relevant to software development.

Cynicism is reasonable, and sorting through real and imagined impacts can be difficult; not least of the confounding factors is the Productivity Paradox. Erik Brynjolfsson coined the term in a 1993 paper ("The Productivity Paradox of IT") inspired by Nobel Laureate Robert Solow: "You can see the computer age everywhere but in the productivity statistics.". In more recent times, there’s conjecture and evidence that the productivity gains of automation improvements can be seen but show up after a lag.

Not all AI-assisted development is vibe-coding

Vibe-coding reflects some interesting progress in its own right and is an enjoyable experience fraught with risk should you ride it into production. Whilst strongly related, it's currently on vibe-coding and is on a trajectory separate from AI-assisted development, but it understandably gets conflated together.

As Simon Willison highlights, Not all AI-assisted programming is vibe coding (but vibe coding rocks)

Maybe down the track, they become one and the same.

The discourse focuses on the endgame instead of what’s already possible.

When it comes to understanding how we work and what software development jobs will look like in the future, examining the most sophisticated use cases and assessing the gap is less informative than reviewing the many mundane instances in which AI assistance excels. Instead of seeing where it falls short against replacing the best software engineers, look for evidence of what it’s already replacing.

As I covered in this post, the capabilities of the median software engineer and the conditions that they work under are a far cry from where the most productive engineers and teams are at, and this is where AI will have an impact first - not by their adoption but certainly where displacement is far more likely:

And, of course, the capabilities are improving and will continue to disrupt a broader segment of developers as the capabilities improve.

Managing Cognitive Load in an AI-assisted context

Our productivity as individuals depends on how long we can spend thinking about the task at hand in a flow state. Our productivity as a team is a function of the ease of alignment of the team members, such as signalling progress and choices in a way that doesn’t overwhelm any individuals and enables a flow of value that can be validated.

Our effectiveness in deriving benefit from AI-assisted development results from managing our cognitive load. One opportunity to conserve cognition is to remove many mundane tasks from our concerns.

Early experimentation with AI assistance will suggest to most people that out-of-the-box AI assistance threatens to make that worse. This is because the amount and scope of changes AI undertakes on our behalf that need to be checked, and worse, some of which will be misaligned with our intent, can overwhelm us—it becomes an inventory of things to consider and check, something without assistance we do in turn with our focus tuned to mostly the scope of each and thus naturally limited from being too draining. This was precisely my experience, but it shouldn’t be the point we step off, especially if we see an opportunity for competitive advantage for our companies or consider ourselves thought leaders.

So, to persevere beyond this point of friction, the effectiveness of AI-assisted development becomes a question of “How can we express intents for which we are confident of the result or have simple ways to verify?” such that the cognitive load of the assistance remains within a comfortable range most of the time.

Objection: Companies’ Adoption of AI will be similar to other trends

One last thought—and this one is a bit more speculative—is that Most software organisations' difficulty with change suggests that adapting to make good use of AI is low for most.

This is a fair point; it will be a challenge, but I am not sure it will limit the impact of AI-assisted development. We may see a resurgence of outsourcing arrangements where the capability builds up in other firms and the shift in unit economics makes it feasible.

NZ Tech Leader Resources

Conclusion

The typical objections to using AI-assisted development tools seem more plausible from afar. Still, they are subject to the limitations of theory alone because details that may contradict the inferred limitations are unavailable from that distance.

Similarly, shallow tyre-kicking can lead to confirmation bias, as known limitations can be interpreted as confirmation that your reasoning for not investing more time was justified. The junior developers will be all over this stuff. As Geoff Huntley puts it, the future is for people who can do things and signals a period of discovery and acquisition of how to do things using the new paradigms.

Instead, with potentially momentous trends, it's essential to look for what they may mean as viable and valuable tools that can help you. There are tools you use today that others once were hesitant to embrace, and it's hard to imagine you, too, might be susceptible to the same rationalisation that leads to later adoption, which puts you at a disadvantage.

Where are you in your AI-assisted development adoption journey? In the comments, share your concerns, experiences, and lessons learned.

Leave a comment

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

What Principles Might Change In AI-assisted Software Development?

Daniel Walters — Wed, 16 Apr 2025 12:56:06 GMT

Photo by nygi on Unsplash

Hi everyone,

I strive to make each post a helpful resource on the topic it focuses on so that when a CTO has a need, they can reference an atomic nugget of insight. To this end, I regularly revisit and refine my posts, ensuring you always receive the best and most up-to-date information with maximum clarity.

If you’d like to support the growth of this resource, consider upgrading to a paid plan and take advantage of the additional ways I can help you.

Subscribe now

Recently, CEOs and CTOs have asked me what assumptions might change with the advent of AI-assisted software development. Some companies are pausing hiring and increasing their experimentation with AI-assisted coding to see if they can be more productive with fewer people but more AI.

As I explored in my recent post, leaders are looking for improved efficiency and effectiveness from AI - some are naively looking to vibe-code their way to the bank, and others are being more deliberate about their approach :

Putting those with poor and misguided intentions aside, I believe this is still a legitimate question: whether it was inspired by hype and unrealistic expectations, leaders should be considering what changes as AI takes hold.

I am observing people using AI for significant productivity gains. Whether those gains are 30% or 100x gains, as some claim, remains to be seen. From what I have observed, the gains are more than the average technologist may realise and in ways many won’t anticipate. If that’s the case, what might change with rapid productivity gains?

Don’t get me wrong, the limitations of AI that many are highlighting, such as hallucinations and limits of reasoning and creativity, are real, but what is underreported is the effectiveness of what people do to overcome those limitations. I will look to cover more examples in future posts. In the meantime, let’s gaze into the near future and consider:

“What software development principles are subject to change in the AI-assisted software development era?”

This thought exercise challenges our assumptions. Things that may have become pillars of our belief system may crumble when there is a significant change, such as the change that AI-assisted software development represents.

The Principles Likely to Change With AI-assisted Software Development

I empathise with people who feel it is hard to know what impact AI will have on software development. Indeed, I have no idea where it will end up. Still, from my unique vantage point, I have seen enough to be confident that there’s enough progress and momentum that many of the principles and touchstones associated with software development may be subject to change.

Recently, with the express goal of identifying which principles may be in question as AI-assisted coding evolves, I’ve spoken with colleagues, friends, CTOs I consult with or coach, software engineers and a range of other people with different perspectives that, along with my experimentation, and here is my list of which are likely and why :

The size of teams
- “2-pizza teams”
- Overall size of a software development organisation
The relative importance of maintainability and code readability
- Don’t Repeat Yourself (DRY)
- Literate/readable/clean code
Specialisation vs Generalisation
- The split of responsibilities between roles
- The rise of new roles
- stable teams vs dynamic teams
Conclusion

Why these principles may break down in an AI-assisted environment

The size of teams

The size of teams may be disrupted by changes in the productivity around a range of tasks. Whether it’s the increased effectiveness of an individual or, depending on what you believe is possible with AI, with developers managing teams of synthetic developers, what may need to be invested to achieve specific outcomes will change. Of course, that will change the market, and it’s hard to judge what the effects of that will be.

“2-pizza teams”

The 2-pizza team was an extension of a rule attributed to Jeff Bezos for effective meetings (seen as a counteraction to the Ringelmann Effect ), and it has been cited informally as a guideline for software teams ever since. Whether intentional or not, many team structures over the past couple of decades, whether feature teams, tiger teams, stream teams, or other configurations, have all approximated this size of 5-8 people (and no greater than 15).

AI tools assist in all aspects of the software development lifecycle. Thus, they promise to shift back towards more generalisation and away from specialisation due to the potential for most topics. AI can either help the developer learn enough to undertake the task themselves or do it with AI assistance.

It may be more effective for much smaller teams of 2-3 engineers to collaborate with the support of code-assist tools, agents, synthetic co-workers, or other AI-assist methods.

Overall size of a software development organisation

A prevailing question I have been getting recently is whether overall software development organisations can be smaller regarding headcount. I believe that in most cases, the answer is yes, even without the progression of AI, as too often leaders add roles as a default response to problems and because they are poor at managing other factors such as delivery, change management or quality. With the progression of AI, even more will be possible, but whether it’s the traditional organisations or AI-native organisations that prove this remains to be seen.

Factors include the increased costs of AI tooling, possible increased productivity, and the generalisation of present-day roles. I cover this in more detail in a separate post, which will be published soon.

The relative importance of maintainability and code readability

Don’t Repeat Yourself (DRY)

Principles such as "Don’t Repeat Yourself" exist to help with code literacy and maintainability. Suppose we can change code more swiftly and spend less time reading lines of code because other indicators might become more valuable representations of the state and capabilities of code. In that case, we may put less stock in such principles.

Literate, readable and clean code

Over time, code representations may become more critical for machines than humans. As this shifts, practices concerned with human code readability may be superseded by machine reading efficiency and literacy.

Specialisation vs Generalisation

There is always an oscillation between specialisation and generalisation as software and software practices evolve. Specialisation of roles occurs as the depth of what can be known and must be known to be effective in an area grows. It can spring back as tools and practices evolve, allowing some complexity to be managed more easily. AI is already demonstrating an ability to facilitate this shift in ways it can support rapid learning of technical concepts and take some of the toil away from developers. In effect, it can also lower the barrier to participation in development.

The split of responsibilities between roles

Our definition of the expectations for each of the typical roles in a software development team is likely to change. Existing trends of shifting left may be accelerated and devolved such that any team member may do them.

The rise of new roles

Conversely, other types of specialisation may form, such as a range of AI-specific competencies, including specialists in prompt engineering, monitoring for model drift, AI ethics, and other concerns that start to require dedicated expertise and management. These changes are driven by need and demand and may not all come at once; hence, the oscillation effect between specialisation and generalisation continues.

Like stars, these changes will appear like oscillations when viewed from a certain angle. Still, should we map out the components and their evolution using a tool such as a Wardley map, we are likely to see more sophisticated movement as the relative effects different components have on each other play out.

stable teams vs dynamic teams

The acknowledgement that much of the world’s software must be actively supported to achieve the quality of experience most expect from modern software has led to a slow shift towards stable teams organised around a service or discrete value that the organisation has committed to providing.

The advent of AI-assisted software development may challenge our assumptions around this, as developers can re-establish the context of working on a service and may be better able to move between services and value pools to make improvements.

The issues associated with teams that form around transient needs may be lessened due to improved observability and ability to view the architecture through various lenses AI tools may afford us, whilst advantages such as flexibility and responsiveness are retained.

Conclusion

Some of us have used some or all of these principles to inform our approach to software development over the past few decades. However, as the world changes, we may hold on to these assumptions too tightly.

It helps to identify these and examine what was true that led to that principle's usefulness and what might need to shift to render it less valid. This can help us continue to have strong opinions, loosely held, knowing that as things change, we remain adaptable.

What principles may not hold as AI-assisted development rises in popularity? Share what you think and shifts you have already noticed in the comments.

Leave a comment

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

A response to 'By what means? Management without objectives'

Daniel Walters — Mon, 14 Apr 2025 19:01:21 GMT

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

Photo by Jason Weingardt on Unsplash

Martin Chesbrough wrote an insightful post recently about some of the risks and issues of using OKRs, which is worth a read. He highlights, in particular, an issue when leaders highlight the desired output or outcome, as they might do in the form of an OKR, without engaging their team on how they might achieve that.

His conclusion is not to use OKRs, which differs from mine as evidenced by the fact that I’ve used them in multiple work contexts, which is his prerogative. As I’ve stated several times on this blog, OKRs are not the only way to solve the alignment challenges they were conceived to address, nor are they the best available goal-setting approach; they are merely the most popular (and only of the formal and semi-formal goal-setting systems i.e. if you ignore the generic use of SMART goals, ad hoc goals, or not using a goal-setting approach at all which I am sure are all more popular still).

For me, the interest in OKRs has been because that was where we started, and it was a stepping stone towards ideas such as, and because their relative popularity helps with accessibility and familiarity for the audience:

The concerns he raises are part of why I suggest OKRs should respond to a particular need and not a universally relevant practice for all companies at all times. This should not surprise any of you who have read my various posts on the importance of context. They are also why I feel that OKRs alone are insufficient to help an organisation and why I was motivated to write the post Improving OKRs. I would never suggest they are always a good thing to do as context-free advice for companies. They should be a response to a problem and tested to see if they help address the issue and either be adapted until they address it or abandoned in favor of something else.

Martin was responding to Noah Cantor’s post: OKRs Are Management Malpractice and my series of response posts, which challenged Noah’s quite definitive take on the subject:

I wrote a long comment in response to Martin’s post, which I thought the audience of this blog, especially those of you who were drawn to this publication because of the exploration of goal-setting I’ve covered. I also encourage you to check out Martin's comments in other posts' comment sections, such as the thread at the bottom of this post:

Enjoy!

Hi Martin, it's a nice post. I agree that ‘outcomes over output’ is reductive—it's not a phrase I like to use. It can't be one or the other.
Leaders who fail to discuss how something will be achieved would be derelict of duty.
You seem to suggest that because a team wrote down their agreement of what a desirable effect of their work was, they won't engage in the means of achieving it, and neither will any leader who may be supporting them.
That's not behavior I've observed.
I wholeheartedly agree that leaders tend to copy and paste what worked in a previous situation or what they perceived worked. They tend to focus on the final form of where they evolved, addressing needs as they developed.
Look at all those applications of the Spotify model or SAFE, etc. These are context-free solutions applied to unexamined problems. OKRs could easily be misapplied using the same flawed thinking. Dr Jabe Bloom's Ideal Present Design is a very accessible introduction to Ackhoff's ideas in Idealized Design and Gap Thinking vs Present Thinking, which I've found helpful in helping others spot the same error.
Google used OKRs and was successful. People copied OKRs initially because they wanted to be as successful as Google, failing to notice that many factors were at play in Google, including many invisible factors that contributed to their success. That might be like thinking the horse symbol on a Ferrari is what makes the car fast.
A more helpful reason to adopt any goal-setting method is that you observe energy wasted on pushing towards divergent outcomes. The desired result is implicit, and because of this, there was a lack of awareness of the differences in views. This issue led to adoption at a team level.
Another scenario was that teams that seldom but very occasionally have interactions that can contribute to an effect were unaware because, absent of any summary of intent, they would have needed to consume a lot of every team's modelling, plans, etc. This led to the public sharing of goals.
In Seek's example, teams with consumer-facing products could sometimes operate independently. Other times, they would collaborate or coordinate with teams updating AI models shared across interfaces (mobile apps, email, and push notifications) or operate on changes that affected both sides of the employment market—e.g., a change that affects how candidates interact with hirers.
Being aware of those intents, often before any work had occurred, was very helpful in triggering those teams to reach out and identify how they might need to interact—coordinate, collaborate, self-service, etc. Leaders also helped with this, but there were so many teams and potential interactions that it helped if this could be something everyone could participate in.
OKRs was only one of many things we and most teams felt was helping. We also modelled everyday interactions between teams, relationships between goals (i.e. the logic of why we thought interventions would have the effects they might have - theory), "TEAM APIs", etc.
My purpose in writing about OKRs is not to advocate for them. I have written in great detail about my experiences. Hopefully, by accessing the details, people who opt to try OKRs can see why we tried them, what worked and didn't, and what it may have been about our environment that might explain that. The examples above might illustrate how I differentiate alignment with management.
You also mentioned tampering with just part of a system—that it's an issue we were aware of and why we mapped relationships and systems rather than using OKRs with teams in isolation. It's a valid concern, and we expect teams not to get it initially, but that was a nice on-ramp into systems thinking for everyone.
Similarly, when adopting OKRs as a solution to an issue—I don't advocate starting by applying them across the board—we started incrementally and experimentally and monitored whether it was helping.
Hope that's helpful insight into your line of inquiry.

Note 1: I’ve edited my writing further, improving it for clarity but hopefully without changing its substance too substantially.

Note 2: I was fortunate to catch up with Martin on a video call recently after posting this last comment, and we had a good chat. Martin shared some of his career experience, in which he’d seen firsthand leaders who were very focused on sharing an outcome but less interested in engaging teams to understand how they might support them in achieving the goal. I explained the distinction between using OKRs for managing teams and using OKRs to address alignment and a bit more about what led us to choose OKRs as a solution in a few different contexts (a corporate with 20+ teams and a startup with effectively a single team) and the very different implementations that applied to those very different contexts.

Where do you stand regarding the usefulness of approaches such as OKRs? Do you share the concerns covered in the post I am responding to? Have you experienced these challenges? Did you persist with OKRs? Let us know in the comments.

Leave a comment

If you enjoyed this publication, please help others find us and benefit from the insights.

Share Great CTOs Focus on Outcomes

Paid Subscribers Only: Value-driven Technology Funding — Aligning Investment Mechanisms with Software Excellence

Daniel Walters — Sun, 13 Apr 2025 19:00:59 GMT

Photo by Krystal Ng on Unsplash

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

Originally Published by Daniel Walters on the HYPR blog on Jan 02.25

In my earlier post, ‘CEOs, software funding and budget mechanisms could damage your investments’, I detailed how the nature of software development warrants a tailored approach to funding and managing it to enable better performance. Here are the options for doing this...

One of the common missteps I see executives make (including me earlier in my career!), is trying to operate within the funding structure presented to them. What is available regarding funding and accountability mechanisms probably wasn’t selected with software development in mind. Or it may serve the convenience of another group in the organisation, unaware of the potential side effects.

It is easy to assume that funding mechanisms are fixed, leading one to work only within what seems available. Additionally, it can be tempting to believe that the impact will be minimal. The disconnect between decisions regarding the work and the associated budgeting creates friction, which occurs frequently and presents barriers to achieving acceptable software quality.

What if we could achieve the transparency that traditional approaches aim to provide and the flexibility that eliminates wasted time and resources? The good news is that you can.

We will explore both interim measures you can start with and full measures, which may take some time to agree on (in one company where I was CTO, it was at least a year, possibly two, into the role).

The unwanted side effects that come with inappropriate funding approaches

There are many reasons organisations turn to project-based funding for managing funds allocation. The drive for consistent handling can lead to different types of work being funded similarly when a different approach may lead to better results.

For example, a project management office may find it convenient to organise work into programmes and projects, align funds and budgets accordingly, and treat them similarly to all other work within the organisation, and this is matched to funding decisions. Another example is that the finance team or CFO often considers new expenditures as initiatives. They would like to know when new spending will likely begin and when it is expected to conclude so they can understand the effects of these initiatives on the company revenues. Another example is that the Human Resources team may want to provide the CEO with some visibility on workforce allocation.

Whatever the reason, the intent is rarely malicious; it solves the part of the problem they are exposed to, and the other effects occur well outside their visibility. If we understand what the people responsible for the mechanisms are trying to achieve, we can look at alternatives that may serve those and our software development needs.

A classic example is that line items for spending were identified at a time when there was less information, and changing these triggers an approval process elsewhere in the organisation. This may be manageable if it happens a few times a year. But I’ve seen cases where it may occur for each developer multiple times a day, and the approvals may take up to six months or more to resolve.

I won’t claim it is impossible to work within these constraints. It’s not. I’ve done so numerous times, and so have many others. However, the cost of effort and elapsed time to achieve sufficient quality can be multiplied many times until it’s addressed – and I observe many successful CTOs who are effective at influencing change in this area and, in doing so, free up energy for themselves and their teams to redirect in more productive improvement. There are strategies you can apply in the interim to try to minimise the impact. Still, in my experience, it’s worth working towards a more wholesale change, step-by-step – especially when a large software development team is involved – to address the issue entirely.

Practices for Funding Successful Software Development

I cover a variety of strategies and practices in this article that can be used to better align how funding and budgeting support successful software development by aligning friction and support with the value being sought.

Each of these provides practical adjustments you can use to help improve your situation and provides tips on how to apply these leveraging concepts your CFO is already familiar with and capabilities they already have:

Fund value, not projects.
Funds flow like an undulating stream.
Where organisational strategy intersects with funding.
Adaptive funding and value streams.
Cross-functional collaboration on budgets.
Beware of artificial boundaries.
Funding envelopes, more frequent budget reviews and partial allocation.
Decision-making relating to the use of funds.
Consider funding maximisation over cost minimisation.
Assessing the alignment of investment mechanisms with value delivery.

Subscribe for the price of only a coffee a month and get additional practical advice, steps and tips you can immediately put into use every week. 

Please support me to continue to provide you, and all the other CTOs in need, the vast majority of content of this site (150+ posts and new posts weekly) available for free.

Subscribe now

Are Software Development Progressives Becoming the New Curmudgeons?

Daniel Walters — Mon, 07 Apr 2025 19:01:30 GMT

Hi everyone,

I strive to make each post a helpful resource on the topic it focuses on so that when a CTO has a need, they can reference an atomic nugget of insight. To this end, I regularly revisit and refine my posts, ensuring you always receive the best and most up-to-date information with maximum clarity.

If you’d like to support the growth of this resource, consider upgrading to a paid plan and take advantage of the additional ways I can help you.

Subscribe now

There’s something about getting older and, somewhere along the line, realising you're becoming your parents. You notice things like when your parents stopped listening to new music and the potential for that to start happening to you. I think it might be like that with learning new technologies. I've ridden a few waves, including the rise of SaaS, client-side web programming, and big data and analytics, and I will probably ride a few more before they become beyond my reach or interest. Each time, I went deep and learned everything I could, and my reward was gainful employment.

The age at which you stop listening to “new music” differs for each of us. It happens naturally and is a function of both your networks and the effort you make. Your networks influence what you are exposed to, but even if this diminishes with effort, you can overcome this if you are determined to learn, discover and sense-make. You must be aware, however, that with age and experience, you will develop cynicism and preferences and will need deliberate tactics to overcome these.

Is AI Hype an Inhibitor for Adoption by Experienced Software Engineers?

Because AI hype is a mix of informed professionals, excited newcomers and bad actors all singing from the pulpit, there is much noise and, frankly, wrong information being shared. It is understandable why this is a turn-off. This is also a risk, though, as it presents an easy out for some who may have been contemplating learning something new.

The Risk for Late Career Technologists

An example of this, I suspect, is emerging with the growth of AI. I’ve noticed a pattern among my contemporaries, which appears to be a mix of both healthy and unhealthy skepticism regarding the value of the current state of AI, especially the generative AI popularised by commodity AI providers such as OpenAI, Anthropic, Google, Meta, and the like. I won’t highlight any specific examples in this post as my intent is not to shame, and in many ways, I can empathise with the thought process. In almost all cases, these individuals hold prominent positions in the industry and have a strong history of championing progressive movements within software development. I won’t highlight any examples

In some cases, these individuals have a strong affiliation with the agile, lean software, or systems thinking movements. They’ve helped organisations achieve more value sooner for decades. However, there is now a new opportunity to do this using new methods, and not all of them are on board. Whether they are on board or not is their prerogative; what I seek to explore in this post is the range of considerations both as an exploration of my thinking and if any my

Healthy skepticism of AI-assisted software development

The healthy part is that there is skepticism and calling out hype worthwhile education on the nature of the models underlying LLM which compromise their effectiveness for certain types of problems and which suggest they won’t be the path to achieving the much vaunted Artificial General Intelligence (AGI) - a hypothetical kind of AI that possesses the ability to understand and learn any intellectual task that a human being can. Even more significant are the worries of what the societal impacts are when there is blind adoption.

These are concerns I share. However, I believe the change is inevitable, and while I won’t work to accelerate the disruption, I will do what I can to ensure that people are prepared to adapt. From my perspective, as I addressed in my earlier post, I worry about the rate of change having significant social impacts when large numbers of information workers are displaced and lack the skills to compete for the new types of jobs being created. My position is not about an unfettered progression of AI; that will happen, but what we do as a society to manage the changes is within our control.

Unhealthy skepticism of AI-assisted software development

The less healthy part is more of a knee-jerk reaction to the AI hype by some of those contemporaries. With so much focus on the march towards achieving AGI and the perceived threat of software engineers being replaced by AI, there is a general dismissal of the capabilities already available - some because they fall considerably short of the promise of AGI and some because they fall short in terms of being trustworthy. Concerns for the latter appear to be focused on the tendency for these models to hallucinate, making them unreliable, as well as the aforementioned limitations of LLM and similar generative AI approaches. The models, after all, are leveraging probabilities based on the many examples they’ve processed as part of their training.

These are valid limitations of these models. The misleading part is that some contemporaries have suggested there aren’t practical applications of these technologies, or at least that they haven’t seen any. As technologists who have navigated numerous technological waves over the past few decades, we’ve developed a keen sense of where to look for practical applications of emerging technologies. The practical applications of generative AI technologies are similarly discoverable, although admittedly obscured by a mountain of AI hype posts flooding social media.

Such a claim ignores significant examples of companies creating demonstrable competitive advantages with their AI investments. There are, of course, other companies with early AI missteps. More substantially, numerous jobs have been reduced to menial or limited responsibilities, which AI is disrupting.

Some may argue that the size of the investment in these technologies is far greater than what can reasonably be returned in the short term. In response, I emphasise that the trend of investment bubbles has a rich history, and while we can anticipate a correction, this does not diminish the utility of the technology itself. All investments are based on the uncertainty inherent in them. As certainty grows, the potential for return on investment becomes clearer, speculation reduces leading to a reallocation of capital.

Evidence of the Applicability of AI and AI-Assisted Software Development

The likelihood is increasing that if you’ve made or received a call to a call centre, the conversation was with an AI. It accounted for nearly 2% of all interactions in 2023 and is projected to make up 10% of all interactions by 2025. Of course, it’s not all smooth sailing; companies are still learning which interactions synthetic call center agents can manage most effectively. You can read about the experiences of company owners and agents themselves working alongside synthetic counterparts, as well as what works and what doesn't.

Some of these automations were limited simply by their lack of access, which is being addressed in the public commodity models through capabilities such as computer use and tool connectivity approaches, such as MCP. Commodity providers such as OpenAI and Anthropic are often mistaken as the only game in town due to the prevalence of their use in the consumer sphere. Companies have progressed much further with custom-developed models they train or by working with open-source models that they extend.

When it comes to AI-assisted software development, it’s easy to become both amazed and then quickly disenchanted. Through my experimentation and conversations with others who are well ahead of me, I am learning that there are many things you can do to improve the results you can achieve when assisted by AI. Some of these may become universal practices, while others will be based on the preferences you develop as you discover what works for you. The journey to mastery may well be a long one due to the range of variables at play combined with human factors.

The Experience of the AI-Natives

The inverse of the risks late-career technologists experience is valid for the generation that will be the AI-Natives. Whilst we may imagine that those entering the industry will all become time bombs prone to riding their synthetic partners into production incidents, like Major T. J "King" Kong rode the bomb in Dr. Strangelove, the reality is that there will be a spectrum. There will be capable software engineers who learn to leverage AI tools to maximise what they can achieve, and there will be those who will make a mess ignorantly.

What AI-Natives don’t have is the baggage of prior assumptions about how things work. That knowledge can be an advantage for my generation, but it can also blind us to specific changes, as some assumptions may change drastically in ways we don’t expect. The time that all our experience provides an advantage may be shorter than we assume. The AI-natives have access to all the world’s knowledge, supported by unprecedented tooling for accessing that knowledge. And they are actively using the tools that others are still tentatively trying to decide whether to dip their toes into.

Check out CTO Life Line

A Strategy For Dealing With AI-hype

Paid Subscribers Only: Attention CEOs! How You Fund and Manage Software Budgets May Be Damaging Your Investments

Daniel Walters — Tue, 01 Apr 2025 18:02:05 GMT

Photo by Eugene Triguba on Unsplash

Hi everyone,

If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.

Subscribe now

Posted by Daniel Walters . Dec 12.24

I’ve worked with many executives who have great intentions and aspirations for their companies. They’re frustrated that their energy and investment in software development are not meeting those aspirations. Some find a path to success, but many fail to produce software that meets the expectations to compete.

One common thread I’ve observed is that executives who are unwilling to adjust the mechanisms around software funding to fit the nature of software work are at a greater risk of falling short of their goals.

Specifically, I mean how funding is accessed within the organisation and ensuring the mechanisms for using the funding support decision-making. Doing this is in the organisation’s best interests in terms of the speed and quality of the software it delivers, such as the ease of using the funds and being accountable for their use.

Organisations’ traditional funding and budgeting approaches often depend on infrequent changes, centralised control, and governance, which can align with reporting lines rather than the actual workflow. The nature of software development makes it vulnerable to the consequences of misalignment.

This is because funding and budgeting are often closely tied to matters of accountability, authority, process, and policy, and any misalignment left unaddressed will have unwanted effects. Issues that fundamentally affect how people work also impact how decisions are made, and software development, being a high concentration of many compounding choices, is where these issues often manifest.

When executives ignore this issue, in the best-case scenario, it results in a lot of avoidable friction, including interpersonal conflict and fighting upstream to do the right thing. This can lead to burnout, attrition, or reduced engagement in software teams, which is costly for the business and negatively impacts company performance. In the worst cases, it results in catastrophic quality issues that destroy customer trust. There’s a better way.

To avoid these problems, technology leadership must either change the available funding mechanisms or operate within those constraints while being mindful of how funding influences the behaviour of software teams and their supporting leadership. While funding practices are important, they alone cannot protect organisations from all issues related to software development. There are various factors involved, but this remains a significant one.

In this blog, I explore why these mechanisms are so important and discuss some practical strategies that can benefit the teams responsible for developing software while also achieving the goals of managing critical company funds.

Factors influencing software funding mechanisms success

To understand why it is worthwhile to move away from established norms for funding and managing software development, we must examine what about software development lends itself to particular approaches.

Several factors shape how we must think about funding mechanisms:

The continuous nature of software
Software development is inherently uncertain
It’s a team sport
Cost centre accounting shackles value creation

These factors suggest that the mechanisms governing the work should be adaptive, funded for the length of the service and organised around the purpose and the people supporting that purpose. Let’s look at each.