Startup Life

For the past 18 months, I’ve been working at a new startup, seeking a more challenging and innovative environment. From day one, we’ve had to be intentional in everything we do to progress towards validation and traction. With visionaries and peers from the Geotechnical industry, our product bets have often hit the mark. In this post, I’ll explore my reflections on what I’ve learned and what I view as having helped us move quickly in a market ripe for disruption.

agile methodology

I’ve grown jaded of Scrum over time, following copy-pasted approaches without identifying and applying what actually works best for the team and their situation, it can often feel like a huge time sink of meaningless meetings when done wrong, which it often is. On the other hand, I find agile and lean methodologies becoming more and more embedded in my fundamental principles that I hold deeply and apply in everything that I do.

Some of the core aspects I love:

• Collaborating closely with your peers - allows you to be more in sync with what’s being worked on, or happening, and as a result, I find it much easier to pivot or adjust when new information or challenges come to light.
• Incremental development - what’s the Minimum Viable Product (MVP) for our hypothesis? Once we’ve answered that and ideally shipped the solution to our users hands, what’s our next hypothesis, what’s the MVP to prove that? Continuing to grow and evolve methodically and incrementally while minimizing investment in hypothesis’ that aren’t yet proven.
• Customer centricity - spending time to understand our users and how they work, so that our hypothesis’ have a much better chance of being aligned to that. Looking at customer feedback and being quick to respond to frustration or problems, to help grow relationships that can create great feedback for growing the product into something people love.
• Adaptability - inevitably at a start up, things will change, quickly. I believe all of these principles feed into each other, and if you are applying all of them, they help with adaptabiltiy and responding to change. It’s also important that we always continue to look at our work and how we do it at a first principles level so that we can identify when we need to adapt what we are doing.

Applying all of these principles creates a very enjoyable working environment for me, far from some more factory-line-esque ways of working where you plan far in front, work is thrown over the fence from one party to another, and you often end up delivering something all the way through the factory line to find out it’s wrong and you have to go through the entire laborious process all over again. Applying the above principles you definitely still get things wrong, but the goal is it’s less often and the rework less.

Monkeys and Pedestals

When working in a much more agile, and incremental way, one of the challenges can be how do you estimate larger bodies of work that might span months? I’m fortunate to work with founders who value action over endless planning, and so we accept that in the beginning of an initiative, there is inherently going to be a lot more unknowns, and a lot of variance in the resulting time to complete the work.

During a one-on-one with my previous manager at Infinity, Joel Lieser, he introduced me to a powerful metaphor: teaching a monkey to recite Shakespeare while standing on a pedestal. The lesson is simple yet profound. If faced with two tasks - building a pedestal and teaching a monkey Shakespeare - you should tackle the more unpredictable task first. Building the pedestal is straightforward, but teaching the monkey is fraught with unknowns. If you can’t teach the monkey, there’s no point in building the pedestal.

This concept translates perfectly to software development. Consider a project estimated to take two months, filled with technical challenges and unknowns. By focusing on these “monkeys” - the complex, unpredictable elements - early in the process, you gain crucial insights. If one of these unknowns turns out to require an extra month of work, you can communicate and adjust your plan at the project’s outset. This approach is far preferable to discovering a major delay just a week before the expected completion date.

While this strategy doesn’t eliminate all delays in software development, it significantly reduces the risk of major surprises. By tackling the most uncertain aspects first, we can better manage expectations, improve communication, and increase the overall predictability of our projects. This approach allows for more accurate planning and helps maintain trust with stakeholders, even when faced with the inevitable challenges of complex software development.

Failing fast

At its heart, failing fast is about minimizing investment in unproven hypotheses. Consider this scenario: You believe a search functionality would benefit your users. Instead of immediately building a comprehensive solution with AI-powered autocomplete and scalability for millions of records, you start with a basic search feature. After weeks of development on the full-featured version, you might discover that users barely utilize it, forcing you to scrap the entire functionality. However, by building a MVP to test the hypothesis “Will search improve how users navigate records in our app?”, you could have gained this insight in just a few days, saving weeks of unnecessary work.

Implementing a fail-fast approach is challenging but crucial. It requires constant reflection on how each iteration contributes to validating or invalidating your hypothesis. While Scrum retrospectives can serve this purpose, they often become routine and lose their effectiveness. Instead, I prefer engaging in focused, ad-hoc discussions with peers or personal reflections on specific events, both positive and negative. This targeted approach allows for more meaningful insights and faster course corrections than waiting for scheduled ceremonies.

By embracing the fail-fast principle, teams can quickly identify which ideas are worth pursuing and which should be abandoned, leading to more efficient resource allocation and faster product improvements. Remember, the goal isn’t to avoid failure, but to learn from it as quickly and cheaply as possible.

Collaboration

A concept I’ve always been very fond of is what I call the “Three Pillars” approach. While not exhaustive, these pillars represent key roles I’ve encountered in my experience:

• Product
• Design
• Engineering

When building SaaS products, I’ve found tremendous value in ensuring these three pillars work closely together from ideation through to delivery and support. By blurring the lines between these roles, we create an environment that fosters speed, adaptability, and innovation.

Cross-Pollination of Ideas

When Engineering and Design contribute to Product decisions, they can leverage their technical and user experience knowledge to inform strategic choices. Similarly, when Product and Engineering collaborate closely with Design, they can better understand user needs and create more intuitive interfaces. This cross-pollination of ideas leads to better micro-decisions throughout the development process.

Example: During a product planning session, an engineer might suggest a technical approach that not only solves the immediate problem but also lays groundwork for future features, while a designer could highlight potential usability issues, leading to a more robust and user-friendly solution.

Rapid Problem-Solving

This collaborative approach allows for quick adaptation when challenges arise. Instead of waiting for the next sprint planning or formal meeting, team members can quickly come together to reassess and pivot as needed.

Example: Imagine we’re implementing a new data visualization feature. The original design calls for complex, interactive charts, but during development, we realize this approach will significantly delay the release. Instead of pushing ahead or halting work, the engineer can immediately reach out to the designer and product manager. Together, they might decide to release a simpler version first, with plans to iterate based on user feedback.

Shared Ownership

When all three pillars are involved throughout the process, it creates a sense of shared ownership. This often leads to higher quality outcomes and a more engaged team.

Example: Rather than a designer simply handing off mockups to engineering, they might pair with an engineer to implement the UI. This allows for real-time adjustments and ensures the final product closely matches the intended design while being technically feasible.

Challenges and Considerations

While this collaborative approach offers many benefits, it’s not without challenges. It requires team members who are open to stepping outside their comfort zones and leaders who can facilitate this type of cross-functional collaboration. It’s also important to maintain clear areas of ownership and decision-making to avoid confusion or delays.

By embracing this “Three Pillars” approach, we’ve been able to move faster, adapt more quickly to changes, and deliver products that better meet user needs. It’s not just about breaking down silos – it’s about creating a truly collaborative environment where the sum is greater than its parts.

Conclusion

Working at a startup has been a wild journey of continuous learning and adaptation. The principles of the agile methodology, lean’s failing fast, and close collaboration have been instrumental in our ability to move quickly and efficiently in a competitive market. By focusing on incremental development, customer-centricity, and adaptability, we’ve been able to make significant progress with limited resources.

The lessons learned - from tackling the “monkeys” first in project estimation to embracing the three pillars of product, design, and engineering - have not only helped us navigate the challenges of startup life but have also fundamentally changed how I approach problem-solving and innovation.

As we continue to grow and evolve, these principles will undoubtedly remain at the core of my work. For anyone embarking on their own startup journey or looking to inject more agility into their work, remember: stay flexible, focus on what truly matters to your customers, and don’t be afraid to fail fast and learn faster. In the dynamic world of startups, it’s not just about doing a lot with very little - it’s about doing the right things at the right time.