As a software engineer, your comfort zone is generally in front of your computer working on the solution to a well defined problem. You want to write code. You want to build something. You want to produce. But in the early stages of a startup, sometimes the idea or business isn’t quite ready for an all out assault on code.
As a technically focused founder, this can be a challenging time to determine how exactly you should focus yourself in order to contribute maximally to your business. You could hone your technical skills, preparing the tools, languages, platforms and materials such that when the vision is fully in place you’re able to quickly execute. Or you could spend your time brainstorming, defining product, learning about the market, talking to potential customers, and validating your hypotheses. In short, you can engineer, or your can entrepreneur. But how to split the time? It would seem there are three options:
- Only engineer
- Only entrepreneu (yes, this is the verb that I’ve been using casually pronouncing in my head as entreprenewwwww to engage in the activities that an entrepreneur might undertake)
- Engage in a mix of engineering and entrepreneuin’
Surprisingly, I believe that you can succeed with any of the above routes depending on the makeup of your team, the market you are entering into, and your personal strengths and weaknesses.
On one extreme, you may decide that you should spend all of your time engineering. If you are deeply technically focused, have full trust of your partners, and are comfortable that the company direction is set firm enough such that you won’t be disappointed with any product or business decisions that come down from above, then you can get some great momentum and a great head start on the technology. You can set up data systems and engineering practices, you can prototype initial versions of the ideas being tossed around, and you can get familiar and tinker on the platforms that will be inevitably crucial such as iOS, AWS, or HTML5. All of these activities will pay tremendous benefits and allow you to come out hot when it comes to finally producing product. But know the tradeoff is that you may not be involved in much of the early learning, feedback, and brainstorming that will shape the direction of the company.
On the opposite end of the spectrum, you could spend all of your time entrepreneuin’ until you are confident that the vision for the company and product is clear enough to build with confidence that things won’t change out from under you at a moment’s notice. You’ll spend your time meeting with every person you respect who’s done something smart in your space. You’ll run through your thinking in front of everybody who will listen, you’ll absorb their feedback, and you’ll spend time thinking hard about how all of this external stimulus should shape the direction that you take the company and product. You’ll think about strategy related to team building, fundraising, product design, distribution, user acquisition, and more. But you won’t build – and this may be frustrating. As a software engineer, you’re trained to default your free cycles to your editor, but in this stage you’ll default your free cycles to thought. The tricky part with this approach will be identifying when the right time is to cross the gap from thinking to building, because when you begin to build you’ll want to go all in. In a startup you may never know exactly what you’re running at, but when you have defined clear goals of what you need to prove in order to reach the next stage of your business, this can generally be a good point to get to work on building to reach your goal.
Naturally, between the two extremes lies a compromise of doing a bit of engineering and a bit of entrepreneuin’. This is the approach that enables you to stay technically relevant, ready, and optimize for the first sprint when it comes time to get building, while also participating in the all important shaping of the business from the get-go. It is also the approach that I’m currently taking as I get started on building my next company. The key with this approach is discipline, as you risk losing out on both sides of the equation. You could easily spend an entire day tinkering with iOS performance, while spending absolutely zero time on solving key early business strategy, and you could likewise spend an entire day in meetings getting feedback, without getting any closer to that prototype which you’ll have to show off in a few weeks to recruit that great product person to come join the team. If you’re disciplined, and allot certain time for building, and certain time for thinking and meeting, then you’ll be able to find a healthy balance that lets you productively work towards engineering readiness while also steering the ship and making the tough early calls that will guide the business.
With any approach, you know that eventually you’re going to transition into a technical lead responsible for the company’s engineering team, engineering culture, and technical decision making. Depending on your founding team, the market you are entering, and your personal strengths and weaknesses, you can determine the best path to take to get you to that point.