Monthly Archives: July 2013

High performance teams

I had an interesting discussion with someone recently about what “high performance” means in the context of development teams. Specifically, I mentioned to this person that I thought I had been able to build a high performance team at my startup, to which he immediately countered: “So what do you mean by high performance?”

I had used the phrase somewhat casually, as though it was obvious what it meant, but I realize that the term can mean very different things to different people. Everybody’s trying to build (or be part of) a high performance team, but how do you get to one?

In my experience, a high performance team has the following characteristics:

1. Lightweight processes are enough to maintain progress. A light agile process may be sufficient.

2. Everyone has a rough idea of what everyone else is working on

3. Made up largely of generalists. Specialists may be necessary for some functions, but most engineers are comfortable working on the front end or back end, and artists can be given work as far apart as UI or character animation.

4. People are curious and eager to take on new challenges; they have the “get stuff done / JFDI” trait

When hiring, I generally found that what I call “context-free programming questions” were effective only as a base-level filter. These are questions that test the interviewee’s ability to write code on a whiteboard, often after thinking of an algorithmic solution to an abstract problem: “Write a function to print a matrix in spiral order”, “Write an iterator which implements the next operator for a binary search tree” etc.

Programming problems can serve to show that the candidate has a base level of programming ability. I’d generally ask Fizzbuzz┬átype problems which are even simpler than the ones above — they helped weed out people who were out of touch with programming in general. For artists, I’d ask them to sketch a background on a piece of paper in 30 minutes; this assumes that drawing skills are highly correlated with digital art skills (which is generally true in my experience).

Questions more complex than this run into issues of people getting nervous and freezing up, or simply being unable to think of the right solution to the problem in a limited amount of time. Either way, there isn’t much point in trying to infer a person’s long term fit for a job from such a small set of observational data.

The most high quality predictor of productivity on the job that I’ve found for programmers is to ask them in detail about their past projects, preferably ones that they did as side projects.

I interviewed mostly people at or close to the start of their careers, where side projects are an indicator of whether they are curious enough to do things that are not strictly necessary to get their college degree.

Questions like the following are very useful:

1. Describe one of your side projects

2. How big was your team? What did you do, specifically?

3. Why did you pick this problem?

4. Why did you pick this set of technologies to implement this project?

5. What was the most difficult technical challenge in this project? How did you solve it?

6. Describe the most complex bug you had to fix. How did you debug it, and what did you do to fix it?

New questions naturally emerge from the candidate’s answers to these questions, and are a good way to further drill down into their experience.

If a candidate answers “I don’t have any side projects” to question #1, that’s a strong indicator right there (although it’s typically not sufficient to simply stop the interview there).

I found over time that refining these questions, and maintaining answers from previously successful hires as a benchmark, helped me get better at determining who to hire or not.


Startup locations in the Bay Area

I’ve had occasion to speak with a number of startups in the Bay Area over the last few months. One trend I’ve seen is how many of them are located in San Francisco, in SOMA as well as other locations in the vicinity of Market Street. Two BART stops seem to cover a large number of these SF-based startups: Embarcadero and Montgomery.

It didn’t always used to be this way. When I first moved to the Bay Area, most tech companies — both established ones and startups — were in the peninsula. My first job was at a startup in Redwood City. SF was a city you used to drive through on the way to Marin County, and none of my friends from college worked in the city.

Things began to change around the end of the 2000s. I’m not sure what exactly it was — perhaps SF got really cheap or the peninsula got too expensive — but a lot more startups seemed to be popping up in SF. I met with an acquaintance at a game company near AT&T Park in 2010 and noticed how many tech companies I passed on the way to his office from the Caltrain station. The trend seems to have accelerated since.

It seems that there are relatively few new startups being started in the peninsula, and of the ones that are, many move to SF soon after their first serious round of funding.

I’m interested to see how this trend plays out. Being in a city definitely has its advantages in terms of attracting a certain type of employee (generally younger and single), but it may have adverse effects on hiring more experienced employees with families. It may also limit the radius within which companies can hire — unlike mid-peninsula locations like Palo Alto, SF is hard to reach from many places in the Bay Area (and much harder to find parking in!).

Be that as it may, I now have several friends who commute up from the peninsula into the city every day.