This is kind of interesting but it sounds like the perpetual worry of the perfectionist developer. Of course you end up with tech tech, you develop new things when you could improve existing things, you deploy something that could be iterated but you don't.
The truth is that the world is a complex place and you don't always know whether you can keep your existing customers by improving what you already have or get new customers to decrease the risk of declining income. It is hard to measure what is acceptable tech debt and what is worth addressing.
In one sense, the proof is in the income. If you can help customers with an 80% OK product then you just need to live with the dodgy 20% bit.
I agree with the danger of big customers though! If you ever think something is a way to avoid hard decisions, pivots and annoying some of your customers, then it is too good to be true ;-)
I'm far from being a developer perfectionist, I wouldn't spend 10 years in this company if I was one, trust me (btw we fired a lot of them along the way).
The point of the article is not to convince anyone to slow down as much as possible and work on bugs/etc. It's just that at some point (3, 4 years in?) there comes a time that you just have to put more effort into the things I described, otherwise it gets complicated fast.
Obviously there is a tradeoff, my opinion is that this tradeoff wasn't correctly balanced (especially further down).
I think the article starts out sounding that way --- but reading all the way through, it's about how to DO BETTER if you want to ship more often (the key take aways from the article being: document, iterate/revisit, and be intentional)
Firing perfectionists is a strange signal. If the customers are sufficiently large, you should do everything possible to please them; beyond revenue, they are themselves an asset (sometimes a company is acquired for this only). In many industries it can take years to establish yourself as an approved vendor for a large org, and especially to a large enterprise company, this can be worth more than the underlying business. Not suggesting that’s the case for Base, but if you’re not gunning for an IPO, your exit strategy isn’t going to be one that necessarily resonates with a product or eng team.
I worked at a large web development company. The one thing which continually hamstrung the company was we had several large customers who were paying us a good chunk of money to maintain their web properties. They sucked up so much of our resources to keep them happy that other smaller customers suffered as a result.
The amount of churn we had was always the smaller clients who were still paying good money but felt neglected and would be open to changing vendors.
We went out of our way to mind the big clients and thought if we lost these few big clients it would so dramatically adverse the companies bottom line, we couldn't afford to lose them. This resulted in a situation where they were able to hold our company hostage, make unreasonable demands on time and energy and hamstrung our ability to keep our more loyal clients (who only bothered us on occasion) happy.
It was a good lesson there is a danger when you have a small company servicing a much larger company that you get into a position where your fear of losing them is a detriment to your other, more faithful clients.
The truth is that the world is a complex place and you don't always know whether you can keep your existing customers by improving what you already have or get new customers to decrease the risk of declining income. It is hard to measure what is acceptable tech debt and what is worth addressing.
In one sense, the proof is in the income. If you can help customers with an 80% OK product then you just need to live with the dodgy 20% bit.
I agree with the danger of big customers though! If you ever think something is a way to avoid hard decisions, pivots and annoying some of your customers, then it is too good to be true ;-)