We work with clients on extremely short timelines, and they often ask us for guidance in hiring more people who can do what we do:

  • work with a variety of systems
  • communicate well across the organization
  • prioritize effectively during a crisis
  • solve problems located in arbitrary places of either the technical stack or the organization.

Hiring for this blend of skills is exceedingly difficult, even for organizations that expend enormous resources to do so. Worse, even if you find someone, often they are happily employed elsewhere, or outright beyond your budget.

Good news! While we struggle with providing hiring guidance beyond “good luck, we don’t have shortcuts for that, either,” we frequently find that an organization already has underutilized instances of this talent spread around their technical teams.

If you run an organization with more than 50 software engineers or system administrators, and you have any user-facing product that works then some of the right people already work there. The trick is finding them and allowing them act on their best engineering instincts.

So who are you looking for? That person mentioned as an expert during seemingly disparate engineering discussions. Someone who disregards formal organizational boundaries and gets things done. The quiet developer who repeatedly contributes surprising insights about edge cases of systems administration.

On the technical side, they have no orthodoxy about which technology or programming language to use, and will make a decision based on the realities of the environment. They’ll happily chase a bug from an obscure user report through multiple systems (and organizational layers) to reach a resolution.

A weird thing we have found to be true: hobbies or past careers that require rapid decision making and prioritization are a solid indicator. Think theater (on or offstage), live music, event production or emergency response of any kind.

Here’s some examples, drawn from real programmers and operators we’ve encountered in our combined experience.

Kate L: A recent CS grad who spent college working as a theatre tech, Kate’s hobby is building looms from scratch. Newly hired into a technology company, she was assigned a vague initial project and had to work on multiple system components spread across isolated teams to succeed.

Paul C: A former aerospace engineer with a PhD in applied physics, Paul is known to management only as a quiet software developer. He’s respected by peers on all the software teams at the company for his work improving developer efficiency and building shared infrastructure and tooling.

Susan H: Susan worked as an EMT after she dropped out of high school. She has no credentialled higher education and her previous job was being the entire IT department for a small ISP. One of her first projects where she now works was deploying multi-factor authentication to the whole 500 person organization.

Jo R: After their only job in college was running the campus radio station, Jo’s BS in biology lead them to a researcher-cum-sysadmin role in a computational biology lab. Recently, Jo is always the go-to when their software team’s component is being debugged in production by the ops team.

We’ll publish a follow up on some of our best methods for setting this sort of talent free inside of an organization, and empowering them. In the meantime, as you try to build out adaptive capacity: start your search at home.