3 ms·

> Revenue and business impact are ALL that matter. Sure, but only until your up-and-coming competitor eats your lunch because everything got taken over by a-ho

> Revenue and business impact are ALL that matter. Sure, but only until your up-and-coming competitor eats your lunch because everything got taken over by a-hole MBA and PMP-types, everyone cool leaves, and the only people doing the work are disinterested consulting companies charging you through the nose.

ChuckNorris89 7y ago
Your statement only applies for the FAANGlike companies/monopolies form SV working on the latest AI thingamajigs where they have enough AdSense/VC funds to support costly talent without worrying about making money. 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.
lmeyerov 7y ago
Unless the the startup already nailed the startup part and is at $5-10M/yr or will flip with 0 revenue, you have no lunch to be eaten, just aspirations. Your biggest competitor is your internal non-business efforts that distract from experimenting with what gets people to pay in a repeatable way. Only after you have built a working revenue machine -- which (depressingly) can simply be VC revenue and hoping the music doesn't stop -- do you have a lunch to worry about. Luckily, as Twitter and friends show, once you have made that lunch, you can turn even the biggest Ruby fail whale and php ball of mud into engineering for scaling & doing tiny feature iterations. 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
- dakna 7y ago
  >Your biggest competitor is your internal non-business efforts that distract from experimenting with what gets people to pay in a repeatable way >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.
- crispyambulance 7y ago
  > I've come to appreciate either... So basically either naked greed or blue-sky-burn-rate ? 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.
  - lmeyerov 7y ago
    No: Either business-focused engineers, or enough money so that every 5 folks who aren't ("scale!" "this adds velocity!" "10% faster!") can add up to 1 developer who is. 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.
marcosdumay 7y ago
You avoid low quality code because it has business impact. If it didn't, you'd write it as fast as possible shrug, run/distribute, and move to the next problem (what is exactly what is correct for run-once code). 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.

ChuckNorris89 7y ago

Your statement only applies for the FAANGlike companies/monopolies form SV working on the latest AI thingamajigs where they have enough AdSense/VC funds to support costly talent without worrying about making money. 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.

lmeyerov 7y ago

Unless the the startup already nailed the startup part and is at $5-10M/yr or will flip with 0 revenue, you have no lunch to be eaten, just aspirations. Your biggest competitor is your internal non-business efforts that distract from experimenting with what gets people to pay in a repeatable way. Only after you have built a working revenue machine -- which (depressingly) can simply be VC revenue and hoping the music doesn't stop -- do you have a lunch to worry about. Luckily, as Twitter and friends show, once you have made that lunch, you can turn even the biggest Ruby fail whale and php ball of mud into engineering for scaling & doing tiny feature iterations. 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

dakna 7y ago
>Your biggest competitor is your internal non-business efforts that distract from experimenting with what gets people to pay in a repeatable way >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.
crispyambulance 7y ago
> I've come to appreciate either... So basically either naked greed or blue-sky-burn-rate ? 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.
- lmeyerov 7y ago
  No: Either business-focused engineers, or enough money so that every 5 folks who aren't ("scale!" "this adds velocity!" "10% faster!") can add up to 1 developer who is. 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.

marcosdumay 7y ago

You avoid low quality code because it has business impact. If it didn't, you'd write it as fast as possible shrug, run/distribute, and move to the next problem (what is exactly what is correct for run-once code). 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.