1. Resources
  2. /
  3. Blog
  4. /
  5. The Delivery First Mindset

The Delivery First Mindset

10 minute read

This blog post marks a big day for Buildkite. Today we’re launching the world's first Scale-Out Delivery Platform. Our platform fills a real need—while there’s been a big advancement in tools for creating software, the tools for delivering it are lagging way behind. Companies must focus on both to succeed. The two go hand in hand.

We’re honored that so many of the world’s leading software companies have standardized on Buildkite, and we’ve learned a lot from them about the qualities a good delivery platform needs. That platform should:

  • Encourage the teams that use it to innovate.
  • Be flexible so every company can adapt it to fit its own particular needs. 
  • Scale to whatever size your business needs, no matter how large it grows, without a decrease in performance or efficiency. 
  • Allow a company to deliver value to its customers at lightning speed.

The Buildkite Scale-Out Delivery Platform does all of this. It provides the capabilities a company needs to have a modern delivery system, one that’s designed for today’s complex, demanding world. 

Today I’m first going to give you a bit of history about how the Buildkite Scale-Out Delivery Platform came to be. Then I’m going to talk about why good software delivery tools are critical to a company’s success. Finally, I want to explain how those tools will help you develop what I call a Delivery First mindset—a way of thinking where delivery is as important a part of a product’s design as anything else and is always in the mind of every developer on the team. 

By the way, my definition of what a “good” tool is isn’t based on particular feature sets or a clever UI design. My background has taught me that a good tool leads to innovation because it encourages people to try out new ideas.  

My background

I always loved experimenting and making things when I was young. I loved playing with Legos. And, of course, I was always interested in computers. I liked building apps that helped me do things and then sharing them with people so they could benefit too. Essentially, I fell in love with solving problems in interesting and unique ways. 

My other obsession was magic. I was a professional magician for a while. I used to do magic shows and, when I was 18, I won the South Australian Magician of the Year. I found that what I liked about magic wasn’t the technicalities or the craft itself. I liked performing and engaging with the audience. Magic for me was very much in the service of entertainment. I wanted people to have a good time, to be involved and show their engagement by trying to figure out the trick.

What inspired me to tackle software delivery?

When I became a software developer, that desire to provide a great experience for people never left me. As a developer, what made me crazy was the state of software delivery tools. (Keep in mind that although I’m going back to 2013, I would argue that even today, things haven’t changed much.) Not only was it personally frustrating, but I saw how a clumsy delivery process hampered the company’s ability to deliver value to its customers. 

I also saw what those tools did to the people who had to use them. As much as they wanted to do a good job and get product out the door, the tools were always in their way and were bad for team morale. They limited the team’s vision, stifling any sort of creativity and innovation. The tools deprived them of their chance to master their craft or try something new, which in turn meant that they never created additional value for customers. 

Bad tools also had adverse effects on their general quality of life. Because the tools were so fragile, they couldn’t touch them when developers were going to run builds. They had to work nights and weekends to maintain them. If they tried something during normal working hours, they’d risk bringing down production.

The worst consequence of bad delivery tools was what I call delivery decay, which in turn led to a poor company culture.

Delivery decay

Delivery decay happens when tools feel so hostile to their users, so difficult to use, no one wants to experiment with the tool or maintain it. As a consequence, the tool becomes flakier, buggier, and even more difficult to use. That decay doesn’t affect just the tool—it affects the entire delivery process. The most important part of the development process, getting value to customers, becomes what everyone most wants to avoid.

Tools affect company culture

When a team’s relationship to delivery is bad because the tool is bad, the team becomes risk averse and slow to react. It's not because the tool itself is necessarily slow, but the tool has taught people, over time, to be slow and cautious. If you ask them what the root of the problem is, they probably wouldn’t recognize that the tool is the problem. They just know they’re operating in a hostile environment. People react by making delivery a back office process, an afterthought that no one cares about.

A slow, risk-averse culture that considers software delivery nothing but a nuisance is disastrous for a company. That company can’t survive in a world where success depends on constant innovation and rapid delivery of value. Only a good tool gives you that edge.

The result

My experience as a practicing magician taught me that people are happiest when they’re entertained and involved. My engineering predilections made me want to take on the problem of building a great delivery tool. As a result, I decided to make a delivery tool that encouraged innovation and creativity because people loved using it. They would be fully engaged in the entire software delivery process, from development to production. 

Why good delivery tools matter

If all this seems too “touchy feely,” I’m going to argue that good tools are critical, not just to an individual, but to the company as a whole. When delivering your products depends on an unreliable tool, your business is in a lot of trouble. There’s no innovation and no ability to quickly pivot when the market changes. What’s the solution? Find a tool that people want to use! 

When people have good software delivery tools, they naturally develop a Delivery First mindset. The Delivery First mindset is my way of describing what I’ve seen in our own customers, who are some of the most forward-thinking software companies in the world. Delivery First is where a company considers software delivery to be on a par with software creation. It’s built into the product just like a new feature or compliance standard is.  

Delivery First encourages innovative thinking in product delivery. Take Blockbuster and Netflix as an example. Blockbuster was strictly a brick and mortar experience. Using Blockbuster always meant a trip there and back, no matter the weather, and always with the possibility of disappointment. That DVD you were counting on might be in stock but if it was a popular one, your Friday night was ruined. 

The Netflix founders wanted a better way to deliver movies to people. They offered what turned out to be the far better alternative of streaming. You could watch what you wanted, when you wanted, simply by clicking a button. Of course, they also offered a mail order service because of streaming’s initial limitations, but, as the capabilities of streaming grew, Netflix could quickly adapt and take advantage of those new possibilities and phase out the slower side of the business. 

This all happened because they had the right delivery platform. The founders of Netflix were early adopters of the “infrastructure as code” mentality, which allowed them to automate their delivery tools, react quickly to market changes, and find innovative ways to deliver their product to customers. They didn’t call it Delivery First then, of course, but it’s an early example of that kind of thinking and proof of how successful a company can be when they have the right tools. Netflix succeeded and Blockbuster failed because they knew that how a customer gets a product is just as important as the product itself.

More about the Delivery First Mindset

A company with a Delivery First mindset is a company that knows software delivery must be at the core of a company’s culture. It’s not an afterthought. It’s not some obscure back office process. Everyone on the team plans for delivery even before they’ve built their product. A company that understands Delivery First invests in tools that make this vision possible because that mindset is only realistic when the right tools are there to make it happen.

Delivery First encourages innovation

A Delivery First mindset gives your team the power to innovate. Innovation isn’t planned. It comes from quickly trying something, failing, learning from that failure, and trying again. One way a good tool makes that possible is because it makes delivery cheap, not just in dollars but in time.

If building something takes 6 to 12 weeks, then you’ve invested too much up front. You have to front load all of your effort into design and talking to customers and you’re taking a huge chance because it has to be right the first time. You can't open yourself up to experimentation. One way to correct that is to give teams tools that encourage them to try new things.

The hallmarks of a Delivery First Mindset

Delivery First is practiced by Buildkite’s own customers, like Shopify, Uber, and Canva. Those companies know that software delivery is critical to their company’s success; they know that innovation isn’t planned, it’s discovered. Success comes from throwing new ideas out there as fast as possible, trying them out, learning from failures and trying again. Security is built into the delivery pipelines from the get go. It isn’t added after some lengthy review by a committee. Finally, these companies are always improving their delivery process.

In practice, they: 

  • Pick outrageous targets—like insanely fast build times. Bold targets drive innovation; incremental goals don't.
  • Break the rules—they throw away the old playbook. Best practices never lead to innovation—experimentation does.
  • Optimize—the world changes fast; they are always looking for new ways to innovate and improve.

To focus on delivery, you need a good foundation: a flexible platform that scales as needed and can be adapted to fit the workflows their business demands.

Shopify and Delivery First

In 2018, the CTO of Shopify decided to upgrade their delivery platform to Buildkite precisely because of the limitations of their existing delivery tools, and, consequently, their delivery processes. Before Buildkite, deployments had slowed to 45 minutes, which was really limiting their business. Delivery had become a back office thing. No one cared about it. It was always someone else's problem, someone else's job; nobody was trying to improve it.  

With Buildkite, the CTO knew things would change for the better. He tackled the problem head on and set an outrageous target for the team—instead of 45 minutes, they were going from commit to production in 10 minutes. He knew that setting a seemingly impossible target would require innovation and focus, and he felt it would positively impact the team culture. With the Buildkite platform, which was designed for scale and adaptability, he had confidence that it was possible. The team embraced the challenge, they completely upended what was a typical workflow design, and iterated until they hit the target. And they’ve never looked back. In other words:

  • He picked an outrageous target.
  • He broke the rules.
  • He optimized.

Buildkite embodies Delivery First

Buildkite’s customers have inspired me to make Buildkite a company that truly practices delivery first.

Right from the start, we set an important engineering principle—we deploy continuously. As soon as a pull request is merged and tested, it makes its way to production (behind heavy feature flagging systems). That was the healthiest rule we ever instituted. Every line of code a person writes will be in production in about half an hour.  That was my outrageous target and I suppose that many people would think I’d broken a lot of rules about how to deploy software. 

However, that one principle yields far better, higher quality engineering than anything else. Take security, for example. As you write your code, you have to think about how this code might be exploited in 30 minutes. In other words, security, governance, and compliance are built into the delivery process from the start.

Winning with Delivery First

My personal belief is that if you have a Delivery First mindset, if you think about delivery as part of the product you're building, and you have the right platform, you will win.  We see this in our own, very successful, customers. Give your teams the tools that make winning inevitable. If you’re fostering a delivery first mindset, you can't go wrong.

Learn more about Buildkite’s Scale-Out Delivery Platform, or get started for free at buildkite.com/signup.


Related posts

Start turning complexity into an advantage

Create an account to get started with a 30-day free trial. No credit card required.

Buildkite Pipelines

Platform

  1. Pipelines
  2. Pipeline templates
  3. Public pipelines
  4. Test Engine
  5. Package Registries
  6. Mobile Delivery Cloud
  7. Pricing

Hosting options

  1. Self-hosted agents
  2. Mac hosted agents
  3. Linux hosted agents

Resources

  1. Docs
  2. Blog
  3. Changelog
  4. Webinars
  5. Plugins
  6. Case studies
  7. Events

Company

  1. About
  2. Careers
  3. Press
  4. Brand assets
  5. Contact

Solutions

  1. Replace Jenkins
  2. Workflows for AI/ML
  3. Testing at scale
  4. Monorepo delivery

Support

  1. System status
  2. Forum