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.
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.
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.
> Revenue and business impact are ALL that matter.
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.
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.
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.
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.
Isnt that what google did to yahoo? Apple to Nokia? And now kubernetes does to AWS?
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 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.
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.
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.
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.