How do you build your engineering/dev team from the ground up? There are a few different ways to do it, but unfortunately, none bring a guarantee of success.

Let’s make a few assumptions: You are a founder, you have your idea, and you have your money. It is just you. You need to bring in the right people to build your product.

What kind of engineers do you need?

Now consider a few high-level categories of engineers:

  • Front-End
  • Back-End
  • System/Ops
  • Native App Types

 

The best engineers I’ve worked with cross into multiple categories. I’d consider them to be more like generalists. So this further complicates your search. Sometimes, the decision about who to look for is easier than other times. If you are building an iOS app, you’ll certainly need someone who knows how to do that. If you know you are building something that is web-based but very UI intensive, an engineer with lots of Front-End experience is ideal.

My opinion (and I’m certainly biased on the matter) is that at the very beginning, unless you know that you’re exclusively building a native app, you should look for the best generalist you can find. I’ve been on a number of founding engineer teams and so far, zero-percent of the time, we’ve ended up building exactly what we set out to build. Things change along the way as we learn. So having an early team of engineers who are hyper-focused on their silo-ish set of skills (front-end, back-end, etc.) hurts your team’s ability to juke left and right as you sprint down the startup road. But having a few generalists who are willing and able to work on anything and perhaps have a wider perspective of how to construct software will allow you to have that necessary flexibility.

Certainly, there will be a time when you’ll want to reinforce the team with really strong specialists — but at the beginning, its about being nimble.

Sidebar: I was recently talking to another engineer about the notion of “Full Stack Engineer” and both of us agreed that the phrase has essentially lost all value. For starters, saying you are “Full Stack” as an engineer has become like saying you’re a human who “breathes.” Secondly, many of those people are either lying or just trying to sell you. The full stack includes all of it, not just the parts that were taught in the 10-week bootcamp and not just the MVC parts of your JavaScript Framework Du Jour.

This idea of flexible generalists hired early leads to another question: How do you then vet potential hires? I think the answer is tricky, depending on who you are as an entrepreneur.

If you aren’t an overly technical founder, it would be good to have a trusted resource in your network who can either give you referrals or can help you vet the technical competency of your target. This is about trust — a lot of trust goes into this first engineering generalist. You need someone who can make strong architectural decisions and isn’t going to take out a massive Technical Loan.

 

A Bit About Technical Debt

During a recent Presidential debate, the following premise stuck in my head (I apologize, but I can’t remember exactly which person said this):

You can stop putting charges on the credit card, but that doesn’t mean the debt isn’t still there. At some point you need to address it.

Completely avoiding technical debt at your startup is nearly impossible. We all succumb to occasional moments of “just get it done.” That said, having an early team that is mindful of not piling on that debt will pay big dividends down the road. For instance, an engineer is much less likely to add to your technical debt if that engineer has a broad understanding of — wait for it — “the full stack.”

There are few things worse than when your product is really starting to get traction and you want to step on the gas but run into an innovation wall because “our system just isn’t setup to do that — we’d have to basically re-write the whole thing to add that sort of support.”

Now, not even Nostradamus can predict each twist and turn your product might take, but don’t you want to be in the best position to navigate?

The point is, technical debt can’t be avoided or eliminated all by itself. You and that early engineering hire need to approach the problem with intent and be informed.

 

Helpful Interview Exercise

Here’s one exercise I think is helpful for anyone in the company to try which can perhaps give you a clearer picture of whether there’s a fit and whether the person you are targeting has the necessary vision:

Describe the problem and the product you want to build.

As the founder leading the interview, whiteboard or draw on paper the various parts of the model in simple ways: boxes with labels.

This isn’t a technical exercise but rather a more narrative one. Let’s say you’re building a small app that lets a user tell you their professional sports team interests. You might start by drawing a box labeled “User,” and in that box you write, “First Name, Last Name, Email.” You then draw another box and label it “Team.” Within that box you write, “Name, City, Logo.” This might lead to a conversation with questions like, “Can a user like multiple teams?”

The answer today might be, “No, today this is an app about favorite teams only, but down the road, maybe it expands.” As an engineer myself, I’d hear that from the founder, and I’d then be able to better architect how the actual data models should look, with a bit of future-proofing, all while having a better understanding of the big, non-tech picture. And a non-engineer founder can then hear me as the candidate start to zoom in on what problems we’re trying to solve, describing them as a narrative.

Unfortunately, there’s no silver bullet to building the team. In the end, while you need to find people who fit well in terms of culture and technical skills, you also need to find someone who can enable your business to get where it needs to go, when it needs to get there — yesterday.