The most common error I see is to assume that shipping is easy. The default state of a project is to not ship: to be delayed indefinitely, cancelled, or to go out half-baked and burst into flames. Projects do not ship automatically once all the code has been written or all the Jira tickets closed. They ship because someone takes up the difficult and delicate job of shipping them.
It's surprisingly simple. It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective. If they can't do that, then they themselves are ineffective, and that is the sort of thing that is the responsibility of THEIR manager, and so on up the line. They shouldn't need me (or anyone else) to tell them about what's going on with their damn direct reports!
Case in point: Regular people have spent years watching the price of goods increase "due to inflation," despite the fact that the increase in pricing was mostly driven by — get this — corporations raising prices. Yet some parts of the legacy media spent an alarming amount of time chiding their readers for thinking otherwise, even going against their own reporting as a means of providing "balanced" coverage, insisting again and again that the economy is good, contorting to prove that prices aren't higher even as companies boasted about literally raising their prices. In fact, the media spent years debating with itself whether price gouging was happening, despite years of proof that it was.
When trying to understand systems, one really eye-opening and fundamental insight is to realize that the machine is never broken. What I mean by this is, when observing the outcomes of a particular system or institution, it’s very useful to start from the assumption that the outputs or impacts of that system are precisely what it was designed to do — whether we find those results to be good, bad or mixed.
Systems: The Purpose of a System is What It Does - Anil Dash
But too many of those who fought to advocate for increasing access to healthcare, or other similar goals, have been pulled into the trap of "reasonableness". Reasonableness is a slow method of failure in which the first step is to concede half of the goal up front, the turning point is losing the passion and backing of the most enthusiastic supporters to disillusionment, and the final step is poisoning the well for future efforts by providing a cautionary example of defeat.
Raise your hand if you’ve ever been in a planning meeting, assigning estimates to tickets, and either found yourself multitasking, falling asleep, texting a friend, or otherwise being entirely unengaged in the activity. If so, you’re not alone. There’s this thing about engineering estimates that is sometimes overlooked: they’re not useful in the way that people often think they are. Instead, estimates are often misused; it’s time for R&D leaders to consider a new framework that makes it so there’s one fewer meeting (or at least a shorter meeting) for you to zone out of.
Zenful Estimates: Ditching Task Estimates to Build a Faster Team
Not only does Musk owe a lot of money to his creditors, but he’s knee-deep in litigation that one might argue would never have been necessary had he abided by existing legal agreements, contracts, and labor law. Yes, it can save money in the short-term to stiff your landlord and cloud provider, or to forego state law-mandated severance payments. But it creates a lot of billable hours for lawyers and expensive potential settlements, along with the threat of regulatory enforcement. (As for reputational damage, Musk doesn’t seem to care.)
The person whose public reputation was most damaged by his own Twitter activity was probably Elon Musk, which is why it makes sense that the product roadmap since he took over has mostly revolved around reducing the attack surface for rich and famous users like himself:
I don’t think it’s due to stiff competition, shifting markets, or even tight deadlines—those have always existed. But one significant change has occurred in my daily work routine: I’ve been forced to start working in sprints (usually 1-2 weeks) instead of spending larger chunks of time on larger projects. This shift has had some unfortunate consequences.
That's the New York Times' in-house technology rube, Kevin Roose, for my money the most embarrassing journalist presently working in the English language, recapping a public demonstration of the OpenAI company's new talking version of its famous ChatGPT large language model. If anybody else with a byline at a major newspaper fits more boobery and dogshit critical reasoning into a pair of paragraphs before midnight on New Year's Eve, I will eat a goddamn iPhone live on Twitch. Or pull my head off and punt it into a swamp.
If Kevin Roose Was ChatGPT With A Spray-On Beard, Could Anyone Tell? | Defector