3 ms·

Interesting, you are not the first person to describe the article like "myths that business people tell". But I've never worked around the "business people": I'

by ivm 8y ago

Interesting, you are not the first person to describe the article like "myths that business people tell". But I've never worked around the "business people": I'm a developer who has always been freelancing and bootstrapping. All my previous clients were 1-10 person teams, mostly staffed with developers. 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.

mlthoughts2018 8y ago
I can totally agree there are segments of the software industry where these issues exist more meaningfully, like in your experience. 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.
- ivm 8y ago
  Understood, thank you for the explanation. 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.

by ivm 8y ago

mlthoughts2018 8y ago

I can totally agree there are segments of the software industry where these issues exist more meaningfully, like in your experience. 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.

ivm 8y ago
Understood, thank you for the explanation. 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.