Getting things "done" in large tech companies

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 value they can to their company. From the perspective of their manager and skip-level, they’re not getting anything done.

What does it mean to get things done in large companies? Most importantly, it means finishing things. How can you finish things in a world where you can keep improving systems indefinitely? It means getting them to a point where the decision-makers at the company are happy. At that point, you have to declare victory and walk away! Go and do something else! I’ve seen many engineers stick around delivering one more tweak or one more refactor - long past the point where their work stopped being perceived as a successful project and started being perceived as wasted time. Better to deliver two more things in that time.

Second, it means delivering the kind of things that are legible to the decision-makers at the company: i.e. visible to your manager, plus 1-3 skip levels, depending on your title. The easiest way to do this is to deliver things that they already know about, such as projects that they’ve asked you to do, or incidents that are serious enough that they’re involved in them. It’s possible to make other work legible to them as well. If your work produces or saves money, that will make it immediately legible, for instance (or you could just be really convincing). By default, work you do isn’t legible: to the decision-makers, it’s generic technical nonsense. They don’t know whether it’s crucial high-impact work or pointless code reshuffling, and will tend to assume the latter.

In short, getting things done means getting them in a state where:

(a) executives at the company understand what’s happened, and (b) are happy with it

To many, this will be an unsatisfying definition of what it means to get things done. Lots of engineers will want a more solid definition than “it’s a social construct”. However, as someone with a philosophy background, I have a healthy respect for social constructs. The concept “chair” is a social construct, and chairs are plenty real[2]. In some ways, “getting things done” is even more real. It can pay your rent! If you don’t respect it, it can even get you fired.

Summary

• Just because you’re doing work doesn’t mean you’re getting things done
• Nothing is ever “done” in the non-abstract world. Everything can be worked on indefinitely
• If you want to get things done you can’t be a gardener. You have to aim for a bullet-point list of achievements
• So what’s “done” mean in that context? It means the company is happy with the state of it
• Declare victory and walk away: go and do something else!