Although we often think of VC and risk capital as being a relatively recent phenomena in the Bay Area; starting during the 1950s and 1960s with the rise of the microchip industry and the birth of “Silicon Valley.”
But the culture of of risk capital extends far before that, all the way back to the 19th century!
I’m reading this great book San Francisco Stories (borrowed from a public library… yay libraries!!!), which is a collection of letters and essays by great writers on San Francisco.
One who was not impressed by the city is Anthony Trollope, indeed his letter is titled “Nothing to See in San Francisco”
But as he wrote his letter in 1875, he was amazed by the willingness of San Francisco entrepreneurs and San Francisco financiers to take risks on new ventures, something that he could not imagine taking place in London or elsewhere in the US.
The great commercial community is there [in San Francisco]… If a young man there can make friends, and can establish a character of honesty to his friends and for smartness to the outside world, he can borrow almost any amount of money without security, for the purposes of establishing himself in business. The lender, if he feel sure that he will not be robbed by his protege, is willing to run the risk of unsuccessful speculation.
(Although we need to continue to ensure the risk capital investments and investees increasingly are women, as well!)
My recent article in the Globe and Mail highlighting that while innovation is important, but it has to be coupled with a strong business plan and market adoption.
The weather here [in Silicon Valley] is warm but the culture is coldly capitalistic. If you want to talk about investment, be prepared to talk about return. If you want to talk about business partnerships, be prepared to talk about customer demand and market opportunity.
Networking is a key part to success. You need to find your mafia, groups of people you can call on to help with business, advice or job hunting.
I try to find different mafias, some centered around my b-school friends, some centered around my old workplaces.
Coming from Canada, I also spend a lot of time with the Canadian mafia here in Silicon Valley.
Here’s an excerpt and a link to an article I wrote that talks about Canadians in Silicon Valley and our relationship to Canada
I’m from Toronto and I’ve been in tech for more than 15 years. A lot of my friends are also Canadians in tech. In fact, I got my last three jobs through my network of other Canadians in tech. I’ve done deals with other Canadians in tech.
We go to tech conferences together. We go to evening socials and networking groups together. Of course, there are always hockey and baseball games to go to. We know each others’ kids.
We do a lot of things you’d expect a network of Canadians in tech would do, except for one. We don’t live in Canada – we live in Silicon Valley.
In the cloud, everyone is making a connection.
Cloud software companies are working together to connect processes, to connect dataflows, to connect user-experiences, and to connect go-to-market strategies, all in an attempt to make users more successful with software, faster.
Cloud apps tend do one or a few things really well, and for what they don’t do, they connect into an ecosystem of other apps that do those other things. Unlike software of the past, cloud apps are architected to be rapidly deployed, and rapidly integrated.
“Don’t worry about huge, complex implementations,” they tell customers. “We’ll connect our software to your directory to your existing environment and it will all just work. The software is lightweight and integrated. Just log-in and you’re good. “
When integrations work well, a company’s data passes effortlessly from one app to another, letting end-users accomplish more tasks, collaborate more effectively, better manage processes and get more value out of their combined applications than they would from each application operating individually
How this happens is as easy as ABC. Well, A and B anyway… as in APIs and BD.
On the tech side, the responsibility for connecting to other software is handled via API, those carefully managed front doors that control the access of users and data from one app to another.
The human equivalent of an API is BD. BD is the sharp doorperson managing those front doors. What is the business model? Who can access the front door and under what conditions? At what price?
Never afraid to create hokey sayings around bad math, BD is always on the lookout for a great value-added partner to really discover how “1+1 can equal 3”.
Cloud software will only increase the need for both APIs and BD. Cloud software is easy to deploy, and therefore easy to rip out. Connecting via API to other software entrenches a cloud app within a customer’s environment, creating that elusive “sticky” factor we all crave.
But we crave sticky with a purpose.
Across the industry, smart companies have moved past the notion of connection-for-connections sake. Increasingly, APIs are no longer open but are governed by well-defined terms. Ecosystems can still be large and open, but the good ones are now better organized and exist for a defined business purpose.
Organizing these ecosystems is the responsibility of an ever more sophisticated BD function. BD is no longer measured by the size of their ecosystems, but rather the value those ecosystems bring to the company.
Successful BD people are coming up with ever more novel ways to sell the value of their company to partners and thereby build the highest quality ecosystem. With this ecosystem, BD has the opportunity to create new go-to-market initiatives that drive increased value for (1) their company, (2) their partners and (3) ultimately the joint customers.
Hmmm… It seems 1+1 really can sometimes equal 3.
One of the interesting challenges I’ve come across is sometimes figuring out exactly what does business development “own”? With other functions, it is more clear. Product owns the product, Sales owns “the number”, Marketing owns the message and so on. What does BD own? A strategy? A partnership? Sometimes maybe a number. And even if its ownership is clear, how BD achieves success often isn’t.
Often to achieve a BD-related goal, you need to partner closely with multiple functions; ie: Product/Engineering to help with an integration, Marketing to promote a partnership, Sales to share leads etc.
That is why BD is as much an internal facing job as it is an external one. To be successful, you have to understand the imperatives not just of the the business as a whole, but of individual functions. I sometimes think of BD an internal corporate diplomat, trying to get agreement and resources from multiple functions towards a single idea.
Here’s some of my guiding principles:
Brief early, brief often: Get your idea out there internally with all the relevant (and even tangentially relevant) functions to get buy-off and feedback. Yes, sometimes it takes a lot of time but it is worth it. If you’re going to be coming back to various functions for help or if you’ll be assigning them work, you better make sure you have their input and they feel invested in your deal.
If they think it, you’ve thunk it: Basically, do your homework and try to understand your colleagues’’ priorities and the potential objections. Know their individual imperatives and how your deal fits into them. Yes, your deal may be fitting into some larger corporate strategy, but how does it also fit into each function’s individual priorities. Don’t just pitch a deal. Pitch the deal internally and highlight the unique relevance to each function (again, Sales, Marketing, Product, Engineering… etc)
You don’t have to do everything, just make sure everything gets done: The two big mistakes in trying to get multiple things done to complete a deal is either trying to do everything yourself, or the opposite, which is just dumping tasks on people and assuming it’ll all get done because of the “strategic importance” of your deal. Neither approach works. Good BD people are always in partnership and working with functions to get things done. Sometimes it is rolling up your sleeves to do something yourself, sometimes it is sitting with a function and helping them prioritize what you need them to do. There’s an art to being flexible all while working diligently to a deadline.