Jump to job: Tock (2019 - 2023) | SwipeSense (2016 - 2019) | Syndio (2011 - 2016)
I've been building software professionally since 2011. Here's a walkthrough of my career. For a quicker overview, check out my LinkedIn or resumé.
Most of my experience has been building B2B SaaS. I've worked on software used by all types of businesses, ranging from small restaurants to huge Fortune 500 companies.
I love being involved with all aspects of product development, from the early design stages, to coding, to monitoring usage and iterating until a feature has the intended outcome. I've mostly worked on small teams where everybody has the chance to take ownership and think like an architect.
I especially love solving problems faced by SaaS companies who have started to see product-market fit and are experiencing rapid growth. At previous roles, I've spent a lot of time balancing trade-offs between the short-term needs of existing customers and the long-term needs of a growing product.
If you're here, you might be thinking of hiring me. You may have seen hundreds of resumés from other engineers. And let's be real... most of them look pretty similar to each other. It's impossible to distill over a decade of experience into bullet points on a PDF.
This page will walk you through my career with a little more depth.
My most recent full-time job was at Tock, where I mostly worked on the business-facing application that gets used daily by restaurant owners and staff. I was an engineering manager for about a year, and spent the rest of the time as an IC.
I joined the company when it was a startup that had just started to see product-market fit, around 50 employees and 12 engineers. I was there through the entire growth phase as well as their transition into becoming part of a public company.
You know how when you check into a restaurant, the host has an iPad where they can see all the tables and reservations before deciding where to seat you? Chances are, you might have seen them use the application I worked on.
But simply seeing a floor plan of tables and a list of reservations is just the tip of the iceberg. There's a whole world of complexity that goes into running a restaurant. especially "fine-dining" establishments that want precise control over the guest experience.
Distilling that complexity down into easy-to-use software that can scale to tens of thousands of restaurants and millions of diners was a big part of my job.
Here's the most impactful project I worked on.
Picture this. You're running a high-end restaurant with 100 tables. You want to offer nightly dinner reservations. Your restaurant is open later on weekends, and is closed on Mondays. You want to fill tables as much as possible, but you don't want to overbook your reservations and make diners wait for a table.
Seems pretty simple on the surface, right? But wait. Let's dive into this a bit more and think about some of the rules and constraints you need to configure:
- The average party of 2 stays for 90 minutes, but the average party of 6 stays for 3 hours.
- You don't want to overwhelm your servers and kitchen staff, so you need to make sure your reservations are somewhat evenly distributed. You can't have everyone showing up at exactly 7pm.
- Some small tables can only seat 1-2 people. Some large tables can accommodate parties up to 12, but you don't want parties smaller than 6 reserving those tables. Some smaller tables can be pushed together to make a larger table, while some cannot.
- Most of your tables, anyone can book for free. But for the better ones, you want to charge a $10 deposit to ensure people actually show up. And the best tables? You want to charge for the meal ahead of time to completely eliminate no-shows.
- In the summer, you open up your patio and increase your overall table capacity. On weekends, those patio tables are in extremely high demand, so you can charge a premium to reserve them.
- Certain tables should be reserved for VIPs and friends of the staff, and therefore cannot be booked by the public. But if nobody has booked them 6 hours before dinner, they should automatically go into the pool of publicly available reservations.
- ... and many more.
Hopefully, this gives you an idea of how complex reservation and table management at a restaurant can get.
When I joined the company, we had many of these features, but it was not self-serve. All the configuration was pieced together for each restaurant by our internal staff. If a restaurant wanted to make a change to any of these settings, they had to reach out to customer support. This didn't scale well, and led to extremely high onboarding and support costs.
I was the engineering lead on the project that wrangled all this complexity into a set of tools that empowered our restaurant partners to manage their own configurations.
I was involved in every bit of this process, from nailing down the (constantly changing) requirements, to iterating with our designers on a UI that was feasible to build, to monitoring usage and making improvements over the years.
A large part of this project involved designing a data model that was compatible with both our future requirements and the configuration data we had for our existing restaurant customers. In some cases where the existing data was incompatible with the new model, we build tools for restaurant owners to see these incompatibilities and make decisions about how to migrate their configurations.
This project was a resounding success. Onboarding time for new customers was cut down by months due to the drastic decrease in back-and-forth communication needed to set up a new restaurant. The customer support burden also went down significantly because restaurants were empowered to make their own changes, which made our customers happier as well.