The dynamic this creates is that everything is sacrificed at the altar of velocity - including the things that make it possible to do good work, or even stop bad work from getting done. This shows up well on a dashboard but creates a phenomenon that @jmspool.bsky.social calls "user experience rot."
It's a real shame that enshittification as a concept became so diluted, because this is a completely separate phenomenon with distinct causes. Enshittification is when companies degrade the experience to extract more value. Experience rot is when companies lose the ability to make a good experience.
Jared's original article only focuses on the product side, but the degradation of the process is the biggest *cause* of experience rot. Orgs deliberately optimize their ability to ship new features, eliminating any thoughtfulness that may have existed as undesirable friction.
Take for example Threads. Remember Threads? No? That's because it was shit. Not deliberately so - Meta would have loooved to suck in a whole new audience - but because Meta is no longer capable of conceiving a non-shit experience.
Facebook was once legitimately appealing to users! That's the only way to kick off the enshittification cycle. Meta didn't even try to pull that off a second time. Whatever Threads was marketed as, it's clear that its conceptual model is "more features for Instagram users."
Capturing a new generation of users you can lock in and exploit is hard work and risky. Better to just push Threads on every Instagram user and then say "look how many millions we have on our platform, Bluesky who?" to investors and execs. No value was created but that was never the point.
This kind of dovetails into another thread: shipping features that show up on dashboards is the surest path to looking good internally, and the bigger a company becomes, the more that becomes the overriding concern of everyone working there.
@iris-meredith.bsky.social talks more about project management as a control tool here, and how the logic of Scrum migrated into politics alongside the tech bro takeover.
I honestly donāt think the methodology really matters. I donāt especially like daily stand ups but they can be useful in teams that donāt communicate enough. And the end of a sprint should never be considered a deadline. The point is to get a handle on how long things take to help plan.
In my experience a two week release cycle seems about as good as you can get unless you have the scale to be doing AB testing and continuous delivery. Any longer and you get people trying to push stuff in half baked because they donāt want to wait another 3 or 4 weeks to see it deployed.
They donāt even have to show up on dashboards necessarily. I was exhorted by a manager to come up with a āshiny thingā in 2009, and Iām a back end developer.
I am screaming internally
These are excellent points. Most organizations are not set up to think about their products in terms of the value they deliver, only in terms of being the receptacle of more work.
It was eye-opening like 10 years ago when I realized that in Big Tech you get promo for *convincing* people that you did something, not that you actually did something. Folks good at the promo game are almost always "ship it, move to a new team, and let someone else figure out why it's garbage."
Exactly, you end up with "The work got done" and it also becomes irrefutable that it got done. It did get done. It just sucks. And arguing about "Acceptance criteria" just maintains the dynamic of management deciding what complete means. It's all harvesting Watermelons: youtu.be/mQGOUdqEhaw?...