The best way to build a dev team: Go where the devs aren’t.
Yeah, I admit it, I’m in love with Elixir. And when we’re in love, perhaps we behave a bit irrationally. And we can’t stop talking about the target of our affection, and we bother all our friends, until they roll their eyes and cast knowing glances at one another as we blather on. Nevertheless, at the risk of becoming the guy who spends his life addressing all the objections you might have in choosing Elixir for your next project, I’m going to address one more.
Recently, a couple of people suggested to me that one problem when adopting a new development platform like Elixir, is that you’re going to have a much harder time finding developers to work on it. This is not true, and I’ll show you why.
Obviously, a new platform is going to have fewer experienced developers, and those developers who are experienced are going to have a lot less experience than in a platform that’s been around for awhile. I seem to remember DHH posting some ridiculous email he got from a recruiter in 2008 or thereabouts, looking for “a Rails developer with 10 years of experience” or something like that. Nowadays, if you want an Elixir dev to have more than 3 years of experience, you’re going to need to talk to Jose, ’cause he’s probably the only one. It feels like a legitimate concern… after all, there are millions of Ruby devs, Python devs, and Javascript devs out there. I have no idea how many Elixir devs there are, but it wouldn’t surprise me if less than 100,000 people had any experience with the language at all. This has be a bad thing, right?
Not only is it not a bad thing, it’s a really good thing. Situations like this come up quite rarely, and they represent a big opportunity if you’re building a team. Here’s why:
1) Developers are not defined purely by their chosen toolset.
On some level, good developers tend to be good developers, and they are capable of working with several different toolsets. If a dev has been working in the industry for 10 years, it’s likely that they’ll be fairly expert in three or four completely different languages, and a dozen frameworks. The principles of production software development tend to transcend languages and frameworks.
Back in 2006, I was responsible for building the development team at Mint Digital. We were a Rails shop at a time when Rails was very new. No one out there had much in the way of production Rails experience, and that included me. At the time, other CTOs warned me what a mistake I was making, because there were approximately 2 billion PHP devs, and no Rails devs at all, and where was I going to find people to build my team? I told them that I didn’t intend to find any Rails devs, I intended to make them.
We went looking for good developers with experience in any object oriented language. We hired a PHP dev who had production experience in PHP5, which supported objects. We hired experienced Java developers. We hired a C++ developer who was excited about Ruby and had taught himself a bit in his spare time. We posted a job ad that read “Looking for great front-end developers who would like to learn Rails”. That ad generated a huge response, with many outstanding candidates. Our newhires were typically productive in Rails within 2–4 weeks, and within a couple of months, their general development experience would come to the fore, and soon we had a team of excellent Rails devs building very high traffic applications for the TV industry.
2) Fun is seriously underrated.
A lot of CTOs, when picking a platform, think about things like robustness, scalability, TCO, maturity, etc, but I’ve had people literally laugh at me when I tell them that for me the most important characteristic of a framework was “fun”. Well let me tell you, fun and profit are closely related, here’s why:
Mint was trying to build our dev team in two offices: New York and London. Nowadays, both cities have very strong startup communities, but back then, if you were a developer in New York or London, the odds were good that you worked for the banking industry. The companies in that industry were paying devs absolutely enormous salaries and bonuses to build massive systems in Java or .NET, and my budget simply didn’t come close to what a developer could make working on those systems. I had to think hard about what I could offer that might tempt someone away from such a firm, and what I could do to ensure that my best developers didn’t jump ship in search of a giant paycheck. What I offered was fun.
My sales pitch was basically, “Work for me, and you won’t make as much money, but you’ll learn a ton about modern software development, and you’ll have fun doing it. I promise you won’t be maintaining some monstrous Java application that’s been hammered together by a team of 20 over seven years, and your days will be filled with more joy than pain.” It turns out that if you have a pitch like that, you can get great people without paying bankers’ salaries.
3) You don’t need 1000 developers
If you’re reading this, I’m guessing you’re involved in building a team. I’m also guessing that that team is less than twenty devs. Probably less than ten. You don’t have 1000 open positions, unless you’re Google, or Facebook or something, in which case I imagine none of my advice applies to you, so thanks for listening and go with God. Your challenge in building a team, is not generating a huge volume of applicants so that your massive HR organization can hire 500 devs every quarter. Your challenge is, rather, finding one or two outstanding developers every month or two at the most. Maybe you’re at a startup that recently took funding, and you need to hire ten people right away. Either way, you still need to accomplish just two things: Identify excellent developers and convince those developers to come and work for you.
Choosing a platform like Elixir will help you solve both of these problems. First of all, the early adopters in any platform tend to be some of the best devs. That isn’t to say that there aren’t great Rails devs out there who aren’t experimenting with new platforms, it’s only to say that those people who are experimenting with those platforms are, on average, going to be a lot more passionate about software development in general than those who are not. You will have to sort through a lot fewer resumes to find the great candidates. Second, by choosing a platform where there are not yet very many production apps, you are competing with very few companies as you try and attract that talent. It will be a hell of a lot easier to convince those great devs to come work for you, when you may be literally the only game in town.
4) Learning a language is much easier as a team
Maybe you already have a dev team, who are familiar with some other platform. In this case you might be worried about the time required to not only hire new people and get them up to speed, but potentially the time required to retrain your existing team. When Brian Cardarella talked about switching his whole team from Rails to Phoenix/Elixir at the same time, I remember thinking that this was a brilliant idea, because it takes a lot less time to train ten people than it does to train one. If the whole team is learning simultaneously, especially if they’re learning as they do real work, they’re helping each other, and becoming individual experts in different parts of the ecosystem. The burden on each developer is reduced, as they can learn enough to be productive while leaning on the growing expertise of their peers. We definitely learned Rails as a team faster than we could have done it individually, and I’m sure Brian will have encountered a similar effect.
Ok, let’s suppose you believe me. What should you do next? Well, one thing you might do is post a job listing in Elixir Radar. It doesn’t cost anything, and you won’t be competing with very many other companies.
Another thing you might do is consider sponsoring an event. If you’re based in New York, I’d recommend reaching out to me, as I’m helping to organize the Empire Elixir Conference in May, and I’d love to talk to you about our sponsorship opportunities. We expect to have between 100 and 150 passionate Elixir developers during our one-day event.
Finally, the elixir slack team has a jobs channel. As I’m writing this, there are 626 people subscribed to that channel, and if you post an elixir job opportunity there, I think I can guarantee you’ll get a rapid response.
If all that fails, I’m in that slack team (cameronp) pretty much all the time. Feel free to ping me if you need help, or to tell me how wrong I am :-).
You might also like:
