Retrospective on my time at Zume -Lesson 1: Optimize to Learn

I joined Zume in October 2015 as the company’s first full-stack engineer, when we were still Zume Pizza. I was let go last month, from my role as VP Engineering, four and a half years later, along with my entire team and business unit, due to a restructuring that was prompted by the COVID-19 pandemic. My cross-functional team of engineers, product designers, and product managers were responsible for building software for Zume Forward’s mobile kitchens. Ironically, we were on the verge of launching a new SaaS product aimed at helping restaurants transition into an off-premise first world.

Even though the company shut us down so abruptly, these last few months, leading this team, which we called Phoenix, and working with the rest of the Zume Forward business unit, was by far the pinnacle of my time at Zume. Leaving on this note was jarring and painful, but the relationships I’ve made and the lessons I’ve learned have been invaluable and will undoubtedly accompany me. Ultimately I had a unique opportunity to reinvigorate a culture in a team that was just devastated by a huge layoff and had to keep rallying and fighting the good fight. In the end, we had a blast, and I learned a ton on how to run a fast-moving, inspired software organization effectively.

I’ve decided to document some of what I learned and what I did with these learnings during the last few months with Team Phoenix in a few blog posts. I hope these lessons will serve other engineering and product leaders and entrepreneurs. At the very least, it’s been cathartic to retro on this incredible 4.5-year sprint.

First, a Little Context

Before joining Zume, I had directed and produced student films, served as an infantry company commander in the IDF, launched and sold a student cafe while doing my BA in New York, and started two startups. So I had had my fair share of trials and errors, successes, and failures. Zume Pizza appealed to me for a few reasons: the opportunity to join a young startup, work on a greenfield tech stack, disrupt an outdated industry, and work with fun, smart, ambitious people. After building and launching our MVP, the team began to grow, and new opportunities to lead arose.

As an engineering manager and director, I continually questioned how we did things and introduced new concepts to my teams: pair programming, mob programming, Hiring Day (a riff on Menlo Innovation’s Extreme Interviewing). While these methodologies bore fruit, I often felt like a bit of a black sheep, a salmon swimming against the current.

When Zume went through a significant restructuring in January this year, in which the company divided into separate semi-independent business units, our CEO asked me to stay and lead the software EPD (Engineering / Product / Design) team within Zume Forward as a Divisional CTO. Although the challenge ahead of us was daunting, I saw this is an opportunity to step up and contribute substantially.

Not surprisingly, when I sought feedback from one of our departing engineering executives on how to lead in this next chapter, he cautioned against reverting to my experimental ways and suggested I adhere to a more traditional approach. In the end, though, I decided to stick to my true north. Here was a chance to implement all that I had learned and had been advocating for. It was a chance to put into play the Agile principles I had come to believe in so strongly, to form a cross-functional product building team and culture rooted in empowering people, an opportunity to create value for real customers, and to move fast finally.

So what was the Outcome?

As I mentioned, Zume ultimately let go of my entire team and business unit overnight. But the accomplishments we made in those three months were impressive:

• we deployed our KDS (kitchen display system) app, built for our mobile kitchens, within several brick & mortar kitchens, expanding our market reach
• we finally removed our monolith and moved to a complete microservice architecture (something we had been working on for months before the January RIF and many other engineers and teams had contributed to)
• we changed our CI / CD process from Jenkins / Spinnaker to Codefresh to simplify our DevOps
• we cut down our infrastructure expenditure by 85%, and we removed a significant hardware dependency that was slowing us down

We also built an entirely new SaaS product in a matter of weeks once the coronavirus pandemic hit, to help restaurants cope with a new world in which off-premise orders were their only revenue source. This product included a native app in both iOS and Android and a turnkey web-store experience.

But most importantly, we left Zume at our top. We experienced what a performant, self-organized, cross-functional, motivated, GSD team looks and feels like. I’m incredibly grateful for the chance I had to work with this exceptional group of engineers, designers, and PMs.

Here are some of my takeaways:

Lesson 1: Optimize to Learn

If I can impart one lesson for working in a startup, it would be this — optimize to learn. When you’re just starting, you’re making a ton of assumptions about the world, the market, potential customers, and what they want and need. Until you’ve reached product/market fit, insights that can help you validate or invalidate your assumptions are gold. Before you reach product/market fit, optimize to learn: stay very lean and agile, iterate quickly, try things, talk to customers, run surveys. Both qualitative and quantitative insights are valuable. Treat your initial product like a t-shirt you wear to paint your apartment that you don’t mind scrapping; it’s just a starting point to learning. Only begin to optimize for scale when you’ve reached product/market fit, not a moment earlier.

And even then, you may not be ready to scale. Product/market fit is merely “necessary”, but not sufficient, for scaling. The other key ingredient before scaling is “Business Model”. Product/market fit means your customer wants what you’re selling, but do you, the company, do well by selling it? At those prices?

Raising money from investors intensifies the pressure to scale. So knowing where you are on the product/market fit spectrum is crucial. Being able to withstand internal and external pressure to scale prematurely and being very intentional in how and on what you deploy your resources are also critical. These are disciplines that must be ingrained in the company’s culture early on.

Your level of confidence in the solution you’re implementing should dictate the amount of time and resources you devote to it. If your faith in the solution is high, you can spend more resources, both time and team. Executive or founder whims should not be the source of your confidence. It needs to be grounded. When you’re just starting out researching the problem and developing an initial solution, your confidence should be low, as should the number of resources you devote.

In Team Phoenix, we were very intentional in how we allocated resources depending on our confidence level of the proposed solution. We usually assigned one or two team members to research a new problem space and suggest solutions. The problem spaces themselves, by the way, were also surfaced and prioritized by the team. They could use any means at their disposal to better understand the problem and come up with a proposed solution. The proposed solution might be an additional experiment to gain more confidence. The more confident we became in the solution, the more resources we were willing to allocate until the work went from a “spike” (i.e., research phase) to actual implementation and became a “project.” We used this model for product questions, engineering questions, and general team process questions. This approach is also known as Hypothesis Driven Development.

Lesson 2: Sprinting does not make you Agile

Companies with software engineering teams that work with Scrum sprints often believe that, by doing so, it is “Agile.” While Scrum is indeed an Agile methodology, if the rest of the company hasn’t embraced Agile thinking, the fact that the engineers are sprinting is nearly meaningless.

Agile, at its core, is not a methodology but a set of principles and values. When those principles are understood, embraced, and upheld by both leadership and the teams on the ground, then the company stands a chance of being agile, nimble, and focused on real customer needs and can learn fast. When they are not, the scrum team is merely sprinting their step in a waterfall process. Running sprint retrospectives will help them improve as a team from sprint to sprint, but the company as a whole is likely slow to learn and will take much longer to find product/market fit.

Sprinting within a waterfall

Lesson 3: One team

A team should have all that it needs to understand the customer and their needs, conceptualize, design, build, deploy, and maintain the solution and, as necessary, measure its impact. The official Scrum Guide stresses this point clearly, “Scrum Teams are self-organizing and cross-functional… Cross-functional teams have all competencies needed to accomplish the work without depending on others, not part of the team.”

Putting together a cross-functional team is not enough. The team must feel like they own the product. They need to be empowered and coached to leave the safety of the office’s fluorescent lights, meet customers, understand their pain points, and design solutions together as a cross-functional team. Having product managers, designers, and engineers all understand the customer and work together on the solution is extremely important. Once the team agrees on a plan of action, each function can work in parallel, checking in frequently with the rest of the team to update on progress and to further coordinate.

Some of the work may need to be sequential, like product design before front-end development, but it is essential to think through the problem and solution together as one team. While individual members may have more expertise in some aspects of the solution than others, no one person should own the entire solution. Ultimately, the team is as strong as their collective ability to understand problem areas and develop exceptional solutions together, each contributing from their vantage point. Their individual ability to understand and respect each other’s craft, skills, and timetables and their ability to continually communicate and collaborate from start to finish is critical. It is what ultimately makes them a team as opposed to different stations on a factory line.

Stay Tuned

In future posts, I’ll explain how we shaped our product roadmap, created a self-organizing team culture, and formed a “SWAT Team” to handle on-call rotations and tech debt.

If you have any thoughts or questions on any of this, please feel free to comment below.