21 Oct 22

Your company is not Facebook or Google, don't borrow their slogans!


Lead Engineer - 2012 - 2016

At Kenna Security, I joined as the first full-time software engineer. Employee number 5. There were two other people contributing to the codebase already, but engineering was not their full-time responsibility.

During my time, the company grew in every way possible. We graduated from our temporary co-working space to our meager, but official office space. We grew the engineering team. We moved from a data center to the cloud. We hired a sales team. We opened a San Francisco office. We even hired a new CEO (twice).

BUT, we were not Facebook or Google. We moved fast because we were small. But we didn't break things, because we had customers. Customers that paid for our services.


Our task was to offer a service that security practioners could use to improve their security posture. Our competition was Excel. Like I said, we were not Facebook or Google. We were niche and developing a product not a platform.

A given with the task was to create a solid foundation that features could be solidly developed on. And once established, hire a competent team that could develop, deliver, and maintain features.


My role was two fold. I helped established the foundation of the product from a technical point of view. I started as an engineer and became our lead engineer. I/we made some mistakes along the way, but we quickly recovered or pivoted.

We implemented Elasticsearch before it was even at a 1.0 release. We ran into situations their support team didn't have solutions for. I implemented an OAuth solution for single sign on for our largest partner–Dell Secureworks.

Once the app foundation was in place, I was directly responsible for hiring engineers. I conducted almost every interview. I did phone screens. I did in-person interviews. I recruited. I helped decide when we were ready to support bringing on the first junior engineer.

As the team grew, I helped establish process and culture. I spent a lot of time in Pivotal building a healthy backlog. I helped establish a pattern of developing on remote EC2 instances that could be shared to demo features. This was a little ahead of its time, but it really helped us accelerate onboarding.


In the end, the engineering team was more than 13 when my time came to an end. It included seniors, juniors and qa engineers. The customer base grew from a few beta testers to over 100 paying companies. We had a solid partnership with Dell Secureworks.

The foundation of Rails, MySQL, and Elasticsearch stood the test of time and remained in place. Ultimately, the company was sold to Cisco.


What could have gone better? / What would you do differently?

We could have done a number of things differently. One of which was break outthe key scanner data import process from the monolith. That pattern proved to·be inflexible. We lost some data more than once.

We could have held off on hiring our first sales team until the product was alittle more mature. We could have built out a more formal roadmap andestablished our engineering needs around it. In general, we were founder leadrather than Product lead.

When the founder decided to hire a CEO to help with funding, we could have not·hired the first peson we hired. He was a big mistake. Little did we know, he·was trying to be a CEO at another company during this time and was only going·to work for us half the time. Glaring oversight. Don't assume people are·forthcoming. Quickly recover as soon as you discover these things.

Could you have gotten the same results with half the budget?

In regards to our use of Elasticsearch, absolutely. Like I said prior, theirsupport team was still in their infancy and couldn't help much.

We could have postponed hiring an expensive sales team. We could have spent moretime on building a healthy backlog of items that didn't require senior engineersto implement. This would have required less feature development in the middlestages and more planning and process. We moved fast developing features which wehad the ability to do, but we didn't exactly measure if the features weresuccessful. Ultimately, we could have measured in order to determine if thebudget in engineering time and actual cash money was being well spent.