Leveling Up Hacks - Think Ten Steps Ahead
One simple habit that's accelerated the careers of top ICs.
I've noticed that the most successful individual contributors share a particular trait.
They don't just stay one step ahead — they think ten steps ahead.
Instead of reacting to problems as they arise, they anticipate what's coming next. As a result, clarity follows. They leverage proactiveness to showcase their leadership and ownership skills, eventually leading to recognition and promotions.
I want to share and break down that skill with you today: Thinking Ten Steps Ahead.
Welcome to the 500+ new subscribers since the last edition of this newsletter. If it's your first time here, welcome! I've been writing a series called Leveling Up Hacks. These are tips and tricks that I've seen throughout my 15-year-long career. These hacks have helped me grow in my career, and I hope they help you too. If you want to check out previous articles, here's Share Your Progress and Take A Step Back.
Importance of Thinking Ten Steps Ahead
Why is thinking ten steps ahead important? There are three key reasons:
Extreme scenario planning: Thinking ten steps ahead stretches your mind to consider unlikely scenarios or even black swan events.
Anticipates needs ahead of time: Discovering needs before reaching them will help you prepare for these scenarios. Planning for capacity and scalability is a great example here.
Builds and strengthens key relationships: Use this as an opportunity to build relationships with others. For instance, if your project will impact an infrastructure team, use this chance to reach out and build your network. You never know when it'll come in handy.
Thinking ten steps ahead showcases your proactiveness, which shows you take responsibility for your goals and ultimately your life.
I like to frame proactiveness in terms of three themes:
Scenario Planning
Communication
Managing Timelines
I'll provide questions within each theme to help guide you through it. These questions overlap with each other and are not necessarily disjoint.
Consider the situation you're in, and utilize these questions as necessary.
Scenario Planning
Scenario planning is key to identifying blind spots that you might have missed.
Ask yourself: What could I be missing? What are some situations that this might turn into?
Example 1: If you're leading about a product launch, you could think: How does this product look when launched? Did we miss any potential use cases? Will users complain if they hit a problem? How would they feel?
This could ultimately lead to discovering new edge cases, such as a developer who fails to receive a payout because you missed a tax form during onboarding.
Example 2: If you're refactoring code, you might ask, "How will others use my code after it's been refactored? Is it readable enough? How can I ensure that future folks don't make the same mistake I did here?"
By ensuring that others don't fall into the same trap, you're helping your team and showing that you can think bigger. If you're already used to thinking like this, great! Try taking it a step further, e.g., from team to organization, organization to company, and company to the industry. Every layer you apply this to gets harder, but if there's enough overlap, the rewards also dramatically increase.
Ask yourself: What could go wrong? What do I do in these cases? How do I handle it?
Example 1: If you're about to launch a big product, you can hold a pre-mortem with your engineers. These exercises are helpful because they bring the team together and help them make a plan for each situation.
Identifying unforeseen scenarios is only the first step. Coming up with a plan to address this takes this one step further. Once you have a complete pre-mortem, work out a response plan with POCs and show you have covered all the blind spots.
Communication
This is the marketing side of your project. You need to constantly communicate before, during, and after your project. You also need to know who and when to communicate.
Communication is crucial in all companies. I've also noticed that the larger the company, the more often you have to repeat yourself due to the noise within the company.
Ask yourself: Who are my key stakeholders? Who would be interested in what I'm up to? And why would they be? What would happen if I didn't inform them?
Example: You are building an RFC, and want to gather feedback. You could find five engineers/teams most impacted by your proposal, and reach out to them individually to collect feedback. These people would want to know because your project directly affects their work. To find them, think of who would be upset if you didn't inform them beforehand.
Ask yourself: How do I inform them? What's the best format? Emails? Slack messages? Forum posts? Meetings? 1:1s?
With so many communication methods, you want to find the one they're most receptive to. This takes a bit of spying and understanding of the situation. You can find folks who've done the same thing before and learn from them. Pro-tip that I learned from a previous colleague at Lyft: If you ever come across a great piece of writing, save it for future use.
Example: I'm looking to write a project update. I remember other engineers leading a similar project, sending weekly emails, and getting pretty good responses. I'm going to give that format a shot and start measuring feedback.
Ask yourself: When do I inform them?
This point is essential: you need to know when to inform someone. You don't want to catch someone running to a meeting to tell them about your project update. Find a time when people aren't overloaded.
Example: For instance, if most folks have meetings on Tuesdays and Thursdays, utilize the other weekdays. If you have a lengthy update, mornings tend to work best since that's when most folks are mentally refreshed. IThat might be your best time if you see folks read updates in the late afternoons before they clock out
Ask yourself: How do I help my audience?
Last, you want to understand how you can help your audience. Similar to building a startup, you have to be helpful.
Example: if you're contacting oncalls to notify them, provide them with a handbook to handle emergencies. If you're reaching out to the teams that will be impacted, try thinking from their perspective and offering solutions. This way, when you frame it, you can soften the impact on your audience.
Managing Timelines
Ask yourself: How do I set expectations low and over-deliver? How can I make sure I have time for handling unexpected situations?
For every deliverable, I inject at least a 30% buffer. This gives me enough time to handle emergencies and breathing room for my team.
When communicating externally outside of my team, I add even more buffer. The further you communicate, the more buffer you have to add. External promises are harder to change, and your reputation depends on them.
Example: I know we can achieve a deliverable deadline of April 15th. I added a couple of buffer weeks and told the managers I work with within my organization that we'll be done by May 15th. Externally, I mentioned to other teams that we would finish by June 15th. These buffers will allow me to handle unforeseen circumstances.
Ask yourself: If timelines are about to slip, who do I need to notify immediately?
This harkens back to communication — your key stakeholders must be always kept up to date. For most engineers, these are the managers of the teams you work with. For larger projects, they will be the entire XFN team.
Also, only ring alarm bells if you are certain that your timelines will slip. You don't want to be the boy who cried wolf too early.
Example: Despite adding all the buffers, we had a showstopper bug, which is going to delay the project by three months. I work closely with the team to determine our next best date, show that we're making progress on the bug, and notify all the relevant XFN. I also work with the product managers to determine a new timeline to inform leadership.
That's it! Thinking ten steps ahead and being proactive might sound tough, but you can hone this skill well with enough practice.
Have feedback/thoughts? Leave a comment below.
What else am I reading/watching?
I've been studying communication techniques from Vanessa Van Edwards. She gave two excellent talks on body language that I suggest watching on YouTube (Talk One, Talk Two). These have helped me improve my communication skills. I strongly recommend it if you have time this weekend.
I've also been checking out
’s lightning talks on Maven. She explains how to ask for sponsorship, which is a huge driver of career growth. If you haven't seen it, give it a go.
Thanks for the shout-out! 🙏😊