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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
We doubled the Engineering team from 54 to 109 full-time employees. We expanded our team footprint to include: Brazil, Portugal, and the US. We evolved our road mapping and planning processes from two Product squads to eight Product squads, in alignment with PM areas of ownership.
VP Engineering at Trustly Group AB
Nani Nitinavakorn, the Sr Product Owner at Revolut, shares how she gained her first technical position, creating a direct method to apply for jobs.
Sr Product Owner at Revolut
Federico Fregosi, VP of Engineering at Contino, shares how he hired a candidate with an untraditional background and grew into a key player in the industry.
VP of Engineering at Contino
Nikita Ostrovsky, Sr. Manager. Site Reliability Engineering at Peloton Interactive, shares how he has grown multiple small teams to medium-sized teams, hiring new candidates and creating a psychologically safe environment.
Sr. Manager. Site Reliability Engineering at Peloton Interactive
Ranadheer Velamuri, Director of Engineering at Tesco, shares how he brought experience diversity into a team of senior engineers to increase energy levels and innovation within the team.
Director of Engineering at Tesco
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.