Why you should invest in undervalued people

It’s very hard to get hired as an entry-level software developer today.

There are more than ten times as many senior web developer jobs for every junior web developer job on both VentureLoop.com (jobs at startups) and Indeed.com. Browsing through companies that have recently IPO’d or raised $100M+ rounds -- where one would expect a company to be able to hire junior developers -- all I can find are jobs that require at least three or more years of experience or are explicitly only hiring “Senior” or “Developer II” or higher.

I have been working with bootcamp graduates and community-college graduates for years. But from my vantage point, when growth companies hire people with no development job experience, they are usually hiring top-tier, four-year college graduates. (There are some exceptions! Twitter’s internship program is admirable, although I don’t know in practice how restrictive the admissions end up being).

One can understand wanting to make sure that the first few hires into any department have enough experience to build and maintain high quality software, except that

a) that often doesn’t prevent terrible technical debt, and

b) no one ever changes the expectations over time.

And so the culture just becomes, “we only hire people with experience.” I am a huge fan of Segment (and a happy customer for more than five years), but despite their senior-developer-packed engineering roster, they seem to have to rebuild their entire architecture every few years. Every company starts by hiring seniors; most seem to keep hiring seniors, and many have to keep throwing away code constantly.

Everyone agrees that talent is scarce, and that hires often fail -- and that failure is expensive. Why don’t companies ever take a conscious look at how to build talent instead of buying it?

Put another way, it’s ironic that an industry that tends to want to build everything instead of buying it chooses to buy the absolute most expensive thing on the market: talent. 

It is a fallacy that only hiring senior developers will lead to better results than hiring many junior developers. There are bad things about senior developers that no one should want in their organization, and without juniors to counterbalance, you’ll be overindexed to these downsides.

The most common error I see senior developers make comes, ironically, from their prior successes, combined with the pace of technology.

Most developers at the beginning of their careers are good at knowing and using most of the best practices at that time. But there is no continuing education in software development, and compensation is tied to shipping, not learning. So once a developer is five or more years into their career, there’s a really good chance they’re still relying upon tools, libraries, and practices that are no longer the best way to build, deploy, and run software.

Case in point: Instagram, all on the public cloud, sells to Facebook for $1B with 13 employees in 2012; Bank of America makes its first announcement to do anything with the public cloud in November of 2019. Kevin Systrom had only just learned to program when he started Instagram; Bank of America’s technology organization is run by people who are decades from being practitioners. (Lest anyone try to argue Bank of America’s slowness is due to regulatory issues, consider Capital One).

Another problem with senior-developer-only organizations is that most organizations don’t have constant flows of work that require lots of experience. A tremendous amount of software development is updating interfaces to add functionality or improve usability, not building back ends from scratch that have to scale to hundreds of millions of daily users.

And as we have better and more powerful cloud services to build on (e.g., AWS, GCP, Azure, Netlify, Twilio, Stripe), more developer focus turns to interfaces. Having an organization filled with senior developers who aren’t mentoring junior developers is asking to find senior-developer problems to solve, even if they’re best solved by an existing service.

Many developers are systemically undervalued because they do not fit central casting for appearance or mentality. Others are undervalued because organizations typically aren’t willing to hire software developers who need some training to do the job effectively. 

Instead, whatever cargo-cult exercise an individual had to learn to become an interviewer (e.g., inverting binary trees on a whiteboard) tends to be viewed like a fraternity hazing ritual: "I had to go through it, so I’ll make everyone else after me go through it."

There are excellent software developers who hate hackathons and would rather spend time raising their children on weekends than on coding side projects. There are people who are neuroatypical who can’t deal well with your unrealistic, on-the-spot brain teasers. There are people who need some additional training and mentorship to be able to ship software effectively for most organizations. These people are all undervalued by the standard hiring practices in tech, which means that, with some effort on your part, they’ll give the highest return on investment of any hires you can make.

Over the past twenty years, I have seen a real difference between hiring software developers with the view of, “You’re a superstar and we need you to come in and kick ass” versus, “We will bring you in, teach you how we think and build, and then you’ll help us achieve our mission.”

The former attitude can lead to developers thinking they are better than other departments and other people in the organization, because no one else can do what they do. (After all, they are superstars!) The latter is fundamentally aligning to a mission and a team and a culture.

Remember, all software developers pick up bad habits. They usually don’t know all the latest best practices. They generally haven’t been given work time and space to experiment with new technologies. They won’t know all of your code or your stack or how your teams’ specific approaches to software development. These generalizations hold true for all developers, junior to senior.

You can choose to not invest any effort into training and aligning senior developers and still see things ship, but that doesn’t mean that you’re growing cohesive teams that are making the right decisions for your organization. You should invest in bringing everyone up to speed and together. When you do that, you realize that bringing junior developers onboard is not necessarily a greater effort than bringing senior developers onboard, especially if your criteria for success is successful, happy teams that are making the best decisions.

If you hire undervalued people and you train them to be successful for your organization, you will end up with teams that are more aligned and more loyal to your mission. The right way to do this is to onboard people in stages that end up with developers working on your codebase, as opposed to hiring everyone with the expectation that they’re working high-priority tickets on day one.

For example, at Branch, we have a multi-stage process where entry-level developers are initially granted a stipend to fund living expenses while taking online courses, working through sample exercises, and attending office hours for any questions. The end of the first stage is completing the Branch take-home developer hiring exercise that we have used to hire all developers.

The second stage is a paid internship that has the goal of learning how to work as part of the development team, but having the space to go slowly and ask lots of questions, and the expectation that there may be many PR revisions. We identify tickets in our backlog as “intern” work, so that there isn’t high pressure to complete anything in a short period of time.

This entire process does take time from the existing development staff, but it can be contained (mostly) into onboarding, office hours, code reviews, and weekly 1-on-1s. And it allows you to make hiring decisions that exclude bad cultural fits because you will find enough talent by investing in your workforce. You’ll create a massive competitive advantage over your competitors who are still stuck in their fraternity-hazing ruts.

Without the right learning path in place, you risk losing time and money toward your investment. That’s why we created Learning Paths — custom tech and IT development plans tailored to your team’s needs.

Many venture-backed companies seek people dedicated to their missions, but then shoot themselves in the foot by only looking to hire people from “elite” schools or out of “name-brand” venture-backed companies. Those hiring pools are filled with people who are ready and able to job-hop to further themselves, and are often very weakly committed to company missions. In contrast, if a company invests in undervalued people who need some mentorship, training, and experience to reach their full potential, those people are much more likely to commit to the company and the mission with their full selves.

Joe Emison is the CTO of Branch Insurance, which provides home and auto insurance. Previously, Joe founded BuildFax (acquired by DMGT), Spaceful (acquired by Xceligent), and BluePrince (acquired by Harris Computer). Joe graduated with degrees in English and Mathematics from Williams College and has a law degree from Yale Law School.