Dave Farley tells a story about an organisation that took months to ship a release. Staged, layered, careful. While someone walked him through the process, he asked what happens when production breaks and a fix has to go out now.
"Oh, we can do a type seven release in under an hour."
So why not run every release as a type seven?
"We couldn't possibly do that. The risk is too high."
Type seven was their name for skipping every check the normal process existed to run, shipping the diff, and hoping. That organisation kept two paths to production: one so slow nobody could learn from it, and one so dangerous they saved it for emergencies.
Your observability has a type seven too.
You know the shape of it. Production is misbehaving, your dashboards answer none of the questions you have, so someone adds a log line and ships it. Waits for the deploy. Reads the output. Adds another log line. Or flips debug logging on across a service for twenty minutes and flips it off before the bill arrives. Or attaches a debugger to a live process and holds their breath.
Nobody files that under "the normal process failed". It goes under incident response, where uncomfortable things go to be forgiven.
The talk this story comes from is worth watching in full:
Organisations that get this right never need a type seven. Releasing is already cheap and fast enough that even a real emergency uses the normal path, with the safety still in it. Fast and safe stop being a trade-off. Two paths exist when you plan your way through a system that only yields to learning.
Matt Pocock got Uncle Bob on a livestream, and the bit I keep coming back to is the house.
Bob asks you to imagine that every change to a house costs a dollar. The foundation, the roof, moving the kitchen, moving the stairs. All of it, a dollar.
Would you pay an architect thousands to get the plan perfect before the contractor starts? Or would you tell them to put the foundation there, walk through it, decide the traffic pattern is wrong, and move the stairs?
He is right about the plan. He leaves out the other half of what an architect does.
I’ve seen non-developers build apps that would have taken engineers days, if not weeks.
Not just functional apps, but polished apps with rich functionality that bring joy to users. They meet real needs, and the attention to detail is unmatched.
Product people and domain experts can build good apps, and they build them fast.
So the question is: when does a vibe-coded app become a real product?
That is the question a lot of companies are about to face.
In many businesses, engineers are no longer the only people building the next prototype. Client managers, sales teams, product people and domain experts build it too, using tools like Lovable, Base44, Claude and other AI app builders.
You choose a direction with incomplete information, under time pressure, and with trade-offs you cannot fully test in advance.
That does not make the decision weak.
It makes it real.
In a previous post, I wrote about how design by committee leaves engineering change unfinished. The deeper reason is simple: many organisations treat technical decisions as though they should be certain before the work begins. But most meaningful engineering decisions are not certainties. They are bets.
Engineering change often gets stuck for the same reason: design by committee. Not because anyone has bad intentions, but because the pursuit of alignment quietly replaces the pursuit of learning.
It usually starts with good intentions. People want alignment, consistency, and lower risk. So a proposed change gets pulled into more meetings, more reviews, more stakeholders. Before long, the goal is no longer to try something, learn from it, and improve it. The goal becomes finding one perfect solution for every team.
Strong opinions should be earned, not borrowed. If you want to propose a change, do the work first.
Understand the trade-offs before you walk into the room.
I see the same pattern again and again in software teams. Someone reads a blog post, watches a conference talk, picks up a new buzzword, or sees how a company like Spotify talks about working, and by the next meeting they are proposing that the whole team change how it works.
The idea often sounds compelling at first. But the moment you ask about the trade-offs, the case falls apart. There is no real research, no serious risk assessment, and no clear plan for what to do if the change creates new problems rather than solving the old ones.
That gap between enthusiasm and understanding is where teams get into trouble.
Last month, our company hackathon became a vivid illustration of a broader shift in how software gets built. Across teams, from sales to support, product to engineering, domain experts huddled around laptops, experimenting with AI powered platforms such as V0, Lovable and Bolt. Within hours, they'd fashioned interactive prototypes complete with navigation flows and validation rules, all without writing a single line of traditional code.
Although these early demos relied on mock data, the fact that non-engineers could conjure usable software unaided was striking.
As a full-stack engineer accustomed to crafting CRUD apps from the ground up, I found myself asking a new question: How might we empower these citizen developers to build more often, more securely, and with live data? Their deep problem domain knowledge meant they moved swiftly, iterated boldly and learned faster than any handoff-laden process could permit.
An isometric illustration of a futuristic highway under construction, where software engineers in hard hats are laying down glowing code-shaped road segments.
Over my two decades in software, I've discovered my highest leverage isn't in writing every screen or endpoint myself, but in architecting robust APIs, infrastructure and tooling so that others can deliver user value. In this two-part series, I'll share how engineers can transition from gatekeeping code to enabling creation at scale. In this first instalment, we'll explore the mindset shifts and guiding principles. Part 2 will dive into concrete patterns and architectural strategies for secure, sustainable enablement.
Companies must be agile and respond quickly to changing customer needs in today's fast-paced and constantly evolving technology landscape. That's why DevOps practices that emphasise collaboration and communication between development and operations teams to deliver software rapidly, reliably, and at scale have become increasingly popular.
Shifting left, a core principle of DevOps can significantly benefit companies of all sizes. By empowering engineers to take on more operations responsibilities and promoting a culture of experimentation and innovation, companies can improve collaboration, increase reliability, and deliver high-quality software at scale.
In this post, I'll discuss how and why Cambridge University Press adopted a shift left culture.
Engineers are responsible for designing and building complex systems that are expected to perform optimally under different conditions. However, without a deep understanding of how these systems behave, they risk making assumptions that can result in inefficiencies or even system failures.
In this post, we'll discuss why understanding a system like a doctor helping a patient is essential for engineers and by taking a proactive and data-driven approach, engineers can ensure that their systems are performing optimally and can make informed decisions that result in improved performance and reliability.
As engineers, one of our primary responsibilities is to ensure that the systems we build are stable and reliable.
However, despite our best efforts, issues and issues will inevitably arise in production environments. When this happens, it can be tempting to try and patch the problem and move on quickly.
However, recreating production issues locally is a critical step in the debugging and resolution process.
In this post, I'll explain the benefits of reproducing production issues locally.
