On data, dates, and deliverables
Years ago I created a document called “The Book of Ian” (juvenile title, I know) and shared it with my team. The document contained objective guidelines for communication about data, dates and deliverables. My goal in sharing it was to codify the (high) standards I wanted my team to meet, and that I would try to meet myself. I decided to dust off and update the document, and also renamed it in the process. I present, for your review and discussion, the Operator’s Manual, 2014 edition. - @ianmcall
On Communication:
Answer the question
Answer first, then explain
Be concrete
When questions should be answered by a date
Who questions should be answered by a name
How much/many questions should be answered by a number. Dates, dollars, percentages. Define your units.
Avoid weasel words (should, could, might, etc.)
Own your problems. Don’t be defensive. “Yes; my mistake. Won’t happen again.” “I don’t know. I should know. I will have that information for you by Friday.”
On Data:
Assume the best answer to any question is data. Data first, interpretation second.
Be precise. Define metrics precisely. Make sure data ties together precisely. Root out error.
Provide absolute and percentage values.
Specify the time range.
If the data you need is not available, make it available. 1) Define what data you need, 2) Create a backlog item, 3) Agitate to get it prioritized appropriately.
Snapshots (i.e. data points) bad, metrics good. In doing the work to get a data point you’ve done 50% of the work to create a metric. Create the metric once so you don’t have to keep creating snapshots.
If it is difficult to determine if the data shows something is good or bad, look for comparative benchmarks elsewhere in the company.
On Deliverables:
Ask for clarification if you are unclear on expectations (due date, format, content).
If asked for a deliverable by a certain due date, send the document by that date or schedule a meeting to occur by that date and bring any requested documents for review.
If asked to schedule a meeting to review a deliverable, you are expected to schedule the meeting.
On Dates:
Be conservative when providing dates and expect to be held accountable.
I don’t like pushing dates back. Given the choice, I will always prefer to move them up.
Assume that every date you give me will be relayed to our CEO with your name and the deliverable attached to it.
COB = Close of Business (5:00 pm)
EOD = End of Day (midnight)
EOW = End of Week (Friday, 5:00 pm)
P.S. Standard disclaimer: This post contains my personal opinions, not my company’s.
Great working principles, Ian!
I remember a similar version you shared to the Delivery Experience team at Amazon, and it was very useful. Thanks for making it public.
One comment: it can feel a bit stern in its current do’s/don’ts form, and hence may appear bossy. What about spicing it up with some emojis?