In Searching for Safety (1988), Aaron Wildavsky argued that trial and error, rather than the precautionary principle, is the best way to manage risks (Wikipedia). In the 1999 book "The new pioneers", Thomas Petzinger Jr. quotes him: "Planning is not a solution to any problems. It is just a way of restating in other languages the problems we do not know how to solve."
In my career, when it comes to company size, I have been on both the absolute ends of the spectrum. I spent a few years as a software engineer in Redmond, Washington, working for one of the largest companies in the technology industry. I've worked as an architect in Silicon Valley in some of the smallest companies alive. And I've worked on my own bootstrapped solo-pilot single-engine seed-stage startup with no initial traction, support or life-line.
I've spoken to CEOs, CTOs, VPs, VCs, Architects, Engineers, Consultants, Recruiters and all the titles in between. It's especially easy in the valley to speak to important people. It's a tight-knit ecosystem where everybody depends on everybody else for survival. All you need to do is to book a cheap event where entrepreneurs are invited, respond to a recently funded venture's job posting, or find a friend who is still in college and could invite you to seminars. And when you meet every celebrity who is a rockstar in the world of software geeks, you realize something very special: The higher you go up the chain of command, the less the person knows about software or methodology.
Software management and development methodologies, to use an analogy, are policies for managing and steering a ship. Recall your favorite navigation scenes from the movie The Pirates of the Caribbean: A British Lord High Admiral, let's call him prince (the VC in our case) has the influence among the rich, and therefore the money and the power. The prince knows nothing about navigation, nor where the treasure is. He needs a captain who has the experience to navigate, the passion to search all over the globe for clues about the treasure, and the desperate need for a ship. The pirate captain (the Entrepreneur CEO) can either prove his ability based on a piece of the treasure that he has found on a secret island using his tiny boat of a ship (prototype traction) or his good name from past semi-successful treasure hunts (credibility) for if any of them were fully successful, he wouldn't need the prince.
A seed investment is made to discover the rumored treasure island, and of course, the talented captain finds it. Series A, B and C are consecutively granted over a period of 3-4 years for the operations to be scaled out. Ships with massive amounts of treasure navigate the globe back and forth between the island and the homeland. But of course, most of the treasure is spent in building up these operations. And soon, just like that, the island isn't able to sustain this massive army anymore. The good captain's options in the treasure have duly vested and he sails, full-handed, to the open ocean seeking new horizons. As the new sailors wave goodbye, they wonder among themselves: Will we become like him one day? How can we maintain our livelihood without his leadership? Is this treasure island going to last forever?
It doesn't. The entrepreneur and his original crew members are not process oriented people. They're survivors of the evolutionary process. They never have to figure out how to work with each other, because by definition, if they didn't have that naturally, they would have failed a long time before meeting the VC. They didn't choose the process. The process chose them. The same is not true about the new massive company. If the new principals, the VCs, are smart enough to stay out of the way, the coordination effort itself among hundreds of employees is painful enough that a process is born out of the new culture and system. For most un-savvy employees, this is a top-down structure. And most employees who have not left as personal favorites of an entrepreneur captain are, probabilistically speaking, un-savvy. Savvy?
The prince's business is not money and treasure. It's influence. The prince wants the crown. Similarly, the VC is happy to see money coming in, but not for the sake of money. His sun shines the day the company goes IPO. But for the public to open arms to the venture, a long lasting source of revenue must be demonstrated. The new challenge appears: How does a massive company stuck with a static process and without maneuvering skills find massive amounts of revenue when the sources of revenue are still unknown and require dynamic maneuvering?
In the technology world, this problem presents itself, but never goes away. Even established sources of revenue have a limited life. Treasures show up and just as quickly dry up. In this analogy, the treasure islands correspond to vertical markets, and the treasure itself is the sense of excitement that can be harvested in the market place. The rate of treasure production corresponds to the rate of innovation life-cycle. The clock on the age of the world keeps ticking, new innovations come to the market, and the old treasures dry up. Captains who spend years planning massive operations to extract the goods of one island may find it looted and empty when they get there. If the pirate captain is still in charge despite the odds of his nature, he finds himself unskilled in maneuvering such a large army using his survival-hardened techniques. He either leaves on his own will or is asked to leave by the irate prince. It is quite common for VCs to replace entrepreneur CEOs with a new "large company" CEO who has his MBA from a royal school and his references lined up.
But this is not a story about the VC, the Entrepreneur, or the CEO. This is a story about the employee. The employees are the life of the company, and this is about how they can work together to reach new frontiers. It is only then that the ultimate goal of creating a public good is reached.
I'm quoting Jim Highsmith's book, "Agile Software Development Ecosystems":
"Clayton Christensen's best-seller, The Innovator's Dilemma: When New Technologies Cause Great Firms To Fail, describes what happens to firms caught in disruptive technological change. When a new technology undermines a particular market, such as when personal computers disrupted the mini-computer market, established firms whose managers are successful by every traditional measure often fail. Christensen's study of the 20-year history of the disk drive market between 1976 and 1996 shows that in a disrupted market, speed to market becomes absolutely critical. When traditional 'stuff happens' change occurs, efficient management is a reasonable strategy, but as Christensen shows, when companies face disruptive change, speed becomes the preferred strategy. This is not an easy transition for many companies, as the demise of mini-computer companies indicates. (Christensen, 1997)"
With the assisted use of an analogy, I've told a story here, but I don't intend to draw a concrete conclusion. I used the East India Company analogy and pirates as an example, because in a way, our today's vocabulary for ventures, exploration, navigation, capital and dominance come from those days. Yesterday's pirate is today's entrepreneur (as aptly put by Steve Jobs, "It's better to be a pirate than to join the Navy"). We take so much of our direction in software engineering from the "business leaders" who have done it before. We never stop to think that all the processes and policies imposed on engineering firms are born out of financial optimization and traditional navigation strategies.
So next time someone, no matter how authoritative, argues that employees need to follow the established process so that the company can execute its strategy to capture a market, first think about this: Does that strategy come at the cost of freezing employee responsiveness to day-to-day changes? For example, are you asked to "not touch" certain things and "only focus, plan and document" certain other things in order to meet a strategic goal? And ask what would happen if 4 weeks down the road, suddenly that goal isn't viable anymore? Is all of your work lost?
I have not prescribed Agile methodology in this article. I'm only encouraging for you to question authority. Methodologies are often the byproduct of a culture, not a top-down policy. But certain leaders turn it into the latter, or upon observing the latter, make no attempt to foster a change in the ecosystem. Good organizations tend to be taken apart by well-to-do leaders who don't realize the rapid dynamics of the changing tech market landscape. And if you take too long to question them, you might find you've sailed across the vast ocean to land on a deserted island.
Why should you care? Not because you'll stay hungry for days waiting for a light and agile ship to rescue you. But because you had aspirations to become a mighty pirate yourself someday. And the longer you spend with comrades on the same ship and the bigger the bounty you return with, the easier it is to sell your battle-hardened pirate face to a prince worthy of his gold pen. And why not after all?
A pirate you were meant to be,
Trim the sails and roam the sea!
- Monkey Island
