Marcel Dybalski on Mentorship That Builds Capability

Marcel Dybalski recently shared something that caught my attention: when he was a junior data analyst, he asked endless questions like "Why doesn't this join work?" and "What's the difference between WHERE and HAVING?" Some seniors ignored him, but one didn't. That senior "pulled up a chair," walked him through it, and most importantly, "didn't just fix my code. He explained why it was broken."

That tiny difference is the whole story.

"He didn't just fix my code.
He explained why it was broken."

Marcel then makes the shift explicit:

"Fixing teaches nothing.
Explaining builds capability."

I want to expand on that idea because it shows up everywhere in data work, engineering, analytics, and leadership. It also explains why two people with similar talent can end up with completely different careers. The gap is often not intelligence or work ethic. It's access to patient, high-quality teaching at the moment you are stuck.

The hidden career accelerant: someone who teaches while you struggle

Marcel writes, "Your career doesn't depend on talent alone. It depends on who decides to teach you when you're struggling." That might sound dramatic, but it's accurate in environments where complexity is high and feedback loops are slow.

In a typical data job, you can spend hours chasing an issue that has three root causes:

• a misunderstood business definition (what does "active" mean?)
• a technical assumption (left join vs inner join)
• an execution detail (filters applied pre-aggregation vs post-aggregation)

A senior who simply patches your query gives you a working output, but they also remove the very friction that would have taught you how to reason through similar problems next week. Meanwhile, a senior who explains gives you something portable: a mental model.

Fixing versus explaining: what's actually different?

It's easy to say "explain more" and still not teach well. The real difference is whether the senior transfers decision-making, not just syntax.

"Fixing" looks like this

• They take the keyboard.
• They change join keys, move a filter, add a group by.
• They ship the result.
• They say, "There you go."

You might learn one trick, but you don't learn how they knew where to look.

"Explaining" looks like this

• They ask what you expected to happen.
• They make you state assumptions out loud.
• They isolate the failure: data shape, grain, or logic.
• They narrate tradeoffs and why they choose option A over B.

The output is not just a correct query. The output is a better analyst or engineer.

Why juniors ask "endless questions" (and why that is a good sign)

Marcel's examples are perfect because they're not exotic questions. They are the questions that reveal whether someone is learning foundations:

• "Why doesn't this join work?" is about keys, uniqueness, and row multiplication.
• "WHERE vs HAVING" is about when filters apply relative to aggregation.
• "Can you look at my query... again?" is about iteration, humility, and the reality that debugging is rarely one-and-done.

A junior who asks these questions is not weak. They are doing the most important thing early in a career: tightening the feedback loop.

The danger is cultural. If the workplace punishes questions, people adapt in unhealthy ways:

• they stop asking and silently ship wrong logic
• they copy patterns without understanding
• they over-rely on dashboards and under-invest in definitions

Then leadership wonders why the team can't be trusted. The root cause is often not capability. It is the environment.

A practical teaching framework seniors can use in 10 minutes

Not every senior has an hour to mentor. The good news is you can teach without turning every question into a workshop. Here's a lightweight pattern that captures what Marcel described.

1) Start with the expected outcome

Ask: "What result did you expect?" and "What did you actually get?"

This forces clarity. Many bugs are ambiguous expectations.

2) Identify the grain

Ask: "What is one row supposed to represent at each step?"

If the junior can't answer, the join probably can't work reliably.

3) Reduce the problem

Teach them to reproduce the issue on:

• one entity (one customer, one order)
• one day
• a tiny subset of columns

This is a transferable debugging skill, not a one-time fix.

4) Explain the "why" with a rule of thumb

Examples:

• "If your join key is not unique on at least one side, expect row multiplication."
• "Use WHERE to filter rows before aggregation, HAVING to filter groups after aggregation."

Rules of thumb become mental shortcuts they can reuse.

5) Close the loop with a check

Ask them to propose a validation:

• "How would you confirm this is correct?"
• "What would you test if the data volume doubled?"

This builds ownership.

What leaders can do: design a team that teaches by default

Marcel's post sits in the mentorship lane, but the bigger implication is organizational. Teaching is not only a personality trait. It can be a system.

Make teaching visible and valued

If promotions reward only individual output, seniors will optimize for speed. If promotions reward "raised team capability," seniors will invest in explanations.

Concrete ways to signal that:

• include mentorship in performance reviews
• celebrate internal docs and office hours
• track "time-to-independence" for new hires as a team metric

Create safe paths for questions

Many teams rely on private DMs. That is inefficient and it hides learning.

Alternatives:

• a public #data-help channel with norms for respectful replies
• weekly query clinics where anyone can bring one problem
• rotating "on-call" analyst support for urgent blockers

Standardize the basics

A lot of repeated questions are about inconsistent definitions and patterns.

Help the whole team by standardizing:

• metrics definitions (what counts as "active"?)
• a join strategy guide for core tables
• reusable templates for common transformations

When the fundamentals are documented, the questions you get become higher quality, and mentorship becomes more about reasoning than trivia.

For juniors: how to ask questions that invite great mentorship

Marcel's gratitude is a reminder that the junior has agency too. You can increase the odds of getting a real explanation by packaging the question well.

Try this format:

• "Goal: I'm trying to compute X."
• "What I expected: Y."
• "What happened: Z (include a small example)."
• "What I tried: A, B."
• "My hypothesis: I think it's due to join key uniqueness. Am I thinking about this right?"

This does two things: it respects the senior's time and it makes it easier for them to teach, not just rescue.

The question I wish more seniors would answer patiently

Marcel ends by asking: "If you could go back, what's the one question you wish a senior had patiently answered for you?"

Mine would be: "How do you know your result is correct?"

Because the biggest leap in analytics is moving from writing queries to proving that the logic matches reality. That requires habits: sanity checks, reconciliation, edge cases, and being comfortable saying, "I don't know yet, but here's how I will find out."

And that is exactly what patient explanation teaches: a way of thinking.

Fixing gets you through today.
Explaining builds the person who can handle tomorrow.

This blog post expands on a viral LinkedIn post by Marcel Dybalski, AI & Data Platform Engineer | GCP & Fabric Certified. View the original LinkedIn post →