Leveling Up Hacks - Take A Step Back
A crucial skill to learn if you want to level up fast
Welcome back! This is my second in the series of Leveling Up Hacks. If you missed the first, it's over here, where I talked more about how sharing your progress helps you level up faster. Now, let's dive into the next hack.
One of the most counterintuitive ways to level up as a software engineer isn’t about writing more code, learning a new framework, or grinding through JIRA tickets.
It’s about knowing when to take a step back.
What does stepping back mean? It means zooming out to see the bigger picture. Identifying blind spots. Understanding the why before jumping into the how.
As engineers, we love solving problems. But sometimes, we get so caught up in execution that we don’t stop to ask:
Are we solving the right problem?
What trade-offs are we making?
How does this fit into the bigger picture?
The ability to step back and see the forest instead of the trees is what I've seen separates senior engineers from mid-level ones. Funnily enough, it’s a skill that doesn’t come naturally. Slowing down feels like the opposite of progress because we've been so geared to keep pushing and hustling.
You need to take a step back in your projects and daily life.
Fitting into the Larger Picture
I've mentored many engineers who struggle with the same issues of not achieving a promotion.
The reason for denying their promotion, as they hear from their managers, was that there was no "business impact".
That's because these engineers who only focus on their piece of the puzzle struggle to make an impact. Conversely, engineers who see how their work fits into the system—technically, organizationally, and especially from a business perspective—become invaluable.
If you want to level up, you need to (1) understand your stakeholders, (2) map out system interactions and (3) eliminate redundancies while working on your project.
Understand Your Stakeholders
A key part to fitting into the large picture is understanding who will benefit from your project.
Ask yourself:
Who will be the biggest beneficiary of my project? Customers? Other engineering teams within the company?
How will they benefit from my work? Can I tie my work to their success? Is their success directly correlated to the company metrics?
Example: I'm working on a project to help advertisers create ads on my site in one simple step instead of three. We hypothesize that a simpler process will improve conversion rates by 5x. This will help increase company revenues.
In this example, it's easy to see how your project has impact on the company.
Found this helpful? Subscribe to make sure you don’t miss new articles and guest posts.
Map Out System Interactions
Understanding how your feature interacts with the rest of the company's systems is essential to figuring out how you and your project fit in the bigger picture.
As you work on your project, ask yourself:
How does this feature interact with other parts of the system? Which other systems can I integrate with?
What will collide/clash with my project? How do I reduce those risks? Are those stakeholders aware?
This reflection helps uncover dependencies, potential conflicts, or even opportunities for synergy between components.
Example: You're adding a new payment module to an e-commerce platform. You review how this module will communicate with the inventory and order processing systems. Although you're working with the Orders team, you forgot to reach out to the Shipping team about your feature. You give them a heads up now, so they can expect a deep collaboration in H2 where they can utilize your project.
In this example, you're making sure that your project will have impact on other teams going forward.
Eliminate Redundancy
Evaluating whether your work overlaps with existing efforts helps conserve resources and prevents unnecessary duplication.
Ask yourself:
Is this work redundant with something else happening?
Or is it redundant because something similar already exists?
Example: Consider a scenario where your team proposes a new user notification system. Before proceeding, you discover that another team is already developing a similar messaging feature. Instead of duplicating effort, you coordinate to consolidate features and systems, saving you time.
In this example, you've made sure that you're not trying to re-build something that was already done. Instead, you're leveraging it to claim even larger impact.
Now let's look at other scenarios of when to step back.
Found this helpful? Subscribe to make sure you don’t miss new articles and guest posts.
Taking a Step Back in Your Daily Workflows
Here's the next part to keep in mind. It's not only essential to take a step back on the projects you're on, but also on a day-to-day basis.
Each day, we're working daily in pull requests, technical documents, and meetings. In each of these, you must remember to zoom out and see the larger picture.
Let's walk through four of the most common situations where you must zoom out.
1. When the conversation jumps too deep into details
Example:
A team is debating which API design pattern to use. One teammate suggests REST, another argues for GraphQL. They’re both deep into pros and cons, and have not even aligned on why they were solving this problem.
What to say:
"Let’s take a step back for a moment. I’m afraid we’re diving too deep—can we first align on our goal? What’s the main use case? Who are the consumers of this API?"
Suddenly, the conversation shifts.
Instead of debating syntax, you find yourself discussing business needs. You're now setting a common goal for both parties.
Take note that in this example, I used "our" instead of "your", because it helps to remind everyone that they are on the same side.
Found this helpful? Subscribe to make sure you don’t miss new articles and guest posts.
2. When the conversation lacks depth and focuses only on breadth
Example:
During a sprint review, the team is busy patching minor UI bugs after every release. Instead of questioning why these issues keep recurring, they fix one bug after another. Here's where you should jump in.
What to say:
"Why do these bugs keep happening? Is there something in our process that’s causing them? Have we analyzed the root cause?"
This question shifts the focus from treating symptoms to investigating a deeper problem. You might discover that a lack of end-to-end testing is at fault, not the UI itself.
3. When the solution isn’t comprehensive enough
Example:
A team is planning to build a custom analytics dashboard from scratch. However, it doesn't cover all the areas that your team needs.
What to say:
"Did we look at what’s available out there? Are there alternatives we haven’t considered? Have we looked at third-party solutions? Would using an existing tool be faster and cheaper?"
By asking these questions, you force the team to ensure they've done their due diligence when looking at analytics tools. These simple questions could save everyone weeks of development time by avoiding the reinvention of functionality already available elsewhere.
Found this helpful? Subscribe to make sure you don’t miss new articles and guest posts.
4. When the conversation gets heated
Example:
In a design meeting for a new feature, the discussion quickly escalates as team members become entrenched in their opinions. Recognizing the rising tension, one engineer interjects by suggesting,
What to say:
"I appreciate everyone's enthusiasm, but it seems like our emotions are taking over. How about we take a short break, revisit our primary objectives, and look at the data to guide our decision?"
This is a fun one that happens more often than you think. Left unchecked, conversations can quickly turn into heated debates.
By intervening and requesting a break, the team can step back, review key objectives, and ultimately find a solution that incorporates the best ideas from all sides.
Remember, you shouldn’t intervene in meetings/docs all the time. If you step back in every single conversation, you’ll slow things down instead of moving them forward.
Here are my three tips of knowing when to intervene:
Pick your moments – Use this when discussions start to derail, not at every minor decision.
Avoid overuse – If you constantly say, “Let’s take a step back,” people will know that all you're doing is trying to zoom out. Try different phrases like "Let's zoom out" or "Have we considered looking at it from this perspective?"
Watch your tone – Delivery matters. If you sound condescending, people will resist. Remember that you are not here to judge but to help the conversation move along.
TL;DR
Stepping back is a crucial skill for engineers if you want to level up.
Focus on why before how.
Take a step back in both your projects and day-to-day work.
Know when to step back — when discussions get too deep, off-track, or lose direction.
Next time you’re deep in execution, pause. Look around and ask questions.
That’s how you level up.
If this piece resonated with you, like, comment, and share with your friends.
"I appreciate everyone's enthusiasm" - what a diplomatic way to say "shut the fuck up everyone". Love it