Recipe for a great startup dev team
Today I'm giving away the actual recipe we use at Kelsus so you don't have to hire us
If you were to ask a TechCrunch reporter how to make a great startup dev team, the recipe would call for 2 parts ex Netflixer with one part Stanford comp sci grad heated in a pressure cooker of high expectations and internal competition.
This recipe has worked before, so I’m not knocking it. But not everyone has access to former FAANG engineers. They’re expensive, and can be finicky employees—especially since they live with the knowledge of what their compensation could be, and this knowledge sits heavier if product market fit is elusive.
There is another way—a calmer way—where you hire developers for potential rather than proven track record. Hiring developers for potential and then guiding them to achieve that potential is a feat. And since it’s hard, it’s basically what we sell at my company, Kelsus. I’m going to lay out our process right here so that you can do it yourself.
The process has two steps. Step 1: interview and hire for five specific values. Step 2: Unlock that new-hire potential. Step 3: profit. I added step three to make sure you’re paying attention. From here, let’s go into detail on the two steps.
Hiring for potential via focusing on core values
Sometime during the recent long winter in Eagle, definitely wearing my quilted wool shirt jacket, and following my unalterable coffee making ritual, I had a call with a fellow consulting company owner named Dustin. There we were looking at each other on Google Meet, each wanting the solution to the age old consulting company problem: “How do I get from where I am now with a handful of clients and a business built on my personal reputation, to an ever growing business that attracts clients because of the organization’s reputation?”
We, like all company leads, spend our darkest hours terrified that we don’t know what we’re doing, but we spent the call giving each other confident advice. “I’ve been doing EOS,” said Dustin.
“What?! The Entrepreneurial Operating System?” I said? “You mean the thing they advertise on CNN?” I didn’t know anything about it, but the CNN commercials made me assume it was for small restaurant owners or accounting firms—surely not international software development consulting companies with their own newsletters on Substack.
“It’s actually really good. Ask me again in 6 months, but the last three months have felt like real progress,” said Dustin, adding, “Their book Get a Grip is on Audible, you should check it out.”
So I did. I checked it out. We’re not going to do EOS (sorry Dustin).
EOS has prescribed meetings to be held at specific times of the week, month and quarter each with their own three letter acronym name. This is anti-Kelsus. Kelsus likes to shorten meeting names in a different way. If we have a biweekly strategy meeting, we might jokingly start calling it the Ivory Power Hour (we have no such meeting).
So anyway, after listening to hours of old school business advice, there was one thing I really did like. There was a section on “hiring for values,” which, on the surface, sounds like a good sleep aid. Just as I started to fall asleep (dangerous since I was driving), they said that you can’t hire for values that don’t already exist in your company. I perked up. That felt like truth. They said to look at the people that best exemplify what you like in your company, and distill 4-6 values out of them.
I loved that. Two weeks later, I was listening to another book called Burn Rate: Launching a Startup and Losing my Mind about Andy Dunn and his personal struggles with mental illness while starting Bonobos, and Andy mentioned being mentored by e-commerce luminary Marc Lore about how to hire a great team. Marc told him something along the lines of, “You have to hire for values, but you can’t hire for values your company doesn’t already have.”
And at the moment, 80 miles an hour in a 65, Audible on 1.7X, I had chicken skin. Both EOS and Marc Lore, who I personally know for reasons I wish I could explain, were telling me the same thing.
So I sat down and wrote our values, and we altered our hiring process to do a values interview after the tech interview. So the process goes like this:
Tech interview The tech interview is pretty standard. There’s a bit of live coding. We do something akin to the “Realistic Coding Interview” in this article:
Culture Fit Interview: The culture fit interview can only be done by people that exemplify the culture. We’re still perfecting this interview, but it’s worked well for several hires, and helped us put our finger on the unsettling feeling we used to get before making bad hires. The point of this post is to make a great startup team, and since we have made a business of making great startup teams, the values we hire for are values that work well exceptionally well in startups.
Supportive / Team oriented: Argentina has an advantage over the United States on this value. Recently, during an all-team, in-person gathering in Villa General Belgrano, Argentina, my wife Kelly and I were driving our rental car to find a good restaurant. We drove past a group of 25 people walking and talking. We looked closely. It was our team! All of the new team members and their partners and families had made an impromptu plan to walk into town together. If you’re reading this in the United States, you know this is irrefutable proof that Argentinians are more group-oriented than Americans. Nonetheless, we see varying degrees of this value during interviews so we’ll ask questions like, “Tell me about the best thing a teammate has ever done for you.”
Followthrough: If there’s one value we’ve talked about even before reading about the values based interviews it’s followthrough. The idea is in remote companies, being ghosted by a teammate when you’re waiting for something on a Friday is really unpleasant. So we need people that keep their word when they say they’ll do something. It’s hard to interview for, so we generally just talk about it and how important it is to us. Do you have any ideas for how to interview for followthrough?
Always learning: Everyone tells you they love to learn during an interview. So we just say, “Great! Tell me about something you know now that you didn’t know 6 months ago and how you learned it.” Just yesterday someone explained how they learned how to use Node.js streams because they kept seeing them used in open source code and didn’t feel comfortable with them. This is such a better answer than a too broad answer like, “I learned react.js,” or an irrelevant to the job answer like, “I did an Elixir tutorial.”
Communicates clearly and succinctly with confidence: Being able to express ideas is more important to a startup than being a boss coder. I will die on this hill. Communication skill varies widely and improves slowly, so we want to hire people that are already good at expressing themselves. During the culture fit interview, I like to ask the candidate to explain how something works that they know cold, and if they don’t have any ideas, I’ll ask them to explain how a database works, or how a REST API works. A big, open question like this shows whether a candidate can quickly organize their thoughts and explain technical things without rambling or getting lost in the weeds.
Adaptability/Flexible mindset: Another one that’s difficult to interview for, but critically important for startups. No one likes throwing away code that is nearly ready for production, but startups need to be able to make quick decisions and avoid the sunk cost fallacy without demoralizing their team.
If you already have an established culture, you won’t be able to use these five values. You have to figure out what your company’s values already are. But if you’re starting from scratch, go ahead and use them! Then after 9 months revisit them and hew them closer to the culture that has emerged.
The culture fit interview is difficult because people only get to it if they passed the tech interview, and it can be so hard to not give offers to people that appear to be great at coding.
A hero’s journey for new hires
Now that you’ve hired someone that has great potential, you need to help them develop that potential. We literally present it to new developers as a transformation they are going to go through after they start working with us. We tell them they’ll know they’ve completed the transformation when they’re ready to help someone else through it.
We have three ways that we’ve been using over the past 15 years to guide the developer through their journey. As evidence that it works, I recently asked Dave Herrald (currently Principal Security Strategist at Google), to describe what it was like to work with his Kelsus team—some of whom we hired straight out of college and developed over 2-3 years. Here are two things he said about his experience, which was at a company prior to his position at Google:
The team has a humble yet confident approach. No problematic egos!
The team loved what they built and supported it like it was their own
How we do it:
Assign a buddy/mentor: This is kids’ stuff. It is obvious. Why am I even writing it? Maybe because I worked at 5 startups in Denver before starting Kelsus and was only assigned a mentor at one of them? Startup leaders are so focused on the product and going fast that they just don’t have time for any structure at all. Simple mentor programs for small teams take 2 seconds to formalize and do. Just do it. Make sure the people that are mentors have exemplary culture fit. If they don’t you will be amplifying the wrong culture signals in your org.
Set learning expectations: I have interviewed hundreds of developers, and I have found the most common insufficiency in their knowledge is deep knowledge of their own frameworks, tooling, and build processes. Using Babel? How does it work? What does it do? How have you been using it for years without being able to answer that? Or similarly, what is the order in which the virtual DOM is modified and promoted to become the actual DOM in react? On day one, and every day after that, we set a clear expectation with every developer that they will shine lights on the dark parts of their toolsets and deeply understand their frameworks.
Let them feel the heat of the flame: Especially in dev shops, but even in startups that hire their own teams, big walls go up between developers and end users. We think developers should talk directly with clients and end users even when those conversations get difficult. And we don’t need to worry about developer communication skills because we already interviewed for that! Similarly, we think that developers should find their own bugs—and help each other find bugs via code reviews and cross team testing—and fix their own outages. We’re in good company here. AWS does the same thing.
Those are the steps! Hire great people and send them on a hero’s journey. You’ll notice it starting to work within six months, and after two years you’ll have an incredible team.
Don’t have two years to develop a great team? We’ll happily make one for you right now. Just reply to this message and I’ll get you setup with a short walkthrough call to see if we can help.
Thanks for reading! Please send this to every dev manager in the world.