Unfortunately, shiny engineering won't solve drastic product market fit iterations, and consumes the limited time & $$$ for achieving it. That's a lot of otherwise good habits and instincts to unlearn for engineers who never really had to go from idea to paying end users and instead needed to ride an existing monopoly and not break it: FANG, bigco, bank, consultants, etc. In a disturbing sense, a small # of new grads can fit in better on a startup team than a loud FANG cohort b/c most know how to do a bunch of small projects without being distracted by post-growth table stakes. (And you avoid the former-consultant "don't care about the end-customer, just the boss/politics" problem b/c of passion for the startup's mission vs. the tech.)
I've come to appreciate either:
Team 1: Staying tiny with people who demonstrably get that or are otherwise mission-focused (vs. tech-focused) until you do hit growth,
Team 2: Or massively over-fundraising and over-hiring (with high risk of fast death) simply to deal with sales/marketing/engineering that is only at say 10% efficiency of Team 1
>Unfortunately, shiny engineering won't solve drastic product market fit iterations, and consumes the limited time & $$$ for achieving it. That's a lot of otherwise good habits and instincts to unlearn for engineers who never really had to go from idea to paying
Having worked in startups and the corporate world, I would apply this also to the role of product owner, who is often responsible for setting up those experiments to learn and also filling up the tech pipeline for the next sprint. I've seen product owners having a hard time to grasp if the technical need for things pitched by engineering is real or just premature optimization. You either need a more technical product owner or a tech lead that puts it's business hat on quite often.
> I've come to appreciate either...
I think there's room for balanced consideration. Sometimes, yeah, revenue and time-to-market is everything. Sometimes there's a need for taking a risk and creating something new.
The new business is the risk-taking endeavor. The job of the team is to derisk, taking the blue-sky concept to something the market will consume. That's so hard and requires so much listening/iterating/etc. that it makes most engineering cycles not spent on meeting customers in the middle (or helping finding alternate customers/offerings) is eating the seed corn. Most startups should assume "default dead" until the $5M/yr point.
There is an interesting question of how to do deep tech. ("10X cheaper spaceflight", not "Tensorflow for AIOps"). That's more capital intensive, and in turn, different kinds of business critical milestones. "We need to do X, Y, Z so we can get $5M gov contract Y and the next round." That deal does _not_ hinge on whether you've upgraded from React 3 to 4 and have a much more approachable graphql orm.
Everywhere else around the world software development is just a SCRUM powered meet grinder where if you don't sprint fast and cheap enough your competitors will eat your lunch.
If some MBA with PMP certs decides to actively ignore the business impact of your bad code, it means he is stupid and incompetent. But that does not mean that code quality is an end on its own.