Anyone who works at a tech company will tell you the same thing: the cogs in the SaaS machine don’t turn without a fleet of talented and devoted software engineers. And Privy’s Engineering team is certainly no exception. Our engineers are the architects behind Privy’s product, which millions of people interact with on the daily (no pressure, guys), from onsite displays to our admin dashboard.

The functionality and health of our software are in their hands, so naturally, a kick-ass Engineering leader is key. Fortunately for us, we’ve had our VP of Engineering (and Ruby on Rails guru), Peter Cai on the squad since early 2015.

We sat down with Peter to crack the surface of our growing Engineering team (we’re hiring!), why they love developing Privy’s software, the challenges they face, and their motivation to keep on keeping on.

Let’s start simple. What brought you to Privy in the first place?

Truthfully, it was our CEO, Ben. He had a compelling vision for what he wanted to do: empower small businesses. It was a small company (4 people at the time), so there was a lot of potential.

What problems are you solving with Privy’s technology?

We are getting to a point where the cost and complexity of software is low enough that we have the opportunity to bring products to small and mid-sized businesses that were previously only available at an enterprise level. Our product can provide both onsite personalization and targeted email marketing to mom-and-pop stores and small ecommerce merchants that previously were cobbling together their own solutions or making do with what was available. Traditionally, this market was really underserved. And having a solution all in one codebase has been a really big boon.

All in one codebase?

Imagine a brand new ecommerce merchant, who just opened their online store. We can add a ton of value quickly with our product, even though it is the earliest stages of their business. They are open to new things by definition.

On the other end of the spectrum, imagine these more established, mid-market merchants who are growing brands or thriving family businesses. We can add a ton of value here as well, even though they aren’t going to fundamentally change the way their business works to use our software - our software has to suit how the business works.

It’s interesting that we have both of these types of customers using the same product with the same features, on the same codebase, where previously it would have been difficult to imagine that because of their different needs and the complexity of meeting those different needs - even the way the software might’ve been delivered was different. Today when we release a new feature, all 400,000 merchants on our platform benefit from it. That’s an enormous amount of leverage.

What is the next big step for the team?

We have been experimenting with splitting into sub-teams so that we can have small, independent squads working on different things. We wanted to divide them in a way that allows the team to be productive without having to coordinate across groups too much. We also don’t want two teams simultaneously reinventing the same wheel, so it’s a balancing act to make sure that they are synchronized enough to be efficient and not duplicate the work.

How do you find that balance?

I don’t have a great answer to that yet, but I know there are antipatterns we need to avoid. For example, we need to be able to easily push out data from our sub-teams; if a team has a meeting, those notes should be available to anyone who is curious, without having to ask or dig. Embracing transparency and openness in the sub-teams is critical.

What were some of the biggest challenges you faced when you were hired 4 years ago?

Managing rapid change was especially hard because we had paying customers the whole time. At one point early on, we were simultaneously pivoting from a brick-and-mortar focused marketing solution to one that was purely ecommerce, and changing our business model from “direct sold enterprise deals” to “self-serve with a free tier.” It was a big challenge trying to serve two masters at once: we had customers on the old model that were used to having things work a certain way, but we were quickly evolving to enter our new market and wanted to move fast and test a lot of hypotheses.

Personally, striking a balance between being a regular member of the team and providing leadership and support was tough. I wanted to support the team but be cognizant of letting people make their own mistakes and have teachable moments.

How did you guys overcome all of that, what kept you all together?

Mostly, openness to new ideas and information. Initially, I joined thinking that we already had a market-tested product, and that it was going to be my job to build it out, add more features to it, and deliver it to customers.

It quickly became apparent that we instead had to build a totally new product and validate it in the market. We were testing so many things and learning so quickly during those days, it wouldn’t have worked unless every one of us was open to changing our minds about almost anything, which we did, all the time.

How does your team set goals at this point? What drives employees to deliver?

Our team sets goals for itself by drawing from the company’s goals. Our company was very engineering-first and engineering-heavy early on, so we’re used to always being close to customers. We often work with the support team on tickets, so that we can understand what customers really want from our product. It’s always a good reminder when we’re building features that we aren’t just writing code - we are solving real problems, and helping real people.