A few years ago, I left my staff engineer role at Slack to build a startup. At the time, I thought that I could lean on the best practices that I developed at Slack. However, I have since learned that startup engineering—especially pre-Product-Market Fit engineering—requires a surprisingly different mindset.
Startup engineering requires the drive and determination to make decisions that will set aside completeness, perfection, scalability, and the traditional hallmarks of engineering "success". These tradeoffs are painful!
If you are not okay with making those tough decisions repeatedly, then startup engineering may not be for you. But, on the other hand, if you want to learn how to be strategic, develop the skills to validate ideas quickly, and drive value for early customers, then startup engineering is for you.
For those looking to leap into the world of startups, below are the four mindsets that will make you a successful startup engineer.
Mindset 1: "I will learn, then I will learn how to learn faster"
When asked, "Why do you want to work at a startup?" many people respond that they want a job where they can learn. But few understand what it truly means to be learning all the time. Learning requires a high level of comfort with vulnerability and persistence.
A great startup engineer will cultivate the learner's mindset.
As an individual contributor at an early-stage startup, your ability to learn and solve new problems day-to-day will determine your success. You will need to go beyond your comfort zone and develop new skills. You will need to fix bugs on code paths that you've never touched before. You will need to build features with interactions that you've never architected before.
The pursuit of learning also extends beyond the individual to the whole team and should be a substantial consideration when you're evaluating a startup employer. The entire startup must learn together. On the way to Product-Market Fit, startups learn as much as possible from relatively small sample sizes and tightly scoped experiments. Startups need to learn who the customers, why they will purchase, and what they will use.
This is commonly described as hypothesis testing, where startups have a customer, market, and product hypothesis to validate. All efforts are put into validating those hypotheses, so software engineers at early-stage startups have to make fast tradeoff decisions that put completeness, scalability, and other traditional benchmarks of engineering success on the back burner (unless those are core to the hypotheses). Startup engineering is not high-scale engineering—it's hypothesis validation engineering.
When you adopt learner's mindset, you will constantly ask yourself the following questions:
- What skill do I need to learn right now?
- What's the fastest way to learn it?
- How can I learn faster next time?
- How can my team and I prioritize learning even more?
Mindset 2: "The critical path is the only one that matters"
Instead of writing perfect code that completes all the cases, a great startup engineer will focus on the critical path. You will learn faster whether that critical path is the right one. If it is, you can invest more time and energy in it. If not, you will save yourself the heartache of solving a problem that will never arise. You will also save yourself from over-engineering a feature that will be thrown away. (For more on this, keep reading to the fourth mindset.)
For example, we only built public channel interactions for the first iteration of Bennu's Slack app, because the distinction between public and private channels had no bearing on our hypothesis that users would use our app for daily Slack standups we integrated with their project management data. Ultimately, we learned that our users need a richer and more contextualized presentation of their data, for which our web application is much better suited.
By the way, this does not mean that you should skip writing tooling or tests, nor does it mean that I am endorsing low-quality code. You still need to write tooling, tests, and high-quality code for the critical path. Tooling and tests should focus on removing roadblocks to hypothesis validation. For example, at Bennu, we write tests for every third-party data transformation, because in our case, the stability and correctness of these features are critical to our business.
Mindset 3: "The business is my business, too"
As a traditional software engineer, it's easy to get into a mindset of "not my problem". But as a startup engineer, it's your business to understand how your work supports the whole team.
Startup engineers are rarely given a clean set of product requirements—you may even be part of the design process! Your team might agree on an idea and immediately start running with it. That's why startup engineers must understand more than what to build—they need to know why. To develop this skill, ask these questions for every sprint and feature:
- What is the business priority?
- What is the hypothesis we're validating?
- What do the users need at this point in the flow?
Participating in these types of business conversations is an invaluable experience that you typically wouldn't get at a traditional company where requirements are "handed down" to engineers. Startups have a lot of opportunities for individuals who show interest and aptitude to jump in and increase their responsibility and impact.
Mindset 4: "I am willing to walk away from good ideas"
"The best way to have a good idea is to have lots of ideas." —Linus Pauling
You can't pursue every good idea without confronting time and budget constraints. That's why it's essential to invest in great ideas. For example, for Bennu's product, there are many data visualizations that users would find "interesting", but only a few are insightful. There are many integrations that we could build, but only a few that make sense right now. There are many features that would generally solve collaboration, integration, and data visibility problems, but we only have time to tackle some.
Never lose sight of the bigger opportunity that you're pursuing—the great ideas, ones that customers will love and early users will flock to. To do that, you'll have to say "no" to a lot of good ideas. The hard part is that it will often indeed be a "no" instead of "not now"! Good ideas are tempting distractions, so walk away and press onward to great ones.
Wrapping Up
Pick one of these four mindsets and try it out! Of course, it will take time and practice to internalize it, but the rewards will be worth the effort. If this process calls to you, you will enjoy startup engineering—and you'll probably find success in whatever you do.
By the way, if these mindsets call to you, we're hiring at Bennu!