So what's the solution? Is there a playbook that avoids these pitfalls, or is it just the cost of the spin. Ideally, something early engineers can point to when we see non-technical founders falling into familiar traps.
- you need aligned incentives across the board. Sales and accounts mustn’t promise what the company can’t deliver
- people need to defend their area of expertise whilst listening to what others are saying about theirs. For me this boils down to a division between technical and business focussed. Techies need to push for non-client facing technical improvements without making everyone ignore them every time they say “technical debt”, and they need to accept that sometimes you just build shit to get business through the books. Sales/accounts need to accept that sometimes the build budget is taken up with mysterious technical drives that will be worth it. When I say “must accept” I mean accept that it must happen some percentage of the time - each case still needs to be backed up by a business case.
- ultimately this needs to come from the top - founder(s) must balance these facts and drive it through the whole organisation, and in the article they didn’t
For me there is no right answer. Maybe the engineer should have been more pushy with what things not to add. Maybe the founder entrepreneur should have been realistic. Maybe sales should have not had to promise things that were not developed yet. But to each of those there is a counter-argument of why that needed to be done in that moment.
Take it as a mental exercise.
for me the company should never have existed in the first place. and that lies with the founder. starts with them. falls on them.
i'm biased i suppose because my part in the "10%" part of my story was finding out just how little research anyone actually did... they all just wanted to play the role of important businessmen, big brain dev, co-founder etc. etc.
thank you for writing this. i'm still trying to come back from crashing and burning at that place. i might read this a few more times as it felt like my story too. the another Engineer part touched me. that's who i was in my story. it hurt.
edit -- https://news.ycombinator.com/item?id=48774444 hits the nail on the head with their last bullet point. bad leadership innit.
More often I see the opposite. 100 page pdfs that fall apart in first contact with reality.
I think it’s not about research, but it’s very hard to contribute in a field you haven’t actually had a career in.
"FOSS is universally unreliable" was one of such assumptions i had to push back against 5 years later. they meant academica produced software. but they assumed all foss is the same as all academica produced software.
When they didn't iterate on PMF with a niche client.
- not understanding sales and properly incentivizing them
- attacking only urgent problems (urgent vs important matrix)
- not taking constraints expressed by domain experts as real. (Big companies are actually good at this.)