Yet Another (ex-)VC Blog

Here’s the first stab at the forward for the VC careers eBook. I’m going to build the content around this, so please let me know if there are topics that you think I missed or that you want to make sure are included in the chapters I’ve outlined here. Comments are very welcomed and appreciated.

Forward

It’s no surprise that it’s not easy to get a venture capital job when you consider some of the factors at play:

• There are very few VC jobs to begin with
• People tend to stay in a VC job for a long time
• Venture capital is not a growth industry; The number of people employed in the field does not typically increase annually (in fact, it may start decreasing going forward)
• VCs only hire through trusted referrals
• VCs are generally well compensated
• VCs work with entrepreneurs who are trying to change the world, or at least the industries in which they operate (which is no small feat, either!)
• Bottom line: VC is a great industry and the jobs are great, too

The combination of scarcity and quality of the jobs makes for a big labor supply/demand imbalance that works mightily against the venture capital job seeker.

• Acknowledgements and thank you’s (A shoutout to everyone that I can remember who helped me or met with me during my search)
• What’s the job of a junior VC? (A discussion of the day-to-day work of an analyst or associate)
• Onramps to venture capital (Discussion of the feeder jobs and industries to the venture capital industry)
• Do you need an MBA?
• What makes a good VC? (Discussion of skils that can help you be successful in this industry)
• Where are the jobs? (Finding/creating venture capital job opportunities)
• Where are the internships? (Finding/creating internship opportunities as an undergrad or grad student)
• Introductions and followups (The lifeblood of a VC job hunt)
• The Informational Interview (Once you get it, how to get the most out of it)
• Offer negotiations (If you’re fortunate enough to have offers to join multiple firms)
• Exit options (If you’re not a VC lifer, some thoughts on careers that might make sense post-VC)
• Final advice
• Online information sources (Sites and blogs that I found useful during my job hunt)

If you are interested in careers in venture capital, think about subscribing to my mailing list. I promise not to spam you and will only send information related to venture capital jobs and careers. Please input your email address in the field (and click ‘Submit’) below if you would like to subscribe.

Related articles by Zemanta

• Venture Capital Careers Panel at Columbia Business School (johngannonblog.com)

If you visit the blog fairly regularly, you may notice that I removed the M&A Funding Pipe feed in the right column and replaced it with the @vcdeals twitter feed.

@vcdeals tweets any financing or M&A announcements that get posted to a variety of blogs and then provides a bit.ly link where you can get the full article.

If you are a twitter user and follow the venture-backed startup market, follow @vcdeals and let me know what you think.

Special thanks to the Twitterfeed folks who made it really easy for me to get this going.

Venture-backed companies often leverage distribution and VAR channels to ensure that their product is available to a wide variety of potential customers.  Companies with a well-functioning channel program can increase revenues without a proportional increase in costs.  Investors like to see this kind of scalability develop in companies they’ve backed, or believe that this scalability can be achieved at some point in the future.

If you are thinking about taking your product or service to market through the channel, here are some things to consider:

If you can’t sell the product, the channel won’t be able to sell it, either.

Just as you probably shouldn’t hire any sales and marketing employees until you have come up with a product that you (the founding team) can successfully sell, trying to establish a channel before you have developed some market traction on your own is a moot point.  After all, why would a potential partner want to spend time and effort on pushing a product that no one has shown interest in purchasing?

Potential partners are going to want to see market interest in your products (as evidenced by sales or PR) before signing up to work with you.

Enable and support your channels.

A sure path to failure for any moderately complex technology product is to sign up channel partners to resell and/or support the product without educating them on the sales and support of the product!

It seems obvious when you see it in print, but in my experience this is one of the big ‘gotcha’ areas when developing and supporting channel programs.

Lack of education will result in unhappy customers and often a perception that your product is flawed in some way (even though it might not be).   Take the time to educate the channel and you’ll see much better results.

Avoid channel conflict.

Companies who have a direct sales force as well as a channel program need to be careful not to alienate channel partners by competing for the same customers.  Make sure your salespeople are incentivized not to compete with your channel partners.  Again, this probably sounds obvious but you’d be surprised how often it happens.

Related articles by Zemanta

• Strategic Partnering: Turning Suppliers Into Partners (marketing.blogtanker.com)
• Time for a Amazon Partner Program & Product Roadmap (elasticvapor.com)

Brad Feld made a couple of great posts over the last week talking about some of the challenges with cloud computing around the coordination of infrastructure level services in complex cloud environments.  Namely, that most cloud computing (hosting) providers have APIs for primitive functions like creating and starting/stopping instances, but lack coordination or error handling functionality at a granular (operating system) level.

These posts struck a chord with me thinking back to my days as a UNIX systems administrator working for a F100 financial services company.  We ran a three-tier architecture with a large number of web servers, application servers, and a pair of beefy database boxes at the bottom of the stack.  Whenever we needed to reset the environment, we had to go through a very specific process to get things online again.

Here’s what a reset looked like:

• Restart database servers, make sure they were working
• Restart application servers, make sure they are talking to the database
• Restart webservers, make sure plugins are talking to the app servers
• Flush load balancers and firewalls

This whole process would take about 15 minutes, very manual, and thus was quite error prone.   For example, if you started the app servers before the database servers – oops, do not pass go, do not collect $200.

Although that example was from a traditional hosting environment in 2000, I imagine there will be similar problems for medium/high complexity cloud hosted applications.

Vendors like VMware have tried to address this kind of issue by providing a workflow engine that can be used to automate sophisticated processes within the infrastructure, and I know RightScale has the RightScripts framework as well, but there is still a major gap.

These systems presuppose that a developer is going to know and care that there are lower level dependencies beyond the APIs with which they interact with the cloud environment.

The beauty of the cloud is that the developers shouldn’t need to know or care about which server starts before which other server, or that sshd needs to start on box A before box B can run a batch job.

But as Brad implies in his post, I think we’ve got a long way to go…

Related articles by Zemanta

• Does GoGrid opening their cloud API bring new business opportunities ? (byteonic.com)

With the cloud computing market growing so rapidly there has been a rise of cloud computing management vendors like RightScale, Enomaly, Scalr, Elastra, and others.  These companies have developed solutions that work very well for the early adopters in the cloud computing market, but I wonder if these tools are getting an equally warm reception from the enterprise.  After all, most medium to large IT shops use systems management suites like Opsware, Tivoli, etc and don’t have expertise in this new breed of tools.  Not to mention, most decent sized IT shops don’t want yet another management tool because they probably already have three too many!

In the long run, I believe we are going to see hybrid datacenters where enterprise customers are able to run workloads simultaneously in local and cloud datacenters and manage them in a seamless way.  The question is: How will these hybrid datacenters be managed?

I think there are three possible outcomes:

1. Systems management vendors add cloud functionality to existing tools: Opsware, BMC, and the rest of the usual systems management suspects will make their products cloud-aware  just as they have made them virtualization-aware.
2. Cloud management vendors add traditional systems management functionality to their toolkit: This would be a very tough nut to crack, but the emerging cloud vendors could take a stab at developing more traditional IT management functionality, allowing them to handle management of both traditional and cloud hosted datacenters.
3. Proxy or Glueware:  Startups build tools that allow both the cloud management vendors and the systems management vendors to interact with non-native environments.  In effect, they glue together these two separate worlds.  These glueware startups would almost act as proxies, allowing say a systems management tool to manage cloud hosts in a seamless way and with minimal retraining of staff required, while letting a cloud management tool manage legacy IT infrastructure.

I think we’ve seen #1 come to pass in the virtualization market to date, but in the cloud management space I think #3 is a more likely outcome.  There would be major rearchitecture required of most enterprise IT management products to support a hybrid datacenter configuration and so some sort of proxy or glueware would enable much faster/easier integration.

Your thoughts?

Related articles by Zemanta

• Does GoGrid opening their cloud API bring new business opportunities ? (byteonic.com)
• Elastra’s Policy-based Cloud Management: Bring on the Hybrid Clouds! (gigaom.com)
• RightScale CEO sees little need to ‘move up the stack’ (cloudofdata.com)
• One Puppet to rule the cloud? (news.cnet.com)

Cloud hosting providers with any degree of scale should have an application load testing product offering.  In fact, I think it has the potential to be a killer app for cloud hosting companies.

Load testing has traditionally been a painful process and inefficient process from a time and cost perspective due to challenges around traffic generation and scaling.

There have been typically two options for the traffic generation aspect of the load test:

1. Buy a bunch of servers to make into a traffic generation farm, buy some software (e.g. Mercury Interactive) to automate the testing, and tie it together by hand.  This is no fun, no matter whose software you are using.
2. Pay a load testing managed service provider (e.g. Mercury or Keynote) to provide both the testing server capacity as well as construction of the test scripts.  This is less painful than #1, although you are not able to test on demand and its likely that the price you’re paying the provider is going to be negatively affected by the large fixed cost infrastructure load testing providers tend to own.

Let’s also look at a customer’s objectives during a load test.

1. See how much traffic of various types the application as-configured (hardware, software, etc) can handle.
2. See how much more traffic the application can handle if configuration changes are made or additional infrastructure components (i.e. more servers, bigger servers, etc) are added.

#2 is painful in a non-cloud world because a customer has to purchase or rent servers just to see how their site responds to scaling.  And its even more painful if you work with a hosting provider whose business model is dependent on long term usage of server capacity to cover a large fixed cost base.

Here’s where the cloud comes in…

For a customer who has their app hosted w/a cloud hosting company, scaling is not an issue, as long as that customer is willing to take the variable cost hit of spinning up more servers to see how their app handles higher loads.  No need to reconfigure existing servers or purchase new hardware!  For a customer who has a traditional hosting environment but has the capability to cloudburst could see similar benefits.

Also, a cloud-based load testing platform would by definition be available on demand and less expensive to operate than a platform that lives on physical servers since the fixed cost base would be drastically reduced in the cloud case.

And here’s the best part:  if I’m a cloud hosting provider who offers a load testing service (or resells one), I’m getting paid for the extra capacity that the application owner is using during the load test AND if the cloud load testing platform lives on my cloud, I’m getting paid for their capacity usage during the test as well!

Seems like a beautiful thing to me.  App owners get cheaper, more flexible load testing capabilities, load testing companies get paid, and the cloud hosters get paid twice!

Related articles by Zemanta

• HP adds to apps performance management pack (infoworld.com)
• uTest To Launch AppGrader – Free Web App Testing (video) (centernetworks.com)

More and more businesses and consumers are trusting their data to SaaS providers who store customer data in the cloud.  Of course you have the well known SaaS players like Salesforce.com and 37signals but there are also plenty of smaller guys out there.  Because its fairly cost-effective to build a SaaS app thanks to Amazon and other utility computing players, you have a proliferation of companies and solutions from which potential customers can choose.  Choice is certainly good for the customer, but because the SaaS space is so fragmented with many small players (many of whom are probably not financially viable in the long run) you could see a situation where your SaaS provider goes under, and takes your data with it!

There are a few ways to mitigate this risk, although frankly none of them are that great in my opinion:

1. Work with only larger SaaS companies and ignore smaller SaaS players (lose out on innovations made by smaller companies)
2. Request raw data dumps from your SaaS provider (good luck making heads or tails of that data)
3. Work with providers who agree to some standard APIs or data models that allow for easy retrieval of data and prevent lock-in (we’re a long way from that sort of nirvana…)

I know many SaaS companies would happily do #2 (especially if the topic came up as an objection in the sales cycle) but frankly, without #3, there is not much a customer will realistically be able to do with the data.  Taking a vendor’s proprietary data format and making heads or tails of it is generally quite painful.  Small-medium IT shops may certainly get a warm fuzzy feeling that their SaaS provider will give them all the data they want, but if the customer is actually forced to do something with the data because their provider goes out of business, chances are they are going to spend alot of time and money ‘restoring’ the data into a comparable application environment.

Painful stuff…I wonder when we will start to see SaaS vendors moving in the direction of #3 (portability and interoperability between SaaS apps)?

Related articles by Zemanta

• Salesforce.com outage exposes cloud’s dark linings (theregister.co.uk)
• Bloodbath in the Clouds Continues as RSS Email Service Shutters (micropersuasion.com)
• SAP Acquires Coghead’s Technology As It Looks Towards The Cloud (techcrunch.com)

(Disclosure: My employer is an investor in OnPath Technologies, a Layer 1 switching company)

Due to the broad adoption of virtualization technology in the server, network, and storage sectors, it is easier than ever for IT admins to apply business policy to the infrastructure and automate any number of menial tasks that used to suck up manhours.  Servers, storage, and even networking are treated as logical data objects and can be manipulated with ease.

However, to realize the industry vision of the hands off, “lights out” cloud computing datacenter, all parts of the IT infrastructure will need to have automation capabilities, including the physical network.  Just as network engineers don’t have to physically be in the datacenter to modify routing tables or switch configurations and server guys don’t need to sit at a server’s keyboard to manage it, datacenter ops teams shouldn’t have to send someone into the datacenter, in the wiring closet, or under the raised floor to make physical cabling adds, moves, and changes.

Seems logical to me, but I’m not an IT buyer so my vote doesn’t really count :)  Wondering what folks out there are thinking (or not thinking) about this topic of layer 1 automation…

Related articles by Zemanta

• IBM & Juniper team up for Cloud Migration (elasticvapor.com)

Truer words could not have been spoken about pitching:

1. Don’t use PowerPoint, use Apple’s Keynote 09 ($79) even if it means you have to go out and buy a Macbook ($1000) only for making presentations. Even when I worked at a big company who dictated I use a PC, I brought my own Mac for presos. Like a carpenter, I am happy to bring my own tools if needed. Others agree with me.
2. Deliver your presentation standing up. Don’t stand behind a podium. Don’t sit down. Even if there are just one or two people in the room.
3. Demo your product/service first. Before you do almost anything else…demo.
4. Buy a professional font family ($100-$900). My two favorites are Helvetica Neue and Gotham (Obama and Yahoo! both use Gotham).
5. Don’t use defaults (particularly for PPT). No default templates. No default clipart. No default formatting for charts or tables. No default fonts. No defaults.
6. Learn how to do bulleted lists correctly (note: the default formatting for bulleted text, even in Keynote, is completely incorrect).
7. Don’t use slide titles. If you do, they should say something
8. Use lots of screenshots or images of your product or service (or team)
9. Reisist slide animations. Use the “dissolve” transition between slides.
10. Shorter presos are better. 5-8 slides is ideal. 10-20 for longer or more detailed presos.
11. Limit or eliminate text. You are there to speak. They are there to interact and listen, not read.
12. Send PDFs of your presentation, not PPTs as followup.
13. Tell a story. Every presentation needs a plot (1-3 underlying points). For Al Gore, it was “The planet is in trouble, and it’s worse than you thought” and “We are to blame, but if we now we can also be the solution.” The rest of his amazing presentation were just supporting elements to that plot line of his story.
14. Reduce the size of everything. As a default PowerPoint (and Keynote even) make everything too big. White space is your friend.
15. Don’t pass out your slides (unless they are for a board meeting). Don’t send your presentation in advance (there are exceptions to this rule).
16. Make your own color palette and stick with it for the entire presentation. Generally, you should only use 1-2 colors (plus black and grays).
17. White backgrounds are best. Don’t use backgrounds other than solid colors of very subtle gradients.
18. Charts: Reduce categories. Don’t use legends. Reduce font sizes. Reduce guide lines. Use one color with multiple shades. Eliminate or reduce line weights.
19. Images: Clean up your images and graphics with alpha channel. Mask or crop your images.
20. Use reasonable examples or comparisons. Don’t compare yourself to Yahoo!, ebay, Google, Microsoft, Apple, Facebook or MySpace unless they are your competitor.

Kalani, Jeff “the Blog” Bonforte, Feb 2009

Take a look at the whole article if you have a moment.  Thanks for sharing, Jeff!

Related articles by Zemanta

• Why Keynote is better than PowerPoint (en.onsoftware.com)

Online backup (think Carbonite, Mozy, etc) is generally considered a terribly unsexy, commodity business.  You’re basically reselling cheap (and continually declining in price) storage and compute power and then tying it together with an application to shuttle bits back and forth.  Those kind of dynamics give rise to highly competitive markets with numerous players and low profit margins.  Because of these traits, I had always told myself that I would never want to invest in an online backup business.

It’s true that the constituent parts of an online backup service are commodities.  However, I think what a company does with the data once its backed up in the cloud is what will create enormous value.

Once all of a customer’s data is in the cloud, it becomes possible to do a number of things that you can’t do as easily when it is sitting on someone’s desktop or server hard drive:

• share an individual’s data across the organization (content management and collaboration)
• reduce overall data storage needs by eliminating duplicate records (enterprise wide deduplication)
• discover patterns and identify relationships between information workers (social networking)
• run a backed up application as a thin application running in the cloud (convert to VM)

It’s almost as if a cloud computing provider could use online backup as a loss leader to get data into the cloud, and then upsell a variety of new, ostensibly more profitable services (like those listed above).

So, online backup could be the Trojan Horse that accelerates adoption of cloud services.

Maybe I will invest in an online backup business after all… ;)

Related articles by Zemanta

• Mozy Launches Business Version of Mac Backup Service (xconomy.com)
• Carbonite CEO Apologizes for Planted Amazon Reviews, But Bristles at Critics (xconomy.com)
• Backblaze Offers Hassle-Free Unlimited Online Backup [Featured Download] (lifehacker.com)
• Hello Cloud Storage, Goodbye Consumer Hard Disk Drives (domainmacher.com)
• LaCie offers one year online backup with drive (macworld.com)