hiring

Hiring your first “techie”

I had a chat a little while ago with an entrepreneur. Smart guy and with some good early traction. He comes from a commercial background, far from tech and product.

He wanted to chat about hiring the first technical person to join his team. It’s a conversation topic I’ve had a few times in the past, so I thought I’d share my braindump here.

1. Find a product-oriented developer

Some developers love the deeply technical challenges, for example, making something happen 10x faster than before. Others like solving immediately practical problems, like helping buyers meet sellers.

If you’re reading this, chances are that you need a developer who likes solving those practical problems. Find the one who likes making things that people use.

How? It’s not always evident from their job, so ask about their hobby projects. Ask about what they were trying to do or solve. Why this approach over that approach? How did the product evolve? How did they come up with the UI? How did they get user feedback?

Look for signs that they care whether their product is being used or not (it may not be successful, but they should at least care).

2. Full stack!

Developers generally specialize in front or back-end. But if she’s your first developer hire, then try to find someone who has a reasonable level of comfort with both. She won’t be expert at both, but should be good enough in one and very good at the other.

Similarly, don’t hire a one-trick pony, which is someone who really only develops in one language. I’ve seen a startup re-write their entire codebase into a different language, because their key hire was a one-trick pony.

3. Don’t outsource

It might be tempting to hire an agency, but don’t do it. Consider it a test to sell someone on you, the vision and the company by having them join you with a proper level of commitment.

The reason not to use an agency is because things never go according to plan. You need the close working relationship to zig-zag your way through problems. An agency isn’t committed enough (even with equity) to put in that extra effort when the setbacks happen. And chances are that your working relationship won’t be close enough to make sharp left turns on a moment’s notice.

An agency also won’t live/ eat/ breathe your customers. So many product decisions are made on gut feel at an early stage and you need some pretty sharp guts to make good calls.

Outsourcing makes a bit more sense when you have a bigger team that is an organizational foundation and you have discrete chunks of work that you can pass off externally.

4. Get them to explain stuff to you clearly

I say this a lot, but if they can’t explain a past project without using lots of jargon and making it understandable to a non-expert, they probably aren’t good. The great ones will be able to cut through all the complexity and explain the heart of the matter.

5. Be wary of the document-ers and process-ers

I’ve come across devs who are really into documentation. Or process. Before writing a line of code, you need to spend a few days writing a 10 page spec doc of some sort, getting it reviewed, signed off, blah blah (someone please shoot me at this point).

A bit of paper and a bit of structure is not a bad thing. Sketched mockups. A checklist. Some post-its. Whatever. But you really don’t need much at the start, especially if the team is just 2 or 3 people. Less is more (but you definitely need more than zero).

If you see any hint of Microsoft Project, just pull the handle and eject. “Oh look, my cat texted me to tell me the house is on fire. Gotta go!”

6. Try before you buy

A CTO friend once warned me that with interviews, you can work out if someone is roughly ok. But until you work with them, you don’t know if they’re excellent or actually kind of mediocre.

If you can agree a small chunk of (paid) work that the person can do, it will tell you 5x more than any interview. It should be real work, something that you need (but something you can afford to go a bit wrong). This often isn’t practical for a number of reasons, but if it is ever an option, take it.

7. Enlist a trusted tech friend to do a technical assessment

Talking is nice, but ultimately you do need to see if the dev can actually write code that works well. This is the minimum skill set required. Get someone to assess that for you.

 

Hopefully this list saves someone a bit of pain and uncertainty. This is not easy. Recruiting developers is tough. But if you’re in the middle of it, I wish you luck and look forward to hearing your stories about it.

GS Dun builds new ventures and products, including international expansion ventures. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

My favourite hiring tips

Hiring for a new venture is like hiring for a startup. The team is small and the future uncertain. Every team member needs to wear multiple hats. Given this, here is my take on traits to look for in a new hire (almost irrespective of the role).

1. They show progression.

“Progression” is more than just a string of promotions. I think of it as:

  • Stepping outside of one’s comfort zone
  • Being entrusted by others with greater responsibility

Someone who has repeatedly taken on scary challenges has the emotional and learning ability to handle the surprises of new venture life. They aren’t just running on their “expertise”. Their CV probably shows changes in roles, industries or perhaps even career.

However, they might be hopping for the wrong reasons. This is why they should also show signs of greater responsibility. Someone they worked with trusted them to do more. “Greater responsibility” is context-specific, but some examples are taking on more people or being assigned the more difficult challenges. This may be evident from the CV, but probably only becomes really clear in an interview.

2. They have done excellent work in the past.

I’ve studied different languages over the years, having bounced around Europe a lot. But I have one major problem: I ramp up quickly and then stall. A multilingual friend pointed out that with languages, once you master one, mastery of another is easier. The skills of mastery are somewhat transferable.

Doing excellent work is like learning a language. Do it once and it’s easier to do it again.

Just to be clear, excellent work doesn’t have to be a deliverable like a design, piece of code, or document. It might be a skill, such as sales or leadership.

How to find out about their excellent work? Ask them. I sometimes ask people about work that they are most proud of. However, having recently read this great blog post, I think a better variant is “I’m interested in learning more about how you get stuff done. Can you tell me about the best project or piece of work you’ve ever done?”.

In their storytelling, there are three things to listen for:

  • They have the ability to judge their own work. While external feedback is valuable, an inner voice is essential. A designer should have a sense of whether his solution is clunky or elegant. A brand marketer should have a feeling for whether the creative will be memorable or is bland. Probe on this one. How did they know it was going well/badly? What sort of details told them so?
  • They have figured out how to improve it. Nothing starts off as excellent. When they realized something was not up to standard, how did they overcome obstacles and fix it?
  • They have passion. This is the juice that fuels the above points.

3. They can explain complex things to a six year old.

Niklas Sundbaum, a fantastic CTO I’ve worked with in Sweden, taught me one of my favourite lessons in hiring: they should be able to explain complicated things to a non-expert. (Denzel Washington’s character also teaches a similar lesson in Philadelphia.)

Although every field has complexity, the core concepts can be sketched on a sheet of paper. Explaining something simply from their domain is actually a sign of solid understanding.

If you’re hearing jargon and buzzwords – and they can’t clarify it – take it as a red flag. They won’t know what’s really driving their part of the business. And they definitely won’t know how to relate to yours.

———————————-

So there it is: my favourite tips for hiring. Whether you use them or not, remember that the world of new ventures will throw a lot of curveballs. Just make sure the people you hire to stand with you can catch a few along the way.