The McKinsey 7-S Framework: A Simple Guide to Aligning Your Organization

Most strategies don't fail because they're wrong. They fail because the rest of the organization isn't built to support them.

You can have a brilliant plan, but if your structure, systems, and people aren't aligned with it, the plan stays on paper. This is the problem the McKinsey 7-S Framework was designed to solve.

Developed in the late 1970s by Tom Peters and Robert Waterman at McKinsey & Company, the 7-S Framework identifies seven internal elements that need to work together for an organization to succeed. It has outlasted decades of management trends because it answers a question that never goes out of style: why isn't this working the way we thought it would?

It's also a powerful way to share your vision and influence leadership. Whether you're making the case for change in your current role or walking into a job interview, the 7-S Framework gives you a structured way to demonstrate strategic thinking — to show how you see the whole organization, not just your piece of it.

What the 7-S Framework Is

The model maps seven interconnected elements of an organization. Change one, and the others feel it. The seven elements are grouped into two categories:

Hard elements (easier to identify, easier for leadership to influence directly):

• Strategy — your plan for competing and winning
• Structure — how the organization is arranged (reporting lines, departments, hierarchy)
• Systems — the daily processes and tools that get work done

Soft elements (harder to pin down, shaped by culture):

• Shared Values — the core beliefs at the center of the organization
• Style — how leadership shows up and operates
• Staff — the people and their general capabilities
• Skills — the specific competencies the organization has

Shared Values sit at the center of the model. Every other element depends on them. When values are clear and lived, the rest of the system has something to organize around. When they're not, the other six elements drift.

Breaking Down the Seven Elements

1. Strategy

Your strategy is how you plan to build and maintain a competitive advantage. It answers:

• What are we trying to achieve?
• How will we respond to competition and shifts in the market?
• How does our strategy adapt to changing customer needs?

Strategy only works when the rest of the organization is built to execute it.

2. Structure

Structure is the architecture of your organization: who reports to whom, how teams are divided, where decisions are made.

• Is decision-making centralized or decentralized?
• How do departments coordinate?
• Where are the formal and informal lines of communication?

A structure that worked at 10 people often breaks at 50. A structure that supports innovation can be the wrong fit for scale.

3. Systems

Systems are the processes and tools that keep daily work moving — financial systems, HR processes, communication platforms, project management workflows, decision protocols.

• What systems do we rely on most?
• How are they monitored?
• Where are the bottlenecks?

Outdated systems quietly drain energy from every other part of the organization.

4. Shared Values

Shared Values are the core beliefs and standards that guide behavior. Not the values posted on the website — the ones actually lived day to day.

• What do we genuinely stand for?
• What does our culture reward and tolerate?
• How strong and consistent are these values across the organization?

When shared values are vague or contradicted by behavior, every other element gets harder to align.

5. Style

Style refers to leadership and management approach. It includes how leaders communicate, make decisions, and handle conflict.

• Is leadership collaborative or directive?
• Do teams actually function as teams, or are they groups in name only?
• How effective is leadership at modeling what's expected?

Style shapes culture more than any mission statement.

6. Staff

Staff is about the people in the organization — who's there, what roles exist, and where the gaps are.

• What roles and specializations do we have?
• What positions are missing?
• How are we developing the people we have?

Staff decisions shape what the organization is capable of becoming.

7. Skills

Skills are the specific capabilities the organization is known for — what it actually does well.

• What are our strongest competencies?
• Where are the skill gaps?
• How do we monitor and grow skills over time?

Skills and Staff sound similar but answer different questions. Staff is who you have. Skills is what they can do.

When to Use the 7-S Framework

The framework is useful any time you need to understand how the pieces of an organization fit — or why they don't. Common applications:

• Improving performance in a team or company that feels stuck
• Implementing a new strategy
• Navigating a merger, acquisition, or major restructure
• Onboarding new leadership
• Diagnosing why change efforts keep stalling
• Aligning a fast-growing team that's outgrown its original setup
• Making the case for change to senior leadership in a structured, credible way
• Preparing for a leadership interview, where you want to demonstrate strategic thinking about the organization you're hoping to join

It works at the organization level, but also at the level of a department, team, or project.

How to Apply It

Here's a practical sequence:

Step 1: Start with Shared Values. Are they clear? Are they consistent with your current strategy, structure, and systems? If not, name the gap.

Step 2: Examine the hard elements. Look at Strategy, Structure, and Systems together. Do they reinforce each other, or are they pulling in different directions? A growth strategy paired with a structure built for stability is a common mismatch.

Step 3: Examine the soft elements. Style, Staff, and Skills. Do they support what the hard elements are trying to do? A strategy that requires bold decision-making won't work under a leadership style that punishes risk.

Step 4: Identify the misalignments. Where are the contradictions? Where is one element undermining another?

Step 5: Adjust and reassess. Change one element, and the others shift. This is iterative, not linear. Expect to circle back.

A simple way to track alignment: list the seven elements in a grid and check whether each pair supports the other. Mismatches are where the work is.

A Quick Example

Imagine a small company of five people. The founder's values shape everything. Strategy is clear. Structure is informal but functional. Systems are off-the-shelf and adequate. Everything aligns because it's small.

Now imagine that company at 30 people, selling into new markets. The original strategy has evolved, but the structure hasn't. New hires don't fully understand the founding values. Systems built for five people are buckling. The skills that made the early team successful aren't the skills needed now.

Nothing is broken on its own. But the pieces no longer align. A 7-S analysis surfaces this — not as a list of problems, but as a pattern. From there, the leader can make targeted changes: clarify values for new hires, evolve the structure, upgrade systems, build the missing skills.

That's the value of the framework. It turns a vague sense that something is off into a specific, addressable picture.

A Few Honest Limitations

The 7-S Framework is a diagnostic tool, not a prescription. It tells you where things are out of alignment. It doesn't tell you what to do about it. Two organizations with the same misalignments may need very different solutions depending on context, history, and people.

It's also a snapshot. Organizations are dynamic, and alignment is never permanent. The framework is most useful when revisited periodically — especially during growth, change, or strategic shifts.

Final Thought

The 7-S Framework endures because it reflects something true about organizations: success isn't about getting one thing right. It's about getting many things to work together.

When strategy, structure, systems, values, style, staff, and skills reinforce each other, performance follows. When they contradict each other, no amount of effort in one area will fix what's misaligned across the others.

This is also why the 7-S Framework is such a useful tool when you're trying to influence others. Walking into a leadership meeting — or an interview — with a 7-S lens shows you understand how organizations actually work. You're not just pitching an idea. You're showing how the pieces fit.

If something in your organization feels stuck, the 7-S Framework is a good place to start asking why.

Analytics Frameworks That Actually Help You Think

There is a moment every analyst knows. You've spent three days on an analysis, the SQL is clean, the charts look great, and you walk into the room ready to present. Then someone asks: "Wait! Is this actually the question we needed to answer?"

That moment is what frameworks prevent.

Frameworks are not bureaucracy. They are thinking tools, ways of organizing your work before you touch data, so that when you do, you're solving the right problem in a defensible way. This guide covers three phases of analytical work, defining the problem, deciding what to measure, and prioritizing your workload, and introduces the frameworks that make each phase rigorous.

Part 1: Defining and framing the problem

The most expensive mistake in analytics is answering the wrong question precisely. Before writing a single query, you need to understand what problem you're actually solving and for whom.

MECE principle

What it is: MECE stands for Mutually Exclusive, Collectively Exhaustive. It is a principle for breaking any problem into categories that do not overlap (mutually exclusive) and together cover everything (collectively exhaustive). Developed at McKinsey by Barbara Minto in the late 1960s, it is the foundation of structured thinking in consulting and equally powerful in analytics.

How it works: Before diving into data, draw out the possible explanations for the problem you're investigating. Check two things: first, that no explanation falls into two buckets at once (no overlap); second, that all possible explanations are covered (no gaps). If both conditions hold, your structure is MECE.

When to use it: Use MECE whenever you're trying to diagnose why something happened: a metric drop, a revenue shortfall, a spike in churn. It is also essential when building metric trees or designing dashboards, where you need to ensure that sub-metrics add up cleanly to a top-line number without double-counting.

A common pitfall: teams often group causes by the department that owns them (marketing, product, engineering) rather than by logical structure. This produces categories that overlap and miss edge cases. MECE forces you to think structurally, not organizationally.

Reference: Wikipedia — MECE principle

Issue tree (logic tree)

What it is: An issue tree is a visual problem-structuring tool that applies MECE logic recursively. You start with a big question at the top: "Why did revenue drop?" and branch it into sub-questions, each of which is narrower and more testable. You keep branching until you reach leaf nodes specific enough to be answered with data.

How it works: There are two types of trees. A "why tree" is used for root cause analysis: you ask "why?" at each level until you hit a testable cause. A "how tree" is used for solution design: you ask "how could we fix this?" and branch into options. The branches at every level must be MECE.

When to use it: Use an issue tree at the very start of any complex analysis, before writing any code. It is especially valuable when a stakeholder has come to you with a vague problem ("sales are down, figure out why") and you need to structure the space of possible explanations. It also forces you to have explicit conversations about scope — some branches may be out of scope or owned by another team, and it's better to surface this early.

Issue trees are also useful in stakeholder presentations. Walking someone through a tree makes your reasoning transparent and gives them a natural place to add context or redirect your focus.

Reference: CaseBasix — Issue tree guide

5 Whys

What it is: A root cause analysis technique developed as part of the Toyota Production System. You take a problem statement and ask "why?" five times in succession, with each answer forming the basis for the next question. The goal is to move past symptoms to underlying causes.

How it works: Start with the observable problem: "DAU dropped 12% this week." Ask why. "Because new user activation fell." Ask why again. "Because the onboarding email sequence stopped sending." Ask why. "Because an API credential expired." Ask why. "Because there was no alerting on credential expiry." Ask why. "Because we never set one up." Now you have a root cause — and a specific action to take.

When to use it: The 5 Whys is best for fast, tactical root cause analysis on a specific anomaly — a metric that suddenly moved, an alert that fired, a report that broke. It is less suited to complex, multifactorial problems (where an issue tree is better), but for single-cause failures it is remarkably efficient. Run it in a short meeting with the right people in the room rather than alone at a desk.

Reference: MindTools — 5 Whys

McKinsey 7-S framework

What it is: A model developed at McKinsey that maps an organization across seven elements: Strategy, Structure, Systems, Staff, Skills, Style, and Shared Values. All seven are interconnected, changing one affects the others.

How it works: The framework is used to diagnose why an organization is performing below expectations, or to assess readiness for a change. Each of the seven elements is evaluated for its current state and its alignment with the others. Misalignments are where performance problems hide.

When to use it: Use 7-S when your analytics work is diagnosing an organizational problem, not just a metric problem. For example, if you've been asked to understand why a new data strategy isn't taking hold, or why two teams that merged are underperforming, 7-S prevents you from looking only at systems and data when the real issue may be skills, structure, or shared values. It is especially relevant for senior analysts and analytics leaders who work at the intersection of data and organizational change.

Reference: McKinsey 7-S framework

Part 2: Deciding what to measure

Once the problem is framed, the next challenge is choosing what to measure. This is harder than it sounds. There are always more things you could track than you should track. The frameworks in this section help you cut to the metrics that actually matter.

North Star metric framework

What it is: The North Star Metric (NSM) is a single number that best captures the core value your product delivers to customers. The North Star framework, popularized by Amplitude and widely used in product-led companies, builds a complete system around it: the NSM at the top, 3–5 input metrics below it that teams can directly influence, and guardrails that prevent gaming.

How it works: Identify one metric that, if it moves up, you are confident the business is delivering more value to customers, and that will, over time, drive revenue and retention. Below it, identify the levers: what inputs drive the NSM? Each input should have a team owner and be measurable. Spotify's NSM is "time spent listening." Slack's is "messages sent per team." Facebook's is "daily active users."

When to use it: Use the North Star framework when a team or organization is suffering from metric sprawl: everyone is tracking different numbers and there's no shared definition of what winning looks like. It is also the right starting point when standing up a new analytics function or joining a new company: before building any dashboards, identify the North Star and its inputs. This grounds all subsequent work in what actually matters.

Avoid using it for one-off analyses. The North Star is a strategic alignment tool, not a diagnostic one.

Reference: Amplitude — North Star metric

HEART framework

What it is: Google's framework for measuring the quality of user experience. HEART stands for Happiness, Engagement, Adoption, Retention, and Task Success. For each dimension, teams define Goals, Signals, and Metrics, the GSM process, to turn abstract UX aspirations into trackable numbers.

How it works: Choose one or two HEART dimensions that matter most for your product or feature. For each, define the goal (what are you trying to achieve?), the signal (what user behavior indicates progress toward that goal?), and the metric (how do you measure that signal at scale?).

• Happiness: user satisfaction, NPS, perceived ease of use
• Engagement: frequency of use, sessions per week, content interactions
• Adoption: new users of a feature, upgrades, first-time actions
• Retention: return rate, renewal rate, churn
• Task Success: completion rate, time on task, error rate

When to use it: HEART is most useful when you are working on product analytics, UX research, or any analysis where the quality of the user experience is what you're trying to improve. It is particularly valuable when product and design teams struggle to agree on what to measure, HEART provides a shared vocabulary. It is also a strong framework for feature launches, where you need to evaluate success across multiple dimensions, not just a single conversion metric.

Reference: heartframework.com

AARRR (pirate metrics)

What it is: A funnel framework created by Dave McClure of 500 Startups in 2007. AARRR maps the full customer lifecycle into five stages: Acquisition, Activation, Retention, Referral, and Revenue. Originally designed for startups, it is now used broadly in product, growth, and marketing analytics.

How it works: For each of the five stages, identify the key metric your business should be tracking:

• Acquisition: how are users finding you? (organic search, paid ads, referrals)
• Activation: are new users having a meaningful first experience?
• Retention: are activated users coming back?
• Referral: are happy users telling others?
• Revenue: are you monetizing effectively?

The power of AARRR is that it makes leak points visible. If acquisition is high but activation is low, your onboarding is broken. If activation is strong but retention is weak, the product isn't delivering lasting value.

When to use it: Use AARRR when you need to understand the health of a customer lifecycle end-to-end, or when stakeholders are debating where to invest. It answers the question: "Which stage of the funnel is our biggest bottleneck?" It is especially useful in growth analytics, marketing analytics, and early-stage product analytics. For more mature products with complex user behaviors, the North Star framework and input metric trees tend to be more useful.

Reference: Amplitude — Pirate metrics

OKR framework

What it is: Objectives and Key Results — a goal-setting framework developed at Intel by Andy Grove and popularized globally by investor John Doerr, who introduced it to Google in 1999. An Objective is a qualitative, ambitious goal. Key Results are 2–5 specific, measurable outcomes that define what achieving that objective looks like.

How it works: At the company level, leadership sets 3–5 Objectives for the quarter or year. Each Objective has 2–5 Key Results with clear numerical targets. Teams cascade their own OKRs to align with company-level ones. Analytics teams typically own the measurement of Key Results, they are the ones who instrument, track, and report on whether KRs are being achieved.

When to use it: OKRs are the bridge between analytics work and strategic impact. Use the OKR framework when you need to connect your analysis to something leadership cares about, or when stakeholders are pushing back on why a piece of analysis matters. If you can point to the Key Result your work is measuring or influencing, the conversation changes. For analysts specifically, OKRs are also a useful prioritization filter: if a request doesn't connect to any active OKR, it probably shouldn't be at the top of your queue.

Reference: WhatMatters.com — OKRs explained

DIKW pyramid

What it is: A model that maps the hierarchy from Data to Information to Knowledge to Wisdom. Originally articulated by Russell Ackoff, it describes the journey from raw, unprocessed facts through progressively higher levels of meaning and applicability.

How it works: Data is raw facts with no context (a server log entry). Information is data organized to answer a question (daily active users this week). Knowledge is information understood in context (DAU is declining because of a specific onboarding change). Wisdom is knowledge applied to make a better decision (we should roll back the change and redesign the flow).

When to use it: DIKW is most useful as a communication tool. When non-technical stakeholders ask "why do we need an analytics team?" or "why can't we just look at the numbers ourselves?", DIKW explains what analysts actually add — they turn data into wisdom. It is also a useful self-check for analysts: ask yourself where on the pyramid your current deliverable sits. A report that stops at "information" leaves the hardest work to the reader. A good analyst pushes toward "knowledge" and, ideally, toward "wisdom."

Reference: Wikipedia — DIKW pyramid

Part 3: Prioritizing what to work on

Analytics teams are always overloaded. Requests come from every direction: product, marketing, finance, leadership, and they all feel urgent to the person asking. These frameworks give you a systematic, defensible way to decide what deserves your time.

RICE scoring

What it is: A prioritization framework developed by Sean McBride at Intercom. RICE stands for Reach, Impact, Confidence, and Effort. It produces a single numerical score for each initiative, making it possible to compare very different types of work on the same scale.

How it works: Score each initiative on four factors:

• Reach: how many people will this affect in a given time period? (measured in number of users, customers, or events per quarter)
• Impact: how much will it affect each person? (3 = massive, 2 = high, 1 = medium, 0.5 = low)
• Confidence: how confident are you in your estimates? (expressed as a percentage, e.g. 80% = 0.8)
• Effort: how much work does it require? (measured in person-months)

The formula: RICE score = (Reach × Impact × Confidence) ÷ Effort

Higher scores mean better return on time invested. Rank all initiatives from highest to lowest, then apply judgment on top.

When to use it: Use RICE when you have a backlog of competing requests and need a transparent, data-driven way to sequence them. It is particularly valuable when different stakeholders are each convinced their request is the priority — RICE gives you a neutral framework to have that conversation. Importantly, RICE scores should inform decisions, not make them. Dependencies, timing, and strategic context all belong in the final call, layered on top of the score.

Reference: Intercom — RICE framework

OEC (Overall Evaluation Criterion)

What it is: A framework developed by Microsoft's experimentation team for defining, before a test runs, what a successful experiment looks like. The OEC is a composite metric or set of metrics that captures the goals of an experiment in a single evaluation framework.

How it works: Before launching an A/B test, teams define the OEC: the primary metric the experiment is trying to move, a set of guardrail metrics that must not degrade, and the statistical thresholds required to call a result significant. This is done before seeing any data, preventing the common trap of testing many metrics and reporting whichever ones happened to move.

When to use it: Use OEC whenever you are running a controlled experiment. The discipline of defining the OEC forces alignment between analysts, product managers, and engineers on what they're trying to achieve — often revealing disagreements that are much better surfaced before the test than after. It is especially important for organizations that run many experiments simultaneously, where without pre-registration of metrics it is easy to cherry-pick results.

Reference: Analytics Toolkit — OEC

PDCA cycle

What it is: Plan-Do-Check-Act: a four-stage iterative cycle developed by quality management pioneer W. Edwards Deming, widely used in lean manufacturing and continuous improvement. In analytics, it maps directly to the hypothesis-test-learn loop.

How it works:

• Plan: define the hypothesis, the metric, and the method. What change are you testing, and what does success look like?
• Do: implement the change or run the analysis.
• Check: evaluate the results against your success criteria. Did the metric move as expected? Are there confounders?
• Act: based on the results, standardize the change (if it worked), abandon it (if it didn't), or redesign and loop again.

When to use it: PDCA is most useful as a team operating rhythm, a shared mental model for how analysts and product teams work through improvement cycles. It is particularly valuable in experimentation-heavy environments, where the risk is running many tests but not building cumulative learning. The "Act" step is often skipped under time pressure; PDCA makes it explicit that acting on results, even a decision to stop, is a required part of the process.

Reference: ASQ — PDCA cycle

Jobs-to-be-Done (JTBD)

What it is: A framework developed by Clayton Christensen that shifts the analytical lens from "what are users doing?" to "what are they trying to accomplish?" The core idea is that customers don't buy products: they hire them to do a job. Understanding the job clarifies what to measure and what to build.

How it works: Through qualitative research (interviews, observation), teams identify the "job" a user is trying to accomplish: the functional goal, the emotional motivation, and the social context. These jobs become the anchor for metric design. Instead of measuring "feature usage," you measure whether users are successfully completing their job.

When to use it: JTBD is particularly powerful when quantitative data gives you "what" but not "why." If your metrics show that users are churning after step 3 of onboarding, JTBD research tells you what job they were trying to do and why the product failed to help them do it. It is also valuable when teams are debating which features to build — JTBD grounds those conversations in user intent rather than feature requests. For analysts, JTBD is most useful as a complement to quantitative work, not a replacement for it.

Reference: Christensen Institute — Jobs-to-be-Done

How to choose: a quick guide

The frameworks above are most useful when matched to the right moment in your work. Here is a simple way to think about which one to reach for:

You have a vague problem and need to structure it: Start with an issue tree built on MECE logic. Use 5 Whys if the problem is a specific metric anomaly. Use McKinsey 7-S if the problem is organizational.

You need to decide what to measure: Start with the North Star metric to establish the single most important outcome. Use AARRR if you're analyzing a customer lifecycle. Use HEART if you're evaluating a product or feature from a UX perspective. Use OKRs to connect your metrics to company strategy.

You need to run or evaluate an experiment: Define the OEC before the test runs. Use PDCA to structure the full iteration cycle.

You need to explain the value of your analysis: Use the DIKW pyramid to frame your work as moving from data to wisdom — not just reporting numbers.

You have more work than time: Score everything with RICE, filter first by OKR alignment, then apply judgment on top.

Your Career Doesn't Look Like a Straight Line, and That's the Point

Have you ever sat down to prepare for an interview and felt a quiet dread when you got to the part where you have to explain yourself?

Not your skills. Not your accomplishments. You. The full arc of it. Why you went left when everyone else went right. Why you pivoted. Why, looking at your résumé, the path might seem more like a winding trail than a clean, upward climb.

If that dread is familiar, you are not alone. I hear this from accomplished professionals all the time, especially those navigating a career change or a significant pivot. They have done real, meaningful work. They have built skills, led teams, taken risks. But when someone asks them to walk through their story, something gets lost in translation. The story they tell doesn't match the person sitting in the room.

The Fear Underneath the Question

Here's what I've observed in my coaching work: the professionals who struggle most to tell their story aren't the ones without a story. They're the ones who have decided, somewhere along the way, that their story is a liability.

They look at their career from the outside, the way they imagine a hiring manager might, and they see evidence of someone who can't make up their mind. Multiple industries. A degree that doesn't fit neatly into the job title they're applying for. A lateral move here, a bold leap there. And they conclude, before the conversation even begins, that they need to apologize for it.

So they walk into interviews already on the defensive. They downplay. They hedge. They over-explain. And the very thing they're afraid the hiring manager will think, this person seems uncertain, is exactly what comes through.

Here's what I want you to hear: the problem is almost never the career path. The problem is the story you've decided to tell about it.

Are You Running Away or Running Toward?

Before you can tell a compelling story, you need to answer one honest question: Why did you change?

Not the version you'd say in an interview. The real version.

I ask my clients this because there's an important distinction between two types of career changers. Some people are moving toward something: a growing interest, a deeper calling, a version of themselves they can already see and are actively working to become. Others are moving away from something: a bad boss, a role that never fit, a company culture that wore them down.

Both are human. Both are valid. But they produce very different narratives.

When you're running toward something, your story has momentum. Each decision leads somewhere. You can point to a thread, curiosity, a value, a vision, that runs through all of it. When you're running away, the story is harder to tell, because the logic isn't in where you're going. It's in what you were escaping. And that story, no matter how carefully you word it, tends to feel thin in an interview room.

This isn't a judgment. Sometimes getting out of a bad situation is exactly the right move. But clarity about your motivation will determine how confidently you can tell your story. If you're not sure which category you're in, that uncertainty is worth sitting with before your next application goes out.

The Thread That Was Always There

Here is what I find, again and again, when I sit with clients and go through their careers together: the thread was there all along. They just couldn't see it, because they were too close to it, or because they'd spent years hiding parts of the story they thought made them look bad.

One client I worked with had a background that looked, on paper, like a series of disconnected decisions. But when we traced the through-line, we found it immediately: she had always been drawn to work that sat at the intersection of complex systems and human impact. Every role she'd ever taken, across wildly different industries, reflected that same pull. She hadn't been changing her mind. She had been evolving her understanding of how to pursue the thing she'd always cared about.

That reframe changed everything about how she showed up.

The exercise I guide clients through is simple: start at the beginning. Not the beginning of your résumé, the beginning of what you cared about. What drew you to your first role? What were you hoping to learn, prove, or contribute? And then, at each transition, ask the same question: what were you moving toward?

When you do this honestly, a thread almost always appears. It may not be a role or an industry. It might be a value, making an impact at scale, working with technology, being close to the people your work affects. But it's there. And once you can name it, you have the spine of your story.

"Changing" vs. Evolving: A Reframe That Matters

There's a word I gently push back on when I hear clients use it about themselves: changing.

"I feel like I've changed my mind a lot."

I understand why they say it. But I want to offer a different lens.

Changing implies instability, a mind that can't settle, a person who will be difficult to retain. Evolving implies something different: growth, expanding capability, a person who keeps outgrowing their current container and needs a bigger one.

Think about it this way. If you mastered one environment and then sought a more challenging one, is that changing your mind? Or is that the natural progression of someone who refuses to stop growing?

The professionals I most admire are not the ones who found their lane early and never left it. They're the ones who kept asking more of themselves, who hit a ceiling and, instead of accepting it, looked for a higher room. That is not a liability. That is a leadership quality. And it's yours to claim.

The way you tell the story matters enormously here. "I've moved around a lot" lands differently than "Each transition in my career has been driven by a growing appetite for more, more complexity, more impact, more proximity to the work I find most meaningful." Both can be true descriptions of the same résumé. Only one of them will land.

What Hiring Managers Are Actually Listening For

Here's a grounding truth: hiring managers are not trying to catch you out. They're trying to answer a question. Specifically, they want to know: Is this person going to be committed, capable, and a good fit?

When they ask you to walk them through your career, they're listening for two things:

Coherence. Does this story hold together? Is there a logic to the decisions, even if the path wasn't straight? They're not looking for a perfect linear trajectory. They're looking for a person who knows themselves well enough to connect the dots.

Conviction. Does this person believe what they're saying? You can have the most beautifully crafted narrative in the world, but if you're hedging as you deliver it, if you're apologizing between sentences, if you sound like you're confessing rather than sharing, it won't land.

This is why the internal work matters as much as the external preparation. You can practice your talking points all you like, but if somewhere inside you still believe your career looks like a liability, that belief will leak through. The goal is not to perform confidence. The goal is to actually find it, by doing the honest excavation of your own story until you can see what was always true about it.

A Few Practical Anchors

When I work with clients on their narratives, a few specific tools tend to make the biggest difference:

Lead with the constant, not the change. Start your story with the value, mission, or interest that has been consistent throughout, even if the roles and industries have varied. "Throughout my career, I've been drawn to..." is a powerful opener. It signals that what looks like variety is actually coherence around a single driving force.

Let your tenure speak. If you've spent meaningful time in each role, multiple years, not months, say so. There's a real difference between someone who job-hops every 18 months and someone who has taken big, infrequent leaps. If you're the latter, that track record is evidence of commitment. Use it.

Reframe the degree or credential that "doesn't fit." If you've taken a course, a program, or a degree in a direction that seems out of place, don't hide it or awkwardly justify it. Lean into what it shows: that you invest in your own growth, that you're willing to do hard things to get closer to what you care about, that you show up as a learner, not just a practitioner.

Be honest about what you want, carefully. There's a difference between being honest about your interests and accidentally signaling that the role you're interviewing for is a stepping stone you're already looking past. You can say "I love working with data" without saying "I want to be a data scientist one day." You can express genuine enthusiasm for the work in front of you while being a full, evolving person with continued ambitions. Both can be true.

The Story Was Yours All Along

I want to close with something I tell almost every client I work with on this:

I am not making up your story. I am reflecting it back to you.

Everything that goes into a compelling career narrative is already in your lived experience. The passions, the pivots, the reasons, the thread, it's all there. What most professionals lack isn't the material. It's the distance to see it clearly, and the permission to claim it fully.

You have been building something. Maybe you couldn't have described where it was going at every step. That's true of most meaningful careers. But when you look back, the through-line is there. The question is whether you're willing to own it, not apologize for it, not explain it away, not preemptively defend yourself against doubts that may not even be there.

Your path doesn't have to look like everyone else's to be compelling. In fact, the most interesting stories rarely do.

You have a story worth telling. Tell it like you mean it.

What is the thread that runs through your career, even the parts that felt disconnected? Take a few minutes to write it down. You might be surprised what you find.

Slow Down to Go Faster

Do you ever feel like the only way to get where you're going is to push harder?

More hours. More discipline. More willpower. If you're falling behind, the answer must be to do more — not less. And so you put your head down and grind. You skip the walk with your colleagues. You eat lunch at your desk. You tell yourself you'll rest when it's done.

I've been there. More times than I'd like to admit.

There was a season in my career when 12-hour days had become my normal. My colleagues would step outside for a walk in the middle of the day. I watched them go, but I never joined. I simply didn't have the bandwidth. There was too much to do, and taking a break felt like a luxury I hadn't earned yet.

Then one afternoon, I found myself with a 30-minute gap before several more hours of work. Something made me decide to take that walk.

I came back with a new perspective on the problem I'd been wrestling with for days. What I thought would take hours took 30 minutes. I went home early for the first time in a long while.

That walk didn't slow me down. It was the reason I finished.

What We Get Wrong About Discipline

Here's the story most high achievers tell themselves: If I just push through, I'll get there faster.

The subtext sounds something like: I should be able to handle this. I should have this done by now. Slowing down is falling behind.

These thoughts feel like discipline. They feel like drive. But I want you to consider something — what if they're actually the thing slowing you down?

Think of it this way. Imagine you're running a marathon. You've trained, you're ready, and you're determined to finish strong. Now imagine strapping a heavy pack to your back before the starting gun fires. The pack is filled with every "I should" you carry: I should push through. I should never need a break. I should be further along by now.

You still might finish. But it will take longer. It will hurt more. And somewhere around mile 18, you might wonder why you ever thought this was supposed to feel good.

The weight isn't discipline. The weight is the story you're telling yourself about what discipline requires.

What Runners Know That We've Forgotten

I'm a runner. A slow one — I'll fully own that. But I've learned something from running that I now bring into every area of my work and my coaching.

Jeff Galloway, US Olympian and running coach, has spent 50 years studying what actually helps runners finish marathons faster. His finding might surprise you: strategic walk breaks don't slow you down. They help you go faster.

In surveys of runners who shifted from non-stop running to a deliberate run-walk-run approach, the average improvement was over 13 minutes in a marathon. Runners who took intentional breaks outpaced runners who pushed through — because their bodies recovered more efficiently, their form held up longer, and they didn't hit the wall as hard in the final miles.

Over 98% of Galloway's participants finish their marathons. Not because they pushed harder. Because they learned when to ease up.

The same principle lives in your work, your leadership, and your goals.

Running With a Lighter Pack

When you give yourself permission to slow down — strategically, intentionally — three things happen.

You're more likely to finish.

Burnout doesn't announce itself. It builds quietly under the surface of all those 12-hour days, all those skipped lunches, all those "I'll rest when it's done" promises. The leaders I work with who burn out aren't lazy. They're the ones who believed they had to carry everything, all the time, without stopping. Releasing even a little of that weight — one walk, one slower morning, one week without working late — isn't weakness. It's what makes the long game possible.

You can actually move faster.

This is the part that feels counterintuitive until you experience it yourself. When you step away from a problem, your brain doesn't stop working. It shifts into a different mode — one that's better at pattern recognition, creative connection, and seeing what you couldn't see when you were deep in the weeds. My 30-minute walk didn't cost me time. It gave me hours back. This isn't a productivity hack. It's how we're wired.

You'll actually enjoy the journey.

This one matters more than we let ourselves admit. When every day is a grind you're trying to get through, you stop noticing the moments worth savoring. You stop feeling proud of how far you've come. The finish line becomes the only thing that counts, and you arrive there exhausted, already scanning for the next thing to accomplish. A little more lightness along the way doesn't diminish what you're building. It makes it worth building.

A Few Questions Worth Sitting With

I want to leave you with something to take into your day — not a to-do list, but a moment of honest reflection.

What weight are you carrying right now?

Get specific. What are the "I should" thoughts that show up most often? I should be further along. I should be able to handle more. I should already know how to do this. Write them down if you can. There's something clarifying about seeing them outside of your own head.

What would it look like to set one of them down?

Not forever. Not abandoning your standards or your ambition. Just for today — or even for an afternoon. What would you do differently if you gave yourself a little more grace? What might you notice? What might become easier?

What is your version of the walk?

It doesn't have to be a literal walk (though it might be). It's whatever gives your mind the kind of space where better answers tend to appear. For some people it's a drive with music. For others it's a slow morning before the emails start. For others still it's a conversation with someone who helps them think clearly.

Whatever it is — you haven't earned it yet is never the right reason to skip it.

You don't have to carry all of it to prove you're serious about where you're going. Real strength isn't about how much weight you can carry. It's about being wise enough to put some of it down.