I quit. After about three years in a high growth tech startup I have decided to move on. In that timespan I saw the company grow from about 30 employees to almost 200. While I know this isn’t the fastest growing startup ever, it definitely qualifies as ‘high growth’ in my book.

There are some lessons learned that I would like to impart on other software leaders who are entering this type of environment. While I had worked in many startups before, I found very different challenges in high growth vs. other operating modes.

Lesson #1 – Startup != High Growth

This was my fourth startup company and I had thought I knew what I was getting myself into. I knew how to build products from early stages and some of the challenges of initial production launch. I knew how to execute within very tight resource constraints (budget, people, time, etc.).

The above describes a startup and not necessarily a high growth startup, which is a different type of beast. Under high growth, you are effectively operating with unlimited cash resources. The enemy is time, not money.

While most startups reduce scope (i.e. Lean Startup style) to fit within budget and time constraints, high growth startups tend to keep scope fixed. This large product scope (i.e. vision) is what attracts such large VC investments in the first place.

For example, under high growth I was able to hire anyone I wanted. In fact I needed to grow my team as quickly as possible. Also, I could purchase anything I wanted. A $1M purchase was not considered a major spending decision. On the other hand, our launch date was fixed. We committed to the board and had to figure out a way to get it done.

The lesson here is know what type of environment you are entering, startup or high growth startup.

Lesson #2 – Establish thoughtful processes and tools as quickly as possible

It is so much easier to roll out a new process or tool when the team size is smaller. You just raised your Series X round of funding and know your team is going to expand massively. Don’t put off establishing baseline processes for your group.

Some basics that we benefited from rolling out as quickly as possible:

Bug Triage (including mechanism for assessing issue severity/priority)
Feature Prioritization / Planning
Branching + Tagging Policy
Software Release Process
Peer Review Process and Style Conventions
Software Test Strategy

It’s fine if these are all a work in progress. Create a simple wiki page that documents the current process and have the team identify areas for improvement. Get written documentation ingrained into the culture.

If you need to coordinate between multiple groups, define the interfaces and handoff mechanisms between the groups in writing, especially if these groups are not colocated.

Also, take advantage of modern tools. We used the Atlassian suite of tools, including Jira, Confluence, and Bitbucket. We liked how the tools integrated together. That worked for us. These tools should be rolled out to the entire company as quickly as possible. Be sure to establish a single messaging tool (e.g. Slack, Skype, etc.) that everyone is on.

Lesson #3 – Protect your team from the chaos

A high growth company is by definition going to be chaotic. I liked to think of my role as creating a protective bubble around my team that would shield them from some of this chaos.

Some important aspects to this are:

Define/document how outside groups interact with your team. How are features requested and prioritized? What is the development cadence? What are the specific roles and responsibilities of your team? Is this all captured on a public wiki?
Demonstrate gratitude. It’s very easy to get caught up in delivering a feature and then immediately moving on to the next one. As the leader you need to be able to take a step back and acknowledge what the team has accomplished. Recognize these achievements in public, even if it’s in a standup, slack channel, etc. Let your team know that you appreciate their hard work.
Don’t burn them out. There will be times when you need to push them hard. However, as the leader it’s your job to ensure that you are only committing your team to what is reasonable achievable.
Say NO often. I still struggle with this one. You will need to say NO to a lot of people. Some will get angry with you. You can’t deliver everything and that’s OK. It’s better to say NO than to overcommit and underdeliver.
Big challenges attract top minds. One thing I’ve found working with a company with a big vision is that it usually attracts top talent. Recognize that you need to keep feeding these top minds your toughest challenges to keep them engaged. Spread out the crap work.

Lesson #4 – Buy, don’t build

Engineers love to build things. Our default response when faced with a build vs. buy decision is to build. We know we can do it better ourselves than that off the shelf tool!

In high growth mode, you are operating in a unique circumstance where you have essentially unlimited money. This means you should almost always buy instead of build. Even if down the road you end up building it yourself, it will most likely pay off to buy it now.

The same goes for headcount. Hire contractors now to start implementing features while you build out your team of full time employees.

No matter how much you buy, there will always be too much for your team to build.

Lesson #5 – Establish good communication

This was already hinted at in previous lessons but it can not be overstated. Communication tends to become the biggest problem in high growth environments. New people will be onboarding other new people. The ‘oldtimers’ who are used to a purely verbal way of operating will need to start to write things down. Projects will become more complex and intertwined.

Here are some things that I’ve seen work:

Spend time creating good release notes. Clearly document new features, whether in writing, video walkthroughs, etc. These documents are usefully the most visible communication from outside your group. Spend time to make sure they are articulate, concise, and well designed.
Document what you are building (i.e. the specs) and share with stakeholders. Don’t skimp on this part, as it will end up costing you more time in the longer run if you need to redo.
Communicate what the team is working on and what has been completed. Use demos, newsletters, etc. to demonstrate what each member on your team is working on and how it ties back to the overall business goals.
Communicate high level roadmaps. What features will the team be working on over the next 3-12 months? This may change, but it’s important to message out your current viewpoint to align w/ the product, business, and engineering teams. The roadmap should fit on a single slide.
Use wikis. We put everything here. Specs, design decisions, meeting notes, releases, etc.

Lesson #6 – Be Decisive

In high growth mode you need to be decisive. Don’t let key decisions, whether it’s product, architecture, process, or people decisions linger.

I really like the Amazon motto, of “disagree and commit” here. Get folks into a room, hash it out, make a decision, and move on.

Most importantly, capture the decisions in meeting minutes so you can refer back to them. I can’t tell you how many times I’ve been in the same meeting rehashing the same decisions because we couldn’t remember what we had previously agreed upon, or why!

Conclusion

The high growth startup life isn’t for everyone. For me I ended up realizing that I couldn’t give the time needed at the company and be able to spend the time with my family that I wanted to.

While three years seems like a relatively short run, there is so much compressed learning in a high growth environment that it feels like I have gained many more years of experience. I definitely recommend everyone give a high growth company a shot, ok maybe not if you have a young family, it can be a lot of fun and a very rewarding experience.

Lessons From A High Growth Startup Dropout