Nailing the basics: How to deliver high-quality work products
Being a high performer and getting promoted requires getting the basics right — but most people neglect them
We all want to skip ahead.
When I started my undergrad, many of my classmates were mentally already “done” with the program and thinking mostly about the consulting, investment banking or tech jobs they wanted. Grad school wasn’t much different.
Similarly, when people play video games, they can’t wait to get to the so-called “end game” (the part after you finish the “main” game). There is a whole industry of people who play the game for you so that you can skip that part.
It’s the same at work: Young, ambitious people start a new job and immediately try to figure out how they can get promoted.
The thing is, though: If you want to be successful, you can’t fast forward and skip a bunch of steps in the middle. For example:
If you want to lead large projects, you first have to learn to deliver small tasks
If you want to be a good manager, you first have to be a good IC
And so on.
I propose a new framework for this: The Hierarchy of Work.
It’s inspired by the Maslow Hierarchy of Needs, a psychology framework that makes the point that you first have to satisfy basic needs like food and safety before you are motivated to pursue higher-level needs like belonging and love.
With the Hierarchy of Work, I claim instead that you should focus on getting the basics right before you move on to next-level tasks and opportunities.
People are naturally drawn to stages 3 - 6 because they promise more money and prestige, and as a result, they neglect stages 1 and 2.
However, I’d argue that:
A person with average talent that focuses on nailing the basics will have a higher impact than someone with exceptional talent that neglects them.
I’ve had this conviction for a while, but the positive reception of my recent post on how to run better meetings has convinced me to kick off a series of posts dedicated to these foundational topics.
In this series, I will cover how to nail the following basics (many of these are important for any job):
👉 Part 1 (this post!):
Part 2:
Part 3:
Part 4:
As always, we’ll cover tons of actionable real-life examples.
Let’s get into it.
How to deliver high-quality work products
Why am I starting this series with “delivering high-quality work products”?
Well, simply put, people assume the quality of your deliverables is a reflection of your skill. While that’s not always true, it’s at the very least a reflection of your effort and care.
And I’m not even talking about “big” deliverables like new products or processes you launch. Anything tangible you share with others will be judged.
As a result, raising the bar on the quality of your day-to-day output is key if you want to stand out and ultimately get promoted.
And to be clear: This has nothing to do with perfectionism. I’m not saying your internal work products should be pretty and you should spend a lot of time polishing them.
I am saying, though, that thoughtfulness and a few minutes of effort can make them an order of magnitude more impactful.
We will cover:
💾 Data: How to make sure it can be trusted and how to present it
📊 Models & spreadsheets: How to make them easy to use and interpret
📝 Documents: How to write docs that impress even executives
🖼️ Slides: How to create slide decks that tell a convincing story
If you’re only interested in some of these, feel free to jump to the respective sections.
💾 Data
No matter your role and what project you are working on, you’ll likely present data at some point.
There are four steps to getting this right:
Step 1: Making sure the data is pulled correctly
Step 2: Simplifying and cleaning up the data
Step 3: Formatting the data for instant takeaways
Step 4: Visualizing and telling a story with the data
We will cover 1 - 3 now. Data visualization and storytelling is an important topic that deserves its own post, so I wrote a separate deep dive here.
1. Making sure the data is pulled correctly
Now, you either pulled the data yourself, or somebody pulled it for you.
If you pulled it yourself, make sure you’re using trusted metric definitions from your BI tool (e.g. Omni or Looker) or dbt.
If your company doesn’t have either and you’re pulling metrics by writing SQL against raw warehouse tables, make sure you check the following at the minimum:
Are your joins working as intended?
When you write a complex query with multiple subqueries or CTEs, it’s easy to lose track of what’s happening.
Make sure you check the output of any intermediate step by itself before you combine them to a final query.
Are there unexpected duplicates in the data after the join?
Did any data get dropped from the original tables although you didn’t want that?
As a reminder, here are the most common join types; the blue area represents the records that will be kept after joining two tables A and B:
Are you using all relevant filters?
It’s not always immediately obvious what filters (WHERE clauses) need to be applied to get the correct data cut.
Ideally, you check with a subject matter expert that knows the ins and outs of the dataset your’e working with.
If you can’t find anyone, your second-best bet is to look at queries other people wrote (e.g. by looking at the data sources behind trusted dashboards in your company).
Whether you pulled it yourself or not, you need to sanity check the data:
Does the general magnitude make sense? E.g. if you pull a customer number that is larger than your user data, something might be wrong. You likely have >= 1 user per customer
Does the data match known sources of truth? For example, if you pull commonly used metrics like user counts or revenue, there will be dashboards that show the same data. If your data is materially different, you need to understand why.
2. Simplifying and cleaning up the data
Before you present the data, you need to remove excessive detail.
Many analysts produce tables like this:
Some best practices you should follow:
You rarely need more than two decimal points for a number, and often you don’t need any at all
Make sure the data is readable by humans (i.e. no weird acronyms and column names)
Clearly show units (e.g. $k) for any numbers
You usually don’t need to show the entire “long tail” of the data (i.e. you can group small segments together)
Now let’s look at the cleaned-up version:
Which one do you find easier to read?
3. Formatting the data for instant takeaways
A little bit of advanced formatting can make a massive difference for your audience.
Sorting data
Take a look at this (made-up) table of DoorDash data by city, for example:
What is the takeaway? Which metric should you pay attention to?
By simply sorting the table by the most important metric (for the point you’re trying to make), you make the data much easier to understand.
Let’s say you want to show in which markets we’re more or less efficient than the competition:
It’s immediately clear that in San Diego, we are paying way more per trip than other delivery companies.
Conditional formatting
While the sorted table is better, it still has a major problem: It takes some effort to really interpret the deltas in the last column.
How much worse is San Diego than other cities?
Which cities are better or worse than the competition?
Conditional formatting solves this problem.
It’s easy to do (here’s an example in Google Sheets)…
… and makes data much easier to digest:
Highlighting thresholds or cut-offs
Conditional formatting is already a step in the right direction; but you can go one step further by explicitly highlighting important thresholds.
In the example above, you could draw a line between Philadelphia and Atlanta, but the chart is pretty easy to read even without that. It becomes more important if your table is a bit more complex.
Check out this sensitivity table:
The company is interested in launching the new business if it can generate more than $500k in revenue. Because of that, the table is conditionally formatted to show numbers below $500k in red and above in green.
But it becomes even easier to read if you just draw a “border”. Any scenario below border is acceptable, those above are not:
📊 Models & spreadsheets
No matter what your job is, chances are you’ll be creating spreadsheets.
At first glance, it seems simple enough: You open Google Sheets or Excel, dump a bunch of data in, and do some calculations.
But as always, the devil is in the details. Following some best practices can help you prevent mistakes and make your spreadsheets much easier to read for others:
Keep calculations simple and transparent
When someone looks at your spreadsheet, they don’t want to have to click into every single cell to see what’s going on.
Similar to writing code, simplicity is key. As a general rule:
Avoid doing complex calculations in a single cell. Show your work and break calculations out into individual steps. Most formulas should just be simple additions, subtractions and multiplications
In the same spirit, don’t put hardcoded numbers in a formula. Put them in a separate cell and reference them.
Keep rows / columns consistent. For example, in a financial model, the calculation in every single cell in a row should be identical. If you do have to make an exception, clearly mark it and put a comment explaining why.
Show your sources
You’re not an investigative journalist; you can and should reveal your sources.
Put yourself in the shoes of somebody opening your spreadsheet. They look at the numbers, and might wonder why they’re different from what they expected (e.g. lower than what they saw in a dashboard).
And when they trace back the formulas to see where your data is coming from, all they find is a block of hardcoded numbers.
How are they supposed to figure out why the data doesn’t match if they don’t know where it’s from and how it’s defined?
Worst case, people will assume you’re this guy:
The solution is simple:
If you took the data from a dashboard, or got it from an external source like a website, add a comment and link to the source
If you pulled the data via SQL, add a link directly to the query you used (remember to give read access to others in your settings)
Add a user guide / readme
If you are building a model with multiple tabs, it can be hard for others to understand how the whole thing works.
The simple solution: Add a brief “readme” tab at the beginning of the spreadsheet.
Here, you give an overview of:
What the model is (and isn’t) supposed to be used for
What the individual tabs do, and how they work together (e.g. users might have to update the “Inputs” tab before moving on to the “Model” tab).
Use consistent formatting
The point of formatting in a spreadsheet is less about making it pretty (although that’s a nice side effect), and more about making it clear what each number is without having to click into the cell.
Any number is either:
A hardcoded number (blue font; plus a yellow background if it can be changed)
The output of a formula or calculation (black font)
A reference to data outside of the sheet (green font)
Check formulas and outputs
Before you share your spreadsheet, you should do some checks to find any potential errors.
Check that you “pulled” all formulas down / across
When you make a change to a formula, it’s easy to forget to make that change everywhere that formula was used.
Check for errors
You can just hit CTRL + F (Command + F for Mac) and look for the most common types:
#N/A, #ERROR!, #REF!, #NAME?, #DIV/0
Sanity check your output
Do a quick check of the outputs of your model to spot any “odd” numbers or trends.
One of my favorite ways to do this is to create charts of the most important metrics in your sheet; it’s much easier to spot outliers visually, and it only takes a few minutes.
Keep track of versions
While tools like Google Sheets have a basic version history, you still need to put a bit of effort into documentation.
I once spent an entire evening trying to dig up a specific version of a spreadsheet that I had (apparently) shared with Finance and almost had a nervous breakdown over it. I definitely learned my lesson.
You have two options:
Name versions in the version history
At a minimum, you should highlight important versions of your spreadsheet in the history. In Google Sheets, it works like this:
Create an “index” of your most important spreadsheets and their versions
This is the real pro move. It takes only a few minutes of effort, but I’ve seen people up to the C-level be impressed by this.
It can be as simple as this:
📝 Documents
In my experience, many documents are incredibly hard to make sense of.
They often feel like a brain dump or stream of consciousness rather than something that was structured intentionally.
But hey, that’s good news — it means it’s easy to stand out.
Write with your audience in mind
Before starting to write, ask yourself: “Who are you writing for?”
Your document will need to look very different depending on the audience; e.g. for Data Scientists or Engineers, you would include more technical details, while for executives, you would focus on the big picture.
And remember the golden rule: You should focus on what the audience needs to hear, not what you find interesting to share.
Nobody cares about a chronological recap of all analysis steps you went through; instead, they want to know:
What does this mean for me?
What are the implications and next steps?
State the context and purpose of the doc
Make it clear to the audience why you are writing this document.
For example, are you trying to drive a decision or is this just documentation?
If the document is a part of a larger work stream, share some context and link out to other relevant resources.
Make the document easy to parse
Avoid big chunks of text.
Instead, use bullet points, tables and visuals. If something is important, highlight it.
Address expected questions & concerns
When you’re covering a controversial topic, documents can sometimes cause chaos.
What starts with a few questions quickly turns into 12-message-long comment threads that are impossible to keep track of.
But: You can prevent that from happening if you anticipate the most likely questions and concerns your stakeholders will have and address them in an FAQ section:
Keep track of reviews and approvals in the document
Many documents either need to be reviewed or approved by different teams (e.g. launch plans, marketing budgets etc.).
Make sure you have a dedicated section in the doc for that; this avoids situations where you thought everyone was aligned, but they later claim they never agreed.
Make it clear who wrote the doc and when it was last updated
When people read your document at some point in the distant future, they’ll want to know 1) who they can reach out to and 2) how current (or outdated) the content is.
🖼️ Slides
Slide decks have a bad reputation. Some companies like Amazon have even completely replaced them with memo.
While I’m a big fan of memos, slides can be a powerful tool when used correctly. Here’s how you can create an impactful deck:
Rule #1: Tell a story
With a few exceptions1, slide decks should tell a coherent story from start to finish.
The fact that most decks don’t do this is one of the key reasons why people think memos are superior; in a memo, the individual sections have to be connected because it’s one single document.
But how do you make sure your slides tell a story?
Create the outline of the deck before you build any of the slides
If you first jot down what you want the storyline of the deck to be and then create the content, it will be much easier to ensure that it flows well.
Rule #2: One message per slide
One of the biggest challenges with slides is that you have limited space.
You might think that this forces people to be succinct, but in reality, most people just use smaller fonts and shrink pictures until everything fits.
This results in messy slides that are hard to read. Three charts, four text blocks, a bunch of annotations and footnotes? Who knows what the point of that slide is.
Instead, decide in advance what the one key takeaway of the slide should be, and then put exactly the required information on the slide; not more (this gets confusing), not less (you can’t make the argument with incomplete data).
Rule #3: Use action titles
“What’s an action title?”, you ask?
An action title is a slide header that expresses the key takeaway of the slide. For example, instead of labeling the slide “Sales update”, you would write “Sales are up 15% quarter-over-quarter, but 3% below plan”.
This way, you can follow the storyline by just flipping through the deck and reading the headers.
But it’s not just helpful for readers. Remember how we talked about writing the outline before building the slides?
The best way to do this is by creating an empty deck and writing the action title for each slide. You then read through the slide titles and see if the story makes sense:
Is anything missing?
Are some of the slides non-essential?
Rule #4: Add an executive summary for longer decks
Most people are not going to read a 10+ slide deck; they might not even flip through the whole thing to read the titles.
So if you want to make sure they get the key message, you need to create an executive summary slide.
This is especially important if you plan to present to an executive (that’s where the name comes from, duh!):
Most executives won’t sit through an entire presentation; in other words, you rarely get to walk through all your slides.
As a result, it’s often better to just show the executive summary and jump to individual slides if they ask questions that require more detailed information.
What does this mean for the content of your executive summary slide?
The slide should summarize the key points of the deck in bullet point form; you typically won’t have space to include charts, and you don’t need to since you can always flip to the respective slide for a deep dive.
Conclusion and outlook
This post became a bit longer than I planned. But I think that underscores the key point I’m trying to make:
Getting the basics right and delivering high-quality work products is not trivial.
Our day-to-day deliverables are at the core of what we do, and we should make sure we’re proud of them.
Again, this is not about making them pretty or polishing them to perfection, but rather about making them robust and easy to understand to maximize their impact.
If you found this post helpful, stay tuned; we have at least three more parts coming in the future covering bandwidth management and prioritization, communication and collaboration.
I don’t know about you, but I can’t wait to dive into that stuff. See you then!
In some cases, it’s okay if the slides are not connected through a storyline (e.g. update decks where each team provides one slide, or team meeting decks)
I learned to write executive summaries a couple of years ago. I used to write the whole slide deck and then write the exec summary as the first slide. I don’t do that anymore. I first write the exec summary and then expand each bullet point into a slide.
The summary must tell a story. The story should connect to the core need or goal of the reader. If they are interested they will dig into your slides.
This post is a mini masterclass on producing stellar work items that change the game @Torsten Walbaum
Solid advice