Last week, I listened to Simon Sinek’s podcast episode featuring Dr. Astro Teller, Google’s Innovation Chief and founder of X, Google’s Moonshot Factory. Dr. Teller referenced the “Monkey on a Pedestal” analogy, which serves as a guiding principle at the Moonshot Factory.
The concept goes like this:
Imagine you are tasked with teaching a monkey to recite Shakespeare while standing on a pedestal. The typical response to this difficult problem would be to break it down into smaller, more manageable tasks.
In this case, you have two major tasks: (1) teach the monkey and (2) build the pedestal.
It’s clear that teaching the monkey is the more difficult task while building the pedestal is the easier one. Following conventional wisdom, you might think tackling the easier task first makes sense, building the pedestal to gain momentum and mark off some quick wins.
After all, both tasks demand time, money, and attention.
Task Completion Bias
Starting with the easy tasks may seem like a smart way to build momentum. You can check them off your list and feel a sense of accomplishment.
However, Teller’s analogy cautions against this approach because it encourages procrastination by focusing on non-critical tasks — what psychologists call task completion bias. This bias pushes us toward completing easy, trivial tasks because it gives us the illusion of progress. It’s far more satisfying to tick off several small tasks than to face the reality of working on a complex issue that will take time to resolve.
I frequently observe this phenomenon in my team during our daily standups and backlog reviews. Our tasks range from simple requests, like resetting passwords, to complex issues, like resolving critical system outages.
When given the freedom to choose, team members often gravitate toward quick-fix tasks. These allow them to mark off items quickly and feel productive, but the more challenging and urgent issues remain untouched, building up in our queue.
Sometimes, these critical tasks edge dangerously close to our SLA deadlines.
It’s not a matter of capability—my team can handle the tough problems—it’s the human instinct to prioritize quantity over quality, the satisfaction of saying, “I closed 10 tickets today” rather than “I’m still working on the big one.” This constant chase for visible progress often comes at the cost of solving the most pressing issues.
Sunk Cost Bias
This behaviour doesn’t stop at task completion bias. It also feeds into what’s known as sunk cost bias. The more time and resources we invest in something, the harder it becomes to walk away — even when it no longer makes sense to keep pushing forward.
A few years ago, I managed a project for a large-scale implementation. We ran into a significant design flaw in one of the solution’s secondary features. Despite recognising the problem early on, the team had already poured hours into trying to find a workaround. Instead of reevaluating the situation and shifting focus to the critical components of the solution, we kept sinking more time and resources into this secondary issue.
As we inched closer to exceeding the project’s budgeted hours, the main features were still lagging because so much effort had been diverted to fixing the flawed design. We were trapped by sunk cost bias — the belief that we had already invested so much in the original approach that we had to see it through, despite the fact that it was costing us more time and resources than we could afford. In hindsight, the smarter move would have been to regroup, admit the approach wasn’t working, and pivot earlier. But the time and effort already spent made it hard to change course.
Dr. Teller’s analogy offers a simple but powerful reminder: in any project, the real success hinges on solving the core problem — teaching the monkey to recite Shakespeare. If you can’t do that, the pedestal is useless. This principle applies to all complex problems: don’t waste time building the pedestals when the real issue remains unresolved.
In the same project, we eventually managed to deliver on time, but we cut it dangerously close to exceeding the deadline and budget. Looking back, it would have been better to focus on delivering the core features — the “trained monkey” — even if it meant leaving the secondary features unpolished — the “unbuilt pedestal.” We got caught up in secondary issues instead of prioritising the main problem.
Reverse Salient
This lesson is directly related to the Reverse Salient concept introduced by Thomas P. Hughes in his book “Networks of Power”.
Hughes borrows the term from the military, which refers to a part of an advancing force that lags behind and slows progress. In the context of early electrification, Hughes referenced Edison’s struggle to transmit low-voltage direct current over long distances, a hurdle that held back the progress of electrification until alternating current technology was developed.
In modern terms, reverse salient is what we now call the showstopper, bottleneck or weakest link. The progress of a project or product is limited by its reverse salient — the critical problem holding everything else back.
MVPs and Agile Development
Similarly, in Agile development, an MVP (Minimum Viable Product) aims to strip away all non-essential features and focus on solving the key problem as efficiently as possible. By developing an MVP, teams can test core hypotheses, gather feedback, and learn quickly from real users.
This approach reduces the risk of sinking time and resources into building a fully developed product that may fail and aligns with the Agile philosophy of continuous improvement and iterative development.
One of the main benefits of Agile development is its flexibility, allowing teams to adapt as they learn more about user needs and market conditions. By releasing an MVP early in the development process, teams can quickly get a product into users’ hands and collect valuable feedback to guide future iterations. This approach fosters a “fail fast and deliver faster” mindset, where the goal is to identify and address issues early on rather than wasting time perfecting features that may not matter in the long run.
In summary, combining the MVP approach with Agile development empowers teams to stay focused on solving core problems, adapt quickly to feedback, and deliver solutions that meet user needs efficiently — ultimately minimising waste and maximising value.
Ensuring Project Success
Through my experience in project management and team leadership, I’ve learned that success often hinges on correctly identifying and addressing the key challenges — the “monkey” in any endeavour. In complex projects, getting caught up in secondary tasks and feeling productive is easy, but the real value comes from solving the hardest problems first.
That’s why, before diving into any endeavour, performing a reverse salient analysis is crucial. This ensures that the most critical obstacles are identified early and addressed head-on.
Here are the key lessons I’ve gathered over the years:
- If the central challenge (the “showstopper” or training the monkey) is unachievable, it’s better to cut your losses early and pivot to a different approach or project. Pouring more resources into a problem you can’t solve wastes time and energy.
- If the showstopper is solvable and relatively easy to implement, then it’s safe to move forward with other tasks (building the pedestals) and continue progress as needed.
- If the showstopper is solvable but difficult, then all focus must be directed toward overcoming this challenge before investing time in secondary tasks. Tackling the hardest problems first ensures you aren’t wasting time on work that may later become irrelevant.
In essence, these experiences have reinforced two critical principles:
- Always start by working on the unknowns.
- Focus on solving the real, core problems that will define the success of your project.
Whether it’s managing a team, providing a service or developing a product, the takeaway is clear: only by confronting the most difficult aspects of a project can you achieve meaningful, lasting progress.
Leave a Reply