Building an Organization From the Ground Up

Problem

A few years ago, I joined a startup started by two of my former colleagues and the CEO who was funding the new venture. We had to build everything from the ground up. While building things from scratch is never easy, it is also an exciting opportunity for engineering leaders to help start greenfield projects. In that regard, the two largest challenges we faced were:

• We had to quickly scale our product up, attract users, and generate marketplace transactions on our platform;
• We had to grow the engineering team.
  

Since I was the first engineer on the team, it was on me to decide on technical foundations: architecture that will scale, what programming languages we will use, what our development process will look like, how we will develop our engineering culture, etc. I had to figure out how to set our processes agile while being the most productive and bringing the biggest ROI.

Actions taken

I spent considerable time with the CEO and heads of Product and Marketing to create a solid MVP that would allow us to go to market and raise more funds. We explored a myriad of scenarios deliberating over what would be our first foot out and how best to position ourselves.

I also had to expand my understanding of the new domain. Our startup was into the mom-and-pop gardening space, which was all new to me. I personally like gardening, but I had to familiarize myself with the terminology and naming conventions ranging from growing zones, types of soil, and fertilizers to different kinds of plants that could be raised. Learning about the domain helped me better connect with the market’s supply side and understand how they run their businesses and deal with challenges. I spent a lot of time visiting nurseries and talking to owners and employees, absorbing what they did and cared about.

That gave us a foundation in terms of the design and features our MVP should have. Once we had that, we had to figure out how to bring Engineering and Product to collaborate. We had to choose infrastructure, cloud service provider, and programming language, and that took some time. Overall, we had to balance speed with being productive and coming up with the best solution. We also knew that some of our decisions were not permanent, bearing in mind how fast we wanted to move.

One of those decisions was build vs. buy. We were a small team and had to ensure that all our integrations fit together -- from inventory management, payments to delivery service. It was important to differentiate what we could buy and leverage the existing solutions and what would be the core of our business that we should build in-house. Finally, we started to hire, looking for people who could help us achieve our goal and scale up the organization.

One of the main challenges we faced was that there was no centralized place to obtain data. We reached out to the US Department of Agriculture and UC Davis College of Agriculture, but none had the data we needed. We had to look for different data sources and bring them in one place -- our platform -- and structure that information so we could share it with our users. It was quite time-consuming; once we completed the research, we had to figure out how to bring that data, either by paying for it or through some free service, which was both an operational and engineering challenge. In the end, we decided to go with the divide and conquer approach. Our product and marketing team were tasked to establish contact with organizations that had data, and my team was responsible for getting the data in. Some of the data were available in simple CSV files, others in some legacy database on-prem, while the third had APIs. So, I had to operationalize that aspect of integration, which took some more months.

Once we got data, it was much easier to put it on our platform for consumers to look it up across different growing zones or attributes of plants. We were able to share that with local mom-and-pop nurseries. We were able to augment their inventory with our data and help provide a more comprehensive buying experience for consumers. That directly translated into a number of transactions we were able to generate on our platform.

As an organization, as soon as we became more operational, we needed more help and started to look for engineers as well as data analysts to join our team. With family and friends funding, it was difficult to attract top talent and pay for their salaries. We expanded the horizon of our search outside of the Bay Area to include South America as well. In a span of three months, we grew from a one-person engineering team to nine people. We grew from four people when we started out to 17, 18 people in three months. We grew significantly and had to focus on internal processes: how we do our releases, how we write our stories, how we do our QA, etc. It went through several iterations in the vein of best agile practices. As more people were joining, we were able to remove some bottlenecks resulting from being understaffed.

Lessons learned

• Be aware of all the consequences of rapid growth. We grew up quickly, knowing that we had a good amount of transactions happening on our platform and that more nurseries were joining us. But we were short going to the VC rounds. Balance risk with reward. Strike the balance of growing the team with a number of transactions. You don’t want the hiring to grow disproportionately in comparison to the transactions.
• Having the right MVP is critical. Don’t over-engineer; build the right amount of features that users are going to use. In the early stages, do what is required to run your transactions, get VCs interested, and meet your metrics. Don’t add features that could be or would be used. That will come to bite you later on.
• In startups, things can go south rapidly, so being a bit cautious is always recommendable. That is anything but easy since building things from scratch carries enthusiasm that is hard to contain.