Let’s face it, working at a startup is inherently different than working at a large company. However, what exactly is different and how can you work to increase the chances of your startup succeeding?
We often hear the tales of the great entrepreneurs that with minimal resources managed to displace a behemoth incumbent with nothing but a clever idea. However, what is often unheard is the years of hard (and effective) work put in by the founding team to make their story a reality.
In the next section, we will go over key points that can often differentiate a great startup engineer.
A Startup Engineer Should:
1. Produce Exclusively a Minimum Viable Product (MVP)
Startups move fast! I once worked on an username validation for a pre product market fit startup that changed specifications 3 times in a single day. Of course, this is an example of an extreme case, but in general the smaller user base of startups and the constant need to find their high value users requires that development move at an accelerated pace.
What does this mean for the engineers? Design only the bare minimum that is required to determine if a feature is or not useful. There is no reason to spend a week designing a well polished interface for feature X, if feature X may be deprecated in two weeks. The time would have been better spent designing other missing features so that the company can start collecting data on those other features sooner to better hone in on its product market fit.
The idea of doing the bare minimum amount of work on a product before deploying it would not work out on an established product for a larger company. When using the search functionality of a well known company, for instance, a user expects it to work perfectly. Moreover, a 3% increase in search performance may result in a large revenue boost for a larger company. Whereas, for a startup, a 3% boost is borderline insignificant. After all, a startup’s user base is so small it is often seeking orders of magnitude growth.
2. Design for Constant Change
Startups are in a state of constant flux. A key to a startup’s survival is exploration. To constantly hypothesize on the next big thing that users want and test it out with MVPs.
However, how does this constant shift in the product affect engineering? Consider the example where your company’s product involves some sort of a liking mechanism. Where users can tap a button to like a post. At a larger company, you would design this for performance and maintainability, constraining your data structures to just the right models and relationships to ensure this feature works well.
At a startup, this may not be the correct strategy. What if the feature goes into production and two days later the decision is made to allow likes not just on posts but on comments as well? At a startup, looser models (even if less performant) are usually better. A polymorphic relationship between likes and any model, for instance, would allow this update to be done in minutes instead of hours of work.
3. Design for Obsolescence
The same way that new features are constantly being introduced in a startup’s product, old features are constantly deprecated.
For this reason, a startup engineer should not design data models and systems that are tightly coupled to one another. For example, changing from an image centered platform to a video centered platform should not require rewriting your comments backend.
This is quite different than working at a larger company where tight integration between different systems is common and often not a problem since those systems are likely to remain unchanged for months (possibly years).
4. Test Critical Paths — Only!
Every company big and small should have some form of testing for its products before being released to users. A key difference between the tests in a startup versus a larger company is in the scope.
A startup engineer should test almost exclusively the critical paths. A good rule of thumb is: If this feature breaks, would it cause users to lose trust in your company? If so, you should write tests. If not, it is very likely you can do without tests on this feature since it is quite possible it will be replaced in a near future and with a small number of engineers working on the product work time should be directed in to the most effective work possible.
Consider an eCommerce startup that is offering a revolutionary way to shop for Strawberries. Among the apps features are checkout and marketing banners on the home page. If a user attempts to checkout and upon finalizing their order their credit card is charged but their order is not placed, it would be a severe user facing issue that influences those users trust on the platform. Therefore, this feature should be well tested. On the other hand, if the marketing banners on the home page do not appear for a few hours while you debug the latest release, users are most likely not even going to notice. As such, no tests or minimal tests only.
5. Develop Only What is Core to Your Business
If seeing something you created from scratch work for the first time gives you a great sense of pride that likely means you are a great engineer. However, at a startup, avoid developing anything from scratch that is not absolutely required for your business.
If you are creating a new platform to sell groceries online and the user experience is your main selling point, you may need to build frontends from the ground up. However, can an off the shelf backend to handle product catalog, inventory control, checkout APIs and fulfillment work for your use case with some sacrifices? Can using a cloud provider for your SQL stores save you significant time versus having on premise servers? If so, opt to start with these off the shelf solutions.
As your startup grows, it will become apparent what needs to be redesigned and you can allocate development time into improving those features when said time arises.
6. Focus — Work Towards Company Specific Company Goals
At a startup, you will often find yourself jumping from project to project. The fast pace can cause you to associate productivity with quantity of completed projects per unit of time. However, that is a trap a startup engineer should avoid.
Completing a task that was in the backlog, may have no noticeable impact on user experience nor get you any closer to finding product market fit. Moreover, the time spent completing a few forgotten backlog items could have been spent deciding and then implementing a high impact feature that moves your company a little closer to success.
Therefore, set your work in a way that best aligns with the current company goals. If the company wants to increase user retention that month, work on features that have a measurable impact on user retention.
Effective work from the early members of a startup may be the difference between achieving success or becoming mere statistics. For startup engineers these six key points may go a long way in helping your company succeed:
- Develop always only the MVP for new features.
- Design features considering they may soon change.
- Do not strongly couple features since deprecation is common.
- Write automated tests but only for the critical features.
- Use off the shelf as much as possible.
- Focus your work on tasks that impact near term company objectives.
If you are currently a member of a startup, I wish you success and remember to work effectively!