Skip to main content

Monkeys Juggling Fire on Pedestals

The "Monkeys and Pedestals" concept is a mental model introduced by Astro Teller, CEO of X (formerly Google X), to aid in problem-solving and risk identification. The analogy involves two tasks: training a monkey to juggle flaming torches and building a pedestal for the monkey to stand on. Building the pedestal is straightforward and poses little risk, while training the monkey to juggle is complex and uncertain. The key takeaway is to focus on the most challenging and uncertain tasks ("training the monkey") first, as they represent the critical risks that could impede progress. By addressing these high-risk elements early, teams can determine the feasibility of a project before investing time and resources into simpler tasks ("building the pedestal"). (Annie Duke)

In technical risk identification, this model suggests prioritizing the assessment and mitigation of the project's most uncertain and complex components. By tackling these "monkeys" first, organizations can uncover potential obstacles early in the development process, allowing for timely adjustments and more effective resource allocation. This approach helps in identifying technical risks by emphasizing the importance of confronting the most challenging aspects of a project upfront, thereby reducing the likelihood of unforeseen issues later on.

For a more in-depth understanding, you might find this discussion insightful:

Annie Duke: When To Quit, Monkeys vs. Pedestals & The Dark Side of ...

Here is a structured list of questions that technical advisors can use to identify which elements of a project are "pedestals" (straightforward, low-risk tasks) and which are "fire-juggling monkeys" (complex, high-risk challenges). These questions will help prioritize efforts and mitigate risks early.

1. Understanding the Problem Scope​

1.1 What is the core problem this project is solving?​

Bartendie is solving the problem of disorganized and stressful home bar management for cocktail enthusiasts who host events. The system aims to eliminate last-minute emergencies (like running out of ingredients during a party), reduce preparation stress, and allow hosts to focus on creativity and hospitality rather than logistics.

1.2 What are the key deliverables, and which are essential for success?​

The essential deliverables are:

  • Inventory tracking system with alerts for low supplies
  • Recipe management with scaling capabilities
  • Menu creation tied to inventory
  • Shopping list generation based on menus and guest counts

Secondary deliverables include:

  • Guest preference tracking and RSVP management
  • Flavor profile analysis
  • Bar tool inventory
  • Feedback collection

1.3 What assumptions are we making about the feasibility of different components?​

We're assuming users will:

  • Take time to input initial inventory accurately
  • Consistently update inventory after purchases and events
  • Value precision in recipe scaling and batching enough to justify the complexity
  • Follow the proposed workflow for planning and executing events
  • Find enough value in analytics and feedback features to use them

2. Identifying the Monkeys (High-Risk, Complex Elements)​

2.1 What are the most uncertain parts of this project?​

The most uncertain parts include:

  • User willingness to maintain accurate inventory data over time
  • Integration between multiple bounded contexts (inventory, recipes, events, etc.)
  • Accurate scaling of recipes for varying guest counts
  • Flavor profile analysis algorithms
  • User adoption of the complete workflow vs. cherry-picking features

2.2 Which technical elements involve new, untested, or cutting-edge technology?​

As an Elixir developer, I see several challenging technical elements:

  • The flavor profile analysis system for recipe balance
  • Real-time inventory tracking during events
  • Recipe scaling with proper unit conversions
  • Batch calculation algorithms that maintain cocktail quality at scale

2.3 Are there any dependencies on third-party systems, APIs, or integrations that could introduce significant challenges?​

Yes, several integrations pose risks:

  • Barcode scanning API for product lookup
  • Product databases for ingredient information
  • Email/SMS services for guest communications
  • Supplier APIs for ordering
  • Mobile app distribution platforms
  • Swift/SwiftUI integration with Elixir backend

2.4 Which tasks require significant research, experimentation, or algorithm development?​

Several areas will require substantial research:

  • Flavor profile modeling and balance analysis
  • Batch scaling algorithms that maintain taste quality
  • Inventory prediction algorithms based on usage patterns
  • Menu balance algorithms that ensure variety
  • Measurement unit conversion system with precision

2.5 Are there any regulatory, security, or compliance challenges that could derail progress?​

Yes, there are several compliance concerns:

  • GDPR compliance for guest data collection and storage
  • Age verification requirements for alcohol-related apps
  • App store policies for alcohol-related applications
  • Licensing issues for commercial cocktail recipes
  • Data security for personal inventory information

2.6 What potential technical blockers could cause failure or force a pivot?​

Potential blockers include:

  • Complexity in the domain model across bounded contexts
  • Seamless GraphQL integration between Elixir/Phoenix and iOS
  • Real-time synchronization of inventory during events
  • Accurate unit conversion and recipe scaling
  • Performance issues with large recipe or inventory databases

2.7 What has the highest likelihood of being significantly more complex than initially estimated?​

The flavor profile system and inventory maintenance are likely to be much more complex than anticipated. Maintaining accurate inventory during events and ensuring recipe scaling maintains taste balance will be particularly challenging to implement correctly.

3. Identifying the Pedestals (Straightforward, Low-Risk Elements)​

3.1 What parts of the project are well-understood and have clear, established solutions?​

Several components are well-established:

  • User authentication with OAuth
  • Basic CRUD operations for recipes
  • Tagging system implementation
  • Event calendar functionality
  • Basic inventory tracking
  • Email notifications
  • Database schema for core entities

3.2 What components involve existing technology, frameworks, or libraries that are well-documented?​

As an Elixir developer, I can identify several low-risk technical components:

  • Phoenix LiveView for web interface
  • PostgreSQL for relational data storage
  • Redis for caching
  • Absinthe for GraphQL API
  • Guardian for authentication
  • Swift/SwiftUI for basic iOS UI
  • Standard Elixir libraries for data processing

3.3 Which parts of the project have been successfully implemented in similar projects before?​

Many standard components have precedent:

  • User management and authentication
  • Recipe storage and retrieval
  • Event scheduling
  • Basic inventory tracking (similar to e-commerce systems)
  • Shopping list generation
  • Tagging and categorization
  • Image upload and storage for recipes

3.4 What tasks are primarily configuration, rather than invention?​

Configuration-heavy tasks include:

  • Setting up authentication
  • Database schema creation
  • API endpoint definition
  • Email notification system
  • App deployment infrastructure
  • CDN for recipe images
  • Database backup systems

3.5 What elements can be easily outsourced or modularized with low risk?​

Several components could be outsourced:

  • Email/SMS service
  • Image storage and CDN
  • Authentication system
  • Database backups
  • Basic mobile app UI components
  • Product database integration
  • Barcode scanning functionality

4. Prioritizing Work and De-risking the Project​

4.1 Can we test or prototype high-risk elements early before committing to a full build?​

Yes, we should prototype:

  • Recipe scaling algorithm with test cases
  • Flavor profile analysis system
  • Inventory tracking during simulated events
  • Menu balance calculation
  • Integration between bounded contexts
  • Batch calculation algorithms

4.2 Are there proofs of concept (POCs) that could quickly validate critical assumptions?​

Critical POCs to build:

  • Simple inventory tracker with shopping list generation
  • Recipe scaling POC with various units and quantities
  • Menu-to-shopping-list conversion with guest count scaling
  • Basic flavor profile categorization system
  • Bounded context integration prototype

4.3 What dependencies could cause cascading failures if they don't work as expected?​

Key dependencies with failure risks:

  • Integration between inventory and recipes
  • Recipe scaling affecting shopping list accuracy
  • Barcode scanning for product identification
  • Real-time inventory updates during events
  • Data synchronization between web and mobile apps

4.4 If a high-risk component fails, how will it impact the rest of the system?​

Impact analysis of component failures:

  • Flavor profile system failure: would affect menu balance but core functionality remains
  • Recipe scaling failure: critical impact on shopping lists and batching
  • Inventory tracking failure: would undermine trust in the entire system
  • Integration failure between contexts: could render the system fragmented and less valuable
  • Mobile sync issues: would create inconsistent data and user frustration

4.5 What alternative approaches exist if a key technical assumption turns out to be wrong?​

Alternative approaches:

  • Manual inventory updates if real-time tracking is problematic
  • Simplified recipe scaling if precision is too complex
  • Manual menu balance assessment if flavor algorithms are insufficient
  • Simpler bounded contexts with less integration if full domain integration proves too complex
  • Web-only approach if mobile integration introduces too many challenges

4.6 How can we iterate on the riskiest parts in a way that minimizes wasted effort?​

Iteration strategy:

  • Build minimal viable implementations of each risky component
  • Test with real users early to validate assumptions
  • Focus development sprints on single bounded contexts before integration
  • Use feature flags to gradually roll out complex features
  • Implement core functionality first, then layer on more complex features

5. Project Management and Decision-Making​

5.1 What is the simplest version of this project that delivers core value?​

The minimal viable product should include:

  • Basic inventory management
  • Simple recipe storage and scaling
  • Menu creation with ingredient requirements
  • Shopping list generation based on inventory gaps
  • This core functionality addresses the "never run out of ingredients" problem

5.2 If we had to deliver an MVP in half the time, what features or elements would we cut?​

Features to cut for a faster MVP:

  • Flavor profile analysis
  • Guest preference tracking
  • Feedback collection
  • Bar tool inventory
  • Batch calculation
  • Advanced theme matching
  • Mobile app (start web-only)

5.3 Are we spending too much time refining "pedestal" work before proving "monkey" work?​

We should be cautious about over-engineering the basic functionality (CRUD operations, authentication, UI design) before validating that our core value propositions (inventory tracking, recipe scaling, shopping list generation) actually solve the user's problems effectively.

5.4 What experiments or tests can we run in the next two weeks to reduce uncertainty?​

Quick experiments to run:

  • Paper prototype test of the event planning workflow
  • Recipe scaling algorithm with various test cases
  • Simple inventory tracking prototype with a few users
  • Shopping list generation logic with feedback from actual cocktail enthusiasts
  • Query potential users about their willingness to maintain inventory data

5.5 How will we measure progress on high-risk components to determine feasibility early?​

Progress metrics for high-risk components:

  • User testing feedback on inventory management usability
  • Error rates in recipe scaling calculations
  • Time required for users to plan a complete event
  • Accuracy of shopping lists generated
  • User satisfaction with menu creation process
  • Observed user behavior in maintaining inventory data