It’s been a few months now since WhyHive wrapped up.
And I was talking to lead engineer, Simon Grant, recently about what his next mission might be.
This got me reflecting on a core question I often got asked by other founders – what do you look for in your first dev hire?
Whyhive may not have been a commercial success, but it was a product well loved by a growing community, hitting the 1000 users milestone 2 weeks after launch.
Engineer extraordinaire Simon Grant
The same week we shut down, we crossed another milestone of someone spending over $1000 on their subscription with no demo, no interaction with our team, just from playing with the product… such is startup life!
Building a kick ass product seems to come down to a recipe of an epic community to give you feedback, everyday folks supporting your mission, some incredible investors, but critically, a developer who can build not just a house, but a skyscraper… almost entirely alone.
What does this take?
Let me take you through what I’ve learnt from working with one of the best lead engineers in the game, Simon.
1. You need to admire their ethics
If you’re not interested in your company making a positive difference in some way, you can skip this one.
If you are… then best believe that one of the things that will hold you back is your own blind spots. And in those moments, it’s incredibly important that you have high-integrity people around you to help you see not just through two eyes. You need to be able to trust that they have the same core values that you do (and many even a few you don’t because you don’t have the lived experience) and admire the strength with which they hold them. They need to feel safe enough with you that they’ll call you on your shit if you’re not living up to your own values.
Interview tactic: unpack an ethical dilemma together that you’ve faced in work in the past.
✅ Green flags: tells you the truth even if they don’t think you’re going to like it, questions you, past history working on impact projects, interest in specific impact areas, has sacrificed something in the past (career development, time, money, titles) to work on something they believe in.
2. They’re entrepreneurial
To be clear, this doesn’t necessarily mean that they’ve been a founder of another startup. This means that they’ve taken the initiative to kick off their own project, and they’ve had the grit to put something out into the world and have considered what growth means for that project (whether it’s not for profit or commercial).
How this plays out is that they’ll think about the business implications of development decisions, flag risks and opportunities, and get in the trenches with you when you need to pivot.
✅ Green flags: has experimented with side hustles, has built their own app in the past for fun, has a growing newsletter or research community, or in Simon’s case, has built a game in the past that has 10k downloads.
⚠️ Keep in mind that a lot of folks (particularly marginalised ones) won’t consider themselves a ‘founder’, or put it on their CV, until you ask more questions. I had the privilege to work with an incredible young black woman a few years ago who told me about the events she was organising and how her team and attendees kept growing – and yet this didn’t come up when asked whether she had ‘founded’ anything. She didn’t think the label applied to her.
3. Emotional regulation
Obviously, startup life can be stressful, as is any product build with stakes. It’s VERY helpful to have people around you who are calm, grounded, as well as high performing. This isn’t just helpful for founders looking to keep a team cohesive and to resolve conflict well, etc,. but it also plays out in building a well-considered, smooth product.
To be fair, we were truly spoiled in this department working with Simon. And I do think one of the keys is to trust that the person knows what they need to stay in this epic regulated & high output state (e.g. time off and/or flexibility) – the more you give folks the autonomy to look after themselves the more they seem to thrive. Funny that!
⚠️ Keep in mind, this one isn’t a license for founders to fly off the handle and expect everyone around them to adapt. The emotional regulation you’re looking for in your core team isn’t the type that just absorbs all your stress without holding you accountable.
3. They know how to put the goal ahead of ego
This one is all about being able to ‘kill your darlings’ – that means letting go of something you’ve done or are working on in the name of a bigger vision.
WhyHive cofounders Matt Cohen and T Guthrie and engineer Simon Grant
This has played out countless times when we’ve come to Simon saying that either something he’s worked really hard on in the past, or is currently enjoying building, needs to be set aside to work on something more critical that the user or business needs. If he wasn’t so understanding about this we wouldn’t have been able to move as quickly.
Interview tactic: “When have you needed to stop working on something (or discard something) you were really attached to in the name of a bigger goal? What was that like for you?” – you’re looking for either a sense of appreciation for the bigger mission that they’re also bought into, even if it was tough to let go, or a sense of fixation on the one feature/piece that they’ve identified with. I personally think you’re looking for someone who’s invested but not attached.
4. Being full stack
This might be an obvious one to some – but it’s not just about all the tools someone can work with (beacuse if they’re a good learner they can pick up more -e.g. Simon becoming an expert in Echarts – a data visualisation package) it’s also a mindset.
For me, working with someone who’s full stack means they’re opinionated about different levels of the stack and can see how decisions in one area will affect the whole cohesive product.
✅ Green flags: when you’re talking about tradeoffs, they tell you about how a choice in the back end (e.g. database) will change something in the front end (e.g. UX in terms of wait times, and “maybe we need a cool animation for people to look at while their data loads” ).
5. Produces results, not hours
There seems to be this fantasy that when you’re wanting to move fast and build a great product, the best thing to do is hire a 20-year-old genius who will code for you all night, perhaps almost smashing their laptop against a wall at some stage but coming through at the last minute while everyone bites their teeth – followed by a triumphant team air punch .
Well, as someone who loves to get 8 hours sleep – I can tell you it’s much better to hire a surgeon than a lumberjack. You want the person who’s going to get it done for you in 2 hours instead of “all night”, tell you the three things in your backlog you actually don’t need and then suggest something that will likely save you months of dev time if you invest now.
As it happens, this seems to be a core factor in building a one-person-skyscraper. Hacking away to make a shack is all good, but if you want to make something so smooth and reliable that folks at the ABC, Carmens and Canva use it – then maybe get a handle on any ageism you might have and start looking at candidates who have the experience to get it done.
⚠️ As well as checking your ageism, best to also check other forms of bias (e.g misogyny) that might have you thinking that the aggressive-young-man-dev archetype is the most “high performing”.
6. You want them to win.
Seems obvious but you need to care about them as people, want to see them succeed. If you don’t, then you miss out on the upward spiral of building mutual trust and a team who wants each other to achieve their goals.
✅ Green flags: you get along really well and talk about their goals outside of just the company/organisation.
7. They’re a champion of the user.
If someone has lived experience of the problem you’re working to solve for your user ✨amazing✨. There’s going to be thousands of micro decisions that your developer will make that you’ll never know about – and if they’re aligned in not just values and the direction of the business, but the way in which you want to make your user’s life easier – then those decisions will result in a great product.
✅ Green flags: they advocate for the user, speaking up if they feel like a feature that would be important to them is threatened, or the founders are missing something.
8. They do conflict well
Obviously you’re going to disagree at some point. When you do – how do they manage the conflict? Do they lean in to resolve it, ignore it, become bitter & resentful, completely disengage?
It’s important to understand that how people show up to resolve conflict will be highly depended on the emotional environment you create as a leader. Eg. if you get angry when someone says you’re wrong, don’t expect someone who’s upset about you ignoring their advice a month ago just to have it go wrong in the way you said it would to come to you looking to repair the relationship.
That being said, here are some things to look for to give it the best chance of co-creating a safe, fun space for everyone to grow.
Interview tactic: “When did you get some feedback you didn’t expect? What happened next?” You’re looking for either a sense of perspective taking, getting curious, learning or perhaps understand the context from which the feedback came from even if they didn’t agree. Keep in mind that people have often been through unfair or even traumatic work circumstances, so don’t take someone setting boundaries and being able to label behaviour as unethical as not being a good team player.
Red flag: if the person can’t come up with an example of where they’ve been in the wrong (in the sense that they’d do it differently next time after having reflected), then this, in my experience, can be a red flag.
9. They can zoom out and zoom in
They have epic attention to detail in everything from design to the implications of back-end architectural choices. They also know how to zoom out in a leadership meeting and workshop the company’s next move based on what they know.
And ideally, they can switch from detail thinking to big picture fast.
10. Thriving in change
In a small team with big goals, you’re going to need to be able to respond quickly to feedback in the market, from your users and what you learn about the limitations of existing tools/processes. I can’t tell you how many times we needed to change plans on Simon, even if he’d been working on something for ages, which was always met with presence, precision and action. This of course increased our overall speed.
Interview tactic: “When have you worked in an environment where what you needed to build could change rapidly? How did you manage that?” You’re looking for how they handled it emotionally just as much as any practical processes they used.
11. They acquire deployable knowledge super fast
This isn’t just learning stuff fast, its knowing what stuff to learn in order to complete a task. It’s about knowing when the latest tools will be ideal to solve a problem, and when to put them down.
e.g. we were building during 2023 and the rise of chatGPT – Simon was rapidly acquiring knowledge all the time, but it wasn’t just for the sake of “becoming an AI expert” because that was all the rage – it was to know quickly what would help our mission and make our product better and what would be a waste of time.
Red flag: someone wants to use and research the latest tech without a business reason.
12. They roll up their sleeves when things get tough
When the chips are down, everyone chips in.
This seems to be a function of how much ownership you give your team and requires you to show up for them if you’d like them to show up for you.
(E.g. you call on a Sunday because you’ve been rate limited and you need to find a solution because there’s a massive demo on Monday – true story).
⚠️: This doesn’t mean they don’t set boundaries – what “giving it your all” looks like depends on what’s going on in your life.
Interview tactic: “When has something not gone to plan in a team you were working in? What did you do next?”
I hope this helps! And good luck out there
T Guthrie was CEO & cofounder of WhyHive, and the 2021 Winner of B&T Award for Tech Leadership in Data Science. Follow them on LinkedIn.
