When hiring in secondary markets, seek out great teachers and avid learners

Tobi Lutke is the CEO of Shopify, which is a hugely successful E-Commerce company based out of Ottawa, Canada.

I find him interesting for two reasons:

  1. He reasons from first principles about how to effectively build companies
  2. He’s built a wildly successful technology company in a secondary market (i.e. not Silicon Valley)

As someone that’s also trying to build a successful technology company in a secondary market (Ann Arbor), I’m definitely interested in what Lutke has to say.

One such piece of advice that he offers could be paraphrased as:

When hiring in secondary markets, choose employees with the assumption that you’ll work together for at least 10 years.

That means that hiring based on the candidate’s growth potential is much more important than in primary markets.

This advice resonates with how I see people in Michigan view their jobs: generally, when they choose a job, they pick a job that they could see themselves working at for 5-10 years.

This contrasts sharply with Silicon Valley. If the average tenure at a company is two years, you can sure spend 5 hours each week mentoring Jill on how to better manage her team but gee whiz, by the time that actually starts to pay dividends she’s moved on to the company next door.

I do think that his “hire for growth” advice - while not wrong - is at least insufficient to be useful. What does it mean to hire for growth? Does this mean not to hire senior engineers?

In this post, I’d like to carry forward Lutke’s first principles reasoning in order to determine how you should hire differently in secondary markets.

What does “hiring for growth” mean?

I like to think of what a candidate offers looks something like a layered cake: from bottom to top, the layers are:

  • Foundational character traits
  • Foundational technical skills
  • Professional technical skills
  • Professional social skills

The lower the layer in the cake, the harder it is to change that aspect of the person.

Starting with the bottom:

Foundational character traits include how well someone can teach others, whether they can write well, whether they try to avoid the same mistake multiple times, and how eager they are to learn new things.

These traits take years to take shape and are often the direct result of someone’s upbringing and education. There’s a good chance that if you hire someone with a gap in one of these skills, you’re stuck with it.

Foundational technical skills are the skills that someone needs before they can even really start grappling with the real skills that make them good at their job. For software engineers, you’re probably looking at someone that can program well in at least one or two languages, understands what a unit test is and how to write it, knows the basics of databases and networking, etc.

These skills are certainly teachable (as demonstrated by many-a CS curriculum). However, they’re wide-spanning enough that it likely takes years to learn them in a comprehensive way that ensures good coverage.

For example, when working on a project, it’s hard to justify stopping in the middle to take a few weeks and go learn SQL. If you make a hire without foundational technical skills, you’ll find that you’re often faced with two choices when you encounter one of these gaps:

  1. Halt whatever you’re working on and develop a plan to fill that knowledge gap
  2. Do “just enough to get by” but never really fill the knowledge gap

The first makes it hard to put this person on any sort of time sensitive project, while the latter never really addresses the problem.

That’s why I think that foundational technical skills are a must-have, even when hiring for junior positions.

Professional technical skills

These are the skills that get “layered on top of” the foundational technical skills in order to really make someone effective at their job.

For software engineers, I consider these skills the ones that basically no CS undergraduate will have learned in school. These are things like how to effectively monitor code running in production, design an API, or scale a service as it gets more usage.

These skills are often learned through a combination of actually facing the problem and having someone else around that’s faced it before and can help you learn how to solve it.

Additionally, the problems themselves are often ones that are hard to replicate in the classroom. For example:

  • The solutions to these problems cost significant money (how to implement monitoring and APM services)
  • The problems only exist due to the volume of traffic that a service is receiving (how to effectively use a load balancer)
  • The problems only exist due to many engineers collaborating on a project (how to ensure consistent code styles and distribute knowledge of best practices)

Junior engineers cannot be expected to have these skills.

Furthermore, because these skills are a result of facing the problem before and not all engineers specialize in all things, not all senior engineers should be expected to have these skills. However, senior engineers should be expected to have depth in a few of these areas and - if you’re hiring well - at least one of those areas hopefully addresses a pain point that your team currently has.

Hiring this way allows senior engineers to be the mentor necessary to effectively bring junior engineers and other senior engineers “up to their level” in their respective area of expertise.

Professional social skills

These skills are layered on top of even the professional technical skills and are the ones that allow someone to coordinate a group of people to work together and grow as a team.

I don’t have much insight to offer here: I’m still learning.

Back to Lutke’s advice

In secondary markets, hire for growth potential.

I’d like to offer a corollary to this:

In secondary markets, hire people who are both great teachers and avid learners.

Why great teachers?

Being an effective teacher requires a high level of empathy with the audience along with communication skills that are very, very hard to teach. That’s why I stuck it in the “foundational character traits” bucket above. It’s very likely that if you hire a bad teacher, they’ll remain a bad teacher.

The problem with this becomes apparent when you see what happens when you hire a bad teacher at each level:

  • If you hire a senior engineer that’s a bad teacher, they’re unable to mentor the rest of the team in their domains of expertise. This means that you get minimal leverage on their skillset
  • If you hire a junior engineer that’s a bad teacher, you’re investing years of training into someone from whom you’ll ultimately get minimal leverage from their skillset

In computer science terms, hiring good teachers yields superlinear returns because you benefit from both the work they do and the increased level of productivity they help others reach.

Hiring bad teachers yields a linear return because you benefit only from the work they do.

Why avid learners?

Along with teaching, there’s one other foundational trait that’s critical when hiring in secondary markets: the person has to be an avid and effective learner. A strong growth mindset is critical.

If you think of someone’s growth as a straight line, their attitude towards learning and their ability to effectively learn greatly influence the slope of that line. Finding effective learners is much more important when the time that the person will be spending with you is significant. In high-turnover primary markets, the skill change during the minimal time the employee spends with you is likely to be small regardless of their ability to learn, so you should hire them primarily based on their current abilities. This isn’t true when hiring in secondary markets.

Summary

  • Carefully choose what foundational character traits you care about and figure out how to identify them in interviews.
  • In secondary markets, seek out great teachers and avid learners
  • Choose your foundational technical skills and figure out how to identify them in interviews.
  • Senior engineers should have depth in multiple areas, at least one of which will broaden the team’s overall expertise.

P.S. The startup I work at - Channels.org - is looking to hire a senior software engineer! You can find out more and apply here.

Want to hear when I write something new?

You may also like

Back to all posts