Skip to main content
 

The three-dimensional engineer

I’m hiring for a few engineers right now: five Ruby on Rails positions (most of them senior), two JS positions, and a quality engineer. More than a few people I’ve spoken to for these roles have apologized to me for coming from different backgrounds and not having been the product of a conventional CS track.

There’s no need to apologize for this. At all. In fact, I really like working with people who come from non-traditional backgrounds and/or small startups. Conversely, I’m not at all swayed by whether people went to top CS schools (or did CS at all) or are an an alumnus of a Fortune 500 tech company. Perhaps it’s worth exploring why; it seems obvious to me, but maybe isn’t to everyone.

The short answer is: it’s about priorities and values. Big companies and well-established CS tracks tend to (but don’t always!) lead to a certain kind of templated thinking that doesn’t necessarily translate to a smaller startup environment. People from more creative backgrounds or who have worked on smaller startups tend to be focused on making an outsized impact on a real, human problem using a broader set of skills, rather than developing a niche skill and working their way up the corporate ladder.

The skills required to climb the corporate ladder are intrinsically different to the ones required to solve problems quickly. One of the reasons I’ve avoided big tech companies for most of my career is that I’m allergic to office politics and the confrontation that inevitably arises: if a major concern for someone is building and maintaining power within an organization, becoming a gatekeeper to information, or not being willing to help build a supportive team culture, they’re going to be an obstacle to the team’s success.

If, on the other hand, a person’s focus is on solving the problems in front of the team and building the best product possible (including the best culture that leads to building the product), everyone is going to have a better time working together, and the product is exponentially more likely to be fit for purpose. All teams are communities of people pulling together to achieve a common goal. For any community to work well, the focus must be on the whole community’s success, while also ensuring that every member of the community is treated well and benefits from the group’s work.

In a smaller startup or organization, this is crucial. In these contexts, the focus needs to be on building. You have to go broad, because there just aren’t enough people to go around; you have to have a “no job too big / no job too small” mindset. Everyone needs to be a doer, not a manager. The CEO is doing everything from setting business strategy to unplugging the toilets. Engineers will sometimes need to make product decisions, think about design, or gather insights from customers. They need to find scrappy ways to get answers to questions themselves, sometimes by any means necessary. It’s not about hustling - hustle culture is not productive - but it is about pulling together to build the right product in the right way, using the full weight of your skills and insights.

I’ve been really impressed by engineers who have made their way to the discipline through meandering paths. Some of the best engineers I’ve ever worked with don’t have degrees; some studied music or art or literature. Perhaps this group has self-selected to be particularly passionate about solving the right sorts of problems; perhaps the wider breadth of disciplines helps to build stronger problem-solving skills; perhaps it’s something else entirely.

It’s not that you can’t have these skills if you’ve come from a traditional CS path. I studied computer science (with AI) in Edinburgh, and have met plenty of really strong team players with this background too. But they tend to be people who have been drawn to smaller, scrappier startups in the past. They’ve often built their own thing (although not everybody has the resources and freedom to do so, so perhaps they’ve been drawn to other people’s startups). They have a bias towards working on interesting projects rather than simply building up their own wealth and career.

It’s unfortunately also true that people from more “traditional” paths tend to be from a narrower demographic: CS degrees and Fortune 500 tech companies infamously have an inclusion problem. If you’re serious about solving problems for a breadth of people, you’d better have a team who represents those people. And, honestly, as well as being the right thing to do, it’s just more fun to work on a more diverse team.

Everyone on a team should be compensated well, should enjoy good work-life integration, and should be able to work in an emotionally supportive (not just emotionally safe) environment. Ideally, everyone should bring a different perspective, their unique creativity, and a set of skills and personality traits that allows them to contribute uniquely to the community as a whole. They should have a bias towards action and be able to Sherlock Holmes their way through problems in collaboration with their colleagues. That requires a sort of scrappiness that isn’t taught in CS degrees, and isn’t required in resource-rich Fortune 500 companies.

There’s no need to apologize for being different. I’m grateful for it, and I’m excited to build a community of unique, talented, creative people who build software that matters together.

 

This is a personal post, but I'm hiring Ruby on Rails, Front End JS, and Lead Quality engineers. If this is you, I'd love to meet you!

Photo by Lagos Techie on Unsplash

· Posts · Share this post