Five tenets of an early-stage startup engineer

Five tenets of an early-stage startup engineer

Several skills are required to succeed as a startup engineer. After 15 years spanning six startups, including two acquisitions, here is my take on the five tenets required to ensure success.

Tenet 1 - Ownership

Startups are typically limited by resources. You are a company running in high-efficiency mode to successfully pass through the pre-startup and product-market fit phases. Often the largest team is engineering. Functions like sales, marketing and product are performed by the co-founders. When given an engineering task you should attempt to own it from start to finish as you don't have the luxury of a larger team. Below are some ideas for the validating, planning and delivery phases of feature development.

Validating would be asking questions about the proposal to find out the edges and scope of the problem the stakeholders are requesting. This is crucial to the planning phase as it helps define the issue at hand. Is there a version zero (v0) we can deliver early, do we need all the bells and whistles to deliver this feature? Can we take some early mocks to a friendly customer to validate further? Is the task being requested reasonable from an engineering perspective? We're trying to validate early to ensure ruthless efficiency with our resources. Once we get a good idea of the feature we can now move to the planning phase.

Planning should now be easier. We've scoped the problem in validating. Here we think about delivery and how we can get the feature into the hands of the internal team quickly. Since it's much easier to garner feedback from something that sort of works what deltas can we deliver to get this up and running? Here we break the feature down into bite-sized chunks to meet that goal. Perhaps put validation or security items after we get the basics working. Can we push automated testing later? Are there unknowns we should work on early? The output of this phase should be a clear plan in a Google Doc or Kanban tool.

Delivery is focused on executing the plan. We've made an educated guess on how to proceed, delivery is the realisation and communication of that plan. Engineers should be given the time and space to focus on their deliverables. In return, they should offer open, accurate and generic communication on their progress. Startups don't have the luxury of project managers, who collate progress metrics, so communicating your own progress accurately is key. Be specific in your communication. Do not repeat the same generic I am working on Feature Foo. Be specific, what aspects of Foo are you working on? For example, if you are working on a Login box don't just repeat the same generic description but highlight which aspects of the box you are working on. Are you fixing the API, working on CSS, responsiveness, styling or validation?

Tenet 2 - Flexibility

A career in software engineering has a variety of roles for the many ways engineers like to work. Startups require engineers to wear many hats which narrows the type of engineer that can be successful in this environment. If you are someone who just does Postgres database administration or a dev-ops person that doesn't do any coding; you are unlikely to succeed at an early-stage startup. The successful people I have worked with will take on roles and tasks in their and outside of the purview as important business milestones come into focus. Therefore you need to be someone who is curious about new technologies, someone who enjoys grokking and implementing solutions in a variety of technologies. When building a new UX feature, you may need to work in UX, CSS, UX Frameworks, UX Widget Framework, API design and a db migration model. You can have your area of expertise, e.g. the React expert or the Java expert but you should be willing to work in many areas.

Tenet 3 - Patience

Working in a startup is a process of discovery. In my experience rarely does anyone have an absolute accurate vision of what needs to be built and the plan to execute. It's more like: I have an idea of this thing we should build, validated by some research and key customers, let's aim in this direction and continually validate our findings with our customers and sales metrics. Therefore be patient! And be efficient! Because we don't have complete knowledge don't bother building a huge UX testing suite because the thing we end up with might not be the thing we need. Often engineers like to work on pet projects that give them access to new exciting technology or are able to automate something which takes them 5 minutes to do manually, by building something that takes 6 months to build.

Patience is also required with Tech Debt, because we are being efficient, we will build and maintain a tech debt mountain. Items on this mountain are tackled strategically and often tied to key feature releases for the product. There is a balance to be maintained, if an item of Tech Debt takes an hour to fix obviously go for it, if it's unlikely to introduce a lot of errors and is quick, go for it. If it is a complete refactor of an important module, that doesn't yet have a great testing suite, then a decision to tackle it should be a team one.

Tenet 4 - Customer Focussed

Customers willing to pay for your product, or offer useful and regular feedback are gold. Participating in that relationship by informing and reacting to their input with engineering effort completes the emotional payback circle and increases the value of the relationship. Having five customers which use your product and can be contacted to validate future ideas are essential in successfully delivering a product roadmap. They can be garnered to inform the roadmap, you can validate UX workflow designs, and you can give them early beta access. All great waypoints to use the efficient use of engineering effort.

Focussing on the customer is essential to grow the business and its investment potential but also adds color to your engineering career. Understanding closely why you are really building something, and interacting with the end user who uses the product helps sharpen your focus, increase quality and gain a sense of pride of connecting the dots from coding to use. Here are some ideas to increase the closeness of that connection:

  • Ask to meet the customer on sales trips or events.
  • Participate in Customer Success calls to offer assurance to them or assist in debugging their issues.
  • Own and prioritize important customer bugs and features, work to make the customer feel like they are being listened to, and respond by implementing features they can use.
  • When given an asynchronous delayed task, e.g. a vendor API isn't working correctly and you need to debug with a third party, liaise with the customer to give them regular updates and inform them their issue will take longer due to conditions outside of your control.

Tenet 5 - Tenacity

Why tenacity? You are on a process of discovery for your product and customers. There will be times when no sales are made, previous good ideas are abandoned or pivoted; good ideas will get tossed when validated in the real world. There will be highs, lows, and every emotion in between. Be hopeful, add value, and don't take the ride for granted. You will need tenacity to be someone who never gives up and never stops trying. I am lucky enough to have been involved in five startups. I adore the journey, mission, and the feeling of comradery when building something towards a common goal.

Summary

Add value, be flexible, be communicative and have fun.

Article inspired by startup experiences spanning 15 years. The themes portrayed in this article are inspired by my own method of working and are not related to colleagues near or distant. No identification with actual persons (living or deceased), places, buildings, and products is intended or should be inferred. I have met a lot of good people over the years and hope to work with most of them once again in the future.