Hacker News Reader

Comment by baxtr | Hacker News Reader

I used to work for a Startup considered by many as tech company. Our devs cared a lot about code quality, visited meetups, engaged in the community etc. devs usually stayed for at least 3-5 yrs.

In contrast, there was a company that almost did the same business as we did. But, they were what people would have called a sales company, not a tech company. Decisions were based on sale opportunities, only. No one gave a shit about code quality, devs didn’t stay long and often were frustrated when they applied at our company.

Which one was more successful? Unfortunately they were... we were often slowed down by discussions about code quality, ways of working, ethics and disrespect for revenue driven decisions.

Maybe it was just an exception? But since then I have become skeptical when I hear about “tech” companies. I feel we nerds need to be value driven, too, and not die in beauty.

View on HN

> Disrespect for revenue-driven decisions

I think thats the one that hurt you the most.

https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

Code quality and developer experience matters because it enables you to quickly use a codebase to solve business problems. But you still have to focus on business problems.

A professed concern for code quality sometimes manifests itself in endless bikeshedding over small matters. At least initially, be a little bit skeptical of the person with one system behind him, who is determined to do this one right.

Indeed, this matches my experience exactly.

Your developer driven company may have great code quality and employee satisfaction but unless it has a FAANG-like niche all to itself, it will easily be beaten by the revenue driven agile sweatshop next door despite its low quality code and high turnover.

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.

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)

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

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.

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

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

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

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.

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.

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

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.

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?

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.

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

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

I had a first time similar related experience with a startup in Tokyo. The company was focused on IoT related projects and started by purely business oriented individuals with not much tech experience. Their strategy was to hire as many "foreign" engineers to focus on the development while they push out for investment and business opportunities. Unfortunately, there was an internal clash between the engineers and the business side over code quality vs just pushing some buggy IoT related application into production which led to over half the engineering team quit in under 6 months I being one of them. Somehow though they are still afloat a year after using the barely working buggy app that we finished before we left.

It's an unfortunate reality that sometimes good is the enemy of good enough.

I do think it's easy to go too far the other way, though. You can plan to throw one away. You can write a quick and dirty MVP. You can throw money at the scalability problem if you're lucky enough to have it. Sooner or later, though, you are the player with the established offering. Unless you want to keep rewriting it from scratch every few months, at greater and greater cost as your offering grows, you need decent code at that point to maintain reasonable progress in supporting whatever your next revenue-driven features might be.

>disrespect for revenue driven decisions

That caught my eye as well.

There's such a fine line to walk there where you avoid bad decisions "because customer X wants it" and recognition that giving the customer what they want is what you are there to do / what sells.

I just had a discussion that was "We're not going to do this how they want as that is too wonky / would send the code in all sorts of strange directions ... but we're still going to give them what they want in spirit."

If we had just said no, or blown off the sales guy's POV, probabbly lose a lot of traction with that customer.

The reality is that both engineers and sales have their own respective forms of myopia. Engineers often bias towards elegant code and architecture, salespeople bias towards whatever the last sales lead said on the phone. Both have some value, but neither one will unlock a massively scalable market. To do so you need some vision beyond what the sales lead is saying on the phone or what is easy to design elegantly. Not just that, but you also need rapid iteration and not to fall so in love with your early thinking that you can't effectively capture new insight along the way.

Both of those styles of company focus are often beat out by companies that consider themselves to be customer service companies. A sale is step one, then you deliver the great customer experience which they actually signed up for. Development is a tool to improve that experience. But the company itself is delivering a service... that happens to be tech-based.

Im gonna use this in quotes "I have become skeptical when I hear about “tech” companies. I feel we nerds need to be value driven, too, and not die in beauty." Thanks.

If it makes you feel any better, I worked at the "sales company" and they certainly aren't winning big. I think you're just underestimating the amount of factors involved in determining business success.

IMO you are mixing 2 different things.

1. The business and product

2. The engineering quality

You can have a tech company (business level as described in the article) and produce ugly code (ex: facebook?).

You can sell groceries on the internet and have great code.

Reply on news.ycombinator.com