Notes From Cloud Strategy by Gregor Hohpe
Agility and predictability are at odds. Agility means responding to changing circumstances quickly, but then you won’t be able to predict where you’ll be one year from now. To ensure predictability, you need to freeze a decision like “We’ll stick with a database server with 100 GB memory for the next year”, which is the opposite of agile.
Transparency over control: Companies have rules and want to ensure that people are following them. Legacy companies put in a lot of process and approvals to prevent people from violating them. This slows progress down, and makes smart people leave. There’s a better solution: the cloud offers a lot of transparency. Use it to monitor violations. Instead, the cloud monitor violations of rules rather than putting processes in place to prevent them.
Legacy businesses insist on knowing the destination before starting the journey: “We’re going to Reykjavik.” Digital ones ask if they’re going in the right direction: “We’re going north” And at the right speed. As long as both are true — you’re going in the right direction at the right speed — that’s enough. We can’t know the time it’s going to take to get to the destination, and it doesn’t matter because we’ll adjust the destination as we take the journey, such as going to Greenland instead of Iceland.
You should think in terms of rate of change, not absolutes. For example, don’t ask “Will this project be done by April 1?” Instead ask about velocity: “Have we gotten enough done last month?” If you’re making enough progress every month, the project will take care of itself. Similarly, don’t ask, “How much will building this app cost?” Instead ask about burn rate, “How much have we burnt last month?” After all, salaries are a recurring expense, not a one-time expense. For example, I (Kartick) suggest that a startup have a minimum engineering budget of $1m a year.
Working with absolutes (fixed deadline) creates stress. If your project is late, people are made to go on a death march. This burns people out, makes them less effective in the future, and makes some quit or disengage from the company. A death march is not an effective solution. If you instead think in relative terms, you’ll focus on identifying reasons why a project got delayed and fix these fundamental problems, increasing velocity, not just for the current project but also for future ones. This is a lasting solution.
Legacy Thinking
This section is a summary of the wrong thinking you’ll encounter when working with legacy companies:
When people stuck with legacy thinking move to modern technology like the cloud, they still hold on to their legacy thinking, as with one CIO trying to prevent anyone from provisioning a VM to control costs. Giving legacy people new technology won’t help.
Legacy companies have a misconception of new tech as letting them do the same old thing faster, as this infographic shows:
We used to live in an era where economies of scale mattered. Big companies would win against smaller ones. Today, economies of speed matter: nimble companies succeed, not big ones.
IT has traditionally been commoditized. Innovation didn’t matter because whichever email provider you use, they’re 95% the same, and it’s not as if picking Gmail will make the company succeed while picking Outlook will make it fail. Being agile was considered unimportant because if you’re a restaurant chain using a database for 8 years, what you need from the database is unlikely to be significantly different in the 9th year. Neither was Microsoft SQL Server going to change significantly in the next year. So with both business needs and technology changing slowly, innovation and agility weren’t considered important, and predictability and cost were prioritized. To ensure this, strict procurement processes were put in place. A company buying tech would list both functional and non-functional requirements and ask multiple vendors to answer questions along various dimensions. For example, if one requirement is backup, a vendor who says they don’t have backups might get a score of 0, a vendor who has onsite backups, 1, and a vendor who has offsite backups, 2. The company buying the tech would then total up the scores for each question to arrive at a total score for each vendor, and pick the vendor with the highest total. This process used to work earlier but has broken down, since customer needs are changing rapidly, and tech is evolving rapidly. It’s no longer commoditized. We now have platforms with thousands of features, not just a product with a limited set of features. If you’re picking a cloud and evaluating AWS and Linode, what score would you give AWS to account for the fact that AWS offers FaaS while Linode doesn’t? You can’t come up with a scoring system that accounts for thousands of features like this. Even if you could, it wouldn’t be accurate next year.
Legacy IT separated Dev and Ops. The Dev team was responsible for feature delivery and usability, while the Ops team was responsible for security, hardware provisioning and cost control.
Legacy companies try to imitate perks from modern tech companies like baristas. This doesn’t work. The coffee isn’t what makes Google Google.