From Engineer to CEO - Year Three

Three lessons learned over the last year as I've transitioned from a software engineer to a CEO.

Around three years ago, I was a Staff Software Engineer at Namely, a New York SaaS for HR, Payroll, and Benefits. Today, I sit as the CEO for a 70+ person SaaS company called FireHydrant, a Series B reliability platform. I transitioned from head bobbing to music while writing code to writing emails and enthusiastically communicating our vision. I have a consistent desire to teach others all I can, and with this blog post, I want to give some key lessons I've learned in what has felt like a blink of an eye. There are three, and I've broken them up by year.

Year 1 - If the shoe fits, take it off

Our first purchase was a pull-out couch for my friend and co-founder Dylan to sleep on in my tiny one-bedroom Greenwich Village, NYC apartment in our first year. For the next several months, our life was to wake up, maybe go to the gym together, and write code. Daniel, the third co-founder, worked hard to build our infrastructure on Google Cloud, CI pipelines, and monitoring. All three of us have engineering minds and souls. A large chunk of FireHydrant that exists today was built in those long days between December 2018 and April 2019.

We had a rather substantial surface area in our product by April 2019. Our product enabled excellent incident management in Slack, simple retrospectives, and even integrated with Jira. In addition, it came with single sign on, credit card payments, a service catalog, change event tracking, and a few other nice integrations. We built a lot of great features in short order.

I'm sure you may assume that the lesson I will give here is "follow the lean startup method and ship tiny things fast!" Ship small and fast is undoubtedly sound generic advice. Instead, the lesson I learned is that it is wildly uncomfortable to put on another hat and change lanes in the business when you're very good at writing software. It's the same reason kids love watching the same movie over and over again, why we become regulars at local pubs, and why a Big Mac still hits the spot. We may not fear change, but all of us almost certainly love normalcy. I had been writing software for over 15 years before starting FireHydrant, so naturally, it was my norm. In many ways, it was also my identity.

I learned that you need to shake off your specialized skills the moment you've delivered what could be considered valuable. I've come to believe that people aren't avoiding shipping small things and iterating but more that they're just great at a particular skill. They forgo attempting to sell the great something they've painstakingly built because it's too damn fun to have carte blanche as a founder on your product.

Shifting your identity is not easy. FireHydrant was fortunate in that we had a great group of friends, investors, and former colleagues encouraging us to sell our damn product. I'm incredibly thankful for those who helped me shed my skin as a developer (although not entirely) and emerge as a young CEO with a lot to learn.

Year 2 - If you build it, they probably won't come

I'm a firm believer that developers are different when it comes to purchasing, frankly, anything. We viciously debate the best coffee, whiskey, keyboards, editors, languages, and then back to whiskey again (for good measure). In developer culture, it's common to research products and services in excruciating detail before concluding to purchase. Minor flaws, such as a dead link on the website, can convince a developer that the tool is not worth opening their wallet. I don't intend these observations to come across as a dig on developer culture; I'm guilty of many of them myself. I intend to articulate a simple truth: developers are picky.

I learned a harsh lesson that I need to remind myself daily in our second year: don't measure others with your ruler. I was angling FireHydrant to be the tool I wanted to buy from day one. It's the reason we supported credit card billing right at launch and had no sales team. I had a firm belief that if we built a fantastic product, developers would come and be as excited to use it as I was. I anticipated that others bought software the same way I did: I'll swiftly purchase it and implement it myself if I like it.

Indeed, not having a sales team earlier was a mistake. Since then, we have assembled an absolute world-class sales organization, and they impress me every day. There are several growth models that any startup can employ. Still, the reality is that I was measuring the market with my ruler, which prevented me from seeing a better alternative to growing our business: kick-ass sales. We needed a team of people whose sole job was to think about obtaining currency.

I encourage you to think about what assumptions you're making about your market and product based on your ruler. You might believe that everyone knows they even have a problem, to begin with, simply because you struggled with something so much. Maybe you assume people won't need customer success because you've always been able to figure out your problems. The subtly's of our assumptions can and will creep into our business, and I've learned to be mindful of my own. But be sure they're always an advantage and not a detriment, as our experiences are the crux behind us starting companies in the first place.

Year 3 - There's no such thing as a high performing family

I dislike when companies try to build a foundation for their teams on the idea of "family." As a CEO, my role is to chase our company vision with a great product and business and do it all with a great team. I've rarely encountered a family that I'd consider "high performing." On the other hand, teams should be aiming for high performance anytime they come together. You're a member of your family day in and day out, and there's no selection in most cases.

On the other hand, teams are selected and cultivated by both sides. Team members want to join, and you want them to join, and it's a mutually agreed-upon arrangement.

FireHydrant has, by definition, employees (73 at the time of writing). However, I seldom refer to people that work here as employees. Instead, I prefer to call everyone teammates because that's who they are. We wear the same jersey, play the same game together, and are all in this together no matter what department you are in at FireHydrant. We win together, and at times, we lose together.

The lesson here was an accidental discovery. I've worked for companies that attempted to create a family, and in almost every scenario, the "family" was dysfunctional. How do you give your family feedback? How do you hold a family member accountable? Societal norms prevent us from these necessary tactics when we operate as a family.

It would be best to build an organization that operates as a team. Building the company with the strict concept of "we are a team" will also be a forcing function for work/life balance. I have yet to see disadvantages to operating as a team at FireHydrant or other organizations in the past.

However, one other thought I'd like to offer is that sometimes members on that team become someone you'd consider family. FireHydrant has several members on its team that I believe are my closest friends and family. I've been to their weddings, traveled the world with them, and been there for challenging moments.

It's extremely fun to be a team member of a high-performing team that is continuously improving; I encourage you to build your organization with this in mind.

Recap

• Pay special attention to when you need to change lanes and hats because your previous identity will get in the way.

• Your ruler doesn't measure the same way when compared to others. Figure out others rulers and measure with those instead.

• Build a team, not a family. Families can't be high-performing. You all wear the same jersey.

What's next?

I've learned countless lessons over the last few years as the CEO of FireHydrant. But these three stand out as timeless ones that I can take anywhere and refer to anytime.

As a CEO, I'm interviewing for my job every day, and I expect the following chapters will be no different.