"As companies get larger and more complex, there’s a tendency to manage to proxies. This comes in many shapes and sizes, and it’s dangerous, subtle, and very Day 2.
A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. Gulp. It’s not that rare to hear a junior leader defend a bad outcome with something like, “Well, we followed the process.” A more experienced leader will use it as an opportunity to investigate and improve the process. The process is not the thing. It’s always worth asking, do we own the process or does the process own us? In a Day 2 company, you might find it’s the second."
It's not immediately clear to me, and as such makes an otherwise good-looking argument feel less "solid".
"Amazon.com passed many milestones in 1997: by year-end, we had served more than 1.5 million customers, yielding 838% revenue growth to $147.8 million, and extended our market leadership despite aggressive competitive entry.
But this is Day 1 for the Internet and, if we execute well, for Amazon.com."
Bezos has attached the 1997 letter to every letter to the shareholders he has written since. There is even a building in Seattle named Day 1.
 https://www.amazon.com/p/feature/z6o9g6sysxur57t (bottom half of the page)
You'll notice for example that even my initial comment pointed the guy to the answer (i.e.: it's in the third paragraph of the link).
Now, both requirements aren't opposite, someone could have made a comment like this: I like Bezos's notion of a Day 2 company, how it differs from Day 1, etc.
Basically, I like people to show that they aren't asking someone else to do the work for them (or, if they are, at least they made some attempt).
That's at least as reasonable a position as the one you just expressed IMO.
"In particular, their poor handling of software development has been well known for many years. The answer to the WMF's problems with software development has been well known for decades and is extensively documented in books such as The Mythical Man-Month and Peopleware: Productive Projects and Teams, yet I have never seen any evidence that the WMF has been following standard software engineering principles that were well-known when Mythical Man-Month was first published in 1975. If they had, we would be seeing things like requirements documents and schedules with measurable milestones. This failure is almost certainly a systemic problem directly caused by top management, not by the developers doing the actual work."
"This is not to imply that decades-old software development methods are somehow superior to modern ones, but rather that the WMF is violating basic principles that are common to both. Nothing about Agile or SCRUM means that the developers do not have to talk to end users, create requirements, or meet milestones. In fact, modern software development methods require more communication and interaction with the final end users. Take as an example the way Visual Editor was developed. There are many pages of documentation on the WMF servers and mailing lists, but no evidence that any developer had any serious discussions with the actual editors of Wikipedia who would be using the software. Instead. the role of "customer" was played by paid WMF staffers who thought that they knew what Wikipedia editors need better than the editors themselves do. Then they threw the result over the wall, and the community of Wikipedia editors largely rejected it. Or Knowledge Engine, which was developed in secret before being cancelled when word got out about what the WMF was planning. Another example: The MediaWiki edit toolbar ended up being used by a whopping 0.03% of active editors."