The specific model presented here is at times “Silicon Valley specific,” but tried to make it flexible enough that one could apply it at any company.

Here’s the abstract:

In this talk, you will learn how to think about your career trajectory and approach it like a software engineering problem. We pull back the curtain on common industry practices like review and promotions, career ladders, and some techniques to help you navigate it all by working smarter, not harder.

Image credit: wikimedia commons

Waterfall software development is when we carefully plan out everything in advance and then sequentially march towards a single release.

Everyone knows, waterfall software development is bad.

Waterfall is for dinosaurs. 

Image credit: stability ai

This is Professional Scrum, the most popular Agile software development methodology.

Image credit: wikimedia commons

Everyone knows, Agile is good!

The Scrum Alliance actually has a much better diagram than this, but it’s copyrighted and I don’t want them to sue me. Professional Scrum is a trademark of the Scrum Alliance. So is Professional Scrum Master and Professional Scrum Product Owner.

Sometimes it’s better to just go with the flow

“Waterfall bad, Agile good” is overly reductive.

There have been some Huge Success projects that used Waterfall. The Apollo program was a $250 billion (inflation adjusted) program that put a man on the moon. Their process was mostly waterfall.

On the other hand, Dropbox and Salesforce are two examples of Huge Success companies that adopted Scrum on their way to becoming juggernauts.

What’s the difference here?

For the Apollo program avoidance of failure depended on the proper application of science, so they (kind of) knew what success looked like from the very beginning. On the other hand, Product Market Fit is governed by fuzzy social “sciences” like economics and psychology.

But I thought Agile and Waterfall are opposites, right?

So why is the title of this post How to make a Waterfall Agile?

AGILE | English meaning – Cambridge Dictionary

I love this mental image of “monkeys are very agile climbers.” How can an agile team move like a monkey? Let’s take a moment and watch this video.

How to Move Like a Monkey | National Geographic

What do you notice? He’s constantly adjusting his path. He’s not moving in a straight line.

A thought experiment

Let’s say we are a hypothetical startup NewCo that just raised $1,500,000 and spends $500k/year. We have three years of runway. On this graph the arrow to the right represents time (or money. time is money, after all). If NewCo can get to Product Market Fit before they run out of money, they can raise a juicy Series A.

But this simple linear example isn’t the way the world works. Finding Product Market Fit is not the Apollo Program because startups are by definition trying to build something new, something unknown. We don’t know what success looks like and we don’t know exactly how we will get there.

Because we don’t know precisely where Product Market Fit is, it’s more useful to think of this as a probability cloud.

What if PMF wasn’t right in the center of the probability cloud? We might miss it!

In fact, a vanishingly small percentage of startups find PMF. Failure is the most likely outcome.

In those three years, we hopefully learned a lot along the way. That means the probability cloud got smaller! Unfortunately we also see that the center has moved, we are out of money, and we missed PMF.

If a startup uses a Waterfall process, there are no opportunities to change direction along the way.

So let’s break that line up into pieces.

Ideally, we do a little work, we learn a little more about our customers, and the point cloud target gets a little smaller.

Coming back to the Scrum diagram, each line segment is a Sprint.

And every time we start a new Sprint, we learn and the point cloud becomes smaller and easier to hit.

Each new Sprint gives us an opportunity to steer towards a new heading.

In this mental model, successfully finding Product Market Fit depends on a few things:

1. The more we learn about our customers, the smaller the probability cloud.
   1. Lesson: Optimize for learning, not feature growth.
2. The sooner we learn about our customers, the direction of our vectors will be more accurate.
   1. Lesson: Frontload learning, the benefits of learning compound over time.
3. The more frequently we change the plan according to new information, the smoother our path will be.
   1. Lesson: Well informed changes in the plan are good and should not be avoided.
4. We have to accomplish all of this before we run out of money.
   1. There’s no lesson here. This is just a reminder to hurry!

Finding Product Market Fit is obviously much more complicated than that, but these attributes are “table stakes.”

Here come the Triangles

The next spicy ingredient in our shamefully mixed metaphor is the Iron Triangle from project management.

The Iron Triangle states that:

Scope, cost, and time. You can’t change all three without sacrificing quality, so pick two.

Or mathematically:

ΔCost + ΔTime – ΔScope ≥ ΔQuality

Alternately:

TANSTAAFL – “There Ain’t No Such Thing as a Free Lunch”

The calculus is easier if we assume the horse is a sphere.

image credit: Dall-E prompt “assuming the horse is a sphere”

In an agile startup seeking Product Market Fit:

• If we hold team size constant, Time and Cost are roughly equivalent
• Time+Cost is effectively the same as our runway.
• Quality is effectively the same as Product Market Fit..

Δrunway – Δscope ≥ ΔPMF

But this is a startup. runway can be considered fixed because we are unlikely to raise more funding unless we find PMF.

Δscope ≥ ΔPMF

This equation says “well designed increases in scope might lead to Product Market Fit, but it’s also possible to increase scope and not increase PMF.”

But wait – the Iron Triangle is only “iron” when we know exactly what we need to build. In a startup, scope of PMF is uncertain – it’s a point cloud.

May the Ghost of Heisenberg forgive me for what I am about to do

Looking at a point cloud reminds me of the Heisenberg Uncertainty Principle, a fundamental concept from Quantum Mechanics that states:

there is a limit to the precision with which certain pairs of physical properties, such as position and momentum, can be simultaneously known. In other words, the more accurately one property is measured, the less accurately the other property can be known.

https://en.wikipedia.org/wiki/Uncertainty_principle

Or, much more simply:

The more precisely we know the location of a particle, the less precisely we can know its direction (or visa versa).

Physicists in the audience, avert your eyes. I am about to force a contrived metaphor that is not at all grounded in the mathematics of quantum mechanics. 

[handwave-y metaphor goes here]

Image credit: Dall-E

From here, if I stand on my head and look sideways, I can contort the mathematics in a way that makes the reduced Iron Triangle look a lot like Heisenberg’s equations.

Dear reader, I’ll spare you from this Quantum Woo arithmetic heresy. Agile project management is not a quantum phenomenon. This is only a sloppy metaphor.

Disclaimer: The Uncertainty Principle is used for illustrative purposes only. No physicists were harmed in the making of this blog post (except maybe their sensibilities).

The Agile Startup’s Uncertainty Principle

Given that in a startup:

• we will know precisely what Runway is
• we won’t know precisely what Product Market Fit is (until we get there)
• the only “high confidence” plan is based on fixed time intervals, not fixed features

So, embrace risk, optimize your roadmap for Learning, not Predictability. And hope we reach the Promised Land.

This is a terrifying and unsatisfying result! I wish there was another conclusion to be drawn. 

You have a fixed budget, embrace the consequences.

But what about that Agile Waterfall?

I want to call attention to the little trademark symbol in the title.

An agile startup is one that learns quickly and changes direction quickly.

An Agile startup is a company that follows a specific certified process, like from the Scrum Alliance.

Ideally, all Agile (certified) companies would also be agile (flexible), but in some cases, they might not be. Just because you are Agile certified, does not mean that you learn and change quickly.

Time for one final definition!

Agile Waterfall

/ˈadʒʌɪlˈwɔːtəfɔːl/

noun

Any long-running project that follows certified Agile processes, but never deviates from its predetermined plan.

“That Agile Waterfall wasted a lot of productivity following processes designed for flexibility it didn’t use”

Agility is not free!

Being agile has a lot of overhead compared to the waterfall method. The following table shows the Scrum Alliance’s recommended meeting times for a 2 week Sprint:

That’s 12% of our time dedicated to Scrum alone!

In addition, being (lower-case) agile can be even more expensive. We have science to do:

• create hypotheses
• design experiments
• execute experiments
• measure our progress
• learn from mistakes
• and update our plans

This leaves precious little time runway for building features! We’d better build the right ones.

“Shoot! A fella could have a pretty good weekend in Vegas with all that stuff.”

Being agile sure can be expensive.

But what’s the alternative?

I guess a startup could make detailed plans and carefully execute them all the way into bankruptcy.

Zen Buddhism is taught through a series of paradoxical statements, or koans. Meditating on these koans helps pull the student out of conventional thinking and into a deeper understanding of Zen and conventional reality.

One of my favorite Zen koans goes like this:

If you meet the Buddha on the road, you must kill him.

Linji Yixuan

What does it mean?

At my work, we are creating a new kind of SaaS platform. This platform is something the world has never seen before, so we don’t know exactly what it will look like. We have some great ideas based on 15 years in the location business, but we are still exploring. We are searching for Product Market Fit.

Searching for success, it is common for companies at our size to emulate what seem like “best practices” used at industry giants like Google, Facebook, Amazon, and Microsoft.

I understand the desire to emulate the best, but this is a dangerous game. When initiatives are justified by “that’s how we did it at Microsoft/Google/et al,” this isn’t the flex you think it is.

In fact, we should view the patterns and practices of industry giants with great skepticism.

What’s so magnificent about the Magnificent Seven?

The original Magnificent Seven (1960) is a Western film based on Akira Kurasawa’s classic Seven Samurai. It starred Yul Brynner, Steve McQueen, Charles Bronson, and James Coburn, all before they became big Hollywood stars. Later there was a TV show and a 2016 remake.

It’s a story about how a small village hires seven gunfighters to protect them against a gang of bandits. The gunfighters teach the villagers how to defend themselves, and by the end of the movie, 70 people are dead (including four of the seven).

But I digress. We aren’t interested in that Magnificent Seven. We are talking about this one:

Image credit: Leverage Shares

Apple, Tesla, Meta, Google, Nvidia, Microsoft, and Amazon.

What’s special about these companies? The Magnificent Seven are each lucky to have found a money-printing machine. Google’s advertising business generates $240 billion annually. Facebook’s advertising business has $130 billion in revenue. Microsoft’s Windows and Office units clock in at more than $70 billion per year. Amazon generates $30 billion of free cash flow, primarily from retail operations and AWS. The iPhone business unit makes $200 billion for Apple. These businesses are the ultimate examples of Product Market Fit at scale.

With billions in profits, Google gleefully firehoses money into questionable investments like internet broadcasting hot air balloons and extravagant perks like 20% time. Facebook has spent over $35 billion on the Metaverse. Apple recently abandoned an expensive automotive product.

Additionally, these companies have many peculiar technology practices. Facebook has created its own programming language (Hack) to make a lousy programming language (PHP) safer. The overwhelming majority of Google products are stored in a single Perforce repo.

Therein lies the problem. When a company sits atop a money printing machine, virtually any organizational structure or technical practice will work. Any financial investment seems like a good idea. A few billion dollars will iron out a lot of wrinkles.

When Statisticians Save Lives

Let’s take a brief diversion into the history of statistics. Story time!

During World War II, the Navy was losing a lot of B17 bombers. Military analysts carefully studied returning aircraft and found a notable pattern in the distribution of bullet holes.

The answer here seemed quite obvious. Clearly, we should add more armor in the places where planes are getting shot!

Fortunately for the crews on future B17 flights, a statistician named Abraham Wald was able to prove mathematically that this approach was the opposite of what they should do. Because the airplanes analyzed were the ones that made it home, these damage patterns indicate all of the places a B17 can get shot and still survive. Shells that hit planes that didn’t come home in the unmarked areas caused them to crash.

Survivorship bias is a form of selection bias that can lead to overly optimistic beliefs because multiple failures are overlooked, such as when companies that no longer exist are excluded from analyses of financial performance. It can also lead to the false belief that the successes in a group have some special property, rather than just coincidence as in correlation “proves” causality.

https://en.wikipedia.org/wiki/Survivorship_bias

Applying this metaphor to Tech Startups, only a few innovations matter to company success (such as AdWords, iPhone, MS Office). These are similar to the engines, cockpit, and tail of a B17. If these critical areas can be protected, the rest of the business could actively destroy shareholder value, and the planes would still return home safely.

The lesson here is simple. We must not blindly adopt patterns and practices used by industry leaders.

Which brings us back to the title of this post.

If you meet the Buddha on the Road, Kill Him

What does it mean? I’m not a Buddhist scholar, so I’m going to borrow words from someone more eloquent than I (emphasis added):

There are often points in our practice journey where we need to seek advice and experience from those further along the path. But within the teacher/student relationship can arise a point at which the student is susceptible to idolizing their teacher and thus forgoes their own growth …

Idolizing a teacher is one side of the dilemma. The other lies in the teachings themself. Over the life of our spiritual practice, there may be times when we begin to conceptualize the nonconceptual. We begin to “know” rather than remain open to. When we cling strongly to what we have learned, it becomes easy for us to be convinced that we get it, and in fear of losing it, we begin to hold tightly to it. This fixation ends up becoming a crutch towards our growth. The teacher and teachings are both useful and to some degree, necessary, so they should be utilized, but both also must, ultimately, be allowed to drop away. For one to truly grow in spiritual practice we must let go. Let go of all concepts and remain in an attitude of openness, eagerness, and without preconceptions. A state known, among Zen practitioners, as “beginner’s mind.”

Killing the Buddha means killing our conceptualizations, killing the belief that we understand it all.

– Lion’s Roar

The Beginner’s Mind

How do we identify which patterns and practices are worth emulating?

What made these companies so successful?

The Google story seems simple:

1. Create a step function improvement in search results quality.
2. Copy a competitor delivering a new kind of advertising (Overture’s PPC) to a much smaller user base.
3. Use excess profits to create monopoly market share in search and then protect it.
   1. Buy traffic from industry partners like Firefox and Apple
   2. Acquire compatible competitors like YouTube and Doubleclick

Unfortunately, the first item on the list is quite difficult to emulate!

Let’s examine at Facebook next:

1. Dominate the social media market for universities with a more user-friendly, more addictive social network.
2. Expand dominant share in education into the larger market for all social networks.
3. Sell advertising to a large mobile market assembled from a mix of first-party applications (Facebook, Messenger) and platforms (Facebook Login, Advertising Platform).

Similarly, if we could have invented PageRank or TheFacebook, we would have done it already.

Revolutionizing an entire industry is a mixture of hard work, smarts, “right place, right time,” and a lot of luck.

What are the specific patterns or cultural elements that enabled these key innovations?

To be honest, we’ll never know for sure unless we were one of the first few hundred employees at one of these companies. Most of the people who experienced these revolutions first hand are unlikely to be reading this article while enjoying early retirement on their private jet.

Each of these companies has a certain reputation which may causally explain their success (but really, we will never know for sure):

1. Microsoft – controlled their own distribution with a combination of ruthless deal making and luck.
2. Apple – consistently delivered a better experience by mixing together off-the-shelf technology with one or two key innovations, and holding these new products to much higher usability standards than competitors.
3. Amazon – maniacal customer focus coupled with the best cash flow management in the industry.
4. Google – early focus on speed and quality.
5. Facebook – relentless focus on the user experience and culture of experimentation.

Are these practices worth emulating? Maybe!

Also, maybe not. When deciding whether to emulate a specific practice, you must think critically about whether your company is a good match for this pattern.

• Company Lifecycle – are you still trying to find Product Market Fit? Don’t copy Google’s famous 2007 experiment to pick a shade of blue – when Google had $16 billion in revenue. Instead, consider how Dropbox acquired their first 100 users.
• Size –  If your company has 250 employees, don’t adopt an organizational structure that helped Microsoft scale to 200,000 employees. Instead investigate how Figma pulled a $10 billion valuation with just 500 employees.

This is my tech blog. I write at the intersection of technology, business, and human behavior.

On my personal blog, I also write about travel, finance, and fireworks.