To me part of 10x mindset is seeing most things as a business with an objective. Sometimes that objective gets lost in the name of process. You start accepting projects even when it is not adding a value to the business, but i is done becaude someone wants it. This leaks from the top down. Part of that 10x is to avoid work that is useless.
Implementing unnecessary features also complicates the code. There is a network effect for complicated code -- the more complicated it is, the more complicated you need to make it to add functionality. It's really incredible how fast you can slam the breaks on a project simply by not questioning if you should be implementing something.
On the other hand, feature poor software is not necessarily simple. Simplicity is hard to achieve. It requires a lot of thought and usually a fair amount of iteration. "Don't touch that code because it doesn't have a good ROI" is also a surprisingly good way to slam the breaks on a project.
Maintaining velocity (or even increasing it) requires a delicate balance of avoiding work that will harm you and encouraging work that will help you. There needs to be a dialog between stakeholders and developers that's 2-way to accomplish this.
a delicate balance of avoiding work that will harm you and encouraging work that will help you
Yes this swings both ways. I worked at a startup where every feature improvement was shouted down as a waste of opportunity cost.
They found a decent local maxima but their growth stalled and they degraded into a consultingware company. The more ambitious devs bailed because there was no room for growth.
> I worked at a startup where every feature improvement was shouted down as a waste of opportunity cost.
I'm curious - what were the devs doing with their time, if feature improvements were constantly being vetoed? Were they being kept busy with other tasks which you consider lower-priority, or were they just sitting idle?
>I'm curious - what were the devs doing with their time, if feature improvements were constantly being vetoed?
Yeah it was a really weird culture, there was definitely some quiet time where I would propose a product improvement but still get no traction. Eg the product website was really embarrassingly 90s, they would let us A/B test customer deployments but not their own site.
There also was a lot of repetitive content scraping tasks that should have been improved and resulted in excessive pager duty (hard to explain but think fragile regexes that parsed customer HTML). That was the last straw for me, I'll do pager duty but not every night just because the PHB is a fool.
They mostly burned our time on trivial consultingware requests instead of improving the core product. I eventually started sneaking core enhancements in by padding out the customer work and just not telling anyone.
This is the same PHB who threatened to fire me because I had to rush my partner to hospital with a concussion. Wonderful human being that.
Write code to have an impressive features list in the product, even if half of them have 3 bugs per line of code.
It's not a strategy I approve, but it can be effective from a commercial stand-point, specially if the half that doesn't work is the half barely used in real life.
It was specially true in the past, with on premise software where clients were in a kind of lock-down with the software provider. Today, as we move more and more towards SaaS, this approach is far more risky because your client could easily switch to another service provider.
