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.
Leave a comment
- January 2014
- December 2013
- November 2013
- October 2013
- September 2013
- April 2013
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- November 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- November 2010
- September 2010
- August 2010
- July 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- March 2009
- December 2008
- November 2008
- October 2008
- August 2008
- July 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- March 2006
- December 2005
- October 2005
- July 2005
- May 2005
- April 2005
- February 2005
- November 2004
- October 2004
- September 2004
- August 2004