Why I Joined GrowthSync

One of my earliest experiences at a startup taught me a lesson I have been carrying around for years: the best software starts by understanding the operation underneath it.

Reflexive software

I learned this while working on the supply chain team at Local Kitchens. Local Kitchens was focused on building out ghost kitchens with the caveat of managing the entire operations stack. Rather than just leasing out kitchen space, Local Kitchens managed supply chain, kitchen operations, ordering, and a lot of the messy work around the kitchen itself.

The supply chain was a notoriously difficult problem to solve. Getting a clear understanding of what was actually spent on supplies versus what was theoretically spent helped the team understand operational efficiency and waste. A major dependency here was inventory. To make those calculations useful, you first needed a clear idea of what was actually on hand.

I asked how people took inventory, and it turned out there was no app that made it easy to walk around and fill everything out. It was a combination of Excel, pen and paper, and whatever local system each kitchen had developed. Then teams would order based on that. It was hard to track inventory over time, hard to reproduce, and hard to keep consistent.

I immediately jumped in and scoped out a one-month sprint to build a mobile-responsive web app that people could carry around while taking inventory.

It was a smashing success. The person I was working closely with said they were easily able to write the inventory down in the app. There were some small UI things to fix, but overall it worked.

And then we looked at the impact.

We were not getting a more accurate understanding of inventory. It was not faster. It technically worked as an app to track inventory, but it did not actually solve the problem. I was a hammer and thought every problem was a nail.

It turned out every kitchen had a different system for organization. SKUs were not ordered consistently across locations. So it did not matter how snappy the app was. If you did not clearly understand where something was located, the app could not solve the problem.

We needed to solve the layer below the technology. You cannot just jump to a product solution, particularly with operational problems. You have to take a step back and truly understand the problem.

Put your ego aside. The solution may not involve product at all.

Operational product engineering

That experience gave me a deep appreciation for a different type of problem solving. Sometimes it is called product engineering, which usually means understanding the use case and the space before jumping in. But in operations-heavy domains, where there are concrete items being sold, physical movements happening, and tangible work being done, I think you need to go one click deeper.

You need one more layer of abstraction. You need to look at the business problem and first think as an operator.

What I have noticed about the best operators is that they do not focus on solutions too quickly. They first focus on empathetically understanding the problem. They do not rush to judgment. They start with very little ego and act like a sponge, soaking up as much information about the domain and problem space as possible.

They are not thinking about product solutions, apps, spreadsheets, or anything else yet. They are acting as a student in a class with many teachers. Those teachers are the people doing the work day to day. They can openly explain the problems they face because they are just explaining the nuts and bolts of their normal work.

Only then should you start to think through the core underlying problems. Are there systems in place? If not, why? If yes, are those systems working? Are people being put in a position to succeed?

It is an extremely cross-functional form of product engineering. It is one I found very interesting to work on, and one I knew I eventually wanted to get back to.

Since then

I spent the years that followed building in completely different domains. The work was challenging and interesting. I learned an enormous amount. But somewhere along the way I realized I was missing something I could not quite name.

It was not until I sat down with Mike and Rod that I figured out what it was.

What I found

Clothing brands, CPG brands, and small businesses are juggling a lot. Sales tracking, marketing, supply management, customer support, all at the same time. Many are working with lean, scrappy teams, and it can feel like a lot to manage.

But what I have learned from working in operations-heavy domains is that these are not insurmountable problems. They are a series of concrete, tangible problems that need to be understood and solved one at a time. That is the type of problem that gets me excited to help solve.

In my first calls with Mike and Rod, there were moments where they talked about the struggles brands were having. When they mentioned inventory, I found myself getting excited without fully knowing why. Every time there was another layer of complexity, I became more interested in the space.

Rather than thinking about software and adding lines to a codebase, I was envisioning actually being in the warehouses. I was not thinking about Kubernetes. I was thinking about how a sales team manages its pipeline. I started getting that feeling of solving physical, tangible problems again.

Mike and Rod made me feel extremely excited to be a student again. I could go back and learn how brands operate their entire businesses. I could learn from operators across completely different businesses. That variety was its own kind of education.

The culture mattered too

Something that also stuck out to me was the level of ownership across the team. Everyone held themselves to extremely high standards.

After I decided to join, Mike posted something on LinkedIn that put words to exactly what I had felt. He wrote about always saying "we" and only switching to "I" when something broke. "Fall on the sword yourself. Celebrate with the team." I was not surprised when I read it. It was exactly what I had felt in the room.

It was clear that this was a team where everyone held themselves to that same standard. When that becomes the culture, it compounds. Wins feel collective. Losses get owned and fixed by individuals rather than deflected. It does not matter what your title is. Everyone operates that way, and it acts as a multiplier across the entire team.

That is a great kind of team to be a part of. I wanted to jump in.

What I get to build now

I have spent a lot of time in my career thinking about what types of problems I want to work on and what types of people I want to work with. Rarely do both answers show up at the same time. With GrowthSync, they did.

I get to work on tangible, complex operational problems alongside a team that holds itself to an extremely high standard. I get to talk to operators, learn from them, and build for them. That is exactly the kind of work I wanted to do next.

If you are a brand operator trying to turn messy Instagram demand into clearer workflows, cleaner customer context, and revenue action, start with GrowthSync here.

Sources