We have a strange relationship with tenure.

A résumé with frequent job changes can make someone look unreliable. A résumé with long stretches at the same company can make someone look stable, experienced, and trustworthy.

There are countless heuristics around this.

“They’ve only stayed two years. That’s a red flag.”

“They’ve been there for ten years. They must be very experienced.”

“They’ve changed companies five times in seven years. They probably won’t stay.”

Sometimes these heuristics are useful.

But I increasingly think they are far too simplistic.

The more I think about tenure, the more I believe that the important question isn’t simply how long someone stayed.

The more interesting question is:

How long does it take for someone in this role, in this environment, to receive meaningful feedback on the decisions they make?

That changes everything.

Because one year as an engineer, one year as a manager, one year as a director, and one year as an executive can represent radically different amounts of experience.

Tenure is measured by the calendar.

Experience is accumulated through feedback cycles.

The feedback cycle

Almost every meaningful job has some version of the same loop:

You make a decision.

You act on it.

The system responds.

Eventually, the consequences become visible.

You receive feedback.

You understand what happened.

And, ideally, you change how you operate.

That is experience.

The important variable is therefore not simply the amount of time that has passed.

It is how many meaningful feedback cycles have been completed.

And the length of those cycles varies enormously.

An engineer’s feedback cycle

Consider an engineer working on a substantial technical system.

They might:

• understand the problem
• design an architecture
• make trade-offs
• implement it
• deploy it
• operate it
• encounter unexpected behavior
• discover scaling or reliability problems
• learn from those problems
• redesign part of the system

Depending on the project, that entire cycle might happen within a few months.

For a reasonably sized engineering project, a year or two can provide a tremendous amount of technical feedback.

Of course, this is not universal.

An engineer working on a decade-long infrastructure transformation is operating on a completely different timeline.

But in many software environments, technical feedback cycles are relatively fast.

That is one reason I am not particularly alarmed by a one- or two-year engineering tenure by itself.

If the person has strong technical skills, good references, meaningful ownership, and can clearly explain the systems they built and the trade-offs they made, a short tenure does not necessarily tell me much about their reliability.

It may simply mean they have more optionality.

They may have finished the problem they came to solve.

They may have wanted a harder problem.

They may have learned everything they could from that particular environment.

They may have found that the next stage of growth wasn’t available where they were.

Or the company may simply not have been a good fit.

The résumé tells me they left.

It doesn’t tell me why.

The same clock does not apply to management though

This becomes much more interesting when we move into management.

An engineer primarily changes a technical system.

A manager changes a system of people.

That difference matters because people and organizations often have much much longer feedback cycles.

Suppose a manager changes the team’s ownership model.

At first, everything might look better.

People have more autonomy.

There are fewer meetings.

Decisions appear to happen faster.

But six months later, cross-team dependencies start accumulating.

Or suppose the manager introduces more process because the team feels chaotic.

Initially, predictability improves.

A year later, engineers may have stopped taking initiative because every decision now requires approval.

Or a manager changes hiring standards.

The immediate effect might not be visible at all.

The people hired today may become critical contributors, mediocre performers, or organizational problems two years later.

Management decisions frequently have second-order effects.

You change one part of the system.

The system adapts.

That adaptation changes another part.

Eventually, the consequences return to you.

That can take a long time.

The feedback cycle changes with scope

As responsibility expands, the distance between a decision and its consequences generally increases.

These aren’t rules.

They are just a way of thinking about causal distance.

The larger the system you are responsible for, the longer it can take for your decisions to propagate through that system and return to you as meaningful feedback.

And that makes tenure increasingly important as scope increases.

Professional growth can be misleading…

There is another signal that can be just as misleading as tenure: professional growth within an organization.

We tend to look at someone who has steadily moved upward and assume that the progression itself is evidence of increasing capability.

Engineer → Senior Engineer → Manager → Senior Manager → Director → VP.

It is certainly evidence that the organization kept giving that person larger responsibilities. But it is not necessarily evidence that their knowledge, judgment, or experience grew at the same rate.

Organizations are complicated systems.

People get promoted for many reasons.

Sometimes they are genuinely excellent and have earned progressively larger scope.

Sometimes the business is growing quickly and needs people to fill new positions.

Sometimes someone has deep institutional knowledge and is the obvious person available.

Sometimes a manager leaves and the next person in line gets promoted.

Sometimes someone is exceptionally good at operating within the organization’s existing culture and processes.

Sometimes they are simply in the right place at the right time.

And sometimes a person can keep moving upward because the organization keeps changing around them faster than the feedback from their previous decisions can arrive.

That last case is particularly interesting.

Imagine someone who becomes a manager after a few years as an engineer.

Before they have really experienced the consequences of their management decisions, the organization grows and they become a senior manager.

Then another manager leaves, and they become a director.

A few years later, they are running a large organization.

From the outside, the trajectory looks extraordinary.

But if we trace the actual feedback cycles, something different might emerge.

They may never have stayed in one managerial system long enough to understand its long-term consequences.

They may have inherited organizations rather than built them.

They may have implemented strategies designed by someone else.

They may have moved on before the consequences of difficult decisions became visible.

They may have been promoted precisely when the organization was changing enough that the old problems disappeared before anyone could determine whether their decisions had actually solved them.

In other words, their organizational seniority may have grown faster than their accumulated judgment.

This is why I don’t think professional progression should be treated as a simple proxy for experience.

A person can be promoted repeatedly without necessarily completing the feedback cycles that would normally develop the judgment required for the next level.

And this can be particularly difficult to see in large organizations.

Large companies have enormous organizational inertia.

Once someone reaches a certain level, they can sometimes operate successfully because the systems around them are strong enough to compensate for weaknesses in their own judgment.

They may have excellent staff.

They may have experienced people underneath them.

They may have established processes.

They may have strong peers.

They may have a powerful brand behind them.

They may have large teams that absorb mistakes.

They may have leaders above them who quietly correct decisions before those decisions become consequential.

The organization can therefore create an environment in which someone appears highly effective without necessarily exposing the full limits of their judgment.

This is another reason I think scope should match knowledge, experience, and judgment.

The pace of the industry matters too

There is another variable that I think is often overlooked.

Industry velocity.

Different environments produce feedback at very different speeds.

A technology startup might go from idea to product to customers to scaling problems to organizational restructuring in a few years.

A heavily regulated or conservative industry might take years to move through a comparable cycle.

A major infrastructure project might take a decade.

A pharmaceutical development program can operate on a completely different timeline.

A financial institution may have technology and organizational systems whose consequences emerge over many years.

So tenure has to be interpreted relative to the environment.

Three years is not a universal unit of experience.

The startup founder is a fascinating example

Consider someone who starts a technology company and runs it for three years.

In those three years, they may have experienced:

• product development
• customer discovery
• pricing
• sales
• hiring
• firing
• fundraising
• cash-flow management
• organizational design
• competition
• product-market fit
• scaling problems
• cultural problems
• strategic mistakes
• and perhaps failure

They might even shut the company down.

That can be an extraordinarily deep feedback cycle.

In fact, there is something interesting about failure.

A founder who starts a company, makes difficult decisions, watches the consequences unfold, eventually realizes the business isn’t working, shuts it down, and genuinely reflects on why it failed may come out of that experience with enormous practical knowledge.

I would call that scar tissue.

But scar tissue alone isn’t enough.

Failure does not automatically produce wisdom.

Reflection is what turns experience into learning.

Scar tissue becomes experience when it is accompanied by reflection and changed behavior.

Someone who has experienced failure but learned nothing from it may repeat the same mistakes.

Someone who understands why the failure happened and changes how they operate afterward has completed a very valuable feedback cycle.

A three-year founder vs. a ten-year executive

Imagine two people.

One spent ten years at a stable company.

The other founded a startup and spent three years trying to make it work.

The first person may have enormous institutional knowledge.

The second may have experienced:

idea → product → customers → hiring → growth → mistakes → strategic change → failure

The second person may have gone through an entire business-building cycle in three years.

That doesn’t automatically make them a better leader.

But it demonstrates why calendar time alone is a poor proxy for experience.

The founder may have been exposed to far more consequential decisions and much faster feedback.

But the opposite can also be true

Now imagine someone working in a very slow-moving industry.

They might spend five years on a major transformation.

The first two years involve planning.

The next two involve implementation.

The fifth year is when the organization finally begins seeing the consequences.

In that environment, five years might not be unusually long.

It may simply be what the system requires to produce meaningful feedback.

This is why I wouldn’t say:

“A manager needs three years.”

Or:

“A director needs five years.”

Those numbers are too arbitrary.

Instead:

The required tenure should be interpreted relative to the feedback cycle of the system.

Project scale matters too

Industry velocity isn’t the only variable.

Project scale matters.

An engineer working on a small service may be able to design, build, deploy, operate, and improve the system several times within a few years.

An engineer working on a massive infrastructure transformation may not.

The same is true for management.

A manager of a ten-person team in a rapidly changing startup may experience organizational feedback much faster than a manager responsible for a large, heavily regulated operation.

And a founder building a consumer application may experience dramatically faster feedback than someone building a business where every major customer contract takes two years to close.

So I think the model really has several dimensions:

Tenure is therefore not a standalone variable.

It is a variable embedded inside a system.

The résumé is a map, not the territory

This is ultimately why I think résumés can be deceptive.

A résumé tells you:

where someone worked

and

when they worked there.

It doesn’t tell you:

what happened.

Two people can have identical résumés:

Company A — 2 years
Company B — 2 years
Company C — 2 years

But one person might have spent those six years:

• building systems
• owning production
• dealing with failures
• leading migrations
• learning from mistakes
• progressively increasing responsibility

while the other might have spent them:

• working on narrow components
• avoiding ownership
• moving before projects completed
• rarely seeing production consequences

The résumé looks the same.

The experience isn’t.

This is why the most useful interview questions are often not about chronology.

They’re about causality.