There is No Talent Shortage
Andrew Clay Shafer
Here we go! Today’s conference talk is by Andrew Clay Shafer, who brings us along on a journey to discover how traditional businesses are struggling to build software while not being able to attract or keep talent.
If software is truly eating the world, why are companies still treating the people building software like they are digging ditches?
The conference
The talk was presented in 2014 at CF Summit San Francisco.
The presenter
Andrew Clay Shafer is recognized as an early pioneer of DevOps, and advocates for transforming the development of software through people and culture.
And software kept eating the world…
Back in 2011 Marc Andreessen published an article in the Wall Street Journal that took the world outside of Silicon Valley by storm.
In short, software is eating the world.
In the article, Andreessen makes a case for how software is changing the competitive landscape of major industries, causing once dominant traditional businesses like Borders to become disrupted and eaten by software companies like Amazon.
There is an existential crisis that is happening in organizations that are struggling to transform into software companies. This crisis surfaces out of desperation to survive the impending threat of being eaten by software.
You couldn’t run Amazon. You couldn’t run Google. Not unless you solved these problems—and they did solve these problems. They did it because they had to.
Shafer explains that as a software company, you can either manage a complex distributed system or you cannot. There is no half measure. If you can’t do it with ease, then you’ll be consumed by it. The cost of losing top talent—who are being forced to fight fires instead of building software—will eventually eat you up from the inside. To survive, you have to figure out how to automate.
Infrastructure is code
To start making the right thing the easy thing, you have to learn how to automate your infrastructure. The undifferentiated heavy lifting required to keep your system online is tedious and repetitive manual effort, which is best left to the machines.
Recognizing at the point that you have APIs that can provision machines, APIs that can configure machines—it looks suspiciously like software development.
The tasks that were traditionally system administrators running scripts manually have now become an application.
If APIs are used to build complex systems, why not use APIs to manage complex infrastructure? The key take away here is that you can use the tools and practices for building software applications and apply it to your infrastructure and operations.
Weaponized infrastructure
The Gatling Gun was invented by Richard Gatling in 1861. He is quoted saying that he created the gun to reduce the number of people needed to fight and win a war.
It occurred to me that if I could invent a machine — a gun — which could by its rapidity of fire, enable one man to do as much battle duty as a hundred, that it would, to a large extent supersede the necessity of large armies, and consequently, exposure to battle and disease [would] be greatly diminished.
— Richard Gatling
The Gatling Gun, while terrifying in its capability to rapidly inflict destruction, succeeded at greatly reducing the number of casualties in battle. This is one of many examples in history of a weapon that eliminated a tradeoff to gain a competitive advantage. In this case, the payoff reduced the number of soldiers necessary to successfully engage an opponent with a larger army.
It is the ability to rapidly deploy applications [with less people]—and in some sense that’s what we’re talking about with Cloud Foundry.
Companies who are struggling to deliver software are still struggling with the same constraints that a competitor has already found a way to eliminate. In this example it is using a platform — Cloud Foundry — to rapidly deploy and manage many applications with less people.
If a competitor can reduce the number of talented people required to deliver software and keep it running, those people are now freed up to beat you silly with new applications or features that erode your market share. That’s why software is eating the world.
So, what are you going to do about it?
Culture is strategy
Culture is strategy — and you can use it to define how people interact—you can use it to define how things work. When companies talk about their culture, they’re usually treating culture like it’s a checkbox on a list. They are the same companies using checklists to hire people. The sum of a person’s potential to help a company win won’t be found on any checklist. These companies are reducing their culture to a recipe of checkboxes that any other company can use.
There is no recipe for culture. There are people and problems. Whether or not the people working for you will enjoy solving problems is not decided by a laundry list of buzzwords or jargon.
If you believe that software is eating the world — why are you managing people like they are digging ditches?
If you want to start building microservices then go get a bunch of people who want to build microservices. If you want to have what Netflix has, don’t think about building microservices with Netflix OSS, think about how to build Netflix’s culture. There is no shortage of talent keeping you from winning, you just have to focus on building a culture that reinforces and empowers people to do the work they wanted to do anyways.
It’s not some checklist of buzzwords that make you successful. It’s aligning a company of problems with the right mix of curious people that will learn how to work together to make the right thing the easy thing.
Survival is not mandatory
There is a story in the book The Fifth Discipline about how GM’s dominant control of the U.S. car and truck market was eroded from competition in Japan in the 1960s. The executives at GM went to Japan to see how just-in-time factories were capable of building cars faster and cheaper than traditional factories. Even after seeing for themselves, the GM executives couldn’t believe that these factories were capable of making real cars. The disbelief was because their mental model for how cars were built was fixated on this idea of handling inventory management.
All automobile factories—in the GM exec’s mind—that are capable of building cars, would need to have stacks and stacks of car parts piled on factory floors. Their fixed mental model of how factories were used to build cars was dependent on the idea of how inventory was managed. They thought “these cannot be factories—this is a pageant — this is an act they are putting on for our own benefit.”
It’s not necessary to change. Survival is not mandatory.
Today the same thing is happening with software. Traditional businesses don’t believe you can deploy code 50 times a day. They don’t believe that it’s possible to give developers self-service access to deploy code — but apparently you can—and that’s why Japan eroded GM’s market in the 1960s.
GM lost their stranglehold of the market just because the people making decisions got caught up in the way they believed it was possible to build cars in factories. They didn’t see how certain constraints were eliminated by Japan’s new method of manufacturing cars.
The game has changed
Continuous learning is what it’s all about. You have to cultivate individuals, and if doing that doesn’t change your behavior then you didn’t learn anything. Organizations not only have the responsibility to increase quality of talent, but they are responsible for keeping it and attracting more of it.
If it doesn’t change your behavior then you didn’t learn anything.
The software keeps eating — and it’s not stopping — and it’s going to accelerate.
Organizational learning
There is a correlation between the success and failure of companies that are building software with their degree of organizational learning.
The 7 dimensions of organizational learning is a great framework to think about how to unlock the capabilities that are already in organizations.
The link above explores each of the 7 dimensions that Andrew talks about in the presentation.
The goal of organizational learning is to align vision across different levels and work groups. To try things. To experiment. To use a culture of learning as a competitive advantage that empowers people to do the work they already wanted to work on.
Shafer concludes the talk by stating that “you are either building a software business, or you are losing to someone who is.”
In many ways this has become obvious. Even with all the evidence to answer why software is eating the world, the behavior of companies struggling to deliver software remains unchanged.
You’re either building a learning organization, or you are losing to someone who is.
If you’re too busy struggling with building software slowly today, then you won’t notice how far behind your organization has become until you see your competition moving much faster. Now you have to do what they already did. Just to catch up! And you can’t do that without talented people.
The game has changed
You have to upgrade your culture while upgrading your weapons. One without the other might make you faster, but either one alone will not make you fast enough to catch up and win the race.
For many, the race may already be over. And it’s not because they are too slow—but it is because they never looked up to notice they were running in the wrong race.
The game has changed.
