5 ms·

Rant time.. Revenue and business impact are ALL that matter. Good, clean, scaleable, and testable code only exist to rapidly support the above. The moment you

Rant time.. Revenue and business impact are ALL that matter. Good, clean, scaleable, and testable code only exist to rapidly support the above. The moment you choose tech value over buisness you are a risk not asset to a company. I sware sometimes I see so many delusional software "engineers" who care more about building technically excellent systems that are either delivered late or dont solve a/the real problem... it disgusts me.

achillesheels 7y ago
It likely comes from the fact engineers would rather build than sell, except selling is part of the iterative process! (The most crucial part as it obliterates wishful thinking on what the market needs)
crispyambulance 7y ago
> 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.
deleted 7y ago
[deleted]
spodek 7y ago
> Revenue and business impact are ALL that matter. You might want to look up b-corporations if you haven't. They take into account employees, communities, and the environment as parts of their charters. I'd heard about them for a while but didn't realize the difference they made until speaking to Lorna Davis, who was instrumental in the largest conversion to a b-corp yet. I don't claim it's the best introductions to them, but the conversation was on my podcast, so you can hear her personal inside account: http://joshuaspodek.com/guests/lorna-davis http://joshuaspodek.com/guests/lorna-davis.
- jbob2000 7y ago
  I worked for a B corporation, it’s a meaningless label that was used to beef up our pitches to clients and investors. There’s no oversight by the B organization to actually make sure that it’s companies are adhering to the label’s mandates.
streetcat1 7y ago
So I am confused. A tech company sell tech, no? I.e. amazon ecommerce is not a tech company. AWS is. So if tech company is selling tech, and company A tech is better (e.g. 1 year - 2 year more advanced) than B tech, why would revenue matter? Isnt that what google did to yahoo? Apple to Nokia? And now kubernetes does to AWS?
- adventured 7y ago
  Amazon is a business that has classic technology-heavy segments that involve every type of engineer/programmer/developer and it has retail segments (retail customer service, retail warehousing, retail logistics, etc.), among countless others (HR, accounting, legal, marketing). It does both traditional retail and sells technology products & services (Kindle, smart speakers, tablets, AWS, et al.). At this point they're even doing custom chips; and of course they're increasingly into the media and advertising businesses. For a monster like Amazon it particularly doesn't make sense to call it a technology company or an ecommerce company (or a media company or an ad company). It's a company - really a conglomerate - and it does/sells x y z. AWS is as much a critial part of what Amazon is today as its retail business (on a value basis, AWS is drastically more valuable, and will be even more so in the future). One day they may be split apart, however that is likely a decade into the future or more.
esmi 7y ago
> I see so many delusional software "engineers" who care more about building technically excellent systems that are either delivered late or dont solve a/the real problem That's a management failure not software engineers doing the wrong thing. Software engineers should care more about building technically excellent systems just like safety auditors should care most about safety. It's management's job to prioritize the wants of the business and the wants of the engineers and decide when they align and when they don't.
afarrell 7y ago
> only exist to rapidly support the above Er, they also exist to support the quality of life of the engineer. Suppose your company asks you to spend 6 months writing PHP in an untestable codebase. And you know that you need to have testable code in order to make progress in a codebase. It is better for you to stay off that project, even if it theoretically would make massive revenue gains for the company. Why? Because if the company's revenue doesn't matter to you when annual review time rolls around and you get fired because you didn't accomplish much in the past 6 months. So yes, you should care about business goals, but only insofar as they support the stability of your family life.

achillesheels 7y ago

It likely comes from the fact engineers would rather build than sell, except selling is part of the iterative process! (The most crucial part as it obliterates wishful thinking on what the market needs)

crispyambulance 7y ago

> 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.

deleted 7y ago

[deleted]

spodek 7y ago

> Revenue and business impact are ALL that matter. You might want to look up b-corporations if you haven't. They take into account employees, communities, and the environment as parts of their charters. I'd heard about them for a while but didn't realize the difference they made until speaking to Lorna Davis, who was instrumental in the largest conversion to a b-corp yet. I don't claim it's the best introductions to them, but the conversation was on my podcast, so you can hear her personal inside account: http://joshuaspodek.com/guests/lorna-davis http://joshuaspodek.com/guests/lorna-davis.

jbob2000 7y ago
I worked for a B corporation, it’s a meaningless label that was used to beef up our pitches to clients and investors. There’s no oversight by the B organization to actually make sure that it’s companies are adhering to the label’s mandates.

streetcat1 7y ago

So I am confused. A tech company sell tech, no? I.e. amazon ecommerce is not a tech company. AWS is. So if tech company is selling tech, and company A tech is better (e.g. 1 year - 2 year more advanced) than B tech, why would revenue matter? Isnt that what google did to yahoo? Apple to Nokia? And now kubernetes does to AWS?

adventured 7y ago
Amazon is a business that has classic technology-heavy segments that involve every type of engineer/programmer/developer and it has retail segments (retail customer service, retail warehousing, retail logistics, etc.), among countless others (HR, accounting, legal, marketing). It does both traditional retail and sells technology products & services (Kindle, smart speakers, tablets, AWS, et al.). At this point they're even doing custom chips; and of course they're increasingly into the media and advertising businesses. For a monster like Amazon it particularly doesn't make sense to call it a technology company or an ecommerce company (or a media company or an ad company). It's a company - really a conglomerate - and it does/sells x y z. AWS is as much a critial part of what Amazon is today as its retail business (on a value basis, AWS is drastically more valuable, and will be even more so in the future). One day they may be split apart, however that is likely a decade into the future or more.

esmi 7y ago

> I see so many delusional software "engineers" who care more about building technically excellent systems that are either delivered late or dont solve a/the real problem That's a management failure not software engineers doing the wrong thing. Software engineers should care more about building technically excellent systems just like safety auditors should care most about safety. It's management's job to prioritize the wants of the business and the wants of the engineers and decide when they align and when they don't.

afarrell 7y ago

> only exist to rapidly support the above Er, they also exist to support the quality of life of the engineer. Suppose your company asks you to spend 6 months writing PHP in an untestable codebase. And you know that you need to have testable code in order to make progress in a codebase. It is better for you to stay off that project, even if it theoretically would make massive revenue gains for the company. Why? Because if the company's revenue doesn't matter to you when annual review time rolls around and you get fired because you didn't accomplish much in the past 6 months. So yes, you should care about business goals, but only insofar as they support the stability of your family life.