Enable Others to Succeed

The Multiplier

There is a point in almost every career when being good at your own job is no longer the greatest contribution you can make.

You can solve the problem yourself.

Or you can teach ten people how to solve it.

You can become the highest performer on the team.

Or you can help the entire team perform at a higher level.

Those are different kinds of success.

The first is individual performance.

The second is multiplication.

Your greatest contribution may not be what you accomplish. It may be what other people become capable of accomplishing because you were there.

---

Gives Good Phone

Long before I became deeply involved in technology, I worked in a call center.

I was good on the phone.

Really good.

I had a natural ability to build rapport with people.

My nickname became:

"Gives Good Phone."

One of the descriptions I remember hearing was:

"Voice smooth as butter."

It was funny.

But underneath the jokes was something useful.

I had developed techniques that worked.

I understood how to speak with customers.

I understood pacing.

Tone.

Listening.

Rapport.

How to make a conversation feel natural instead of scripted.

Eventually I was given an opportunity that would teach me something much more important than simply being good on the phone.

I was asked to help other people become good at it too.

---

A-Bay

New employees went through approximately three weeks of initial training.

Afterward, they still had to make the transition from classroom knowledge to actual customer conversations.

We created a team concept we called "A-Bay."

The new hires would rotate through this team after completing their training.

We watched their metrics closely every day.

But the metrics were not the real work.

The metrics told us where to look.

The real work was individual coaching.

I would sit with people one on one.

Listen to their calls.

Identify specific problems.

Explain what I was hearing.

Demonstrate techniques.

Listen again.

Adjust.

Repeat.

The coaching was intensive.

It was personal.

And it worked.

---

The First Group Taught Me How to Teach

The first class gave me an opportunity to refine the process.

Not every coaching technique worked equally well.

Not every new hire struggled with the same thing.

Some needed help with confidence.

Some needed help listening.

Some needed help controlling the conversation.

Some needed help sounding less mechanical.

The important thing was that I was not trying to turn everyone into me.

I was trying to identify what was preventing each person from succeeding.

Then help them remove that obstacle.

That distinction matters.

Enablement is not creating copies of yourself. It is helping people discover how to succeed with the abilities they already possess.

---

Then Something Unexpected Happened

After the first class allowed me to refine the process, the results became remarkably consistent.

Remember what this team was.

New hires.

People who had just completed training.

Every few weeks, the people I had been coaching would rotate out and another group of new hires would arrive.

We started again.

Yet month after month, the A-Bay team's metrics remained near the top of the department.

Top three.

Repeatedly.

At one point, number one.

These were not seasoned representatives with years of experience.

They were new employees rotating through every three weeks.

And they were outperforming most of the established teams.

That got people's attention.

---

I Wasn't the Number Two Team

There is an important distinction here.

I wasn't the number two team.

They were.

I may have built the coaching process.

I may have helped identify the techniques.

I may have watched the metrics and worked individually with the representatives.

But they had to answer the calls.

They had to apply what they learned.

They had to build rapport.

They had to perform.

Their success belonged to them.

My contribution was helping create an environment where their success became more likely.

That was the multiplier.

---

My Manager Looked Very Good

Naturally, the results reflected well on my direct manager.

His area had a development process producing exceptional results.

But the results also created an uncomfortable comparison.

A rotating group of new hires was outperforming many established teams.

That can create questions.

Why?

What is happening differently?

What techniques are being used?

Can they be repeated?

Those are exactly the questions a healthy organization should ask.

The department head became interested in what we were doing.

I documented the techniques.

The process was no longer just something I knew how to do.

It could be studied.

It could be taught.

It could potentially be reproduced.

That is what enablement should become.

When success depends on a person, you have talent. When the method can be taught and repeated, you have capability.

---

Six Months of Evidence

This was not one unusually strong group.

The pattern continued.

New people arrived.

We coached them.

They improved.

They rotated out.

Another group arrived.

We did it again.

Month after month.

For approximately six months, the A-Bay team remained among the top-performing teams in the department.

One month, we reached number one.

That consistency mattered more to me than any single month's ranking.

One exceptional month can happen for many reasons.

Repeated results with constantly changing people suggest something different.

The process was working.

We had created a system for helping people succeed.

---

Then Leadership Changed

Eventually, the department head was promoted.

One of the floor managers moved into the department head position.

She listened to one of the training calls I was using with the new hires.

Her reaction was extremely complimentary.

She told me how good I was on the phone.

She believed that if I returned to being an individual representative, I could become the number one performer in the department.

She was probably right.

But I thought the conclusion was remarkably short-sighted.

Because the most valuable thing I was doing was no longer being good on the phone.

It was duplicating that ability in other people.

---

One Great Performer or an Entire Team?

Leadership faced a choice, whether anyone described it that way or not.

Use my skills to produce one exceptional individual performer.

Or use those same skills to help produce an entire team of stronger performers every three weeks.

I was moved back into an individual contributor role.

Someone else took over A-Bay.

The following month, something revealing happened.

I became the number one representative.

A-Bay fell to the bottom of the metrics.

The decision succeeded at exactly what it had optimized for.

It produced one outstanding individual performer.

And the multiplier disappeared.

If you take the person creating ten successful people and make them responsible only for their own success, do not be surprised when you get one success instead of ten.

---

Don't Confuse Talent With Leverage

Organizations naturally notice talented individuals.

The best salesperson.

The best engineer.

The fastest troubleshooter.

The person everyone calls when something breaks.

Those people are valuable.

But individual performance and organizational leverage are not the same thing.

If the best engineer can solve ten incidents...

That is useful.

If the best engineer can teach ten engineers how to solve those incidents...

That is leverage.

If the engineer can then eliminate the incident entirely through architecture or automation...

That is even greater leverage.

The higher you progress, the more important this distinction becomes.

Your value should not be measured only by how much work can pass through your hands.

It should also be measured by how much capability you create around you.

---

Leadership Can Raise or Lower the Ceiling

Managers have tremendous influence over what their teams become.

They can surround themselves with strong people and help those people become stronger.

Or they can become uncomfortable when someone else's success creates comparison.

They can preserve high standards.

Or they can make the standards easier to meet.

They can ask:

"How do we reproduce what is working?"

Or:

"How do we return things to the way they were?"

I cannot know every reason behind the decisions people made during that period of my career.

And with time, I have learned not to pretend that I do.

What I can evaluate are the results.

A repeatable development system existed.

It produced strong results.

The system was changed.

The results changed with it.

That is enough to teach the lesson.

---

Enablement Is Not Favoritism

There is another distinction worth making.

Enabling someone to succeed does not mean making success easier to claim.

It does not mean lowering the standard.

It does not mean protecting someone from measurement.

It does not mean giving opportunities only to people you like.

Real enablement does the opposite.

It gives people the tools, knowledge, coaching, feedback, and opportunity necessary to meet a meaningful standard.

Then it lets the results speak.

Helping someone succeed is not lowering the bar. It is giving them a better ladder.

---

Make Your People Dangerous

The best managers I have worked with were not threatened by capable people.

They wanted them.

They wanted engineers who challenged assumptions.

People who learned quickly.

People who could eventually perform work the manager could not.

People who might someday become managers, principal engineers, architects, directors, or leaders themselves.

That is how organizations grow.

A leader who must remain the most capable person in the room eventually becomes the ceiling of the room.

A leader who develops capable people raises the ceiling.

---

Your Success Changes as You Grow

Early in your career, success is often measured directly.

Your tickets.

Your sales.

Your code.

Your projects.

Your metrics.

That makes sense.

But as your influence grows, the definition of success should expand.

Did the team improve?

Did someone learn?

Did the process become easier?

Did knowledge spread?

Did the organization become less dependent on one expert?

Did someone succeed because you gave them the opportunity and tools to do so?

Eventually, those questions become more important than your personal scoreboard.

---

The Lesson I Carried Forward

I learned something important from A-Bay.

Being number one felt good.

But I already knew I could perform.

Watching an entire group of new people become successful was different.

That was far more interesting.

My individual performance had a limit.

There was only one of me.

But knowledge could multiply.

Coaching could multiply.

Standards could multiply.

Confidence could multiply.

And when people I helped became successful, their success could continue long after they stopped working with me.

That lesson eventually followed me into technology.

Teach the engineer.

Document the process.

Share the knowledge.

Build the tool.

Create the opportunity.

Then get out of the way and let people succeed.

The strongest leaders do not prove how much better they are than the people around them. They prove how much better the people around them can become.

Create Capability, Not Dependence

When you become experienced at something, an interesting problem develops.

You become fast.

You recognize patterns sooner.

You know where to look.

You have already made many of the mistakes someone else is about to make.

So when a less experienced person struggles with a problem, the temptation is obvious.

Take the keyboard.

Fix it.

Move on.

Sometimes that is exactly what the situation requires.

But if you do it every time, something else happens.

You become faster.

They remain dependent.

Solving the problem for someone creates an answer. Teaching them how to solve it creates capability.

---

Resist the Keyboard

Anyone who has mentored engineers knows this feeling.

You are watching someone troubleshoot.

You already see the problem.

They are looking in the wrong place.

They run a command.

Nothing.

They try another theory.

Wrong again.

You know that if you took control, you could probably resolve the issue in five minutes.

Watching them work through it may take thirty.

Those twenty-five minutes can feel incredibly expensive.

Sometimes they are.

During a major production outage, restoring service may matter more than creating a teaching opportunity.

Take the keyboard.

Fix the problem.

Teach afterward.

But not every problem is a production emergency.

Sometimes those extra twenty-five minutes are an investment.

Because if the engineer discovers the answer...

Understands why it worked...

And remembers the reasoning...

You may never need to spend those five minutes again.

---

Don't Teach the Command

Teach the thought process.

This is one of the most important distinctions in technical mentoring.

Someone asks:

"What command should I run?"

You can give them the command.

Sometimes that is appropriate.

But the better lesson is often:

"What are you trying to learn from the command?"

What evidence are we looking for?

What hypothesis are we testing?

What would this result tell us?

What would cause us to investigate somewhere else?

The command will eventually change.

The operating system will change.

The platform will change.

The syntax will change.

The reasoning survives.

Procedures help people repeat your answer. Principles help them discover their own.

---

Ask Before You Answer

One of the easiest ways to enable someone is also one of the simplest.

Ask questions.

"What do you think is happening?"

"What evidence supports that?"

"What changed?"

"What would you check next?"

"What result would prove your theory wrong?"

"What is the risk of this change?"

"What happens if this doesn't work?"

Questions force thinking.

They reveal understanding.

They expose assumptions.

And they allow you to coach the reasoning instead of merely correcting the result.

The goal is not to make someone guess what is inside your head.

The goal is to help them develop a reliable process inside theirs.

---

Give People Real Ownership

You cannot enable people while refusing to trust them with meaningful responsibility.

At some point, they need to drive.

Let them lead the troubleshooting call.

Let them write the script.

Let them perform the deployment.

Let them present the architecture.

Let them own the project.

Stay available.

Review the work.

Provide guardrails appropriate to the risk.

But give them something real.

People become capable by doing capable work.

You cannot prepare someone for responsibility while protecting them from responsibility.

---

Create Safe Places to Fail

Learning requires mistakes.

That does not mean allowing people to recklessly experiment in production.

Good enablement creates places where mistakes are inexpensive.

Development environments.

Labs.

Test accounts.

Sandboxes.

Code review.

Peer review.

Staged deployments.

Rollback procedures.

Feature flags.

Backups.

These are not only technical controls.

They are learning infrastructure.

They allow people to stretch beyond what they already know without making every mistake catastrophic.

The goal is not to eliminate failure.

It is to control the cost of learning from it.

---

Never Humiliate the Learner

There is an enormous difference between correcting someone and embarrassing them.

Experienced people sometimes forget how much they once did not know.

The answer seems obvious now.

It was not always obvious.

Someone taught us.

Or experience taught us.

Usually through mistakes.

When someone gives the wrong answer, you have a choice.

You can demonstrate how much more you know.

Or you can help them understand what they missed.

Only one of those creates a stronger engineer.

Knowledge used to make someone feel small is not mentorship. It is ego wearing expertise as a costume.

---

Keep the Bar High

Enabling others does not mean making success easier by changing the definition of success.

That distinction matters.

Suppose someone is expected to meet a meaningful standard.

There are two ways to make their performance look better.

Lower the standard.

Or help them become capable of reaching it.

Only one creates lasting value.

Give them better training.

Better documentation.

Better tools.

Better feedback.

Better examples.

Better opportunities to practice.

Remove unnecessary obstacles.

Then keep the standard.

Enablement removes obstacles to achievement. Favoritism removes accountability for achievement.

Those are not the same thing.

---

Coach the Person, Not the Metric

Metrics are useful.

A-Bay depended heavily on them.

We watched performance closely because the numbers helped identify where coaching might be needed.

But the metric was never the person.

A number tells you what happened.

It rarely tells you everything about why.

Two people can produce the same weak result for completely different reasons.

One may lack knowledge.

Another may lack confidence.

Another may misunderstand the process.

Another may have the knowledge but struggle to apply it consistently.

If you coach only the metric, you may prescribe the same solution to completely different problems.

Good coaching asks:

"What is preventing this person from succeeding?"

Then addresses that.

---

Feedback Must Be Specific

"Do better" is not coaching.

"Be more confident" is not coaching.

"Improve your troubleshooting" is not coaching.

Useful feedback identifies something actionable.

"You reached a conclusion before validating the DNS response."

"You interrupted the customer before they finished describing the symptom."

"You changed two variables simultaneously, so now we don't know which one affected the result."

"You solved the issue correctly, but you didn't document the recovery steps."

Now the person has something they can change.

Specific feedback creates specific improvement.

---

Praise What Should Be Repeated

Feedback should not exist only when something goes wrong.

When someone does something well, tell them what they did well.

Not simply:

"Great job."

Explain why.

"You stopped before making the change and verified the rollback path."

"You admitted you didn't know instead of guessing."

"You found the root cause instead of stopping when the symptom disappeared."

"You documented the issue well enough that someone else can repeat the recovery."

That reinforces behavior.

People learn from correction.

They also learn from knowing which decisions deserve to become habits.

---

Don't Create Copies of Yourself

One of the mistakes mentors can make is believing their job is to create smaller versions of themselves.

It isn't.

The people you teach will have different strengths.

Different personalities.

Different ways of communicating.

Different approaches to problems.

That is valuable.

Give them the principles.

Give them the standards.

Give them the boundaries.

Then allow them to develop their own style.

Someone may eventually discover a better method than yours.

Celebrate that.

If your student surpasses you, the mentorship worked.

---

Share the Credit

If you enable someone to succeed, let the success belong to them.

Do not stand behind every accomplishment reminding everyone who trained them.

Do not turn their success into another story about yourself.

You may have helped.

You may have coached.

You may have opened the door.

But they walked through it.

Give them visibility.

Let them present their work.

Mention their contribution when they are not in the room.

Recommend them for opportunities.

A leader who creates capable people should not need to compete with them for recognition.

If you helped someone become excellent, their excellence is evidence enough.

---

Sponsorship Matters Too

Mentorship teaches.

Sponsorship opens doors.

Sometimes someone is ready for the next challenge but does not yet have access to it.

Give them the opportunity.

Invite them to the architecture meeting.

Put them on the project.

Let them lead the presentation.

Recommend them for the role.

Introduce them to people who can help them grow.

Then let them prove themselves.

You are not guaranteeing their success.

You are making sure opportunity is not unnecessarily withheld.

---

Build Systems That Help People Succeed

Enablement is not limited to coaching.

Engineering itself can enable people.

A clear dashboard enables faster decisions.

A good runbook enables recovery.

Automation enables consistent execution.

Good defaults enable safer deployments.

Documentation enables independence.

Monitoring enables earlier intervention.

A well-designed interface enables people to use complicated technology without becoming experts in every layer beneath it.

This is one reason good engineering and good leadership have so much in common.

Both ask:

"How can I create an environment where success becomes easier to achieve correctly?"

---

Measure the Multiplier

As engineers become more senior, measuring them only by individual output becomes increasingly incomplete.

How many tickets did they close?

How many lines of code did they write?

How many incidents did they personally resolve?

Those numbers can matter.

But they miss something.

How many incidents no longer occur because of what they built?

How many engineers can now solve problems that previously required escalation?

How much manual work disappeared?

How much knowledge was transferred?

How many people became capable of operating independently?

How many future projects became easier?

The most valuable work may reduce the amount of visible work attributed to the person who created it.

That is the multiplier.

---

Make Success Portable

The real test of enablement comes when you leave.

Can the person still succeed?

Can the team still perform?

Does the process continue?

Does the knowledge remain?

If success disappears when the mentor disappears, the transfer was incomplete.

The goal is not permanent dependence.

It is independence.

Eventually the person you taught should stop needing you for the things you taught them.

Then perhaps they teach someone else.

Now the multiplier multiplies again.

---

Closing Thought

You can spend a career proving how capable you are.

Or you can use that capability to create more of it around you.

Teach the reasoning.

Give people ownership.

Create safe opportunities to learn.

Keep the standards high.

Give specific feedback.

Share the credit.

Open doors.

Then step back.

The measure of a great mentor is not how many people need their help. It is how many people no longer need it because they learned how to succeed on their own.

Success Should Spread

The best kind of success does not remain isolated.

It spreads.

One capable person helps another become capable.

That person teaches someone else.

A team improves.

A department improves.

Eventually the organization operates at a higher level because knowledge moved instead of staying trapped.

That is one of the most powerful forms of leverage any leader can create.

Success becomes durable when it stops belonging to one person.

---

Leadership Is Not Control

Some leaders measure their value by how many decisions pass through them.

Everything requires approval.

Every important conversation includes them.

Every difficult problem waits for them.

At first, this can look like leadership.

Often it is dependence.

The organization moves only as quickly as one person can think.

That does not scale.

Strong leaders create clarity.

They establish standards.

They explain intent.

They give people enough context to make good decisions without asking permission for every step.

Control may produce compliance.

Enablement produces capability.

---

Give People Context, Not Just Instructions

Instructions tell someone what to do.

Context helps them understand why.

That difference matters.

If I tell someone:

"Use this procedure."

They may succeed when the situation matches the procedure exactly.

If I explain:

"This is the risk we are controlling, this is the outcome we need, and this is why the procedure works."

Now they can adapt when reality changes.

Context creates judgment.

Judgment creates independence.

Instructions help people follow the path. Context helps them find the path when the map no longer matches the terrain.

---

Make Decisions Where the Knowledge Exists

Organizations sometimes push every decision upward.

That creates delay.

The person closest to the work often understands the problem best.

A customer-facing employee hears the customer's frustration directly.

An engineer troubleshooting the system sees the evidence.

A technician working on the equipment understands the physical reality.

Leaders should define boundaries and risk tolerances.

Then allow informed decisions to happen as close to the problem as practical.

That does not mean removing accountability.

It means placing authority where useful knowledge already exists.

---

Create Clarity Around the Goal

People struggle when success is vague.

"Improve performance."

"Make the customer happier."

"Fix the process."

Those statements sound useful.

They are difficult to act upon.

Enablement begins with clarity.

What does success look like?

What matters most?

What cannot be compromised?

What tradeoffs are acceptable?

What authority does the person have?

What requires escalation?

Clear goals give people room to think.

Ambiguous goals force people to guess.

---

Standards Create Freedom

Standards are sometimes viewed as restrictions.

Good standards create freedom.

If everyone agrees on:

• Security requirements
• Naming conventions
• Deployment patterns
• Documentation expectations
• Review processes
• Recovery objectives

Then engineers do not waste energy renegotiating the basics every time.

They can focus on the interesting parts.

Standards remove uncertainty from routine decisions.

That allows creativity to concentrate where it matters.

---

Leaders Should Create More Leaders

A leader who cannot tolerate another strong leader nearby will eventually weaken the organization.

Strong people should not be treated as threats.

They should be multiplied.

Give them responsibility.

Let them mentor.

Let them lead meetings.

Let them make decisions.

Let them represent the team.

Let them become better than you at things.

That last part can be uncomfortable.

It should also be the goal.

If everyone you teach remains below your level forever, something has gone wrong.

The success of a leader is not proven by having followers. It is proven by creating people capable of leading without them.

---

Enablement Requires Trust

You cannot enable someone while constantly overriding them.

Eventually you have to let people make decisions.

Sometimes they will choose differently than you would.

That does not automatically make the decision wrong.

There are often several good solutions.

A leader who insists everything must be done exactly their way may produce consistency.

They may also prevent growth.

Set the guardrails.

Define the outcome.

Let people think.

Review the result.

Then teach from what happened.

---

Allow People to Own Their Wins

One of the easiest ways to destroy motivation is to give someone responsibility and then take all the credit.

If someone led the project, let them present it.

If someone solved the issue, recognize them.

If someone developed the idea, say their name when you discuss it.

If someone improved the process, make sure people know who did the work.

Recognition reinforces ownership.

It also tells the organization something important:

Good work is seen.

---

Protect People When They Take Responsible Risks

If you want people to make decisions, you have to accept that not every decision will work.

There is a difference between negligence and a reasonable decision that produced an unexpected outcome.

People should be accountable.

They should also be able to learn.

If every mistake becomes punishment, people stop taking responsibility.

They escalate everything.

They hide uncertainty.

They wait for someone else to decide.

A culture that demands independent thinking must tolerate honest mistakes made within reasonable boundaries.

If people are punished every time they exercise judgment, eventually they stop exercising judgment.

---

Teach Recovery, Not Fear

People become more confident when they know failure is recoverable.

That is true in engineering.

It is true in life.

If the team knows:

We have backups.

We have rollback.

We have testing.

We have peer review.

We have people who will help.

Then they can attempt difficult work responsibly.

Fear creates paralysis.

Recovery creates courage.

One of the best ways to enable someone is to teach them not only how to succeed...

But how to recover when things do not go as planned.

---

This Applies Far Beyond Work

Enablement is not only a management philosophy.

Parents enable children.

Teachers enable students.

Coaches enable athletes.

Mentors enable careers.

Friends enable confidence.

Communities enable opportunity.

The methods differ.

The principle does not.

Give people the tools.

Give them knowledge.

Give them opportunities.

Give them honest feedback.

Then allow them to become capable.

---

Parenting Is Probably the Purest Example

A parent's goal cannot be permanent dependence.

A child begins life completely dependent.

Over time, good parenting transfers capability.

Feed yourself.

Dress yourself.

Make decisions.

Manage money.

Solve problems.

Accept consequences.

Build relationships.

Eventually the child becomes an adult capable of succeeding without constant parental direction.

That independence is not evidence the parent became unnecessary.

It is evidence the parent succeeded.

Mentorship works the same way.

The purpose of guidance is not to remain necessary forever. It is to make independence possible.

---

Teaching Creates Multipliers

A person can perform one task at a time.

Knowledge can perform many.

Teach one person.

They teach another.

The effect grows.

This is why teaching is one of the most scalable things a human being can do.

The original lesson may continue spreading long after the original teacher is gone.

That is an extraordinary form of leverage.

---

Do Not Hoard Opportunity

Knowledge is not the only thing people need.

They need chances.

Someone may be capable of leading but never receive the opportunity.

Someone may understand the technology but never be invited into the architecture discussion.

Someone may be ready for the next role but lack visibility.

Enablement means noticing those moments.

Open the door.

Then let them walk through it.

There is no guarantee they will succeed.

That is okay.

Your responsibility was not to guarantee the outcome.

It was to make sure artificial barriers were not preventing the opportunity.

---

Strong Teams Make Everyone Better

The best teams have a compounding effect.

One person's strength fills another person's gap.

Someone teaches.

Someone challenges.

Someone documents.

Someone automates.

Someone asks the question nobody else considered.

Nobody has to be great at everything.

The team becomes strong because capability is shared.

That is a much healthier model than building everything around one indispensable expert.

---

Measure Yourself Differently

As responsibility grows, your scoreboard should change.

Do not ask only:

"What did I accomplish?"

Ask:

"Who became stronger?"

"What became easier?"

"What knowledge spread?"

"What opportunity did I create?"

"What work can now happen without me?"

"What did someone else accomplish because I helped remove an obstacle?"

Those answers reveal a different kind of success.

Often a more important one.

---

The Multiplier Is the Legacy

Eventually, every leader leaves.

Every mentor moves on.

Every manager changes roles.

Every parent grows older.

What remains?

If people are helpless without you...

You created dependence.

If people continue learning, deciding, teaching, building, and succeeding...

You created capability.

That is the multiplier.

And unlike individual performance, it can continue long after you stop contributing directly.

---

Closing Thought

The strongest people do not use their strength to remain above everyone else.

They use it to lift others.

Teach generously.

Set clear standards.

Give real responsibility.

Create safe places to learn.

Share credit.

Open doors.

Then let people surprise you with what they become.

Your success is not diminished when someone you helped becomes better than you. That may be the clearest evidence that you succeeded at all.

Founder's Commentary

Being Number One Was the Smaller Achievement

There was a time in my career when being the number one performer would have meant everything to me.

Recognition.

Status.

Proof that I was good at what I did.

And when I was moved out of A-Bay and back into an individual contributor role, that is exactly what happened.

I became number one.

By the numbers, that looked like success.

But by then, I had already seen something much more powerful.

I had watched new hires, people with almost no experience, become top performers through coaching, repetition, feedback, and confidence.

I had watched entire groups improve.

Not once.

Repeatedly.

That changed how I thought about success.

One person being number one is impressive.

Helping an entire team become better is leverage.

---

I Already Knew I Could Perform

By the time leadership moved me back into an individual role, I already knew I was good on the phone.

That wasn't the question anymore.

I had already proven that.

The more interesting question was:

Could I transfer what I knew?

Could I help someone else recognize the same patterns?

Could I help them build confidence?

Could I help them discover their own way to connect with customers?

A-Bay answered that question.

Yes.

And that felt much more meaningful than another personal metric.

Once you know you can succeed, the next challenge is learning whether you can help someone else succeed too.

---

The Real Product Wasn't the Call

At first, I thought my skill was the ability to handle a customer call.

Eventually I realized that was only the visible output.

The more valuable skill was understanding why the call worked.

Tone.

Pacing.

Listening.

Rapport.

Confidence.

Control without sounding controlling.

Making a customer feel heard.

Those were principles.

Once I could explain them, I could teach them.

Once I could teach them, other people could use them.

That was the shift.

The call was no longer the product.

The capability was.

---

Metrics Showed the Result, Not the Cause

The A-Bay metrics became difficult to ignore.

New hires rotating every few weeks.

Yet the team consistently performed near the top.

That told us something.

The people were changing.

The results were not.

When inputs change but strong results remain consistent, you should look closely at the process.

Something in the system is working.

I wish more organizations understood that.

People often celebrate the top performer.

That is easy to see.

The more interesting question is:

What created the conditions that allowed multiple people to perform well?

That is where scale lives.

---

I Was Proud of Them

One thing I remember clearly is how satisfying it was watching someone improve.

A new hire would struggle with something.

We would talk through it.

Listen to the call.

Identify the issue.

Try again.

Then something clicked.

Confidence changed.

The conversation changed.

The numbers changed.

There is a different kind of satisfaction in that.

You know the success belongs to them.

You helped.

But they did the work.

That made me proud in a way that my own performance never quite did.

---

Leadership Can Multiply or Compress Talent

The decision to move me back into an individual role taught me another lesson.

Organizations can use talent in very different ways.

You can take someone who performs exceptionally well and ask them to produce exceptional individual results.

There is nothing wrong with that.

Or you can ask:

How do we spread what this person knows?

How do we reproduce the behavior?

How do we build the process?

How do we make the knowledge portable?

Those questions create different outcomes.

The first concentrates talent.

The second multiplies it.

Leadership decides whether talent remains concentrated in individuals or becomes capability across the organization.

---

I Don't Need to Know Why the Decision Was Made

At the time, I had plenty of opinions about why leadership made the change.

Maybe there were politics.

Maybe some managers disliked the comparison.

Maybe the department wanted to return to a familiar model.

Maybe the new leader genuinely believed moving me to an individual role was the best use of my skills.

I cannot know that with certainty.

And after enough years, I have learned not to build lessons on motives I cannot prove.

The outcome is enough.

The development model changed.

I became number one.

A-Bay fell to the bottom of the metrics.

That contrast taught me everything I needed to learn.

---

Enablement Is Not Lowering the Bar

Another lesson stayed with me.

Helping people succeed does not mean making success easier to claim.

The standard still matters.

A-Bay worked because we watched the metrics closely.

People knew what good performance looked like.

We didn't lower expectations.

We improved the path toward meeting them.

That distinction matters in every form of leadership.

Give people tools.

Training.

Context.

Feedback.

Opportunity.

Then let them meet the standard.

If the standard disappears, you have not enabled success.

You have changed the definition of success.

Those are not the same thing.

---

Do Not Become the Ceiling

One of the most dangerous things a leader can do is require everyone else to remain less capable than they are.

That creates a ceiling.

The team can never become stronger than the person at the top is comfortable allowing.

I never want that.

I want to work with people who know things I don't.

People who challenge me.

People who eventually become better than me at areas I helped introduce them to.

That is not a threat.

That is the point.

If I teach someone and they eventually exceed my ability...

Good.

Now the organization has something it didn't have before.

---

The Keyboard Lesson

I see the same pattern in technology all the time.

An engineer asks for help.

You know the answer.

You can take the keyboard.

Fix the issue.

Everyone moves on.

Or you can slow down.

Ask questions.

Let them investigate.

Let them make the decision.

Explain what they missed.

That takes longer.

Today.

But tomorrow, they may not need you.

That is the trade.

Short-term speed for long-term capability.

There are times when I will absolutely take the keyboard.

Production is down.

The customer is losing money.

We need recovery now.

But after the emergency...

Teach.

Explain.

Document.

Make sure the next call does not require the same rescue.

---

The Best Managers Made Me Bigger

When I think about the best managers and mentors I have had, they shared something important.

They expanded what I believed I could do.

They gave me difficult problems.

They trusted me.

They let me make decisions.

They challenged my thinking.

They gave me enough room to fail without allowing the failure to become catastrophic.

They didn't need me to remain below them.

They wanted me to grow.

That is the kind of leader I try to be.

---

Share the Knowledge Freely

Knowledge should not be used as leverage over people.

I have never believed in hiding answers to remain indispensable.

If I know something that helps someone...

I share it.

If I have a script...

I give it to them.

If I know the shortcut...

I explain it.

If I understand why something works...

I teach the why.

The more people who can solve the problem, the stronger the organization becomes.

And the more interesting the next problem I get to work on becomes.

That seems like a much better bargain than spending a career protecting yesterday's expertise.

---

The Goal Is Independence

Mentorship should eventually make the mentor unnecessary for that problem.

That can feel strange.

Someone used to ask you questions every day.

Then every week.

Then once in a while.

Eventually they stop asking.

That is not a loss.

That is success.

They learned.

They grew.

They became independent.

Maybe now other people are asking them.

The multiplier continued.

The moment someone no longer needs your help may be the moment your help proved most successful.

---

A-Bay Followed Me Into Engineering

I didn't realize it at the time, but A-Bay shaped the way I eventually approached technology.

Documentation.

Automation.

Runbooks.

Training.

Mentorship.

Standards.

The easy button.

They are all forms of enablement.

Every one asks the same question:

How do I take something that currently requires specialized knowledge and make more people capable of succeeding with it?

That is what I was doing in that call center long before I knew I would spend decades in IT.

The technology changed.

The lesson did not.

---

The Scoreboard Changed

Early in my career, I cared about my number.

My performance.

My ranking.

My result.

I still believe in performing well.

Standards matter.

Results matter.

But the scoreboard became larger.

Now I also care about:

Who learned?

Who grew?

Who became more confident?

What can the team do now that it could not do before?

What no longer needs escalation?

What knowledge survived?

Who is ready for the next opportunity?

Those questions tell me far more about leadership than an individual ranking ever could.

---

Number One

I became the number one representative after leaving A-Bay.

I remember that.

But it is not the part of the story I value most.

What I remember most is that a rotating team of brand-new employees could compete with seasoned teams because someone invested in helping them succeed.

That taught me something I have carried for the rest of my career.

Being the best person on the team is useful.

Making the team better is more powerful.

And making people capable of succeeding after you are gone may be the most powerful contribution of all.

I was proud when I became number one. I was prouder when people I taught became successful without me. One proved what I could do. The other proved what I could multiply.

---