Engineering Your Team

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.

Choose your own adventure.

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?

Let’s say, for the sake of argument, there are a few types of very 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”.

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 (I’m certainly biased on the matter) is that at the very beginning, with the exception of knowing you’re exclusively building a native app, is to look for the best Generalist you can find. I’ve been on a number of founding engineer teams and so far, 0% of the time, we’ve ended up building exactly what we set out to build. Things change along the way as we learn. Having an early team of engineers who are hyper-focused on their silo-ish set of skills (front-end, back-end, etc) lessens your team’s ability to efficiently juke left and right as you sprint down the startup road. 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 more flexibility.

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

Sidebar: I was recently talking to another engineer on our team about the notion of “Full Stack Engineer” and both of us agree 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 lying, or at least, “selling”. 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 leads to another question: how do you vet potential hires? I think the answer is tricky, depending on who you are.

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 referral or can help you vet the technical competency of your target but I think it starts, particularly in this case, with finding a great Generalist. A lot of trust goes into the concept that the first engineer you bring in 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 (I apologize but I can’t remember exactly which person said this), the following paraphrased premise stuck in my head: 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 accruing technical debt is nearly impossible. We all succumb to occasional moments of, “just get it done.” That being said, having an early team be mindful of not piling on will pay big dividends down the road. An engineer is much less likely to add to the technical debt if that engineer has a broad understanding of, wait for it, the full stack. That debt does not go away by itself.

There are few things worse than when your product is really starting to get traction and you, as the company, 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?

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

Describe the problem and the product you want to build.

Whiteboard/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 can draw a box and label it “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 a favorite team app but down the road maybe.” As an engineer, I’d hear that and 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. As a non-engineer, its a great way to zoom in on what problems you’re trying to solve.

Unfortunately, there’s no magic bullet to building the team. Ultimately, you want to find people who fit the best culturally, technically, and who can best enable your business to get where it needs to get, when it needs to get there: yesterday.

I am @realmattbrand on Twitter (there are multiple Matt Brands but I’m the, or a, real one). I love all things startup; particularly early-stage. At my professional core, I am an engineer first. I also write a daddy blog: http://mattbrand.com