13th February 2017
Building teams through types

People talk a lot about "culture fit" and hiring "people you want to hang out with". Identifying engineers who are motivated, knowledgeable and good at working on a team is already difficult enough, why further complicate the hiring process with these abstract metrics.

Lets hire people to do what they love doing. Maybe instead of thinking about jobs in terms of technical expertise, like 'front end', 'back end', 'systems', we can talk about what gets people excited.

In today's (relatively) high level programming world, engineers should have a level of comfort across the stack. Once patterns and code standards are somewhat well established, a 'css person' should feel comfortable editing the database models or working on an API and submitting a pull request (if not, your team or codebase has much bigger problems).

We have high level programming languages, why not give people high-level job titles?

Here are a couple of examples of 'high-level' job titles that come to mind:

  • Tooler: building tools to make the jobs people more effective at what they do. This spans the the whole company. You just really love using technology to make people's jobs more efficient.

  • Growth-hacker: while this title is certainly 'in vogue', it is a perfect example of a high-level job title. Your job spans product and engineering, you do whatever it takes to encourage 'growth', however that is defined for your project.

  • User focused: people who love buildings stuff that people use. I'd probably fall in to this category, basically you are someone who will do whatever it takes to get a great product in front of the people.

  • The academic, some people love correctness and broad sweeping design patterns. These are the people who love designing frameworks and APIs for other engineers to work with.

  • The tuner, you love making stuff fast. Performance is a very important feature with 'on the go', mobile lifestyles and the global marketplace. Whatever the task, you want to make sure it doesn't take very long.

While these names are pretty off the cuff, at least lets acknowledge that great things happen when you get smart, passionate people together with diverse perspectives. You can put together that team more effectively if you understand not only the different technical specialties of programming, but the different types of programmers.

Job titles at Artsy

I am one of about 15 engineers at Artsy.net. Everyone is just an engineer here and some people 'own' various technical components but even that gets murky sometimes as people go through their performance cycles. People generally work on what they want to work on. By having such an open ended working process, we've seen these types of roles emerge. As the team grows, if we need to formalize roles, it would feel unnatural to give people titles like 'lead front-end engineer'. I don't know what that means for us. We have an gallery CMS, a mobile site, a desktop site and internal tools, each with their own 'front-end'. As a company, we think in terms 'KPI's we want to keep in line and features we want to build for our users. Roles and responsibilities work best if company priorities align with who is going to 'own' that project. This limits the needs for heavy handed project management and allows our engineers to simply do what they love while happening to build a great product.

Cheers to 'high level' programming titles. This is really just an idea at this point, I'm sure it has its own set of issues. Please let me know if you have tried something similar.

Written By

Brennan Moore

I'm a product engineer based in NYC. I'm passionate about building innovative digital products people love.

Follow me on Twitter here.