AWS Cloud Enterprise Strategy Blog
How to Go Fast
Everyone who works in IT at Live Nation is familiar with the phrase “go faster than what is comfortable.” It was our CEO’s message to us when he called an IT leadership meeting in 2015 and shared his vision for how he wanted to modernize the company—a meeting that sparked a transformation of IT and gave me my mandate to get us out of the datacenter business by going all-in with AWS.
After that meeting, going fast become a priority, and the phrase became our mantra. It became something we’d say to each other when we wanted quicker results—a reminder to never stop going forward and to never slow down (because the CEO said so).
But as helpful as it was to have a requirement to go fast, we also needed the tactics that would allow us to achieve it. What we needed was a set of techniques that would enable us to move more quickly so that we could achieve our goals. I set out to find them. This is what I learned.
Get Started Early
At the beginning of any new project, I always remind myself how important it is to stop thinking and to start doing. In the past, the fear of making mistakes caused me to spend excessive time worrying and analyzing. But the reality is that mistakes will happen, and the only people who never make mistakes are those who never do anything. I realized that we should be afraid—not of making mistakes, but of time passing us by while we’re not moving forward. Most mistakes are recoverable—in the cloud, this is truer than ever. But the time spent worrying and analyzing isn’t. That time is gone forever.
You’ll never be completely ready. The best way to get ready is to get started.
Have a Clear Purpose
People seem to work harder when they know why they’re being asked to do something. I’ve learned to take the extra time to clearly articulate the purpose behind my initiatives and make sure that the people involved understand why it’s important. Making sure people understand why they’re doing something ensures they work with enthusiasm. Or even better, make them part of the decision to do it. When they own it, they have a stake in its success and are more likely put in the extra effort because they want to see their initiative succeed. They care far less about your initiative. In my experience, a motivated team will get things done more quickly than an indifferent one. If you want to move fast, get them on board.
Do Less Work
I’ve found that eliminating work is one of the best ways to save time. Nobody gets extra points for doing more work. And if we can get the same results with less work, we go faster.
One thing I decided to eliminate was kickoff meetings. The purpose of these meetings was to ensure that everyone involved was clear about the project details. In my opinion, a lot of work goes into these meetings for very little benefit. And due to the large number of participants, they usually need to be scheduled two to three weeks out. Eliminating them saved us two to three weeks per project, and if anyone was unclear on what we were doing, they could ask in our daily status meetings.
I also eliminated POCs. Proof of concept exercises were important back when every new idea required a large capital investment in hardware, software, and implementation. The POC allowed us to try a solution before making an investment in it. But I felt that this step had become redundant now that we were using AWS and the cost of experimentation was so low. Instead of doing a POC, we’d just do the project. If at any point it looked like it wasn’t going to work, we’d just shut it down and stop paying for it. For third-party software, we used subscriptions from the AWS Marketplace that offered pay-as-you-go and got the same benefit. Skipping the POC costs us almost nothing, but it saved us several weeks or months per project.
Create Reusable Components
For the work I actually do, I look for ways to do the work once and benefit from it as many times as possible. One way we do this in software development is by creating functions. With system administration, we use scripts. In AWS, these functions and scripts become more powerful because they can control our AWS resources using APIs. We also have the ability to create infrastructure as code by using AWS CloudFormation. At Live Nation, we embraced this idea and made the decision to create all of our infrastructure with it.
One benefit of this approach was that we could reuse our existing CloudFormation templates to create infrastructure for new applications. When we wanted to deploy a new application, instead of creating a new template, we’d copy an existing template and modify it as needed. The investment in writing the initial template paid off dozens or hundreds of times as we reused it. As time went on and our library of templates grew, the ability to reuse them also grew. The amount of time we saved got better the more we used it.
Some people think that simple ideas are somehow rudimentary and unsophisticated. Those people go slow. Complex solutions take a long time to implement. They’re also prone to errors, requiring more time to troubleshoot and fix. A simple solution is easy to understand, easy to communicate, and has fewer steps, so it takes less time to implement.
There seems to be a point in a project where it feels like you’ve turned a corner. Things get easier, and it feels like success is now inevitable. I like to get to this point as quickly as possible. I look for a series of easy wins early on and then work to keep that momentum going throughout the project. I’ve noticed that projects that are stuck tend to stay stuck, and that projects that are moving forward tend to keep moving forward. I’ve learned to be aware of the momentum and to use it as a tool.
At Live Nation we utilized this idea during our AWS migration project. We moved the easiest workloads first for this reason. To eliminate any doubt that we’d be successful, we made sure we had a long series of wins before finally moving on to the more difficult applications. And the more times we succeeded, the faster we were able to go.
Trying to multi-task can slow you down. Switching tasks takes time, and the time required to constantly stop one thing and start another can add up quickly. It also keeps you from thinking deeply about what you’re doing because you’re constantly interrupting yourself to switch tasks. Instead, I like to have people do one thing at a time and keep doing it until it’s completed or they get stuck waiting for someone or something. When you’re waiting for something, it’s the perfect time to switch tasks. Being single-tasked doesn’t mean you allow yourself to be blocked. It just means that you don’t switch tasks without good reason.
In motorcycle racing there is a saying: slow is smooth, smooth is fast. Going fast is not about trying to do everything as fast as possible. That leads to errors (like crashing) and ultimately slows you down. Real speed comes from being smart. The solution for how to “go faster than what is comfortable” is to get comfortable with going faster, and you do that not by going faster than what you’re capable of, but by developing the skills needed to go fast, and by having the discipline to execute them properly.
Amazon Web Services