How to not drop the ball
How to not drop the ball
Build a reputation for delivering, every time
Developing a reputation for reliably getting stuff done is key if you want to be perceived as a high performer and move up in your organization. This requires you to make commitments and then deliver on them consistently.
In high-growth startups, “process” is often seen as a dirty word; the implication is that it slows things down. There is some truth to that; having worked at large FAANG companies, I have seen firsthand how corporate process can get in the way of getting things done.
But that doesn’t mean you should just be winging it; if you don’t approach your work in a structured way, you are guaranteed to drop the ball sooner or later.
In this post, I am going to break down how you can ensure that won’t happen, even when you’re handling multiple complex projects at once.
I am going to touch on:
How to scope and kick off projects
How to handle multiple priorities in parallel
How to de-risk the process, and
How to deal with blockers
Let’s dive in.
1. Scoping and kicking off projects
At this step you lay the foundation for everything that follows. The resulting structure will guide your work and allow you to keep track of all important pieces.
Scoping projects
At a minimum, you need to define the following:
🎯 The goal of the work stream
👫 Key stakeholders & connections to other work
📋 The shape of the deliverable
⏰️ The timeline
💬 The operating model
Even if the work stream is assigned to you, e.g. by your manager, you will have to ensure that you get clarity on all these points.
Managers rarely cover all of this information proactively, so make sure that you ask for it as early as possible.
🎯 The goal
This sounds simple, but it’s a common pitfall in reality. Any vagueness around the goal of the work stream will create chaos later on, so it’s best to tackle this immediately.
Try to trace the purpose of the project back to the origin. For example, “the CEO needs this analysis” is not sufficient; in this case, you’d want to find out what specific decision the CEO is trying to make and how your work fits in. This will allow you to tailor the shape deliverable to the use case.
If you ever find yourself answering the question “Why are you doing this?” with “I was asked to”, then you haven’t found out the goal of your work stream
👫 Key stakeholders & connections to other work
In order to create an impactful deliverable, you need to understand:
Who is the “customer”? I.e. what team is making the request, and who will ultimately be using the output of your work
How does this work fit into the existing landscape? Nothing happens in a vacuum. Will your work be integrated with any existing resources? Is it intended to replace or evolve prior work in this area? Without understanding the context in detail, your work is unlikely to be adopted
Who is providing key inputs? It’s important to get access to the key inputs early on; if they are not available yet, align in writing on clear dates when others will provide them so you can plan accordingly. Always, always name an individual as the responsible party for a deliverable, never a team. This creates clear ownership and avoids finger-pointing later.
📋 The shape of the deliverable
Once you have clarity on the goal and understand where your work fits in, define the deliverable. What content do your stakeholders expect, and in what format?
Again, it’s important to be as specific as possible here. For example, “a Marketing plan” or “a Sales headcount plan” is too vague.
A properly defined deliverable in this case would look something like this:
A Marketing plan for Sales Qualified Opportunities (SQOs) in Google Sheets, split by country and Sales segment, on a monthly level from January to December 2024
For any deliverable that includes data (e.g. any type of spreadsheet), I highly recommend creating a skeleton of the desired output upfront. This way, 1) there is a perfect shared understanding of what will be delivered, and 2) the team waiting for the deliverable can already make all necessary preparations since the format is locked.
Here is a simple example of what that can look like:
Without the skeleton, there is a risk of misalignment because it is tedious to define all requirements in writing. What countries do we need the plan for? What are the Sales segments by country (note that in the example above, Canada has simplified segments compared to the US)?
If you don’t create a detailed spec for the deliverable upfront, it’s almost guaranteed to create problems and a last-minute scramble later on.
⏰️ The timeline
Lastly, you need to define a clear timeline and make sure everyone is bought into it.
Start with the final deadline, and work backwards.
Set deadlines for inputs. As mentioned above, agree with other teams when they will deliver the required inputs for your work, document these deadlines, and follow up on them.
Schedule reviews. Important work streams almost always benefit from live reviews of the output. Schedule these in advance; otherwise you risk drowning in Slack messages and Google Doc comments when people review your work asynchronously.
Allow time for feedback on drafts. Even if you structure the work stream and set expectations well, if your stakeholders see your work for the first time on the day that it’s due, you’re almost guaranteed to have a bad time (more on that below under “de-risking” your work).
Build in buffers. You’ll need time to review and operationalize the output of your work. For example, if you’re supposed to build an Account Scoring model for Sales, finishing the model by the deadline is not enough. You will need time to review the output, get buy-in, upload the scores into the relevant systems (e.g. Salesforce), train people on how to use them etc..
Finally, document everything in a project tracker that everyone can reference along the way. It doesn’t have to be fancy; the most important thing is that it clearly lists deadlines, deliverables and responsible individuals.
→ Example Project Tracker Template ←
💬 The Operating Model
For larger projects, it’s important to agree with the working group on how you want to work together.
Is the timeline very aggressive? Consider doing regular stand-up meetings (e.g. Mo / Wed / Fri) to check in on progress and blockers
Will people need to collaborate a lot on deliverables? Consider creating a temporary Slack channel for visibility on project-related discussions. If everything happens in DMs, you’ll risk people being out of the loop
How are you going to update the broader set of stakeholders? Consider sending weekly summaries to build confidence in the project’s progress and flag any issues that need broader awareness
Kicking off projects
Once you’ve scoped your project, it’s time to officially kick it off. For larger, cross-functional work streams, a live kick-off is recommended. For smaller projects or those where you do the majority of the work, an asynchronous kick-off via e-mail or Slack can be sufficient.
As part of the kick-off, you should:
Share the key facts about the project (goal, timeline, deliverable etc.; see above)
Get buy-in from the internal customers and stakeholders
Confirm commitments on the inputs you need from others
Request feedback (and incorporate it quickly afterwards)
Don’t delay the kick-off too long just because you don’t have all the facts yet; if you find yourself scoping the project longer than a few days, it’s better to move forward.
By officially starting the work stream and setting a deadline, you are creating pressure that will help you and the working group find pragmatic solutions to plug the remaining gaps in the plan.
2. How to handle multiple priorities in parallel
You’ll often work on multiple projects in parallel, so it’s important to manage your portfolio of projects well. The key here is to scope and kick off all projects as early as possible rather than working on them sequentially.
The main leverage comes from the fact that basically all work streams require another person’s input or feedback at some point; by scoping the work at a high level as soon as you take on the project, you can start the necessary outreach and avoid bottlenecks later on.
This sounds like common sense, but the fact that very few people do this is the main reason for why we get so many unreasonable cross-functional requests (“Can you quickly pull these numbers by EOD and fill out these 3 slides?”).
If you dig in, you’ll realize that in most cases, the person making the request got the ask days ago and simply dropped the ball, causing you an unnecessary fire drill.
Don’t be that person.
3. How to de-risk the process
Even with great planning, things don’t always go the way we want. This is why it’s key to de-risk the process wherever possible. You can do this across a few dimensions:
Work iteratively
When it comes to building customer-facing products, most of us are used to building Minimum Viable Products (MVPs) and iteratively improving them over time based on customer feedback.
When it comes to internal projects, though, we rarely follow the same principles although they apply well.
1. By building an MVP of your deliverable, you can ensure you have something to submit by the deadline (even if it’s not the perfect version you envisioned).
For example, if you’re building a predictive model, you can consider an endless number of features. Start with a simple version that only uses the key features that you think will have the biggest impact, and plan to add more later if time permits.
2. It also allows you to show something tangible to your stakeholders earlier and incorporate their feedback, which will minimize the risk of building the wrong thing.
Some deliverables (e.g. dashboards) are “expensive” to mock up in detail during the scoping phase of the project, so in these cases the priority should be to build a rough first draft for high-level stakeholder feedback.
Stay in control
If you’re the owner of a project, you need to manage the entire work stream, not just the portion where you’re doing the actual IC work.
Based on the project plan you created, you should have a good idea of what critical inputs you need from others, and by what date.
Set yourself reminders along the way and follow up to ensure they are on track to deliver what you need by the promised date. For really important projects, build in a buffer where you plan to review their input a few days in advance of when you actually need it. You’ll be surprised how often the first version is not exactly what you were hoping for.
“The other team didn’t give us the input we needed in time” is not an acceptable excuse for missing your deadline. It’s your job to ensure you get what you need to be successful.
Create transparency
Things are not always going to go as you planned; that’s fine. The most important thing is to keep everyone in the loop on important developments.
You’re blocked? Let the working group know and escalate quickly (see below).
You uncovered new risks or anticipate delays? Flag this immediately so the group can plan accordingly.
The worst thing you can do is to keep information to yourself out of fear of looking bad. A potential delay that gets flagged early can either be avoided, or the affected team can work on backup plans; but if you spring this on people at the last minute, it’s likely to blow up.
4. How to deal with blockers
Following the tips above should prevent a lot of blockers from occurring in the first place. However, chances are you’ll still feel blocked at times.
How you deal with those blockers can help set you apart as a reliable top performer that gets stuff done no matter what.
Act like an owner
It’s crucial not to succumb to a victim mentality. Almost every blocker can be resolved.
It’s easy to feel like it’s up to others to unblock you and you’re helpless until they do. That’s rarely the truth, though. For example, let’s say you contacted a data engineer to walk you through how a certain data pipeline works, and you haven’t heard back.
Instead of waiting, there are a lot of things you can do: Browse documentation, ask in Slack channels, ping their peers or manager to see who else could help, look at the code in Github to figure out what’s going on etc..
If you’re still blocked, escalate the issue (see below).
Break the Slack cycle
With chat tools like Slack or Teams, it’s easy to get stuck in a loop where you get referred from one person to the other without anyone taking ownership, or you feel like you and the other person are talking past each other.
Instead of continuing to waste time on this, walk over to the person you need something from (if you’re in the office) or grab 15 minutes on their calendar.
Even if they can’t fully solve your problem, it puts them on the spot and makes them feel like they’re part of the problem, so at least they’ll feel obligated to help find the right subject matter expert for you.
Escalate quickly
A lot of blockers come from misaligned priorities. You need something from another team, but it’s not the most important thing for them right now.
If the other team’s input is crucial to your project, and your project is important for the company, you should be able to get unblocked by escalating this issue up the chain of command.
It’s crucial to do this early; if you give the other team sufficient time to adjust their priorities, they’re more likely to help you than if you escalate right before the deadline and they have to drop everything immediately (and the relationship is less likely to suffer from the escalation).
Be transparent with the other team. If you reach an agreement that you can’t get to a solution by yourselves, and you let them know you’ll need to escalate (and why), they might still not be happy, but at least they won’t be blindsided. This makes it less likely they’ll resent you for it.
Final thoughts
As you’re reading this, you might think “managing a project like this sounds like a lot of work”.
However, investing the time upfront to properly scope and plan the project will ultimately save you time (and stress!). If you dive into the work without a proper plan and cross-functional alignment, you’ll be be less efficient, more likely to miss the deadline, and more likely to have to re-do work .