In the previous episode, we discussed modern multi-tenancy, including why application-level multi-tenancy is unnecessary in modern infrastructure. In this episode, we tackle AI efficiency and effectiveness.
There’s now broad acceptance that AI doesn’t unlock whole-system benefits when it’s applied to the wrong places, or when teams lack the foundations to support it.
Read on to find out why AI is creating a new kind of gatekeeper, why there’s less pressure to say no to features, and why you need to treat your deployment pipeline like a pizza oven.
Watch the episode
You can watch the episode below, or read on to find some of the key discussion points.
Watch Continuous Delivery Office Hours Ep.8
The infuriating AI gatekeeper
By now, most of us have been on the receiving end of a terrible interaction with an organization that’s put an AI chat tool in front of their support or customer service. We can formalize and explore this problem using the beneficiary user and end user types:
- Beneficiary user: The person benefiting from making a task easier using AI.
- End user: The person interacting with the AI or its output.
Sometimes these are the same person, but in many cases, the beneficiary user enjoys a reduced workload while the end user has to run a chatbot gauntlet, review a 15-page vibe-written strategy document, or deal with a poor automated decision.
The ethics of scale explains how to use automation responsibly, and the same thinking applies to how we affect other people through our use of AI.
There’s less pressure to say no
We no longer need to say no to a feature just because we assume AI will make it cheap and fast to build. That removes a pressure many product managers have relied on to keep their roadmap in check, which makes strong product management, backed by a clear product vision, more important than ever. Without it, products become bloated with features, overwhelming users with too many options and losing the simplicity of a curated, opinionated feature set.
Many organizations decline features only because they don’t have the capacity to build them all. If these teams lose that natural mechanism for trimming their roadmap, they might add features that don’t improve the product for most users. That makes the software less valuable, because it becomes harder to understand, harder to use, and harder to maintain.
The software delivery pizza oven
You need certain foundations in place to deliver software in a way that optimizes for feedback. The pizza oven analogy helps illustrate why.
Making a pizza starts with a human process: the dough is hand-stretched, and the toppings are added. Once that’s done, the pizza moves onto a conveyor belt that carries it through the oven at a fixed speed, so it’s always cooked properly and safe to eat.
Software delivery should work the same way. Humans apply their unique skill and taste to create change, then that change travels through a deployment pipeline that checks it works and is safe to use.
Either way, speed only matters end-to-end. There’s no point preparing a pizza if you can’t get it through the oven, and no point stacking up cooked pizzas if customers aren’t ordering and enjoying them.
Too many teams speed up pizza preparation without a good oven. That’s the start of a painful downward spiral toward large-batch, high-risk, high-failure software delivery.
Happy deployments!
Continuous Delivery Office Hours is a series of conversations about software delivery, with Tony Kelly, Bob Walker, and Steve Fenton.
You can find more episodes on YouTube, Apple Podcasts, and Pocket Casts.
