Managers only have one phrase in their vocabulary: "Get this one feature out as quickly as possible." Everything else is just making devs 'heard' (so they can get back to feature).

There have been a few variations over the years: "Just focus on the happy path" and "Build the feature now, and we'll work on stabilisation later". This week I heard twice: "The sooner we get the feature out to the customers, the sooner we can gather feedback and change our product".

Anyway you all know the punch line: there's no 'later', there's no 'stabilisation', only the next feature. And the feedback that we get from the customer is support tickets because the product doeesn't work.

Behind every 500 you encounter in the wild, every piece of lost data or missing transactions, there's a manager really good at keeping his devs focused.

▲

jmaker 4 days ago | parent [-]

But the manager gets to report a new feature, a boon to their career, at the cost of the devs’ careers and satisfaction. The manager might be glossing over or just muting any product satisfaction issues, particularly if no one in their line of report directly puts a KPI on that. That’s about company culture.

> "The sooner we get the feature out to the customers, the sooner we can gather feedback and change our product"

Maybe analyze the target audience before shipping? Also an org issue, where a the PO should put their business analyst hat on. I mean, to me it’s a question of competence if the team is supposed to ship something that must be changed (not fine-tuned or improved) - it’s about how much.

	▲	Nextgrid 4 days ago \| parent [-]
		> Maybe analyze the target audience before shipping? The problem is that there’s a risk the analysis finds out that “the product adequately fits our target market’s needs, there’s no easy way to adapt to another market, so most pragmatic approach is to stay put, cut costs and reallocate resources to marketing or other projects”. No product/project manager and very few devs want to hear they’re not needed, so it’s better for everyone is busywork is continuously being made up, regardless of whether it’s actually beneficial for the business. I’ve been at dysfunctional places where the winning strategy would’ve been to just give the whole team a 3-month paid holiday while higher level management figures out an actual direction for the product, rather than desperately thrashing around and causing damage/tech debt that would continuously slow down further development (I originally wrote “that would need to be fixed later”, but who am I kidding, that will never happen).