informal means, or in other ways.
Single-team startups generally had little trouble using Agile methods. Frankly, a startup is the easy case; it is “table stakes” for Agile. The hard case is making Agile work for a multiteam product, and an even harder problem is making it work in a multiproduct ecosystem.
Agile had no answers for these situations in the early days. Over time, various people tried to address the issue, by defining Agile scaling frameworks, but unlike the original Agile Manifesto, these attempts generally came from individuals and were used as brands to drive proprietary consultancies, so no consensus emerged on what to do.
Meanwhile, large consultancies embraced one or more of the branded scaling frameworks, having their staff obtain certifications in those and then marketing their staff as commodity experts (which seems to us like an oxymoron). This further entrenched the commercial nature of Agile and the approaches for “scaling” Agile. To say that the situation became unhealthy is an understatement.
Today's Tech Platform Is As Strategic As the Business Model
The Industrial Revolution brought about large companies that built really big things—things that required machines. Carnegie Steel, Rockefeller's Standard Oil, Thomas Edison, Henry Ford—big companies were synonymous with the individuals who founded them.
Then during the 1960s, as the business landscape came to be dominated by publicly traded companies without individual owners or prominent founders, modern management thinking came to see a company as a collection of distinct interacting functions. Senior management was seen as existing to increase the value of the company, in a financial sense—something logically distinct from the company's actual business. Managers became financial overseers, and involvement with actual products and markets became the province of corporate vice presidents, who often saw themselves as financial overseers of a market rather than visionaries of products.
The Internet age was like the Industrial Revolution in that it represented a pioneer period in a new landscape: the global network of the Internet. Just like the Industrial Revolution, huge companies grew, identified with their founders: Apple and Steve Jobs and Steve Wozniac; Google and Sergey Brin and Larry Page; Amazon and Jeff Bezos; Netflix and Reed Hastings.
But was this return to owner-dominated giant companies only due to the Internet? What about SpaceX, which was founded by Elon Musk? SpaceX has become a huge company, outdoing the likes of Boeing in the production of spacecraft, yet it was a tiny startup 10 years ago, and it had nothing to do with the Internet, although that is changing since they have undertaken to launch a network of Internet satellites. But the company's growth was based on its approach to building rockets—it was not due to the opportunities presented by the new Internet landscape.
What is noteworthy about these new companies is that their founders are deeply technical. In each case, the founder understood, or learned, the technology used to deliver the product or service. Steve Jobs and Steve Wozniac were both home computer builders. Sergey Brin and Larry Page were both research scientists from Stanford. Jeff Bezos had degrees in electrical engineering and computer science from Princeton.
Elon Musk is an interesting case. He did not know much about rockets when he founded SpaceX, so he hired Tom Mueller, a rocket engineer. But Musk did not do what a modern management executive would do, which would be to concentrate on the business and delegate the product development to a VP. Instead, Musk said, “Teach me about rockets.” Musk continued to drive the development of SpaceX's rockets, deferring to experts but always staying involved in the decisions—just as Steve Jobs personally approved of any product that Apple launched, and Jeff Bezos personally directed the development and technical parameters of Amazon Web Services.3
This personal involvement in the organization's products and services seems to be a common characteristic of managers of the most highly successful technology companies today. The view of these executives seems to be that the product delivery technology is not just a supporting function, subordinate to the company's strategy. Instead, it is part of the company's strategy.
How the company delivers is as important as what it delivers.
The value proposition of SpaceX is that it can launch satellites for less cost, and with higher frequency, than its competitors—substantially so. That is true only because of the way that it builds its rockets.
The value proposition of Amazon is that it can deliver products cheaper and faster than alternatives. That is true because of the way that its technology platform works. And Amazon can also update its platform rapidly and test market-facing features—and that is true only because of the way that it builds and delivers software to its online systems.
The way—the how—is not secondary. It is strategic. It is as important a differentiator as the product itself.
This means that today's executive cannot say, “That's a tech thing—my CTO deals with that.” Today's executives need to understand how things are built, how they are delivered, how they work, and how they can go wrong. Elon Musk knows how rockets can fail because a failure can ruin the company's reputation. One of his main preoccupations is ensuring reliability. He achieves that by influencing how SpaceX builds the rockets. It uses what he calls a hardware-rich approach, whereby they don't try to perfect a design but instead perform early testing and iterate, constantly measuring and refining, until a design has proven itself to be robust and reliable.4
Again, the how matters—strategically.
Does this mean that one person needs to know how everything works and everyone's job function?
No, no one can know all that. But the person in charge of an area needs to know what they need to know—which things are important and which are not. To make that determination, they must have a vision for how everything works at a high level, and what can go wrong, so that they can zero in on those areas and make sure that the important issues are being decided the right way—and if they are not, to intervene and drive good decisions, either through spearheading discussions or setting guardrails.
Most of all, a leader cannot afford to say, “That is technical—I don't need to know about how the technical stuff is done.” That won't work for a company whose business takes place on a technology platform.
What about everyone else? The CEO is not the only decision-maker in an organization. Yes, everyone else matters too. It is no longer the case that someone needs to know “only their job” the way that an assembly line worker at a Ford plant only needed to know how to attach a certain part. Today's organizations work in a more collaborative manner, so you need to understand what others do as well, to be able to participate in discussions with them and understand their needs and how your needs and their needs can be harmonized. Understanding the full range of activities (everyone else's jobs) also enables you to see opportunities for holistic improvement—approaches that make things better overall, instead of locally optimal.
It does not mean that everyone needs to be an expert in everything. That is not even possible. Instead, it means that everyone needs to take an interest in the entire value stream—the end-to-end sequence of activities that deliver value to customers or users. Learn as much as you can, instead of ignoring other job functions as “not your job.”
By now you probably see a connection to Agile: we are advocating collaboration across job functions. One of the Agile Manifesto principles reads, “Business people and developers must work together
