The mistake that (really good) analysts make.

Early on in my career, I once worked for a manager who (half-jokingly) told me:

You know how I decide whether you're ready for the next level? It's when you can handle everything on this project by yourself, and I don't have to do anything.

This was communicated to me somewhat facetiously, of course. But it turned out to be simultaneously really good and really bad advice.

The good part was obvious. It lit a fire within me and made me aspire to be as independent as possible. So I pushed myself to think like an owner. I also tried to take on as much as I could, in order to show I was "ready."

The bad part, however, was less obvious.

You see, in an attempt to demonstrate "I alone can fix it" – I ended up optimizing for the wrong thing. I started doing things like:

• Making unilateral decisions
• Asking fewer and fewer questions
• Dialing down on check-in frequencies
• Updating people only when things were "perfect"

I was so focused on demonstrating independence, that I saw anything else as weakness.

It's Not Just Me.

I'm not the only analyst in history to have struggled with this. Because in the years since, I also started seeing it happen around me.

And ironically, it usually happens with high-performing business analysts.

Because here's the thing: by definition, high performers tend to be highly independent.

But when you're too independent, you might end up doing things like:

• Working in a vacuum (since you're very independent)
• Leaving stakeholders in the dark (so as not to bother them)
• Making key judgment calls in isolation (to show that you can)
• Not checking in along the way (since your work isn't "perfect" yet)

These behaviors aren't necessarily wrong – but they can easily backfire.

And when they do backfire – it not only results in wasted time and effort, but also creates unnecessary angst and distrust amongst your team.

The way to avoid this mistake as a high-performing analyst?

It starts with mastering the iterative approach.

👋 Subscribe for free to get Herng's newsletter directly in your inbox.

The Iterative Approach, Explained

The best analysts all tend to work iteratively. They strike a balance between operating independently and creating healthy feedback loops.

They take agency and make progress on their own. But they always bring in their stakeholders at the right checkpoints.

And when they do this well – they get the best of both worlds. They're able to:

• Enjoy autonomy and trust
• Pivot quickly whenever needed
• Prevent hard work going to waste
• Bring stakeholders along the journey

So if you're an analyst looking to master the iterative approach – here's a few tips.

1️⃣ Figure out your "MVP" First.

Adopting an iterative approach does NOT mean you do the following:

• Build out the first 20% of your work
• Call a meeting to get feedback
• Build out the next 20%
• Call another meeting to get more feedback
• etc.

This is ineffective for everybody.

Instead, you want to build out the MVP (Minimum Viable Product) first – then use that to get actionable feedback.

Depending on what you're working on, your MVP could be:

• The wireframe for a presentation (i.e. "skeleton slides" with the high-level narrative)
• The core methodology or assumptions for a data-driven analysis
• A visual mockup for a new dashboard, workflow, or product feature

Whatever it is – you're trying to trigger the most amount of feedback by doing the least amount of work.

That allows you to iterate quickly and move fast.

2️⃣ Identify Your "Floodgates."

Floodgates control water flows in real life. Anytime you open up the floodgates, it's hard to undo what comes next.

Work is similar.

Complex projects tend to contain "floodgate" moments that create material downstream implications (no pun intended).

For example, "floodgate" moments could include:

• Decisions that dictate scope of work
• Key assumptions used in a model
• Process or workflow decisions

Not everything is a floodgate, of course. Some things (e.g. cosmetic preferences or narrative structures) are easily adjustable on the go.

But for things that aren't – change comes at the expense of time and effort.

The best analysts understand this. They don't ask for other people's time on everything. But they do focus on identifying "floodgate" moments, and loop in people before it's "too late."

They invest time in the short run to save time in the long run.

3️⃣ Iterate with Strong Intention.

Simply meeting your stakeholders frequently does not qualify as iterating.

Instead, you need to know why you're meeting, and what you're trying to achieve.

The worst kind of iterating involves simply meeting at a cadence and doing a laundry-list update of everything that's transpired since last time.

The best kind of iterating is intentional.

When you iterate with people, you can aim to do any of the following:

• Make calls (esp. those with downstream implications)
• Brainstorm to generate or sharpen ideas
• Ask for feedback or pressure-testing
• Align on any "forking" decisions
• Recalibrate output expectations
• Provide visibility on progress

All of the above are good uses of time.

But you need to steer, proactively.

A common mistake I see with analysts? Knowing to schedule check-in's, yet deferring to other (presumably more senior) people in the room to decide how to use the time.

Sure, other people might have a view. But they simply don't know what they don't know.

So make sure you take back agency. After all, you're the one getting your hands dirty.