Thursday, June 29, 2006
The NVCA and Thomson Financial recently released private equity performance data.
The chart provides a twenty year comparison between the returns to specific private equity strategies, as well as to the NASDAQ and S&P 500.
The private equity returns are net of management fees and carry. 71% of the private equity gains reflect realized returns, while the balance of the total return is calculated by taking the current net asset values of the funds as reported to limited partners.
In the last ten years, limited partners have received distributions totaling $202bn, or an average of $20.3 bn per year, while over the same period limiteds made $829bn in commitments, or an average of $83bn per year.
While the 20 year early stage vs S&P 500 risk premium is only 9.4%, over a 20 year period this represents a 6x difference in total dollars returned.
I am banking on the fact that the ability of top firms to maintain access to non-public information, ideas, entrepreneurs, and information asymmetries will support the continued historical investment performance of early stage venture capital despite the 2x increase in number of VC firms, 1.9x increase in number of VC professionals, 2.5x increase in the amount of VC raised, and 3.2x increase in the average capital under management over the last ten years.
Early stage VC is a tough, tough business. I believe that the best firms demonstrate that a commitment to supporting the entrepreneur, while working to create an unfair advantage with respect to information and access to opportunity supports extraordinary performance relative to the industry at large. It will fascinating to watch if the rolling 20 year returns to early stage venture remain in the 20+% range.
Wednesday, June 28, 2006
All the authors listed offer great insights and perspectives on the start-up and vc worlds. A hallmark of our era is the wonderful transparency and direct access that blogs afford to the ideas and experiences of members of our industry. Great to read and fun to learn from.
Sunday, June 25, 2006
TechCrunch wrote an excellent overview, as did Silicon Beat.
The funds will be used to pioneer a new type of marketplace for web-based widgets, called WidgetboxÂ, that enables the placement of many types of applications, functionality and content into blogs, personal homepages, social networking sites, and auction pages.
A web widget is a piece of web service-based interactive content that can be dynamically embedded into a web page. For example, a web widget can be a auction listing, contextual search box, a game, a score box displaying a set of statistics, a weather box, an advertising box or any other functionality to be embedded on a web page such as a blog, personal homepage, social networking profile, or auction page.
PostApp is creating a marketplace that connects web widget developers with bloggers and other personal publishers. Widget developers include online services seeking widespread widget distribution such as Yahoo! and eBay, as well as small independent widget developers.
PostApp offers innovative technology to ease the pain of widget management including the Widgetizer EngineÂ, a powerful but simple tool that lets you turn anything on the web into a widget, as well as tools that make it easier for bloggers to control their widgets quickly and intuitively.Interested developers and users can sign up for the private beta here.
Akimbi extends the virtualization metaphor into the test and development marketplace.
Akimbi's Virtual Lab Automation System provides development and test infrastructure that automates and virtualizes the rapid setup and teardown of complex multi-machine software configurations, shaving man-months off of software development projects and saving development orgs from having to physically provision test configurations.
Congratulations to all.
Wednesday, June 14, 2006
Since the first summit six years ago, Morgan Stanley spent $12.5bn on IT. Importantly for attendees at the CTO Summit, that spend includes millions with 30 start-ups, or 11% of the total companies that were sourced by Morgan Stanley at the summit. Morgan Stanley is expert at deploying technology from both ends of the bar bell – large vendors and the best and brightest innovators. Morgan Stanley first met, at the CTO Summit, and later bought technology from VMWare, Transitive, iRise, Avamar, and others.
I enjoy attending the summit and am often struck by Morgan Stanley’s ability to concurrently scale the technology environment with very little increase in total spending. For example, since 2001:
• Trade volumes are up 7.5x
• Bandwidth is up 20x
• Business data is up 4.75x
• Servers/computers are up 3.5x
• Business connections are up 8x
• The IT group now manages 68,000 desktops, 16,000 servers, 4.5 PB of storage, 10,000 mobile devices…
And yet, the CAGR of IT spend is ~2%. Remarkable. The IT department is allowing Morgan Stanley’s core business to grow and scale without a related increase in IT costs that would reduce the marginal profitability of such growth. In some sense, IT is a fundamental source of operating leverage. A core element of this accomplishment is the use of innovative new technologies.
Key, well-known, sources of savings are:
• the move from SMP to blade servers,
• RISC to x86,
• Unix to Linux,
• 1 GigE to 10 GigE,
• and an increase in the ratio of severs/switch port.
Part of the summit involves Morgan Stanley delineating sources of ongoing cost and a request for technologies to blow out bottlenecks.
Transitive and iRise were recognized as two companies that help meet that mission. Transitive, which allows any software application binary to run on any processor and operating system, helps Morgan Stanley move applications off of expensive legacy hardware. iRise, which is a visual requirements gathering and prototyping solution, helps reduce the cost of failing to deliver applications that meet customer expectations.
With respect to SaaS, Morgan Stanley (Jeff Birnbaum) made several interesting comments. They segment SaaS into three models: web based delivery of applications, Citrix-like terminal emulation with server-side processing, and Softricity-enabled and client-side processing and delivery of rich client applications that require no client installs.
Morgan Stanley views web-based SaaS as, pejoratively, the 3270 equivalent, which demands large back-end server farms and limited user experience. They see a continuing demand for rich client applications, beyond what AJAX delivers, and see Microsoft’s acquisition of Softricity as the most significant new technology of the last 12 months. Softricity streams applications for client-side processing without requiring the .exe to be installed and managed on the desktop. Softricity allows Morgan Stanley to avoid the need to deploy and manage .exes on 60k desktops, while providing traditional rich client application user-experience. It will be interesting to follow what MSFT does with the technology – perhaps Softricity will provide MSFT an articulate, user centric response to the rise of web-based SaaS.
Tuesday, June 06, 2006
The first centers on raising venture capital and the second on building a great team. If you plan to be in Vegas, please let me know.
Funding and Pitching Your Business (Track 101)
Speakers: Laura Merling, Executive Director, SDForum
Building a Top-Tier Team in the Early Stages (Track 106)
Monday, June 05, 2006
A Practical Guide to Structured Interviewing ============================================
All entrepreneurs agree that building a strong team is extremely important for their startup's success, but many first-time founders are not sure how to achieve it, and are baffled by the interviewing process. The number of questions and choices is indeed confusing: where to get the resumes, whom to invite to an interview, whether to conduct interview over the phone or in person, what to ask, how to evaluate the answers, etc.
Luckily, the structured interviewing approach Will wrote about recently can help. Below are some details of how we apply structured interviewing at Coral8 ( a Silicon Valley startup building a platform for real-time analysis of large volumes of data). While what follows applies mainly to engineers (software, QA, support, professional services), the same would apply to many other job functions and positions.
Like any complex process, the interviewing process is best structured and analyzed as a sequence of phases. At Coral8, we have four phases: email interview, phone interview, the first in-person interview (with 1-2 person), the second in-person interview (3-4 others). Whether you have the same stages or not is not important. What's important is having a clear understanding of a) why you are having each phase b) what you are trying to accomplish, and c) how you are going to evaluate the results. It helps if all the interviewers share this understanding, and keep the process as consistent across candidates as possible.
Let's consider the phases separately.
Most startups complain that just finding a good candidates is the hardest part of the process. Post a job description at any jobs web site, and you'll receive hundreds of resumes, most of them from people who are not even remotely qualified. Hire a recruiter, and he'll be sending dozens of resumes your way, again often from poorly qualified candidates. Just opening and reading those resumes is often overwhelming.
The problem may seem impossible to solve, yet a simple solution exists, and here at
Coral8 we are still puzzled as to why so few companies use it. Here is what you do: You never, ever, publish a position description without an accompanying problem that someone MUST solve before you even open their resume. The problem
should: a) have a solution that can be easily reviewed b) take the right candidate about 10 minutes to complete c) test a skill that is core to the job
d) be somewhat interesting e) allow a super-star candidate to show off their
knowledge and skill. Since most of our positions require programming in some
language, our problems often require writing a simple program or function. The language and the complexity is adjusted for each position.
For example, when we interview C++ engineers, we want to make sure they understand polymorphism and virtual functions. It's disturbing how many people who call themselves C++ programmers do not. So here is a problem we sometimes
use: Illustrate the use of the keyword "virtual" by writing a short C++ program which contains this keyword and prints "Hello, world". If the keyword "virtual"
is removed, the modified program should print "Good bye, world".
Some may say that the problem is too simple, and it certainly is. But having a problem like this in your ad does wonders. First, it greatly raises the signal-to-noise ratio. Few Visual Basic programmers will bother to send their resumes if you require a solution to a C++ problem. If they do, or when the solution is wrong, you can quickly ignore the submission. The resumes you'll get are usually from people who are really motivated, and not just sending resumes to all the positions. If somebody gives you a correct solution, you immediately know that you have a strong candidate.
Some folks may think that having a problem discourages some good candidates from applying for a job. Who knows, maybe this is true for some candidates. In our experience, however, we find just the opposite. Some of the very best employees we've hired told us that they applied for a position with Coral8, back then a stealth-mode startup, precisely because they were intrigued and challenged by our posted problems.
What if you do not publish your job openings, but instead use recruiters? Easy!
Give the problem to the recruiter, and tell him that you will not accept any resumes without the solution to this problem. Some recruiters will tell you they don't want to do the extra work. Somehow these are often the recruiters who want to charge you 25-30% of the candidate's annual salary, and you just pass on them. A startup can and should negotiate a much better deal anyway, and, more important, a good recruiter loves the fact that you have this problem!
Why? They know that you get a lot of resumes, from many sources. They want to give you the candidates who are the most qualified, and they have to qualify them somehow anyway. And what better way is there to qualify the candidates than to use your own problem?
So this is what we call an "email interview". In most cases, unless we have a high-quality referral, we refuse to even look at the resume unless we see a solution to our problem. Life is too short to look at hundreds of resumes a week.
Phone interviewing is a much more traditional and better understood process, so I won't spend as much time on it. What we found important is to have a list of questions for each position, and to try to follow this list every time. It makes the process much better structured, and over time you learn which questions are harder than you thought, and which ones are easier. So it helps you calibrate your expectations better.
Since we only schedule phone interviews with the people who pass the email interview, we know they have at least some basic understanding of one area. So the phone interview is used to get a slightly better understanding of the breadth and the depth of the candidate's skills. We spend about 30 minutes with a candidate, and use a part of that time telling the candidate about the company and the position. After 30 minutes, it is usually clear if you want to invite the candidate to a face-to-face interview.
1st face-to-face interview
All right, the candidate comes in to see you, what do you do? As Will mentioned, too many interviewers go with "Tell me about yourself?" and "Tell me about your past projects?" kind of questions. These questions are ok, but spending more than 10-15 minutes on them is counter-productive. The last question is often useless, unless you happened to know a lot about specific areas the candidate worked in. If you do not, it's hard to evaluate how challenging the tasks really were, and whether the decisions he made were correct. Instead, what you should evaluate in these situations is the candidate's presentation skills. Whether you are an expert in his area or not, any good candidate should be able to clearly explain to you what he did, what the overall project was, what the trade-offs were, etc.
But most of the time should be spent with the candidates answering a carefully constructed set of questions. This may be a religious issue, but we at Coral8 strongly believe that the questions should be clearly related to the job, and not some puzzles that test nothing but the ability to solve puzzles.
Now, if you are interviewing programmers, then please, please, please, administer some programming exercises. There is an amazing number of programmers on the market with fancy resumes, fancy titles, and fancy degrees from fancy schools, who nevertheless cannot program well. You do not want to hire people like that. Any resistance to programming during the interview (e.g, "I don't program well during interviews") should be an immediate red flag.
Of course, when you ask somebody to code during the interview, be reasonable.
Many people do not remember the language syntax or the names of library functions. That's entirely ok. We either let people use some reference guide or Google, or just tell them that they should not worry syntax. To us, what matters most is algorithms, so this is what we pay attention to. You may worry more about something else, but whatever it is, make sure you carefully construct your questions to test for that, rather than just asking whatever you feel like at the moment.
2nd face-to-face interview
Now, the candidate passed your interview, and you invited him to come again to "meet the team." Sounds innocent, but this is one of the more challenging parts of the process. You've got to recognize that people have widely different interviewing skills, and sometimes even great engineers make poor interviewers.
Work with them. Agree, as a team, on which questions to ask, and who will ask them. Sit in on some interviews yourself, to make sure you are satisfied with the interview dynamics. It's often best if people interview in pairs: it takes less candidate's time and lets the interviewers to learn from each other.
The 2nd face-to-face interview is also a good time to further investigate some
personality issues. For example, the team may agree that during the interview,
one team member will try to push the candidate a bit, disagree with him strongly on some issues, and see how the candidate handles it. You don't want to go too far, but it's a useful test. Nothing kills productivity in a startup like engineers who do not know how to disagree with each other professionally.
All right, everybody has talked to the candidate, now what? This is the place where it's especially important to have a well-defined process. It's best to have a formal scale, on which everybody will grade the candidate. The scale we have at Coral8 was popularized by Siskel and Ebert: thumbs up, thumbs down, and we also have many gradations in between. It's not important what you have, the scale 1-10 works just as well.
It also helps to have a threshold. Let's say your threshold is 7. It means that you do not want to hire anybody with the average score below 7. If you have only one serious candidate for the position, you just need to decide whether he scored above your threshold or not. If you have multiple candidates, you need to compare them to each other, using their combined scores.
How you combine the scores given by different team members is an art, not a science. You may start with simple averaging. Or you may want to say that anybody with one or two votes below the threshold is automatically disqualified.
You may also keep in mind that one person's 9 may well be another person's 6.
The ultimate decision is yours, but what's important is that you as a team talk about the candidate, and discuss what people like and dislike about the person.
During this discussion, you'll learn a lot about the candidate, and you'll learn even more about your team!
There are many parts of the hiring process that we have not covered yet: formal reference check, informal reference check, offer negotiation, etc. The important point, however, may have nothing to do with hiring per se. To many people, the words "startup" and "process" are mutually contradictory. Processes are for Fortune 500 companies, right? Not so fast. Like it or not, there are many processes going on in any startup. You may recognize, structure, and optimize them. Or you may hope that they just work by themselves. The interviewing process is a good example of a process that will produce some results either way: after all, no startups die because they cannot hire any people at all. But there are certainly ways to make this process much more effective, efficient, and enjoyable for all participants.