# How I select and grow technical leaders
Source: https://manaienko.com/how-i-work/selecting-technical-leaders/
Author: Artem Manaienko

The strongest specialist is rarely the obvious answer. Give a candidate a real team and a real feature, stay out of it, and watch whether the work gets delegated or absorbed.

## My principles

07 operating rules

1.  [01 Run the role as a trial before you name it](#practice-selecting-technical-leaders-principle-1)
2.  [02 Watch delegation, not explanation](#practice-selecting-technical-leaders-principle-2)
3.  [03 Technical trust is the entry condition, not the decision](#practice-selecting-technical-leaders-principle-3)
4.  [04 Interview performance is a poor proxy for ownership](#practice-selecting-technical-leaders-principle-4)
5.  [05 Reverse a leadership hire early](#practice-selecting-technical-leaders-principle-5)
6.  [06 Build the successor before the role exists](#practice-selecting-technical-leaders-principle-6)
7.  [07 Write the scorecard before the first pick, not after the bad one](#practice-selecting-technical-leaders-principle-7)

### Run the role as a trial before you name it

A real team, a real feature, and me staying out of the execution. Two weeks of watching someone run a team tells me more than two hours of interview, and it costs the candidate nothing if the answer turns out to be no.

### Watch delegation, not explanation

What I am looking for is whether the work gets distributed or absorbed. Someone who absorbs it is still the strongest engineer on the team, and now also the bottleneck for everyone else on it.

### Technical trust is the entry condition, not the decision

A team will not follow someone whose judgment they do not respect, so the bar is real. Past it, what decides is motivation, ownership, delegation and communication, and those are the things a reputation says nothing about.

### Interview performance is a poor proxy for ownership

I have had a candidate interview extremely well and then show almost none of it in the job. So a strong interview is now the weakest evidence in the file, and observed behaviour on bounded real work is the strongest.

### Reverse a leadership hire early

A lead who is damaging motivation gets more expensive every week the decision stands. Reversing it early protects the team more than defending my own judgment does, and the team already knows which one I am doing.

### Build the successor before the role exists

Succession handled at the end, as an appointment, is not succession. Delegate real decisions early and into functions that are not the person's own, and let the title catch up with what they are already doing.

### Write the scorecard before the first pick, not after the bad one

I worked the method out through one good choice and one bad hire. Deciding in advance what a lead trial is meant to show would have got me to the same place without the second one.

## What that looked like

03 cases

-   ### Picked a lead by giving the decision away

    **Case:** Two internal candidates: the strongest architect, and a less senior engineer who was more proactive and communicated better. Technical reputation was the obvious pick, and probably the wrong one.

    **My decision:** Give the second candidate two engineers and a genuinely complex feature, then stay out of it. Watch what they do with delegation, not what they can explain to me.

    **Result:** They delegated instead of absorbing the work, shipped it, and the team accepted them as lead before I appointed anyone.

-   ### Caught my own bad hire early

    **Case:** An external lead who interviewed extremely well, then showed little ownership and started demotivating the team.

    **My decision:** Treat the team signal as the decision, not as a coaching problem for another quarter. Reverse my own hire and promote someone internal with less formal experience but real trust.

    **Result:** They became a strong lead. Interview performance is a poor proxy for ownership, so observed behaviour and practical trials are what I weight now.

-   ### Built a successor before I needed one

    **Case:** Succession usually gets handled at the end, as an appointment. I wanted someone already doing the job before the title existed.

    **My decision:** Bring a team lead into decisions that were not their function: product statistics, infrastructure, architecture, organisational trade-offs. Delegate real decisions, and make them informal deputy long before there was a role to give.

    **Result:** Running engineering for the product before I left. After later leadership departures, the top job on it. That last part is supporting evidence rather than the result.