What I Learnt About Deliverables
First, deliverables should be objective, like “Write a design doc and get it reviewed by the engineers”. Once it’s done, people should be able to agree on whether it was actually done. Deliverables should not be subjective, like “Work on the design”. What does it mean to work on the design? Different people would interpret it differently, causing a problem later on.
Second, deliverables should describe outcomes rather than effort. If you’re hiring, a good deliverable is “Make an offer to two candidates” (outcome) not “Conduct 40 interviews” (effort). The former deliverable might encourage you to think of other ways to reach the outcome with less effort, such as giving a take-home assignment. On the other hand, the latter might encourage you to blindly spend the hours without thinking about how to do it more efficiently.
Third, deliverables should map to business value. In the above example, making an offer to candidates is closer aligned to creating business value than merely conducting interviews. Once you think along these lines, you might conclude that having a candidate accept an offer and actually turn up on the first day of work is even more closely aligned to business value than merely making an offer.
Fourth, deliverables should not include things beyond your control. In the above example of hiring, “Have one person join the team” may not be within your control if you’re a consultant hired to interview, because joining depends on how attractive the company is to candidates. In that case, “Make an offer to two candidates” is a better deliverable than “Have one person join the team”, because the former is in your control. If you accept the latter as a deliverable, you may not be able to meet it, and you might later say that there’s nothing you could have done to meet it, which defeats the point of having the deliverable in the first place.
Fifth, deliverables should be time-bound like “1 month”. This, in turn, raises questions like whether you want more delivered over a longer time or less sooner like “Make an offer to one candidate in a month” vs “Make an offer to three candidates in two months”. Or maybe you can have both deliverables that cover different time periods.
The process of agreeing on deliverables drives such discussions, which is good. In fact, that’s the main value of having deliverables in the first place — to drive discussions that make us understand the work better. Such as identifying tradeoffs. For example, if a deliverable “Make an offer to one backend and one frontend engineer in one month” is proposed, you might respond saying you can’t do both in one month, so we should pick one, which forces us to prioritise which of the two roles is more important. Identifying such tradeoffs on day one drives us to make a decision sooner rather than later, leading to faster progress, and a better outcome. That’s the purpose of deliverables. It’s not just a management activity we do for the sake of doing it, or to determine whom to blame if things go wrong.
Sixth, deliverables should be realistic — if there’s no way you can achieve it, you should reject the deliverable to begin with [1]. If it’s a stretch goal, call it out, such as by proposing a deliverable like “Make an offer to one candidate, or two (stretch goal).”
Seventh, deliverables should be agreed upon in advance, and used to guide the work, not communicated after the fact, where it becomes a blame game. If you’re hiring someone, tell them what deliverables you’re expecting from them. If you’re working for someone, ask them what deliverables they have in mind for you over a month, two months and three months. They should ideally tell you this proactively, but it’s in your interest to ask these questions ahead of time so that you succeed in your engagement, rather than pointing fingers after the fact: “I expected you to do ABC!” “You never told me that!”
[1] Otherwise, when you fail to achieve it, you’ll be blamed. Keep in mind that you’re a professional, not a servant.