My two co-founders and I started Gusto with a mission to make payroll, benefits, and HR easier for small businesses. Tomer, Josh, and I founded the company from the master bedroom of a house in Palo Alto with nothing more than a vision for the future and a commitment to do whatever it takes to turn it into a reality.

Six years later, we’re serving more than 60,000 small businesses (over 1% of all employers in the United States), employing more than 600 people (including around 100 engineers), and together, we’ve achieved a valuation of more than one billion dollars.

I regularly hold office hours at Gusto where any engineer can stop by and ask me whatever they want. One question I sometimes get is: As the CTO and co-founder of the company, how has your role changed?

1. 1 Engineer: Nerd in a garage, er, closet.

When we first got started, I was living in San Francisco and my two co-founders were living together in a house in Palo Alto. I thought it was important for us to live together while we built our first prototype (we were all single at the time). Unfortunately, there were no more bedrooms that I could rent, but there was a fairly large walk-in closet in the master bedroom. After convincing all the tenants in the house to let me rent the closet for $300/month, I borrowed a friend’s air mattress, packed my bags, and moved in.

I was the CTO, but at that stage of a company, it felt silly to say that because there isn’t really anything to be the “chief” of. Software Engineer better described my role. I was learning as much as I could about the convoluted payroll system and how the ACH system works while simultaneously coding 12-14 hours a day with headphones on — and it was awesome. The only meetings on my calendar were breaks for lunch, dinner, and going to the gym to exercise. Our goal during this period? To build a payroll backend system so that we could start paying ourselves with it.

2. 2-10 Engineers: One team, one dream.

After getting a basic payroll system (California-only) running and closing a seed funding round, we moved to a loft apartment in San Francisco and I shifted from coding 90% of the time to coding 60% of the time. The remainder of my time was spent sourcing, interviewing, and closing engineers. Many things have changed in my role as a CTO, but the time spent recruiting has always been consistent (and probably always will be). From this point on, I’ve always spent about 30-40% of my time recruiting.

Being a player-coach

Once we hired a few engineers, I went from being the only full-time developer to working in a small team of developers. I still spent a significant amount of time coding, code reviewing, and fixing bugs, but I would occasionally take my headphones off to explain to the team how ACH works or to make a call on if we should start the practice of code reviewing. If there was anything I could do to preserve maker timefor the other engineers — like buy and configure a computer to run our CI pipelines — I would do it. Things like 1-on-1s, sprint planning, and daily standups started creeping onto my calendar. I had engineers reporting to me, but for the most part, there wasn’t a hierarchy and it still felt like a group of peers coding together in a room.

During this period, the media embargo launching Gusto (then ZenPayroll) was lifted and after pulling an all-nighter, the engineering team nervously monitored server logs and refreshed the page to make sure our Linode servers would survive being “Techcrunch’d.”

3. 11-50 Engineers: Clinging to coding.

On the heels of our company acquiring customers rapidly and raising a Series A, I found myself with a team of more than 10 engineers. Coordinating work across all these engineers became more difficult. In addition to size, the tenure of some of the early engineers required me to make our engineering organization more structured. For example, some of our engineers who had been working at Gusto for nearly two years were starting to ask about a compensation framework and what career progression within Gusto would look like. To be honest, I hadn’t given these topics the amount of thought they deserved.

At the same time, despite the larger team, there was still a never-ending list of features to ship and bugs to fix. I probably still had the most intimate knowledge of our codebase, so when a problem arose or a feature needed to be shipped, it was incredibly tempting for me to just jump in the code and fix it. More often than not, that’s exactly what I did.

A trip to New York

In 2015, I knew that I needed to step away from coding and dedicate more time to being a good people manger. To accomplish this, I decided to fly to New York to hole up in a hotel room for three days to read a few highly-recommended management books. On my flight there, I thought there wouldn’t be any harm in coding a new payroll feature — I’d have three full days once I landed to focus on my reading, after all. Boy, was I wrong. When I landed, I felt the implacable urge to finish the feature in its entirety. By the end of the three days, I had only read a very small fraction of the books and I failed miserably at my goal to dedicate more time to people management.

There were only so many hours in the day and juggling both people management (at Gusto, we call it “People Empowerment”) and individual contributor responsibilities was incredibly hard. As a lover of coding, I naturally tended to finish that last feature and punt on the people management topics until a little later. To me, the code issues always felt more urgent. On top of that, I struggled with a deep sense of guilt about not doing my part.

When I did get around to the people management topics, I didn’t spend as much time on it to deliver the same quality as I did with my code. My team wobbled a little bit as a result and I likely did more harm than good by trying to not give up coding.

The binary choice you must make

At this point, I believe technical co-founders have a binary choice: Stay on the technical track and hire a professional manager (usually given the VP of Engineering title), or give up coding and focus on the management aspects yourself. It really isn’t possible to do both.

I decided to focus on growing Gusto’s engineering team, and not our code. The technical books on my desk starting getting replaced with books like Mindset, High Output Management, and The Score Takes Care of Itself — still three of my favorites today. Mindset was critical to helping me prepare myself mentally for the personal journey ahead. High Output Management helped me to learn many of the processes behind managing teams. The Score Takes Care of Itself taught me how to go beyond management and also be an inspirational leader.

Learning and applying those lessons while resisting the temptation to code was an incredibly hard transition for me, but one that was necessary to scale the engineering team in a healthy way.

4. 51-100 Engineers: Embracing a new role.

By the time we reached around 50 engineers, I was spending 60% of my time being the best manager I possibly could to my direct reports, and training other engineering managers in the team to do the same. The remaining 40% of my time was spent recruiting.

The better I got at people management responsibilities, the more I enjoyed it. I would spend time on things like improving engineering onboarding, managing performance, diversity and inclusion, culture, change management, and putting processes in place for big projects like balancing technical debt. The only time that I would code would be during our semi-annual hackathons.

Loving my new role

Not everything I do now is enjoyable at the moment in time that I’m doing it. Being in meetings all day still sucks, and having difficult conversations with individuals is never fun. Nevertheless, I’ve really come to embrace my new role in the company. For example, I spent several weeks negotiating a plan for us move more code ownership of our payroll domain to Denver. Some of those meetings were pretty long and tough, but as a result of that work, we now have a rapidly-growing Denver engineering team that I’m extremely proud of.

My enjoyment now comes less from the things I do myself and more from the impact that I helped others to have. Sometimes you only see this after some time has passed, so you derive satisfaction by learning to look at things on a much broader time horizon.

5. 100-250 Engineers

What happens next? The next chapter will require scaling our engineering team even more while maintaining the same level of quality as we’ve had in the past. This means hiring, growing, and retaining talent will remain the most important part of my role (p.s. We’re hiring!). For me, I’m committed to doing this in a way that we’re proud of by building a diverse and vibrant environment where we can do our best work. If there’s one thing that I’ve learned from a fast-growing startup, it’s that change is the one constant — and I’m excited to see what the future holds.

Thanks to Kirill Klimuk and Vaibhav Mallya for nudging me to write this