Building a Team in the Midwest
24 August, 2020
When I joined my current company we had to scale from 12 to over 100 engineers, product managers, designers, and leaders over the course of 12 months. We had to find people who had skill sets of sufficient quality or who could be taught those skills rapidly. To be able to grow at that rate in the Midwest we had to accept that we won’t be able to find 100 people who would be the perfect fit.
The big problem with hiring in Columbus, Ohio, and more generally in the MidWest, is the availability of talent and specific skill sets relating to technology, languages, or different working environments. We were constrained to hire predominantly from large banks or insurance companies that have a IT development mindset as opposed to a product mindset.
We made a list of what exactly we were looking for and what were the good indicators of someone’s ability to acquire those skills if we couldn’t find what we were looking for. For example, we were looking for IoT skills, but we couldn’t find a lot of companies having people with those skill sets. However, we could find people who had worked on ATM machines, medical hardware integration, etc. and through some initial interviewing candidates with those backgrounds did really well. Based on that we were able to target people who worked at similar companies.
Then we looked for people who wanted to work in the Agile environment and those who early on proved to be great hires led us to the companies where we could source potential candidates. What we learned was that people who were adapting to Agile more rapidly were people coming out of agencies and jumping from project to project as opposed to people coming from larger companies. In general, agency people were able to spin up greenfield work rapidly.
We were also looking at languages similar to Ruby since Ruby doesn’t have a lot of penetration in the Columbus market as compared to Java and .NET. But people who came from other object-oriented languages and Elixir, that has a similar syntax to Ruby, were able to move over to Ruby faster.
By that point much was based on our individual analysis of hiring data -- we identified many commonalities that led us to more profiled backgrounds or companies. Then we would send our recruiters and continue to rinse and repeat until we didn’t augment our ranks with the best candidates.
- We learned that the general skill sets are far more important than a specific skill set. We found that people who came from agencies that work in multiple languages were a better fit than people coming with Ruby experience. We were measuring that in a number of ways: churn rate, how successful was the team they were on (in terms of our ability to deliver customer value, meet their OKRs, etc).
- We had to teach hiring managers that making mistakes is part of being successful. Due to the limited talent in the Midwest, they were obsessed with finding the perfect candidates and lacked the confidence to make the yes decision because they were worried that they would be held accountable for churn. It included allowing our leaders to ‘make mistakes’ and potentially hire someone who looked risky on paper but from the interview process could be successful.
- Be willing to change your interview processes. A lot of companies are sticking with the same interview process for a long period of time even if it’s not working for them. We were adjusting ours on a weekly basis based on the learnings from our data. For example, early on we learned that people were struggling with starting a new project from scratch vs. starting one that was already in place. We changed our interview process for our code exercise from building something from scratch to fixing bugs in already existing projects.
- We were willing to go hunting for the skill sets we needed as opposed to being content finding candidates who worked for a particular company and therefore, were perceived to be a great fit.
Prabha Matta, Senior Product Manager at SquareTrade, talks about her personal experience of looking for a PM job during the Covid-19 pandemics and how the changed circumstances affected her job search and interviewing process.
Senior Product Manager at Square Trade
Himanshu Gahlot, Director of Engineering at Lambda School, explains how he improved the hiring process at his new company by applying the knowledge he acquired working on different teams with different hiring processes in place.
Director of Engineering at Lambda School
Mason Mclead, CTO at Software.com, highlights all the advantages of hiring at once a group of people who have already worked together.
CTO at Software.com
Brian Hough, CTO at Beam Dental, recalls his company’s massive scale from only 12 to over 100 employees including engineers, product managers, designers, and leaders in under 12 months and highlights how hiring in the Midwest differs from hiring on the coasts.
CTO at Beam Dental
Alessandro Pintaudi, Product Management Director at Payfit, dissects all the aspects of the hiring process that will enable you to hire a product person who will take your product to the next level.
Product Management Director at PayFit
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.