Continuous Delivery (CD) is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

You want to go faster, so you invest months in building out a fully automated build pipeline. You modernise your architecture and adopt the latest agile process. And you achieve the dream of CD, with the ability to deploy features and bug fixes to production in seconds with zero downtime. The power is immense! But with that power comes responsibility… and with that comes THE FEAR!

And I don’t mean the fear of having to support Internet Explorer or the fear of Stack Overflow going down. I mean real emotional stuff, that stuff that most of us are none too comfortable talking about. And, unless faced, it will slow you down.


So let's start with a quick definition of fear

Fear is an anxious feeling, caused by our anticipation
of some imagined event or experience

Though people label fears as many things, you can trace them back to one of these five fundamental fears:

Acknowledge and analyse what you are feeling. Then take action. A lot of patterns and techniques that fit well with CD will offset the root causes of your fears. At first, this may seem like an overwhelming task! But overcoming fear is the same as eating an elephant: you do it one bit at a time.

Fear of Releasing on a Friday

Extinction: the fear of annihilation, of ceasing to exist, i.e. looking over the edge of a cliff.

Mutilation: the fear of losing any part of our precious bodily structure, i.e. being attacked by spiders.

Are you nervous when you deploy something? Do you avoid deploying Friday after lunch? Just in case something goes wrong?

The code you write, the application you create is an extension of yourself. Therefore, when you break something, there is an element of mutilation to it. Take the extreme case of a security vulnerability. This could lead to your extinction! You might lose your job, or worse, the company could fold in the case of a breach!

With CD, this is easy to tackle:

  • Deploy small changes to production
  • Cover all critical paths in your application with automated synthetic tests
  • Always have your rollback scenario in place
  • Don’t hesitate to rollback

What is important with CD is not the failure, but the time it takes to respond to it. With each failure, there is always learning; so recover and take what you can out of the experience. You will never know everything, don't let this block you.

Fear of Unintended Consequences

Loss of Autonomy: the fear of being immobilised, paralysed, or restricted by circumstances beyond our control, i.e. committing to a long-term relationship!

Are you confident in clicking that Deploy button? It is working on your machine, passing all acceptance tests on your staging environment? Why wait to push it out into the real world? Is it because, once you click that button, you are no longer in control?

The fear of unintended consequences is powerful. It leads to serious doubt, and that doubt is a drag on you and your team. The first step in tackling this is a simple mind shift. Don’t think in terms of releases anymore; think deployments! Put time into separating out stories into independently deployable tasks. Release a story, deploy a task.

And CD makes these deployments trivial. With a Dark Deployment, you deploy a feature that nothing else sees or interacts with. With Canary Deployment, you direct a small percentage of load or traffic at it. Running smoke/sanity tests through these and the wider system helps you explore any unknowns that might arise in the production environment with little to no risk. You regain that sense of control, knowing that your code, your feature, has no unintended consequences.

Sometimes, in a story, there can be unavoidable dependencies between tasks. This adds to the complexity and, therefore, increases the risk. It is vital to figure out ways to decouple each piece of work from its dependencies. You can then release each piece independently, thereby negating the need for a big-bang release that has lots of scope for unforeseen issues! Simple techniques work like a charm, here:

Stubbing is particularly useful. Because deployment is so cheap, you can stub out a dependency (a mocked endpoint with hard-coded return values, or a completely mocked service) and release it to production. This unblocks the dependent task, allowing it to make its way through to production.

Eventually, with all tasks deployed, your story is released to users. Then the real fun starts. Everyone intends to be right, but due to bias, you could be wrong about the value delivered by such a feature. That is a tough one, and leads to a nasty fear, the fear of feedback!

Fear of Honest Feedback

Separation: the fear of abandonment, rejection, and loss of connectedness, i.e. getting the "silent treatment” from a group.

People avoid feedback. Negative feedback is sometimes received as a form of rejection. It is tough to take. That sense of connection and support you had with the other party can evaporate. This fear can lead to avoidance.

When was the last time you succumbed to scope creep? Added in just one more feature? Got lost in some backend framework? Or did a “quick” refactoring of your code? All instead of releasing the original requirement to the end user? (I am not advocating against refactoring by the way; I am saying you can release first, and then go refactor!)

As in art, we invest all our time and energy creating things of technical beauty. But what if no one uses it? What if no one one loves it? It is easier to avoid these tough questions. Instead, you should be ruthless in questioning and quantifying the value of what you are delivering. Get your product in front of real users at the earliest possible moment and adapt to whatever feedback they provide.

The speed that CD gives you is your friend, here. Using Tracer-Bullet development you:

  • Identify the smallest vertical slice that will allow you to figure out if you are on the right track.
  • Develop it
  • Release it
  • Get feedback
  • Iterate again.

These iterations should last days, not weeks. In terms of quantitative feedback, you should define HEART metrics for each feature. This makes value delivery part of your process. With HEART, you have to call your shots. If developed, how much will this feature move a particular dial for you?

Reviewing this data after a release facilitates very honest discussions. Has this piece of work delivered value? If so, then can we do more? If not, then why not? What if it was down to you? This last question can be a bit uncomfortable and reinforce another fear: the fear of being found out!

Imposter Syndrome

Ego-death: the fear of humiliation, shame, or any other self-disapproval that threatens the loss of integrity of the Self, i.e. being asked to sing at a party.

Are you constantly out to prove yourself? Do you find yourself accepting feature work that is too big or poorly understood? Just taking and running with it? Do you feel an impending sense of shame and humiliation when you struggle to live up to expectations? Does this drive you on again in a vicious circle?

Instead of taking on stories in any form, change this. Open up about your doubts and limitations and come up with a plan to tackle them. With CD, you now have the power to release smaller chunks incrementally, so:

  • Open up honest conversations with your stakeholders
  • Define each piece of value that you will deliver
  • Identify what you are most unsure about
  • Bring the pain forward and tackle the riskiest piece first

This could take the form of a technical spike or a small alpha release. This helps bring any technical blockers or need for further training or resources to the surface. Rather than let inner doubts about yourself and your capabilities fester, you can work through them bit by bit. Each doubt you overcome will increase the chances of bringing you true success.


As a modern software developer, you deliver value fast or die. CD accelerates getting your product in front of your users and the rate at which you can adapt to the subsequent feedback. However, unless coupled with a shift in mindset, it will have little effect. You will not get the desired return on investment. The beauty is that the practices and techniques that CD opens up for you form a perfect vehicle for changing how approach your work. So don’t be afraid of mistakes and feedback that you end up producing nothing at all. Take ownership of and overcome these fears and fully reap the benefits of CD!