Journey From Founding Engineer to Founder: Being Honest About What You Don’t Have

shutterstock_103557563.jpg

One developer turned founder gives insight on how she made the transition from one role to three roles.

By Poornima Vijayashanker (Founder, BizeeBee and Femgineer)

A little over 4 years ago, I decided to transition from being a founding engineer to a founder. I knew that I could build a product and recruit a team I had learned those skills at my first startup, Mint.com. But I was really curious to know what it was like to be a founder. I wanted to build a company and a business.

Most recently I’ve met many engineers out there who are contemplating this transition, and maybe filled with enthusiasm and some anxiety. I know I’ve been there. This is the primary reason why I want to share what I’ve learned with them.

Not Trading One Role for Another

I had a misconception that going from being a founding engineer to a founder would mean trading one role for another. After all how hard could it be to be an founder? Most don’t even write code after a while!

It wasn’t until about nine months into my first year, at my startup BizeeBee, that I realized how much harder it is to be a founder. But it wasn’t until I read the book the E-Myth by Michael Gerber that I realized that it was natural.

In the E-Myth, Gerber talks about how as a founder you’re not trading one role in for another, but really one role for three!

As a founding engineer you care about the product, refining it, and shipping it consistently. Your scope of work is pretty well defined and limited. You might think this is a lot, but it’s actually not compared to a founder’s job.

As a founder you have three roles. The first is being the technical mind being the initial product. The second is the manager who recruits additional talent to continue to build the product. The third is the visionary who charts the course for where the company is headed.

A founding engineer gets a pat on the back for shipping high quality product and equity.

A founder gets all the blame and praise for what is shipped and hopefully a nice pay day. But that is elusive and using that as motivation is a recipe for disaster. True motivation is seeing your product come to life and witnessing how it benefits customers.

Its this praise and blame causes some founders who are engineers to think they need to be in control of it all. One problem that too often arises from this is that they think they can just keep doing the technical work, but if they truly want their company to succeed they’ve got to learn to transition through these three roles and find balance between the second and third. It doesn’t mean that they cannot still provide technical direction, they can, they just shouldn’t expect to keep their hands in the code base indefinitely.

If their goal is to be technical, then they’ve got think about hiring a CEO or a business founder to take over, so that they can focus on what they love to do: technical work.

Many founders do decide against hiring a CEO because they want to have the freedom to set the vision for the company. They want to see the product built based on their vision, set the tone for the company culture, and stay connected to their customers. These are some of the reasons why they chose to transition than continuing to build a product.

For myself, it was really important to have control over the product vision. I also knew the market really well. Hence in year two I decided to promote one of my engineers to the role of my technical founder, rather than hiring a business co-founder. He had stronger technical skills than me, and I wanted to give him the freedom and resources to continue to cultivate those.

Filling In the Gaps

Whether you’re back-end, front-end or even a designer, there are going to be skill gaps and holes in your knowledge. I have yet to come across someone who built an end-to-end product completely on their own!

Most use a combination of off-the-shelf tools and products to get the job done, will partner up with other engineers and designers, or learn how to do work that they don’t know how to do.

I am a back-end engineer. When I started building on my own the first thing I did was transition from Java to Rails, because I knew setup would be a cinch! At the time, I figured it was THE framework for building a web product end-to-end. I had also seen how the Rails community had grown over the years, and knew that it was active, so if I needed any help, I’d know where to find it.

For things that I didn’t know how to do, I decided that my time would be better spent using an off-the-shelf tool or hiring someone else who was capable. Mind you I had the capital to do this. If you don’t then you might instead decide to learn.

Not having a devops background, I decided to use Heroku to manage deployment and the database infrastructure. I also met and talked to the Heroku team to understand how I would be able to scale if I needed to, and putting on my founder hat, made sure that the cost to doing this would be much less than hiring a devops guy and using Amazon web services.

When it came to front-end and design work, I hired a couple contracts, because it’s not my forte.

As an engineer I never really believed in having a QA team, I have always believed in TDD (test driven development). As an entrepreneur I saw having a QA team as a huge cost: additional employees.

The previous companies I had worked at always hired QA engineers. With my own product, I knew I had the freedom to do things differently, I could put in place my own process for building product!

Part of that process was to use TDD.

In the end, factoring in cost along with the desire to hold my own engineering team accountable for the quality of the code base, led to a higher quality product. This translated to saving when it came to customer support as well!

There were additional processes I wanted to put in place, like continuous integration and continuous deployment. But in the beginning it didn’t make sense. I didn’t have a lot of customers or a big enough team to demand putting in that much infrastructure. So I took the low-tech approach: picking an odd time to do the deploy, letting customer know via email, and taking down the entire site to do it. When it became a need, my team and I transitioned to using CircleCI.

Eventually, I did run into some hiccups. The first was when my designer left. My team was growing and we were getting ready to build our second product.

At this point, Twitter Bootstrap was becoming really popular. Engineers were using it to build products. So I decided to use that instead of hiring a designer in house. This was another huge cost savings for my scrappy little startup.

Ultimately, it took me about a year to build a product with a very small team, and get it out into the hands of a handful of customers who started paying for it immediately. Knowing that I was capable of building something end-to-end was a huge milestone for me.

If you’re curious to know what life was like for me as a founding engineer, check out this series of blog post I put out during the Mint.com acquisition.

If you're a founder, what was something you had to delegate or hire out?

This post originally appeared on Femgineer. Image: Poornima Vijayashanker About the guest blogger: Poornima Vijayashanker is the founder of BizeeBee, a platform that helps membership based businesses drive growth. She is the founding engineer at Mint.com, has launched Femgineer, a company that helps entrepreneurs level up their careers and is one of Inc Magazine’s ’10 Women to Watch’ in tech.