Startup Mistakes - Being an Engineer and Not a Founder

I am starting a new series on major mistakes I have made and sometimes continue to make, in my startup journey. This one is especially important as it is an ongoing battle and something I have to remind myself of all the time.

Being a technical founder is great and provides a lot of unique advantages that non-technical founders don't have, but the important thing is that you are a 'founder'. It is your job to get your business off the ground and businesses have a lot of moving parts. When you factor in marketing, design, sales, management, accounting etc. the engineering portion of your work becomes a relatively small percentage of what makes up your business.

My History as an Engineer

Understanding a little bit about me will help contextualize why this is a challenge for me and hopefully some of you can relate to my journey. I have a Bachelor of Computer Science degree through a math faculty from a University. I have no particular love for my time in university, the degree was more a means to an end for me, but I do appreciate the in-depth mathematics as well as the traditional teaching.

My professional journey started briefly at a startup but I transitioned and worked in a corporate environment for 5-6 years. During that time I worked my way up to a Senior engineer and then as a technical leader of my team. This was a very large company, Oracle bought us for 10 Billion dollars 😲.

Some of the key traits of my time working there include:

• Incredibly slow pace of development.
• Every decision required several stakeholders. Both from a product and engineering perspective.
• Having to include Technical Writers, UX, SET's in everything I did
• I pushed strongly for much stronger code structuring.
• Introduced Dependency Inversion and Injection
• Spearheaded Unit Testing and better integration tests. Most things were End To End and they would test every little variation that way 😱
• Helped spearhead a transition from Java to Kotlin across the company

The points themselves aren't that important, what is important is that I didn't include something like "crushed out a huge project". Pretty much everything was me plodding through code slowly, in an incredibly formal manner, and me trying to push the processes to be faster and more stable. If I wanted to change a label on some field in a form, it would take effectively a whole day. That is insane...

In this role being a good engineer meant a few things to me:

• communicating with stakeholders
• converting product manager requests into engineering speak
• writing bug free code, as bugs were incredibly costly to fix time wise
• writing lots of tests
• mentoring others

For anyone who has the builder mentality such as myself, this environment was incredibly frustrating to develop in so I spent most of my effort on improving soft skills (which was very useful). You can probably piece together why transitioning from this environment into the startup world would be challenging.

Why You Can't Just Be An Engineer

From the perspective of an early stage startup founder, there are a few things that I think are very important:

• Being fast in everything you do
• Putting yourself out there
• Identifying positioning and pivoting through the market quickly
• Marketing, Marketing Marketing

There is not a lot of overlap here with my above engineering section. More importantly, I think there are some things that directly contradict each other from a corporate engineer to early stage startup founder.

Bugs Don't Matter

Well okay, that's exaggerated, they matter a little. But only if they are exposing or breaking something very important that affects customers directly.

With a lot of things in the startup world, I think you can employ the 80% rule where you can hammer out things to handle 80% of your cases very quickly and then ignore the final 20% that takes an outsized amount of time. This definitely applies to bug and edge-case handling.

As a startup developer, I think your primary goal is speed. You need to get things built as quickly as possible because the startup is still proving that it has something worthwhile. You need to set yourself up so that your sales and marketing efforts can be the focus. Ignore the bugs, build quickly.

There Isn't Time for Tests

I am definitely annoying a lot of my engineering brethren at this point, especially my former team members that I relentlessly hounded to write more and better tests. I am doubling down on the speed motif as I think that is the biggest driving force for countering traditional engineering.

If bugs don't matter then it follows that there is no time for tests, we need code that drives features.

Engineering is Such a Small Part of the Job

I am privileged that I have a great cofounder who is the primary driver of sales and marketing efforts but not everyone has that luxury. In most cases, a founder has to split up their time across multiple disciplines.

You have probably seen good products get absolutely destroyed customer wise by inferior products. It may have even happened to you, and that can be very frustrating. The reality is marketing and positioning are so much more important to running a startup than development is. You still need some kind of product (in the saas world you can fake most of it, which is a different discussion), but after that, your focus should be drawing attention to it.

Obviously, it is very dependent on what you are building, but if I were to ballpark a percentage of development effort versus other focuses it might look something like this.

• 10% Product. And that includes finding and validating features with customers. So development may be some subset of that 10%
• 80% Marketing and Sales. Just grouped these together because they blend subjectively
• 10% running the business. i.e. accounting etc.

So like 5-10% of time spent developing...

Conclusion

I feel a little hyperbolic, but overcorrecting has done better for me than the reverse. Much of my development effort these days is in support of the other portions of being a founder. At first, I treated it the other way around, because that sounds way more exciting as an engineer, but I feel confident that this is the better mindset going forward.