How do projects fail at large tech companies? As I’ve said many times, failure means executives aren’t happy with how the project turned out. At healthy companies, that typically means that a sensible engineer wouldn’t be happy either, because the project didn’t work or users hated it. But what actually causes the projects to fail? I’ve seen a lot of projects go wrong - both up close and at a distance - in the last ten years. Here are the main reasons why. Doomed from the start Lots of projects fail because there’s no way they could possibly have succeeded. In American law, some cases get dismissed at “summary judgment”: even if the plaintiff succeeds in proving everything they aim to prove, it still wouldn’t add up to demonstrating enough illegal activity to win their case. At tech companies, some projects are like that: even if the plan goes off without a hitch, the project is still doomed to fail. Some doomed projects begin with over-ambitious plans. For instance, an executive…

What does it mean to get things done? In the abstract, you can complete a mathematical proof or a problem set, but the real world is much fuzzier. Suppose I plant a tree in my backyard. Once the sapling is in the ground, is that done? Not really. There’s always more work to do: clearing the ground around it, watering, keeping pests away, pruning, and so on. Programming large web applications is more like planting a tree than completing a mathematical proof. Once you write a service, you can keep working on it forever if you want to. In large tech companies, this fact is a trap for competent but unagentic engineers. They see an infinite queue of tasks that they’re capable of doing, and they start delivering a stream of marginal improvements to a particular subsystem. From their perspective, it feels like they’re crushing it. After all, they’re putting out work at their top speed: no downtime, no waiting on other teams. But they’re not doing their actual job, which is to deliver the most…

I have delivered a lot of successful engineering projects. When I start on a project, I’m now very (perhaps unreasonably) confident that I will ship it successfully. Even so, in every single one of these projects there is a period - perhaps a day, or even a week - where it feels like everything has gone wrong and the project will be a disaster. I call this the valley of engineering despair. A huge part of becoming good at running projects is anticipating and enduring this period. The start of a project always feels good. I have a clear idea of what needs doing, and there’s plenty of time to do it. The very end of a project usually feels good too - by that point all the important pieces are ready, and it’s just a matter of getting the final tweaks and bugfixes in. The hard part is the middle of the project, when all these things are happening at the same time: You’re discovering that some of the things you thought would be easy are actually surprisingly hard New requirements have come…

People have been making fun of OpenAI models for being overly sycophantic for months now. I even wrote a post advising users to pretend that their work was written by someone else, to counteract the model’s natural desire to shower praise on the user. With the latest GPT-4o update, this tendency has been turned up even further. It’s now easy to convince the model that you’re the smartest, funniest, most handsome human in the world. This is bad for obvious reasons. Lots of people use ChatGPT for advice or therapy. It seems dangerous for ChatGPT to validate people’s belief that they’re always in the right. There are extreme examples on Twitter of ChatGPT agreeing with people that they’re a prophet sent by God, or that they’re making the right choice to go off their medication. These aren’t complicated jailbreaks - the model will actively push you down this path. I think it’s fair to say that sycophancy is the first LLM “dark pattern”. Dark patterns are user interfaces that are designed…