Launching Litter-Robot 4

I have waited almost two years to write this, as it marks a significant personal and professional milestone for me. This post not only celebrates the successful launch of Litter-Robot 4 (LR4) but also highlights the evolution of my role and the valuable lessons learned along the way. In this post, I will attempt to summarize some of the key lessons learned and outline future plans. To preserve privacy and not disclose sensitive business information, I cannot delve into the deep technical architecture, specific revenue numbers, or name team members. However, I hope the insights shared here will provide valuable guidance and inspiration for others.

My Journey at Whisker

I joined Whisker in August 2020 as the first software engineer and handled a portfolio of legacy products and tasked with modernizing the cloud systems so the company could evolve. I was eager to contribute to projects like this one and help launch the Litter-Robot 4, the next generation flagship product.

The journey to launching LR4 has been a tough one. From the lack of concrete requirements and clear expectations, to the absence of a robust schedule, it’s been quite challenging to launch this product. Supporting teams often did not have the necessary information to execute their tasks effectively, resulting in costly assumptions, particularly at the firmware and hardware levels. These coordination issues underscored the importance of clear communication and comprehensive planning.

As the company quadrupled in headcount since I joined, many aspects of Whisker changed as it grew. Of course there were the challenges but amidst the chaos, I stepped up to transition to a technical program manager (TPM) role; it wasn’t out of choice but rather necessity. I went from writing code and designing the LR4 systems to managing the software delivery and shepherding the work of multiple engineers across different domains. My responsibilities expanded to a blend of engineering and product management peppered with cross-functional communication and coordination. It was a great time to learn on the fly, try new concepts and identify gaps in leadership, all while ensuring the project stayed on track.

Today, I have cemented the TPM role and the LR4 is just a part of a broader portfolio of projects I manage. While it remains the largest due to its recent launch, other projects also demand my attention. The software organization has grown from just me to a team of 20 talented individuals, and we plan to double this number over the next year. Our focus will increasingly shift towards digital products, with the goal of generating revenue from these offerings for the first time.

Lessons Learned

Now that the launch is behind me, I finally have some time to throw together these insights and lessons I’ve compiled. Before I dive in, I can’t help but think about the Stoic adage “the obstacle is the way” and how aptly it describes the LR4 journey. Each step of the project presented challenges, but overcoming these impediments became our path forward. While difficult at times, it was the only way to progress. It may sound cliché, but from an industrial engineering or management consulting perspective, we experienced growth in S-curves. We grew until we reached a plateau, then new problems emerged, catalyzing the next phase of growth as we tackled these obstacles and pushed ahead.

Don’t Build Software in Silos
Building software in silos is detrimental to the project’s success. Assumptions about inputs or outputs outside your domain can lead to costly mistakes. Instead, seek out the right answers or acceptable ranges of answers. Larger projects require someone to glue everything together—a role that spans beyond the responsibilities of PMs and engineers. PMs handle the “why” and “what,” engineers focus on the “how,” but TPMs must encompass all these aspects and also address the “when.” Initially, we lacked a dedicated product team, and this oversight underscored the importance of having a TPM who can corral efforts, connect dots, and ensure a cohesive strategy. Ideally, a release manager would further enhance this process.

Things Are Out of Your Control
In any project, some things will inevitably be out of your control. Our hiring plan wasn’t competitive enough, the CEO often changed directions, and I found myself supporting a team of engineers without sufficient support myself. Additionally, people leaving the team can affect morale. All you can do is thank a departing colleague for their efforts and wish them well. Beyond that, the plans need to be recalibrated. Flexibility and resilience are key to navigating these uncontrollable factors.

Complexity is Your Enemy
Managing complexity was a significant challenge during the development of LR4. Factors such as changing requirements, unclear ideas, and lack of documentation added to the complexity. Understand the sources of complexity: do a root cause analysis to get to the bottom of it and ensure something at the first level doesn’t propagate several layers later. Also, ensure ideas and requirements are well-defined from the start. Encourage frequent communication and collaboration across all teams.

Communicate Effectively & Prioritize Often
This builds on the previous insight but is critical enough to deserves its own section. I adopted writing memos as well as modified meeting structures to make them more productive. At first there was resistance but folks caught on. Tools like Jira and Confluence went a long way when adopted across the teams. Maintaining clear and consistent documentation across the project reduces complexity and ambiguity and ensure everyone is on the same page. I used diagraming software like Miro and Lucidchart quite often and framework models such as SWOT for product related discussions and ruthless prioritization. RACI matrices also helped in keeping folks informed across the company on which persons were involved and could provided appropriate answers.

Engineering is About Tradeoffs
Engineering is all about making tradeoffs. This realization sparked my interest in the concept of leverage and creating value through leverage by becoming a TPM. I traded my time writing code for organizing and leading the team. The other aspect of tradeoffs is finding the optimal path while juggling different constraints. For example, we faced higher costs than initially budgeted and had to make several compromises. Ultimately, it is vital to recognize the inevitable tradeoffs in every decision and how they can affect the outcome. Pugh matrixes helped here and I often picked cost, time, performance metrics and user experience as my constraints. In the spirit of tradeoffs and leading to the next insight, you have to keep in mind that constraints and their weights can change. Be prepared to adjust plans and expectations as new information and challenges arise.

Optimal Can Change
This is further related to the builds on two previous ones: the importance of tradeoffs and the pitfalls of building in silos without complete context. Optimization is a moving target. One day you might be optimizing for cost, and the next day, a more pressing issue arises. For example, I initially resisted a particular design for handling inbound events due to its higher software costs. However, the firmware costs were fixed at the time of production, and the software, although more expensive, allowed us to use cheaper components during the build. After analyzing growth rates and costs, I realized that the break-even point would be 13 years into the future—well beyond our window of concern. This experience taught me that flexibility and the ability to pivot are crucial in optimizing for long-term success.

People Do Affect a Project
The people you work with can make or break a project. Talented, dedicated colleagues contribute significantly to the project’s success and create an enjoyable and fulfilling work environment. Their support, ideas, and camaraderie are invaluable assets. Conversely, negative people can hurt the project. Fiefdoms and middle management can derail progress, which is something I despised. Rank should not be the driving factor.

In Summary
Engineering is a rewarding career, and I can’t recommend it enough. There is a slow burn of hard work and a lot of stress but it can culminate in moments like this that profoundly shape careers. The launch of Litter-Robot 4 has been a transformative experience and taught me so much about what it means to evolve my role and step up into leadership. True leadership involves taking initiative; acting on the courage to make things happen, setting boundaries, and solving problems proactively. It wasn't easy and I defintely was pushed by necessity but I am glad I took the initative. For anyone embarking on a similar journey, I hope these insights provide guidance and inspiration. While the path may be challenging, the rewards of seeing your vision come to life are well worth the effort.