What makes developers bad at business?
qotoqot.com
qotoqot.com
The business and product side always say things like not choosing projects based on technical challenge, but that’s so extremely far away from the case of reality that it’s just FUD to better politically control things.
Most engineers I have worked with are really clever generally and can quickly grok sales or business considerations at a higher level than the sales or business people can. They want to build things that customers care about and don’t need anyone from sales or product hierarchies to “make” them follow that priority. They only want to test new tech stack choices in careful, isolated ways, not betting the farm on a new toy.
These are basically made up, misunderstood myths that business people tell because they’re insecure that smart engineers are good enough to make both engineering and business decisions.
And the flip side failure mode, where engineers are raising alarms about serious tech debt issues or inflexibility / incapability to innovate, and business people dismiss the seriousness of the issues in a genuine business sense, is rampant.
As an engineer one of my most frustrating experiences is when, _after taking business concerns into account very carefully_, my expert opinion that the business outcome is at high risk of failure due to lack of engineering investment and basic quality focus is just dismissed because “I’m not a product person” or some similar bullshit self-preservation from soft-skilled people writing Powerpoints all day while dismissing the idea that engineers can learn the business (usually very quickly).
This article is the result of my experience of trying to do business myself, watching other developers trying, and talking with ones who would like to try it one day.
But I agree, engineers can learn many of these skills quickly. My goal was to list the biases.
Internally to tech companies though, I think this sort of thing is trumpeted around too much to try to shift the balance of decision making power away from engineers. Sometimes of course engineers are not the ones in the position to know all the relevant factors for decision making. But often they really are, and if they tell you we can’t over-promise to the customer on XYZ because our legacy code is reaching a critical failure state, it needs to be urgently believed and trusted, but most of the time is not.
There’s often a fundamental incentive struggle between parties who get bonuses or commissions because of a binary outcome (closed the sale, shipped the feature, lost the customer, revenue less than the target), and people for whom the binary event translates into long-term service requirements (support the feature and backwards compatibility, deprioritize a critical version upgrade, grow support capacity without being granted more headcount, etc.).
Ideally it should be based on situational evidence and technical details (both business tech and engineering tech), and hopefully not just generic principles (often invoked via confirmation bias or argument from authority) like in this article.
I think I should have named it "bad at starting a business" or something similar. My intention was to help founders of startups or self-funded projects, I don't know much about the dynamics in larger companies.
Marketing is the 3rd essential component in a product, and finding savvy marketers is as hard as finding a really good engineer for your product.
As well, when hiring, a big mistake startups make is to hire samers. You should be hiring people that don't do exactly what you've been doing, as they're also going to be bringing creativity to your business in a way someone doing your same craft cannot bring into the table.