What life as a software engineer has taught me about the business of startups

Charting the pulse of a startup company is generally the job of an organization’s executive leadership, sales, and marketing. It makes sense: they’re the ones with access to costs and revenue streams, and they’re the ones involved in client and/or investor negotiations. It’s rare, however, for subject matter experts (SMEs), who aren’t necessarily in leadership positions, to provide their own insights and analysis about an organization. And that’s often detrimental.

As a senior software engineer who’s worked for three startups in a row, I’ve seen firsthand how all members of a small startup (3-8 persons) must wear multiple hats to keep the business afloat. By virtue of a startup’s limited size, every member becomes immersed in (or at least has extensive contact with) parts of the business outside of their own specialty.

Working with others in the trenches, so to speak, has provided me some key insights into the business of startups. Oftentimes, these “common sense” items are lost on the leadership of a company, who are understandably preoccupied with MBA-esque numbers and practices.

Here are some of the most important things I’ve learned (many the hard way) during my time as a software engineer at startups.

Expect more work than the job posting says (and then some).

When you’re interviewing at a startup, no one wants to scare you away from the business. Remember, if your skills mesh nicely with what the startup needs to improve their product: you’re a desirable commodity. Consequently, workload estimates will be unrealistically low.

Deadlines will change, the product will constantly evolve and pivot. You need to perform well to avoid costing the company a sale, and evaluate changing priorities of multiple projects daily, while still maintaining a life outside of work. In short: you need serious time management skills.

Never underestimate how difficult budgeting your time can be, although everyone in a startup will, at some point or another. Even seasoned entrepreneurs aren’t fortune tellers. If a client signs a large sales contract with a feature stipulation, be ready to drop everything to make this feature work – stat.

Don’t undervalue the input of SMEs.

Businessmen are great at business. Software engineers are great at software. Now and then you’ll get a cross between the two, but not consistently enough to depend on. If you are on the leadership committee of a startup, make sure you have at least one relevant SME on your team.

In the startups I’ve worked for, the SMEs have been on the engineering staff, not the leadership staff. If that’s the case at your company, too, make sure to ask for (and consider!) their input on questions of feature applicability and timing.

Allow SMEs to contest prospective changes and additions before pledging a feature to a client. Involve SMEs in project management, as well, to get a more accurate timetable than someone with a different core competency can provide. Ensure the product you’re selling can be made in the appropriate time and budget the client expects, to avoid sabotaging your relationship with them.

Choose a vertical and stick with it.

When a pre-revenue startup is developing a product, it’s tempting to pursue all possible options in hopes of making a successful sale. Opening up more verticals early on, however, doesn’t magically equate to more sales.

Most startups’ resources are already stretched as thin as possible. A software product in development may meet most of a potential client’s expectations, but fall short of a few. This problem doesn’t need to be a barrier to market entry. Modern software is organic: features can be constantly added, removed, or changed as needed.

Don’t be afraid to market a product that is, for all intents and purposes, incomplete.

Already have a viable product with 90% of its minimum features complete? Have a client who is looking for a product 100% finished to their specifications? Pitch your existing product in your favor. Don’t break the bank (and development’s back) by requiring the last 10% of work to be completed before the client even signs a sales agreement.

Developing new features for every sales pitch you make overburdens your team, making them scramble to get unbaked code working, in hopes of convincing what is only a prospective client. It undermines the purpose of a roadmap, and takes time away from improving the base software with tasks like bug fixes.

Instead, focus on a vertical that has the most potential for both early clients and early investment. Then, seek out clients whose requirements are concise and specific enough to present a common set of features with other prospective clients in that vertical. Develop your base product with these common features in mind, so that future requests in the same vertical will require less work.

Keep people informed.

Large organizations are structured in a hierarchy, and consequently most employees don’t need to know what’s going on in all the divisions all the time. Startup employees, meanwhile, should be kept aware of major goings-on in other sections of their company.

All members of a startup deserve to be kept informed about big issues like payroll, expense accounting, prospective clients, and investment. For example, budgeting expenses (like cloud hosting services, travel costs, or computer hardware replacements) needs to be a group discussion within a startup, because resources are limited.

No matter their role in the startup, all employees should also be made aware of their risk. For example, if there is going to be an unanticipated gap in payroll, all should be informed as early as possible. The counterargument would be that employees can always opt to leave if they’re not paid: while this is true, not giving employees a heads-up will basically guarantee those who would leave before will quit anyways when their paycheck is conspicuously absent one day.

Keeping everyone in the loop allows employees to plan ahead for issues like brief delays in pay, limiting the likelihood they will bring legal action against the company for them, and earning their trust.

Check your ego at the door.

Startups are already small, closed environments – fill them with the entrepreneurial personalities that startups usually attract, and you may have issues. Talented people who are fiercely proud of their ideas, even rightfully, won’t hesitate to stomp on other people’s thoughts.

Be prepared, no matter your role in a startup, to deal with egocentric and aggressive personalities. Prepare to act like that yourself sometimes, too, and be cut down.

In the end, what matters is that everyone recognizes the importance of a solid, sustainable product over their personal contributions to it.

The overall quality design and implementation of a software product should be the focus for everyone: not recognition for their personal contributions. That’s what things like patents are for. Not to mention, it’s uncomfortable (if not impossible) for everyone to contribute fresh and constructive ideas to a project that “belongs” to one person. When egos get in the way, a quality product can be limited by a myopic vision.

Don’t be afraid to let people go.

One adage I’ve heard from many people in the startups I’ve worked for is that no startup can afford a bad hire. While this statement has plenty of truth to it, it lacks a corollary. If you do make a bad hire, don’t be afraid to let the person go if (or rather, when) it begins to affect business.

Once some entrepreneurs make a bad hire, they seem to feel compelled to keep the person on until the business begins to be self-sustaining. There are plenty of logical reasons that could be behind such decisions. For example: How long will it take to replace the person? What company resources will they have access to, or control over, if they are terminated immediately? Will they actually adhere to any non-disclosure agreements?

Because startups stake so much on every single hire, replacing just one employee can seem like a gargantuan task. Not replacing them, however, can have significant, long-term consequences.

The negative effects depend on why the bad hire should be terminated. Lazy hires eat away at limited resources while continuing to under-produce, causing a drain on morale. Narcissistic or combative hires can stop others from speaking their minds and sharing ideas, hindering innovation. Unpredictable “loose cannon” hires can derail deadlines or cause scenes, damaging client relationships and interpersonal relationships.

A good startup leader will make the often difficult decision to remove a bad hire once the employee’s costs to the business outweigh their benefits. When things are getting out of hand with a bad hire, with no apparent solution in sight, that’s when a startup truly can’t afford a bad hire.

These are just a handful of the points I’ve picked up over the last five years or so of working for nothing but startups. Hopefully these notes from a software engineer will give you a helpful, unique perspective on the startup experience.

---

Please note: this is a repost of my article of the same title, previously published on LinkedIn on 9 Feb 2015:

https://www.linkedin.com/pulse/engineers-view-from-startup-trenches-anthony-turner