Monthly Archives: January 2013

You are browsing the site archives by month.

Attracting engineers

A few weeks ago I wrote about the challenges non-technical entrepreneurs face finding good developers to build their idea. But even for a capable entrepreneur, finding talent and getting that first bit of interest isn’t the end of the challenge. I’ve seen more than a few smart, well-networked, -resourced and -researched entrepreneurs struggle to attract technical talent to a genuinely promising business because, well, us programmers are odd types and you need to understand what we want. Many aspiring entrepreneurs seem think that developers will be attracted to the same things that they are: an impossibly huge ambition, constant uncertainty and change, a statistically unlikely shot at millions of dollars, that kind of thing. For better or worse, that’s not generally true. Remember: great engineers have many attractive options. To attract them to your company you need to understand what they want, and make sure you can provide it (along with the entrepreneurial excitement).

Everyone’s different, but in my experience really good technically-minded people tend to value two things above all else: working with great people, and working on technically interesting problems. Working with great people–at least as good as oneself–amplifies the impact of your work. When you can trust that your peers are capable, motivated, intelligent problem-solvers it’s easier to see how your work will be valuable as part of a quality end product, as opposed to a jewel buried somewhere in a steaming pile of code. Talented peers will appreciate your talent and effort and be best able to arrange their own work to complement yours. Great people provide constant opportunities for learning: from how they work, from their existing expertise, and together as you explore new ground. And the best technical minds will attract even more great people to work with them, compounding all these benefits. Working with great people is the number one attraction for most good developers I’ve met.

Interesting problems are a close second. Solving problems is the essence of working with computers: problems of domain modelling, problems of complexity, problems of user interface, problems of scale, and so on. Sure, developers and engineers spend a lot of time writing code, expressing their solution formally, but the really interesting bit is solving the problem in the first place (often concurrently with writing the code). That’s also the most valuable part to your company in the long run. Solving problems presents constant challenges and opportunities for growth and learning. Solving hard problems, especially in collaboration with talented colleagues, is a realisation of one’s potential, the very top of Maslow’s hierarchy viewed through an engineer’s eyes. Without interesting problems, a developer is likely to get bored and realise their job could be done by someone with lesser talents. Now, you might not have technically interesting problems early on in your new company (the problems of making sure you’re building the right product are far more urgent), but you need the promise that you won’t shy away from them when they arise, that you’ll allow your team to stretch. Great people want a challenge.

After these two values, working with great people on interesting problems, people’s values vary a lot more. Your entrepreneurial vision, potential impact, company culture, work environment, technical infrastructure, decision-making freedom etc. are all really important. But don’t think that they’re enough without a promise of great peers and great problems.

For your first couple of technical hires, of course, you can’t demonstrate the quality of your as-yet-unformed team. The best you can do is promise to engage an outside technical mentor to help you hire  good people, and hand technical hiring over to the development team as soon as practical so that they can control the quality of future hires.

For many potential candidates the first impression they’ll get about working for your company will be a job ad, on your website or elsewhere. This job description (and the rest of your online presence) needs to sell the benefits of working with you. That means you need to sell your talented team and interesting problems, and you need to sell them above your ill-defined vision or potential riches. I’ve drafted up a mock software engineer job ad to help people who don’t know where to start. It’s based on those I wrote for Posse where they were very successful (and Posse’s still always on the lookout for great people). It’s missing a few specifics and anything about company vision and culture will of course depend on the company. But it’s a job ad that I would have been interested in, and aimed at the kinds of people I’ve most enjoyed working with in the past and hope to in the future (stay tuned!).


 

[Company] is seeking talented and ambitious engineers to help us build the future of [product area].

You might be an experienced engineer with multiple specialties or a class-topping graduate keen to learn while applying your talents to hard problems. At [Company] you will develop creative and innovative solutions to novel problems amongst accomplished peers. We are a small, growing team and you will have a great impact on the design and development of our product. We’re particularly interested if you have [specialty] experience, or are keen to get dirty learning about it.

Responsibilities

Our engineers:

  • design, implement and test clear, elegant code (we use [technologies]);
  • work with with other brilliant developers to craft robust systems and beautiful interfaces;
  • sweat the details with product management and designers to implement compelling features;
  • develop tools and processes to continually improve our team’s productivity; and
  • share knowledge, teach, and learn from colleagues.

Requirements

Our team all:

  • have a passion for developing creative solutions in a team, translating abstract concepts into code, and understanding and adapting to our users;
  • demonstrate strong technical design sense across both the big picture and the devilish details;
  • derive joy from conquering complexity through abstracting, refactoring, and applying well-understood (and sometimes novel) principles and patterns;
  • know how to balance engineering perfection with shipping product;
  • are independent, enthusiastic, and keen to lead talented peers in innovation; and
  • are in-tune with the [industry or vertical].

Us

[Company cultural values or mission]. We release early (daily!) to learn from real users and react quickly. We work end-to-end, so each engineer understands their work in depth. We encourage everyone to learn and share knowledge with others to improve our craft. We exalt engineering productivity and quality and continually improve our tools and processes. We are building a culture and a codebase that are a joy to work in.

[Company] hires only the best and brightest. We offer [compensation and benefits outline]. Other benefits include [more benefits!], plus other random acts of appreciation.

About Company

[Company vision, product outline, challenges]

[Company back-story, market opportunity, notable investors & backers, other evidence of likely impact]


 

Note this slight tweak to a traditional responsibilities and requirements list: instead of listing desired traits of the applicant, I’ve listed the actual traits of existing staff applicants might work with. You don’t need to be this explicit about it, but in describing applicant requirements a job ad implicitly describes the attributes of your existing or future team, and this is the most important attractor of new talent. This is an ad, the beginning of the pipeline, not an acceptance checklist. Its role is like that of a resume: to get to interview. So sell the experience of working at your company by selling the future peers of successful applicants.

Without getting into details, the ad also makes it clear that interesting problems and challenges exist. With more knowledge your product you can probably be more specific, but details might be better left to a discussion. You should add interesting nuggets of information about your company. Maybe you have some particularly distinguished team members, a unique technical challenge, or some great traction stats. Any of these will help you stand out from other opportunities. And, if you can, add some personality to the mix. Let your company culture shine through. BigCommerce did a great job of this with a Hypnotoad hook, boosting views of their add some by 10 times.

Note also what this ad doesn’t have. There’s no laundry list of specific technical knowledge or experience. There’s a placeholder mentioning what technologies the company presently uses, but you should be looking for people who can take part in decisions about what tools are right for the job. Limiting applicants to specific prior experience is really just limiting your pool of candidates to people who don’t like change. There’s definitely no “N years experience with X” requirement. A flexible team is made of people who learn fast, and you’ll be far better off, a few months down the track, having hired someone who is super-smart and learns fast but has little direct experience with your tech stack than someone who’s been using the same tools for 5+ years and likes it that way. I’ve had this approach validated multiple times by people I’ve hired. Flexibility is super-important when your company is young, so look for smart, motivated generalists over experienced but less-driven experts.

Some other recruitment drives that I’ve been particularly drawn to are those of Asana and Quora. Note the emphases on colleagues, learning, challenges and impact, as well as each company’s mission. Feel the culture of the two companies in the expression of who they want to hire. See how the “requirements”, such as they are, tend to be phrased more like character attributes than specific experience checks. If the teams at these companies live up to these descriptions then they are the kind of people that great developers aspire to be, and will fall over themselves to work with.

I hope that’s helpful for some of you on the hunt for early technical employees. And if the mock ad appealed to you as a developer, well, I’m sure I’ll be building another team like that someday soon.