The Work Before the Work

How to think through problems when the request itself is unclear

This is the final piece in “The Work Behind the Work” series. It’s about the part of analytics that never shows up in dashboards, models, or stakeholder decks: the thinking that has to happen before you touch the data. I’m sharing the framework I use to turn vague requests into analysis that can actually hold up under scrutiny, along with a real example of what it looks like in practice.

I once got a request that made me stare at my screen for a good minute trying to figure out what the person was actually asking for.

“Can you pull turnover data for the last year? We want to see what’s going on.”

The question looked simple enough; just give them the data (duh!). But the longer I sat with it, the more I realized I would be doing me and the requester a disservice. Just giving them the data ultimately wouldn’t be as easy or as useful as it sounded. That’s when the overthinker side of me took over.

What did “what’s going on” mean in this context? Were they tracking down a specific problem they’d already identified and just wanted validation, or were they hoping the data would reveal something they hadn’t noticed yet? And who exactly was “we” in this request? The person asking and their manager? Some cross-functional team that had been discussing the issue? Leadership who’d raised a concern in passing? Different audiences need different things, and without knowing who I was building for, I couldn’t make decisions about scope, granularity, or framing that would make the analysis land well.

More fundamentally, I didn’t know what they’d actually do once they had the data in front of them. Would they intervene somewhere based on what they found? Change a process or policy? Present findings to someone who could make decisions? Or would they look at the numbers, acknowledge them as interesting, and then move on to whatever fire needed putting out that afternoon?

When I asked for clarification, the response came back as “we just want to get a sense of the landscape,” which told me everything I needed to know about how this was going to go. “Sense of the landscape” was a blanketed response when they haven’t figured out what they’re actually asking yet but feel like they need data anyway, which means I could pull anything, frame it however I wanted, deliver something technically accurate and well-constructed, and it still wouldn’t matter because they didn’t know what they needed.

I had two options at that point. I could just pull the data (extract it, build a report, send it back with fast turnaround and call it a day). The risk being they’d either say “this isn’t what I meant” or come back with follow-up questions I’d have to answer separately, stuck in email ping-pong iterating on something I didn’t understand in the first place. OR I could ask questions before touching the data, figure out what decision this was supposed to support, understand what they already knew and what would actually change based on the answer, and position myself as someone who delivers insights rather than just someone who pulls data on command.

This wasn’t an isolated incident or a particularly difficult stakeholder. This was just a pattern I kept seeing across different people, different topics, same structural problem underneath every request. The requests kept coming in, missing the same foundational elements: no decision attached to the analysis, no baseline established for comparison, no clarity about what would change based on whatever answer came back. I’d been spending months answering them anyway, building technically sound work that people would look at once, thank me for, and never reference again because the requests themselves were missing the thinking that makes analysis useful rather than just accurate.

At some point I stopped answering requests the way they came in and started asking questions before I touched any data. What decision does this support? What do you already know about this? What happens if the answer turns out to be X instead of Y? Who’s going to act on this, and what specifically are they going to do? I kept asking the same questions in the same order, and eventually I realized those questions weren’t just useful for clarifying bad requests; they were a structure for thinking through problems that separated work that would actually matter from work that would get filed away regardless of how sophisticated the analysis was.

I turned it into something I could use consistently and named it so I could apply it consistently and teach it to other people…

I call it S.E.A.R.C.H.

Not because acronyms are cute, and not because frameworks magically fix work, but because naming a way of thinking makes it repeatable.

The S.E.A.R.C.H. Framework

The framework has six steps, and each one forces a specific kind of clarity that most people skip when they’re under pressure to deliver analysis quickly.

S - State the Business Question. Before you touch data, rewrite the request into something that has a decision attached to it. Not “analyze turnover” but “what factors predict turnover among high performers, and what should we do about it?” The question needs to be specific enough that you’ll know when you’re done and what done looks like. Most requests fail here because people think asking for data is the same as asking a clear question, but those are different things entirely.

E - Explore the Data Landscape. Spend ten minutes just looking at the data before you analyze anything. How much data exists? What’s the baseline you’re comparing against? What segments are available? What’s messy or missing? This step keeps you from building sophisticated analysis on top of bad assumptions. You’re checking what’s normal versus abnormal, what data you can trust, and what constraints will limit what you can conclude later.

A - Analyze by Segments. Break down the data strategically, not randomly. Start broad, then drill into where the signal lives. Ask specific questions one at a time: does the pattern vary by department, by tenure, by manager, by compensation? Each cut should tell you what question to ask next rather than just producing more numbers to look at. Most people either get overwhelmed and freeze or build one massive pivot table hoping something useful emerges. Neither works.

R - Recognize Patterns and Outliers. Step back from individual cuts and see how they connect. Individual segments tell partial stories. Patterns across segments tell you what’s actually driving the outcome. Look for what’s consistently above or below average, what repeats across different slices of data, what happens together more often than chance would predict. Not every pattern requires action — you need to distinguish signal from noise.

C - Consider Business Impact. Translate numbers into stakes. How many people are affected? How far above baseline is this? How quickly is it happening? What breaks if nothing changes? Impact isn’t always financial; sometimes it’s operational risk, talent flight, or strategic misalignment. The point is making the problem tangible enough that decision-makers understand why it matters enough to act rather than just filing it under “interesting to know.”

H - Hypothesize Recommendations. Move from insight to action with five elements: specific action, clear owner, defined timeline, measurable success metric, and why it matters. Weak recommendations say “improve retention.” Strong recommendations say “require 18 months minimum tenure before promotion, owned by Head of Talent, effective in 6 weeks, success measured by turnover below 15%.” If someone can’t execute your recommendation after reading it once, it’s not specific enough.

That’s the structure.

If I tried to explain each step abstractly, this would turn into the exact kind of framework article I really don’t want to write. The real value of S.E.A.R.C.H. shows up when the request is messy and I find myself ready to think too quickly; so I’m going to walk through an example the way it actually plays out.

The Problem (A Fictional Scenario)

Note: This is a constructed scenario for demonstration purposes. The company and situation are fictional, but the analytical approach and thinking process mirror how I actually work through problems like this.

Sarah Chen runs Talent at FastGrowthCo, a Series B SaaS company that’s scaled from 200 to 1,200 employees in eighteen months. Her message on Tuesday morning laid out a problem without much cushioning: they’d promoted 23 people to management over the last year and a half because they needed leadership capacity immediately, but 8 of those newly promoted managers had already left. All eight were high performers before promotion, rated 4 or 5 on a 5-point scale. Leadership was divided on what was causing it. CEO thought they were promoting people too early. VP of Engineering thought compensation wasn’t competitive enough. Head of People Ops thought they weren’t training people after promoting them.

Next promotion cycle was in six weeks, with another 12-15 people planned. Sarah needed to know what was actually happening before they did it again.

The dataset arrived with her message. 1,200 employees, eighteen months of history. Performance ratings, compensation, promotion dates, termination dates, manager assignments, training completion records. The data had the usual problems: performance ratings weren’t calibrated across departments, manager effectiveness scores only existed for 60% of managers because it was a newer system, exit interview themes were inconsistently categorized. But there was enough structure to find patterns if they existed.

Rewriting What We’re Actually Answering (State the business question)

Sarah had asked what was happening with promoted managers, which was reasonable as a conversation starter but not something I could build analysis around. Before opening the dataset, I needed to rewrite this into something with a decision attached to it.

What decision did this support? Whether to change selection criteria for who gets promoted, whether to adjust compensation for management roles, whether to build training infrastructure that didn’t exist, whether to pause promotions until they fixed whatever was breaking. The analysis had to point toward one of those clearly enough that the recommendation would hold up when someone pushed back.

What did done look like? Not interesting findings about turnover patterns, but a recommendation backed by evidence that Sarah could defend when leadership asked why she was suggesting one fix over another.

What was the real question underneath? Were they promoting incapable people, or promoting capable people and then failing to support them? Those are different problems requiring different solutions. One means changing who gets promoted. The other means changing what happens after promotion.

I rewrote it: What factors predict post-promotion departure among high performers, and what specific interventions would reduce manager turnover in the next cycle?

Specific enough to guide analysis. Broad enough to capture the real problem. Tied to a decision that mattered.

Getting Oriented to What’s There (Explore the data landscape)

For the first ten minutes, I just looked without analyzing. 1,200 employees. Twenty-three promoted to management. 8 left, 35% turnover rate. Twenty-three is a small sample, which means I need to be careful about declaring patterns definitive, but large enough that strong signals should surface clearly.

Baseline: company-wide turnover at 18%, all managers at 31%, newly promoted at 35%. So the problem wasn’t just that management had higher turnover, it was that newly promoted managers were leaving at rates even higher than tenured managers, which suggested something about the transition itself was creating instability.

What segments existed: department, tenure at promotion, performance rating before promotion, compensation adjustment, manager quality, training completion. Each could reveal something, but I didn’t know which would matter yet.

The messiness constrained conclusions. Performance ratings weren’t comparable across departments: Engineering rated tough (most 3s, high performers got 4s), Sales rated generously (average performers got 4s). Manager effectiveness scores only existed for 60% of managers. Exit interviews were incomplete and inconsistently coded.

But scanning the raw data, I noticed something immediately: among the eight who left, average tenure at promotion was 1.4 years. Among the fifteen who stayed, 2.1 years. I didn’t know if that was meaningful or noise, but it was worth tracking.

Finding Where the Signal Lives (Analyze by segments)

I started asking the data specific questions, one at a time.

Does turnover vary by department?

• Engineering: 10 promoted, 4 left (40%)
• Sales: 8 promoted, 3 left (37.5%)
• Product: 5 promoted, 1 left (20%)

Engineering and Sales were hemorrhaging managers. Product held steady. The problem wasn’t uniform, which meant departmental context mattered: culture, manager quality, or how desperately they were promoting people.

Get Whitney Hosea’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Does tenure at promotion predict retention?

• Less than 18 months tenure: 9 promoted, 6 left (67%)
• 18–24 months: 8 promoted, 2 left (25%)
• More than 24 months: 6 promoted, 0 left (0%)

There it was: clean, striking, and undeniable. People promoted before eighteen months left at catastrophic rates. People promoted after two years didn’t leave at all. FastGrowthCo had been moving fast because the business demanded it, but speed was directly causing the problem they were trying to solve.

Does compensation matter?

• Over 15% increase: 12 promoted, 2 left (17%)
• 5–15% increase: 7 promoted, 3 left (43%)
• Under 5% increase: 4 promoted, 3 left (75%)

Compensation clearly mattered. Meaningful raises retained people and nominal raises didn’t. But even substantial raises didn’t prevent departure if other problems existed; you can’t pay someone enough to succeed in a role they weren’t ready for.

Does manager quality affect retention?

• Reports to high-rated manager (4–5): 15 promoted, 2 left (13%)
• Reports to average manager (3): 6 promoted, 4 left (67%)
• Reports to low-rated manager (1–2): 2 promoted, 2 left (100%)

Manager quality wasn’t one variable among many, it was the variable that determined whether other risks became manageable or fatal. Even early promotions could survive under exceptional managers. But early promotion under a weak manager was almost guaranteed failure.

Does training completion matter?

• Completed within 90 days: 14 promoted, 1 left (7%)
• Didn’t complete: 9 promoted, 7 left (78%)

This gap was almost unbelievable but the data was clear. Training was the single most effective intervention in the entire dataset. The problem: it was optional, so people who needed it most skipped it because they were overwhelmed.

What the Patterns Actually Mean (Recognize patterns and outliers)

Stepping back, four patterns emerged:

1. Tenure was the strongest single predictor. Promoting before 18 months created 67% turnover. After 24 months, zero turnover. Speed was killing retention.
2. Manager quality amplified or mitigated everything else. Great managers could compensate for early tenure, modest raises, incomplete training and weak managers made all those problems fatal.
3. Training was the most effective intervention available; 7% turnover among completers versus 78% among non-completers. This was the difference between success and failure.
4. Compensation mattered as a multiplier but couldn’t override structural problems. Big raises helped when other conditions were favorable, but couldn’t save someone promoted too early under a weak manager without training.

One person showed all risk factors stacked: promoted at eleven months, under 5% raise, manager rated 2, and no training. They left in four months. Compare to someone promoted at twenty-six months, 18% raise, manager rated 5, training completed in thirty days who’s still there and thriving.

The problem was the combination. When factors aligned, people stayed. When they didn’t, people left.

Making It Matter (Consider business impact)

Eight managers were gone, but fifteen are still there and at risk. The next cycle would promote 12–15 more. Without changes, the data suggested losing four of them within a year…predictable, preventable attrition.

35% turnover vs. 18% baseline. That’s 94% higher than normal. Not expected management turnover…this was a case of systemic failure in handling the IC-to-manager transition.

Average time to departure: eight months. Not people who stayed two years then left for better roles. People who struggled for six to eight months without support, then exited before fully ramping. FastGrowthCo was losing the high performers they’d promoted — all eight departures were rated 4 or 5 before promotion. People identified as future leaders, promoted, then lost because conditions for success didn’t exist.

The costs also compounded. Financial: replacing high performers, lost productivity, stalled projects. Reputational: word spreads that management roles are career killers. Team instability: new manager builds relationships, leaves six months later, team gets reassigned, morale drops, performance suffers, cycle repeats. Growth constraint: without retaining managers, can’t build capacity to support 40% annual growth.

Fixing this would create a sustainable pipeline, protect investment in high performers, and improve team stability. This wasn’t just retention, this was a scaling problem disguised as retention.

What to Actually Do

Four recommendations, each with specific action, clear owner, timeline, success metric, and rationale.

1. Establish eighteen-month minimum tenure for promotion. No exceptions without VP approval and documented readiness assessment. Head of Talent owns it, effective in six weeks.
   Success: zero promotions under 18 months unless VP-approved, turnover below 15% within 12 months. Matters because under eighteen months creates 67% turnover, over eighteen months creates 14% turnover.
2. Audit manager quality and reassign reporting lines. Identify promoted managers reporting to managers rated below 4. Reassign to high-performers or provide intensive coaching with quarterly assessments. VP of People and Department Heads own it. Complete in 30 days and implement in 60.
   Success: 100% reporting to rated-4+ managers, turnover under 10% post-reassignment. Matters because weak managers drive 67–100% turnover; we’re basically setting people up to fail.
3. Make training mandatory within thirty days. Down from the 90-day optional window. Cover 1:1s, feedback, performance management, conflict, peer-to-manager transition. Completion required for promotion finalization. Head of L&D owns it. Next cohort starts day one.
   Success: 100% completion in thirty days, turnover under 10% among completers. Matters because non-completers left at 78%, completers at 7%.
4. Standardize 15% minimum compensation increase. For all IC-to-manager promotions, plus equity refresh. Head of Compensation owns it and implements it in 6 weeks.
   Success: 100% receive minimum 15% increase, turnover below 15%. Matters because under 5% increases create 75% turnover, over 15% creates 17%…pay signals value.

This is what Sarah takes to leadership. Not findings, but actual diagnosis, actions, and measurement.

What this framework actually does

S.E.A.R.C.H. doesn’t exist to make analysis like in the fake scenario easy or automatic. It made it structured in ways that kept me from skipping the critical thinking steps that determine whether the final output will be useful rather than just technically accurate.

The framework forced clarity at each stage: defining the decision before building anything, understanding the baseline before declaring something a problem, analyzing strategically rather than randomly, recognizing how patterns connected rather than treating them as independent, translating numbers into stakes that mattered, building recommendations specific enough to execute.

The framework demands clarity at each stage:

• It forces you to define the business question before you jump feet first in the data
• Makes you the data landscape before before you start interpreting it
• Pushes you to analyze strategically rather than randomly: segmentation instead of averages, patterns instead of anecdotes, and impact instead of trivia.
• Recognizing how patterns are connected rather than treating them as independent.
• Helps you to come up with recommendations that are specific enough to execute.

But the framework is just structure. This requires knowing what questions to ask when the data doesn’t immediately reveal answers (when most times, it’s won’t), recognizing when a pattern is signal versus when it’s noise that looks meaningful until you test it more carefully, understanding organizational context well enough to know which recommendations will hold up under scrutiny and which ones will get dismissed as impractical regardless of what the data says, and having enough conviction to push back when a vague request comes in and say “I can’t answer this until you tell me what decision it supports” even when that feels like you’re creating friction instead of being helpful.

Most of that can’t be taught through a framework. It comes from doing the work enough times that you develop instincts about where problems usually live, what questions usually matter, and what recommendations usually stick versus the ones that sound good in meetings but never actually get implemented. The framework just ensures you don’t skip steps when you’re under pressure to deliver quickly, which is most of the time.

That’s why I’m ending the series here. Models and dashboards get the attention, and they should. But the work that determines whether those things will matter has usually happened earlier, quietly, before the first line of code and before the first cut of data.