The Power of Constraints

A constraint is a limitation that’s placed upon us. In this post we’ll look at three different types of constraints—time constraints, resource constraints, and guardrails—and explore how each of them can be used to drive innovation, speed, and efficiency.

Using Time Constraints to Focus on the Things That Matter

In their post on The Two-Week Rule, Phil Potloff and Ajit Zadgaonkar describe how Edmunds.com used a time constraint to keep their AWS migration moving forward and on schedule. By limiting the refactoring phase of each application to 10 working days, they maximized the amount of work NOT done to achieve their goal. The rule was a time constraint that forced them to remove non-essential work from the process, and it kept them on target throughout their migration.

In my cloud journey at Live Nation we set a goal to move all corporate IT systems to AWS within 12 months. Nearly all of the applications were of the monolithic legacy variety (e.g., Oracle, SAP), and because the infrastructure team tasked with leading the project had virtually no cloud experience, they required training before we could get started.

Did we complete the migration in 12 months? Sadly, no. But by aiming for 12 months we were able to do it in 17, which was far quicker than anyone had thought was possible. The deadline was a time constraint that created a sense of urgency, forcing us to find ways to be more productive in less time.

Doing as much as we could in parallel, we spent the first three months on an accelerated training program for our team, and began migrating while training was still in progress. We did both simultaneously in an effort to save time, but the real benefit ended up being that we were able to actually apply what we learned in training to our production environments. This proved to be extraordinarily useful.

The team would show up to training every day with real questions based on real problems they encountered during the real migration process. They could then discuss these problems and their solutions in the classroom along with the rest of their team and their instructor. This allowed the team to get up to speed quickly and to gain an amazing amount of confidence in a short period of time. It allowed them to quickly resolve problems they encountered early in the migration process, and then have the entire team learn from them. Our constraint forced us to get started on the migration early and learn along the way.

Like Edmunds.com, we put rules in place to limit refactoring. We did this to save time, but the real value came from being forced to focus on our long-term outcome—moving to AWS (not refactoring our applications). Without our constraint it would have been easy to get distracted by all of the little individual enhancements each application needed, and to get bogged down in a mass-refactoring exercise. By putting ourselves under a tight deadline we removed that temptation. Our constraint forced us to focus on what really mattered.

Would we have been as focused with a more relaxed deadline, or with no deadline at all? Not a chance. We did these things because we had to. We did them out of necessity.

The power of time constraints comes from the fact that they force you to move quickly. You may want to move quickly even without a constraint, but want is a weak motivator, whereas need is a strong one. You can ignore a want, but you can’t ignore a need. Wants create good intentions. Needs cause people to rise to the occasion and get creative. Needs bring teams together.

Using Resource Constraints to do More with Less

Frugality is one of the 14 leadership principles at Amazon. The frugality principle is a resource constraint that discourages Amazon employees from spending money in ways that don’t benefit our customers. Frugality drives down our operating costs, allowing us to lower our prices. AWS has reduced prices 67 times since our launch in 2006, and these price reductions help us attract and retain customers. Our frugality constraint grows our business.

We used the concept of frugality at Live Nation, and it has pushed us to do more with less. Moving all-in to AWS initially brought our total cost of ownership for IT infrastructure down by 18%. After the migration, we added a new constraint—reduce our cloud costs by an additional 50% in 12 months.

We were emboldened to take on this challenge for a couple of reasons. First, we had learned that the high bar set by these types of constraints caused us to find ways to win. We had missed our previous goal of migrating in 12 months, but it was still considered a success—a success we owed in large part to aiming so high. We learned that it can be better to aim too high and fail than to aim too low and succeed. We learned that if you aim high enough, you can miss the mark and still exceed expectations.

Second, we learned a few things along the way about the fundamental nature of cloud. For example, in the old days of on-premises, costs generally remain fixed. Changing the configuration of our on-premises infrastructure had little impact on our overall costs because we were locked-in by the hardware purchases we made, and any changes we made afterward didn’t affect the money we had already spent. But with AWS, because we’re billed hourly based only on the resources that we’re using, the changes we make to our infrastructure have an immediate, and possibly significant, impact. If we shut everything off, we pay nothing; if we double everything, we pay double. Or more realistically, if we reduce our consumption by 10%, we reduce our bill by 10%. The more we seek out ways to reduce consumption, the more we save.

This line of thinking eventually led us to implement a continuous optimization process that allowed us to make incremental improvements to our cloud infrastructure and lower our costs over time, which not only put us on track to meet our goal, but also allowed us to keep our costs under control on an ongoing basis. This was an idea borne out of the need to conform to the constraint. The constraint forced us to find a way.

Using Guardrails for Governance and Control

Guardrails are a type of constraint that provide rule-based governance and prevent deployment of resources that don’t conform to policies. Because guardrails act as a safety net, they give us confidence, allowing us to begin building sooner and to include more people in the process. Guardrails allow us to offer self-service while maintaining governance and control. At re:Invent we saw several new product announcements with a guardrail theme, for example:

AWS Control Tower: A new service that automates the creation and governance of well-architected multi-account AWS environments. Guardrails in Control Tower assist with governance and compliance by ensuring that resource deployments conform to your policies.

AWS License Manager: A new service that manages licenses in both AWS and on-premises, and can help enforce licensing compliance by automating the reassignment of licenses and by stopping instances from being launched if they violate policy.

Amazon S3 Object Lock: A new feature that can enforce compliance and retention policies by automatically blocking deletion of objects in S3.

At Live Nation we implemented guardrails by limiting AWS access to the core cloud team, who had very specific policies around provisioning of resources and change control. This allowed us to enforce best practices and to ensure that all new applications were deployed in a cost-efficient, resilient, secure, and compliant way. The downside was this was a manual process lacking the self-service capability needed to truly scale.

Moving forward, solutions like AWS Service Catalog and Private Marketplace solve this problem for us. They implement self-service with guardrails to enforce governance by facilitating pre-approved catalogs of services and third-party products, giving us the best of both worlds.

But whether in the form of automated services or manual processes, these guardrails are designed to keep us from going off track.

Embrace the Constraint

Sometimes a limit is all we need to realize our full potential. Using time and resource constraints sets a high bar that encourages high performance, and guardrails encourage bias for action by providing a safety net and guidance on how to move forward. Modern technology has given us all the tools we need to be successful. Let’s make sure we’re utilizing constraints so that we can get as much out of these tools as possible.

Jake Burns
Enterprise Strategist