Building An Engineering Team May 2014

I’ve played the role of chief architect for three early-stage products where I was responsible for creating something out of nothing. These included being a founder, first engineer, and contractor. Two of these experiences were at fast-paced startups that had just raised one million dollar seed rounds. In these experiences I’ve learned a few things about how to build an initial product and an engineering team as well as what not to do.

Discovering The Scale & Complexity Of Your Product

At my first company we built a video analytics engine. If you think that sounds complicated, then you are right; it was. We started out building a initial product that worked great but didn’t scale. In most scenarios this would have been the perfect lean approach, but even our smallest viable paying customer would have needed to send us billions of data points per day in order justify paying for our product, so we decided to start over and rebuild our entire system at enterprise scale. We hired three top-notch engineers, dove into a big data approach with Java, Cassandra, Titan, and some exotic data structure implementations (mostly bloom filters). As uber-geeks, we found this to be a hell of a lot of fun, but it took the remainder of our million dollar investment and left us with no time to actually fit the product to customers. We needed at least one more solid iteration before we would have found our place in the market. We started the company aiming to tackle small companies, hobbyists, and bloggers as our target demographic but ended up pivoting and chasing the corporate world. If we had raised enough money and recognized that we were building enterprise software from the beginning, we might have been successful. Maybe. But we weren’t so lucky.

We suffered because we did not recognize the necessary complexity and scale of what we were building soon enough. It’s important to recognize enterprise software early enough on in a company’s lifespan to raise appropriate investment or to figure out how to make it into something that is smaller and leaner than enterprise software, which also requires even more time for testing your market to see what features they are willing to do without.

Hiring

Another point that can make or break a software project is hiring the initial team. Imagine that you’ve just raised a million dollars to build your company. You are excited. You can’t wait to finally build the team of your dreams and have real employees. It’s what a real company looks like, right? Careful! Hiring a bunch of employees quickly is likely to be a terrible mistake - especially if you are still figuring out how to define your product and your tech architecture. Every engineer has their own preferences for technologies and philosophies, so there is a lot of up-front time spent within the team figuring out how to work together and which tools to use. A lot of time will be spent debating architectural decisions and even more time spent scrapping and rebuilding entire components of the system as you make new technical discoveries or learn how your users actually interact with the software.

Component Ownership

It is important for each part of a system to be “owned” by an engineer so that they have full responsibility for its integrity, maintainability, and craftsmanship. Breaking a system down into components that can be owned takes time, and is best done by slowly adding new engineers to the project as components become well-defined enough to be broken off into separate modules that are own-able and maintable by a new team member. I’ve seen too many times where a bunch of engineers are added to a team at once and suddenly so much time is spent communicating and deciding that things actually start to take longer than if less people had done them in the first place. Brooks talks about this phenomenon extensively in the Mythical Man Month - see Brooks’ Law.

Discoveries

There are two types of discoveries that every new tech-driven company is going to make as it builds its first product.

The first type of discoveries are product discoveries - discoveries about what features the product should have and what minimum level of quality is necessary in order to enter the market as an acceptable product. An example would be discovering that your customers need multiple accounts to share a resource so that they don’t have to share a single account.

The second type of discoveries are technical discoveres. These are realizations about how the product should be built and scaled. For example, discovering that a relational database is not appropriate for modeling your data and that you instead need a distributed graph database.

Even if you understand your product and market perfectly from the beginning and make absolutely no mistakes about what features you need (which never happpens in the real world by the way), you will still make technical discoveries and get things wrong once and awhile. You will occasionally have to rebuild something or rewrite some code. This is inevitable.

It is important to understand what has been discovered and what has not been discovered. Of course you cannot know exactly what is left to be discovered, but you can certainly analyze the amount of unknown. You can ask questions:

When To Stay Small & When To Grow

If there is a lot left to be discovered then there will be constant changes as you adjust your product based on new information. Every time you make a discovery, your software architecture will change. You will have to add and remove features that affect every other part of the system. You will make breaking API changes and you will backtrack on what you once thought was progress.

As a startup, it’s important to make your way through this battlefield of discoveries as fast as possible so that you can get to the meat of the project and build the final iteration of your first version.

This battlefield is best navigated with a tiny team of just one or two engineers so that they can react to technical or market discoveries quickly without having to worry about interfering with the work that other team members are doing or breaking other people’s code. It is during this mysterious period of discovery and flux that a small team with minimal communication needs and a long financial runway is important. This is when it is time to save money and be agile. Only once you have made it through the worst of this constant change and the product is beginning to stabilize should you begin to grow your engineering team.


If you enjoyed this post (or if you hated it), send me an email at [email protected] and let me know what you thought. And feel free to follow me on Twitter to keep up with my latest publications :)