Selecting high potential individuals and the moral quandry N. 2

In a previous post post I shared some reflections about how I apportion time given a set of reports - and highlighted my use of the potential (especially appetite) and efficacy of that time given the report, to answer the question: who should I give more time to?

That post aimed to address how to think through time allocation, but didn’t speak to high potential individuals and the work of finding and nurturing them.

High potential individuals are folks you’ve identified as having a high degree of potential - that is, they excel in aptitude and in appetite relative to their peers. You’ll run into these people without looking for them, they are good and they are hungry. They aren’t quite yet the exceptional engineer that makes your team go much faster or that you’d really like to join your Org - but they will be… they could be that engineer.

Your job (one of your jobs) is to find and nurture these people!

So… how do you find HIPOs (High Potential)

In general, the key thing you are trying to avoid here is Bias. You will have a bias - I promise you. So, look to data relative to specific characteristics when you are identifying high potential individuals. In the previous post, I covered some salient factors I tend to use when thinking about time allocation. It should be no surprise these are also things I look out for. Let’s flesh these out a little more:

Aptitude: the foundation of skills and behaviours that mean an engineer can effecitvely contribute to the team’s delivery. Look for the relative ability to contribute within your team. This is difficult to do without going in depth (into PRs, and proposals and being present in rituals), because it can be masked by appetite (more on it below). That is, a high degree of aptitude can go unnoticed when paired with low apetite, often showing up as low relative output. Do the work here to understand quality in relation to time. You are looking for high quality within reasonable time, and good pragmattic decision making.

Appetite: you are looking for people in your teams who are hungry. Most often this is visible ambition - don’t ignore it. Folks who are asking you for more scope, in 1:1s or sprint rituals, are literally telling you - I am hungry for more impact. A good sign for appetite.

Don’t ignore people who aren’t shouting though. Here are some signs to look for independent of how vocal a report is. On top of effecitvely contributing to their team’s deliery, these engineers tend to:

• fix issues without making much noise about it, except when setting an example of how to do something
• touch code (contribute to / fix) well outside their teams’ scope
• often improve underlying services their proximate goals depend on - despite not really having to
• are effective in differentiating between intrinsic (internal to the problem) and extrinsic (deriving from context or existing solutions) complexity
• drive or contribute to discussions about improving core (hot path, high risk or high value) systems to their team

While apptitude is a requirement for doing many of the things listed above, actually doing them stems from appetite.

Efficacy: “coachability” is a low resolution similie for efficacy. Here, I’m speaking to how efficacious a time investment is likely to be. A good proxy for this is how well report reacts to (interprets and then changes course) feedback.

There’s a few other things I look out for:

• Comfort wrangling ambiguity: engineers that gravitate to soving problems, rather than working on tasks, and thus are comfortable bounding ambiguity, thinking about risks and one way doors, milestoning and communicating a technical approach in service of solving a problem. In order to do these things, these engineers are comfortable dealing with cross functional partners, like Design, or Sales or Product.
• Bias to action: engineers who act quickly. The key here is the distinction between delivering quickly (also useful signal) and acting quicly. Acting quickly is often related to being comfortable with ambiguity - specifically not needing everything to be defined before getting started.
• An intuition for value: if a bias to action is a valuable trait, a bias to valuable action is better. And that’s the point here - solving for value (better than solving a problem, and much better than working on tasks) means an engineer is engaging with why their work matters, and thus take decisions at that level of abstraction.

So, you’ve seen some signal across some or all of the dimensions above for people in your teams. What next?

How to get started with a HiPo programme?

First, make the intended outcomes of your programme clear. What do you intend to happen as a consequence of running this programme? What will be true 12 - 18 months in the future that isn’t true now. This usually means stating a specific problem, like, we lack technical bench strength (a common consequence of fast growth), or we have gaps in our technical leadership.

Often, a HiPo programme is intended to cultivate the next batch of leaders in an organisation. If that’s the case, define what you mean by Leader. In most effective modern engineering organisations, Leader is mostly uncorreclated with people manager. If you are looking for the next batch of managers, your programme should reflect this.

Bring in other disciplines - this is super valueble - in the ideal case you are creating a cohort of new leaders who have worked together for a while. Align on your objectives with the other disciplines.

Design your interventions relative to the outcomes you seek. Common interventions are:

• uncapped learning budgets
• rotations to other parts of the company
• matched coaching with a senior leader (often outside of the direct reporting line)
• increased visiblity and engagement on strategic work (goal setting, re-orgs, tactical org decisions)
• increased autonomy and opportunities across an Org

Match those interventions to the outcomes you are looking to drive.

Second, create a plan and timelines. Both of these should guide how and when you identify, communicate and check in on the programme. There are some important things to decide:

• will folks apply to the programme?
• will managers select individuals from their reporting lines?
• how will you communicate about the programme, both to folks selected as well to a wider audience?
• how will and when will you check in? How will you know if a person should be offboarded from the programme?

Third, and though long term quite important (but easy to forget) - seek follow-on opportunities after the programme. Given the investment put into these folks, where can you best deploy them to give them further opportunity and leverage in the business.