Perspective

I Build People to Leave Me

The job description is not a document you file. It is the level set that training, feedback, accountability, and reward all have to tie back to, or they are decoration.

By Keith Formell

I build people to leave me.

Not because I want them to go. Because I want them to be capable of going.

The person who could leave tomorrow and chooses to stay is choosing. Nobody else is.

Ownership without agency is just blame with a schedule.

Someone who can only do the job in your shop, under your supervision, with your context, is not developed. They are dependent. Dependency looks like loyalty right up until the moment it looks like resentment.

The test is simpler than that. If I leave, can they carry the work forward?

The mechanism is unglamorous, and it is one of the first things I build.

A job description is not a document you write once for HR and file. It is the level set. Training, feedback, accountability, and reward all need somewhere to trace back to. If they do not connect to a common definition of the work, they become subjective, and everyone can tell.

I did not arrive at that view by insight. I arrived at it by being told.

A mid-year review early in my management career rated me highest of anything on the form for developing others, and in the same paragraph said my job descriptions took too long to get completed and needed more work. That was accurate. It stayed with me. The thing I was best at was being undercut by the thing I was slowest at.

At one manufacturer I built career-progression descriptions for field technicians, business systems analysts, and data analysts. Three levels each, ten documents in all. Each described the work, the expectations at that level, and what somebody had to demonstrate to move.

The field technician ladder was built within a couple of months of my arrival. The analyst ladders were still being written in my final weeks. One of them went through two revisions in two days.

That last detail matters more to me than the documents. A career ladder is not useful because it exists. It is useful because somebody is still willing to work on it.

The same was true of the org chart. Twenty-odd versions across the tenure, still being revised the week I left. Structure is not a thing you draw once.

The document does several jobs at once.

It tells a candidate what they are walking into.

It gives feedback somewhere to stand. "You're doing well" is encouragement. "Here is where you are, here is what the next level requires, here is what you need to demonstrate" is development.

It makes promotion defensible. When somebody advances, the decision has a standard behind it. When somebody does not, they have something concrete to work toward rather than a suspicion about how the decision was really made.

And it survives me. If I leave and the ladder leaves with me, I built a dependency, not a system.

The same discipline shows up in how the hires themselves get justified.

The headcount request I used was not a formality. It asked whether the role was needed because of inadequacies in organizational design, existing staff capability, or process, and whether the need could be preempted by fixing one of those instead of hiring. It asked whether the current team's capability had been maximized, and what had changed.

Those questions are built to make a manager argue against his own headcount.

I answered them honestly. Could the need be preempted? Yes and no. Had the existing capability been maximized? Yes, and the cause was historic underinvestment in staffing.

Neither answer helped my case. Both were true, and putting them in writing is what made the request worth approving.

That philosophy changed how I hire.

I stopped optimizing for the finished candidate.

In a public safety organization I took someone with a telecommunications background and developed him into a network professional. I have hired from outside when the inside answer was not there. I have hired people whose business understanding was stronger than their technical background and taught them the technology. The reverse is harder.

What I look for is the gap between what somebody was asked to do and what they actually did. That gap is about agency, and agency is the thing you cannot train into someone who has never shown any.

The interview form went through three versions in five months, because the first one was not asking the right questions and I could tell.

There is a financial side to this that I do not pretend away.

One headcount request included a compensation market analysis to support the baseline salary for a role I had not yet filled. The argument was narrow and specific: for this role, in this market, the number on the requisition was the constraint.

A salary can get someone in the door and it can keep them there.

It cannot tell them what good looks like. It cannot give them a path from one level to the next. It cannot make their advancement defensible to the people who did not get promoted. And it cannot make the organization less dependent on the person who hired them.

Those have to be built, and they are the part that lasts after somebody has stopped noticing their paycheck.

I should be honest about where this goes wrong, because it is not where people expect.

The usual failure of leadership is hoarding. The leader becomes the bottleneck for every real decision, the team escalates everything, and from the outside it reads as indispensability. It is the most fragile structure you can build. The leader leaves and the function collapses to the level of the documentation, which is usually not very far.

That is not my failure mode. Mine is the opposite one.

A performance review scored me highest on the form for giving people authority to work independently, and in the same section scored me poorly on delegating assignments. My own written comment at the time was that I delegate well but sometimes too much for a company of that size, and that I had spent the previous six months taking on more of the trench work myself.

Pushing authority out is right. Pushing it out faster than the organization can absorb it is not generosity. It is a different way of failing the same people, and it took someone else's assessment to make me see it.

The other half of this is the part nobody writes essays about.

Building people to leave you means being willing to write down, formally and on the record, when it is not working. I have done that. A development plan and a performance improvement plan trace back to the same level set. A leader who will only produce the first one is not actually holding a standard. He is just being pleasant.

There is a version of me that would rather be needed.

I spent roughly sixteen years with my hands directly on the work, and the years since leading the people who do it. The image I keep returning to is that I fought in the trenches and eventually learned to design them, so the people who come after me fight better, safer, and with a materially better chance of winning.

After me. Never under me. The hierarchy version of that sentence is weaker than the outcome version, and I have watched leaders choose the weaker one because it feels better to say.

Two people I worked for built me. Neither was in the room on the day it counted, and that was the point. The standard they set survived their absence, which is the only real test of whether a standard was ever transferred at all.

So I build people to leave me. Some of them have.

Either way the objective is the same.

Build the capability. Give it agency. Make the standard transferable. Then make yourself unnecessary to its survival.

— Keith Formell