Loading...

Building a Team in the Midwest

Brian Hough

CTO at Beam Dental

Loading...

Problem

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.

Actions taken

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.

Lessons learned

  • 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.

Be notified about next articles from Brian Hough

Brian Hough

CTO at Beam Dental


Engineering LeadershipLeadership DevelopmentCommunicationOrganizational StrategyDecision MakingCulture DevelopmentEngineering ManagementSprint CadencePerformance Metrics

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


Product

HomeCircles1-on-1 MentorshipBountiesBecome a mentor

© 2024 Plato. All rights reserved

LoginSign up