Mar 20, 2012

Seven Ways To Hire A Great Product Team

I’ve started six companies and sold three of them (this just published: EMC Acquires Storage Software Partner Likewise). I’ve been developing software since age 12. Building great product teams has become second nature to me. So when a friend of mine yesterday at Facebook and another friend last week at Salesforce asked me how I put teams together, I had to think hard about the answer.

A crucial topic in these times of highly competitive technical hiring, that answer merits a full blog post.

1. Embrace a distributed workforce. The short version is that I don’t build 100% local teams. In fact, I’m currently building one product completely outside the bay area—way outside. “How do you find developers in the Ukraine?” my friends at Salesforce and Facebook both asked me. I’ll answer that question in detail, below.

For another product, the core team is local but certain parts of the system are built elsewhere – we have a fantastic developer in Syracuse, NY for example.

There simply isn’t enough software engineering talent in the bay area, regardless of whether you’re starting a new company, scaling up, or trying to build out a product team at an established leader like Facebook, Google, or Salesforce.

The other question I often get asked is, “would the development team move here?” In January, it was 68 and sunny in San Francisco. In the Ukraine, it was a good forty some degrees colder. Weather isn’t everything. Proximity to some of the world’s hottest tech companies is another big attraction, of course.

2. Get critical mass. There is a big advantage to having everyone in the same place. So when it comes to distributed teams, the same rule applies—put together an entire team in one place.

For my engineers in the Ukraine, I have two teams of developers, one team of four and another team of two. We sync up frequently over e-mail and IM. The developers then work closely together hour to hour and day to day. When they get stuck, they help each other out. And they have a team so they’re not working in isolation.

How I work with the individual developers depends on the specifics of the team. From a strategic perspective, I set the priorities, design the product, and specify the roadmap—and you should too.

From a tactical perspective, for the two person team, I have a development lead who writes code and who manages the other developer. For the four person team, I have a senior architect who does the database and system design. The three other developers work for me directly.

I often try to hire people that have worked together before. This isn’t easy, but it’s amazingly effective when I can do it. First, a great developer tends to work with other great developers. Second, they already know how to work with each other, so they have good chemistry. Third, it’s a lot faster than trying to find people one at a time.

3. Hire a great architect and a great designer. For a system and team of any significant size and scale, an architect is critical to ensure design consistency, scalability, and that seemingly simple things like—where and how does data get stored—are done in the right way.

Databases have a funny way of growing out of control. Another table here, another table there, and before you know it you have lots of inconsistent tables and no idea how they all work together.

The same thing happens with code. Say you’ve got a function for sharing a link to an image. It’s the same functionality all over the product, but without an architect and solid design guidelines and principles, that same functionality could be written a dozen different ways. That means when you want to improve the functionality a little bit, you have to change it in 12 different places—a nightmare.

A great architect ensures that this does not happen and lays out the coding principles, technologies, and guidelines the rest of the team needs to follow. He or she also thinks about the big picture—what does it take to scale the database and the system and how performance continuously improved so things are fast and users, as a result, have a great experience.

A great designer is just as critical. Great developers write great code. Just as the architect thinks about the product implementation as a whole, the designer thinks not just about individual icons but about the whole product design.

A great designer not only produces a design that wows your users due to its simplicity and intuitiveness, but also ensures consistency of icons, popups, fonts, colors, and the like across your whole product. That’s the difference between a product that feels like it has rough edges and one that feels clean and makes your users have that “wow” experience.

4. Focus on product. Problem is, I didn’t want to go out and raise $5M or $10M from the get-go. Having both boot-strapped and raised venture capital multiple times, I first wanted to spend some time in boot-strap mode, making the hard tradeoffs that entails. I wanted to get back to product. I wanted to make users really happy before I poured the gas on user acquisition, hiring, and scale.

Now don’t get me wrong. When it comes to starting a company, having millions of dollars in the bank is really nice. It’s comforting. You can hire a lot faster and you can pay yourself and other people. But as I wrote about in my book Why Startups Fail: And How Yours Can Succeed, raising too much money too early can all too often be a recipe for disaster.

A lot of the bad distributed team experiences I hear about are because people assumed the product would turn out the way they wanted. Building product requires day to day if not hour to hour participation in and leadership of the product. It means testing out the site yourself to make sure everything works, not just assuming that it does.

5. Start with a product background. People who tell horror stories of working with remote or offshore development teams all too often don’t come from product or technical backgrounds. They have no idea how to design and build product, manage developers, or prioritize features. They end up hiring poor engineering talent, getting poor product, and having a miserable experience as a result.

Remote, distributed, and off-shore development teams can work amazingly well, but you have to have the skillset and knowledge to manage them effectively. If you don’t, team up with someone who does. Or go spend a year or two working on a product somewhere else. Learn the ropes. Then build your own.

6. Hire on performance. When I tell some people that some of my best developers and managers are people I’ve never met in person, only talked to on the phone, on Skype, or over email and IM, they are amazed. They ask me questions like, “How can you trust those people?” “How do you know they do good work?” Or they just look at me with wide eyes that say, “Seriously?”

At one of my companies, Speechpad, the leader in crowd-sourced audio/video transcription, we’re creating work for thousands of people around the country. While we’ve never met many of these people in person, they’re some of the hardest working, easy to manage, and most communicative people I’ve ever worked with. Some of our best transcribers have become transcription managers and account managers. Rather than having to evaluate them based on a job interview or a resume, we can evaluate them based on their performance, on the quality of their work over time.

When it comes to software engineering, I’ve experienced a similar phenomenon. Not every hire I make works out. In fact, I fully expect that many will not work out and am pleasantly surprised when they do. I have new developers work on well-contained parts of the product until they prove themselves.

At media hub Onepo.st, I look for developers who:

- Write lean code

- Write code fast

- Produce code that’s maintainable

- Work well in a team

- Think about scale

- Can communicate

Developers who write great code consistently I have work on the core product. They take on larger and larger ownership. And, of course, I get a feel for who is good at what. One person excels at user interface while another person excels at database and scalability. That helps determine who I assign to work on what.

Unlike companies that have to hire purely on job interviews, I don’t. Because I look for engineers that have worked together in the past, and I evaluate new engineers through their actual performance, I have a much better sense of performance than a job interview or a coding problem can provide.

7. Leverage online marketplaces to discover undiscovered talent. Great developers are hard to find anywhere. But Internet marketplaces are changing the nature of work. Marketplaces like Amazon Mechnical Turk and oDesk, while very different in the nature of the work they support, provide an incredible avenue for discovering undiscovered sources of talent.

Finding great talent isn’t always about going to where the obvious talent already is—Silicon Valley. In today’s world, it’s just as much about finding great pockets of undiscovered talent and then forming that talent into virtual or real-world teams. And in some cases, it means relocating those teams to the Valley once they are built.

Building great teams is hard to do. Over the years, I’ve found lots of great individual contributors. But putting together a team remotely takes a certain amount of patience, skill, and luck.

There are three keys to keeping distributed teams (or any team) engaged:

- Build up a long-term relationship with engineers and designers over a period of time. That creates trust and chemistry. That chemistry is key to nimble and efficient product development. Frequent two-way communication over IM, email, and sometimes Skype, is critical.

- Provide steady work. Always be ahead of the curve on feedback and new work items; don’t let things linger. Pay on time.

- Provide interesting work. If the work you have is mundane, that is fine for a while, and a part of every product development cycle at some point. But the most talented engineers want to work on products and technologies that are current and interesting. Make sure yours is.

As always, if you want to talk further about building distributed teams—or building product teams in general—please drop me a line.

1 Comment

  • Dave, thanks for writing this.

    There are a number of pragmatic points I have have taken note of. I have just added you to my reader- I look forward to reading more.

    Regarding odesk and the like, finding good people online is much easier said than done, but it can be done! We had to pay a lot of attention to the people we used in order to find usable people, including instigating hiring processes akin to HR ones. We got a lot of strange results sometimes (In one instance i came up with the idea of giving odesk staff skype accounts to get them to qualify leads on the phone to australian businesses!) and after investigation found that some people just didnt fundamentally understand the task- we have found great people though. Our experience is that the good ones have a great work ethic. We had one or two that would work extra time for free to ensure the output was correct!

    The point of finding good developers is very apt, i really have found that they are plugged in and know other great developers they have worked with or at least are friends with. At one major incubator portfolio company, one hacker that was hired brought the rest of the dev team in.

    How do you find developers in Ukraine (and to remote operate)? My inference is you are taking them on as contractors too?

    I would be interested in reading (learning) how you developed your product knowledge? You touched on this is point 5.

    Thanks,
    Alexander

    Thanks!

Leave a comment