Manic versus Myopic Leaders

We see plenty of unique challenges at all the midsize companies we evaluate for investment each year.  But the most common and potentially most fatal is the myopic founder.  It's not a surprise when we see it, as it generally serves a founder well during the roller coaster that is building a bootstrapped company, but it has to end if you want to scale your business.

Manic can be good.  Myopic is always bad.  And here's the difference.  Manic behavior drives you to leave your old job and start a company with your personal savings on the line.  What sane person would do that?  Manic behavior gets you into your customers' heads so you can anticipate their needs and build a market-driven company with massive customer loyalty.  It makes you keep a disciplined vision as you grow, not allowing you to get too far away from the core business as you build a team, expand geographically, introduce new products and enter new markets.  Manic behavior gives you that innate feeling that informs what your customers and employees need.  Maybe it's an entrepreneurial sixth sense or maybe it's that feeling Michael Jordan had when the game around him slowed down while he played at full speed.  Or maybe it's that feeling John Starks had when he dunked over Horace Grant and MJ in the 1993 NBA Eastern Conference Finals.

Myopic is on the same spectrum as Manic but it's hard to discern when energized, outward focus crosses over into subjective focus, narrowed squarely on the short-term. The short answer is that it's where you end up after years of burrowing into your business without lifting your head.  Myopia turns your vision inward and limits your upside.  It keeps you from making forward progress because you stay in protection mode so long that others start passing you by.  It's why your best employees start looking for new challenges somewhere else.  It's when you dismiss your competitors as inferior and out of touch.  It's when you start blaming people for not getting it.

And we private equity investors aren't immune to the sickness either.  When we see a solid winner and then stop investing, or when we start thinking about the exits too soon, we have become myopic.  It's when board meetings focus more on last quarter's profits than on next year's growth initiatives.  It's when budgets start to reflect the investor's guidance rather than management's intuition.  Or when we spend more time planning the board dinner than the content of the board meeting. It is hard to pinpoint when we have made the shift, but the symptoms are unmistakable.

So how do you make sure Mania survives without turning into Myopia?  Find yourself a touchstone, a yardstick to gauge your place on the manic-myopic spectrum--a shit-stirrer (as my friend Andy Stefonovich affectionately calls them).  This is the person who asks the tough questions; the person who makes you uncomfortable, who creates purposeful disruptions in your business.  This is the person who asks you, "When was the last time you visited a customer?" and, "What was the last failure you celebrated?" and, "What little bets are we going to make this year and how are we going to measure their success?"  Once you identify a shit-stirrer (in your business, on your board, a peer, CEO friend, or just a trusted outside observer), you can figure out where you stand with a simple question:  

Do you seek this person out and let them shake you up?

If you do, you’re still Manic. Your focus is still turned outward and you know their agitation is making you better for the benefit your customers and employees.  If you shut this person out, you are Myopic and you better fix it before it's too late.

Zuck's 3-dimensional chess game

Two billion dollars for Oculus.   I could not believe that Zuckerberg would pay that kind of money for a character from Mad Max 2: The Road Warrior.   Oops, turns out that the character in the movie was called the Humungus, not Oculus.  My bad.   

jmilbery.jpg

By all accounts, Zuckerberg is a very smart guy, much smarter than I am.  He's got to be playing some sort of 3-dimensional chess game with Facebook's future and all we can do is study his tactics and take a guess at his strategy.    Instagram for $715 million.   Not profitable, but they had lots of users and were encroaching on a function that Facebook deemed to be critical for the future of social media —photo sharing.   WhatsApp, nineteen billion dollars.   Again, not turning a profit, but the company had phenomenal user growth and a very strong international presence.   I can't see why it's worth nineteen billion dollars, but adding 450 million users to the FB empire seems like a smart decision. Facebook isn't exactly paying cash for them anyway.

Oculus, two billion dollars. 

Two billion dollars for what seems like a really fancy science project.  This is no tactic; this is strategy. It’s like when Bobby Fischer sacrificed his queen at the Rosenwald Memorial Tournament. It was an expensive move that offered no immediate gain. No one knew why he did it but, considering the player, no one walked out on the game. Only Fischer knew that he was making a play—taking on risk he deemed acceptable—to ultimately assume control of the board. 

Zuckerberg is seeing something that I don't.  Virtual reality is hard to do well and, even though Oculus has some very smart people working on it, I don't see the fit in the short term.   Therefore, Oculus must be a REAL long-term play for Facebook. 

That's the difference between venture investing and private equity investing.

Zuckerberg and company have to place big bets and risk making huge mistakes in order to control the future of big markets.   In the middle market we can't afford to make huge mistakes.   There are no white knights willing to pay billions for science projects in the middle market. Ours is a different game.   We're not playing 3-D chess in the middle market, we’re boxing.  It’s a sweet science that combines nuanced tactical action with straightforward strategy. Our long game requires us to win one round at a time— customer by customer —and I'm plenty tough enough to do that.

The Magical Kingdom of Venture Superlatives

Attacking the Big Boys

There was a great piece on Foursquare in yesterday's VentureBeat that I thought might be worth a quick word.   Not because I am particularly interested in FourSquare, (tried it a year or so ago and didn't find it all that appealing/useful/enjoyable).  It's interesting to me because the article is a great example of the use of uber-superlatives that are the bread and butter of venture-backed technology companies.    Let's start with the title of the article.   Foursquare's CEO (by all accounts a smart dude) was speaking at the Structured Data conference and he commented that Google and Yelp are "...incredibly broken...".   Now I'm no expert, but I've used both Google and Yelp in the context of mobile search and they didn't seem all that horrible to me.  The good news is that Foursquare offers a competing solution that is MAGICAL.    That's right, MAGICAL.  It's all black and white in the venture business.   Competitors are INCREDIBLY BROKEN and you are MAGICAL.

It's downright MAGICAL!

Since venture-backed companies are always swinging for the fences, it's vitally important that they make themselves the solution for a HUGE problem that isn't solved by the entrenched vendors (whether this is actually true or not).   You either need to capture a massive number of customers and become profitable, (Google, FaceBook, etc.) or you need to get big enough to scare the bejesus out of one of the big boys so that they buy you (WhatsApp, Instagram, etc.).   That's basically it.   You can't be a great solution for a small set of the market or a really good point solution for a niche market.  You have be solving a HUGE problem for a HUGE market that the BIGBOYS are failing to solve in a truly HORRIBLE WAY.    Thus, Foursquare is not just a better solution for mobile search, Google and Yelp are INCREDIBLY BROKEN.  

On the middle-market private equity side, we have investments in very profitable companies that serve smaller markets (i.e. thousands of customers) with really good products.   You can make great money without ever having to hope that you get swallowed up by a larger company -- because you aren't worried about running out of money.    A large percentage of venture-backed companies fail (40% by some counts).   I find that so hard to believe when their competitors are so HORRIBLY BROKEN and all of these fledgling startups are so MAGICAL.

-- Jim Milbery

WhatsApp Doc?

Jim's take on it.

Jim's take on it.

By now, everybody in the galaxy is aware that Facebook is paying some $19 billion in cash and stock for chat application vendor WhatsApp.   Congratulations, Sequoia.  Great exit for a great group of venture guys.  Congratulations to the WhatsApp team as well, $355 million per employee is a terrific outcome.  There will be a metric TON of folks opining on this deal from the win/loss perspective, so there is no need for me to belabor the point here.  I'd pay particular attention to anything that Mark Shuster writes on this topic, or anything that Dave Kellogg writes.    From the middle market, I look at this as a cautionary tale for several reasons.

For Founders -- it matters who owns you and who buys you.

There is no doubt that Sequioa was going to take this deal, $19 BILLION for a company that was MAYBE generating $350 million in revenues (best case) and no profits.   Did the founders want to sell?   Probably.  However, they famously eschewed advertising dollars, public marketing efforts and anything else that made them look like everybody else in the social media space.   They gave their users a free year of usage for WhatsApp and then charged $1/year after that.  Seems like they were very strong in the international market where SMS charges were expensive and WiFi access was cheap - so $1/year is a GREAT price.  But they weren't making any profits at a $1/year.   They sold the company to Facebook and you can bet your "likes" that Zuckerberg has plans for WhatsApp well beyond charging a dollar per year to those customers.  Zuck gave the WhatsApp founders a seat on Facebook's board as part of the deal.  That way they'll get a front row seat for the show.   The WhatsApp software has access to ALL OF YOUR CONTACTS.  The ultimate social graph.   Let the monetizing begin.  As founders they may no longer care what happens at a price of $19 Billion.  If they do care, well, the emperor knows that the rebel fleet ain't on Dantoine.  

For Middle Market Customers

WhatsApp isn't really a business-to-business software application - although it could be used that way.   The parallel here is that as a customer you need to be really careful about which applications you build your business around, especially venture-backed businesses.   Once the venture guys sell the company to a Google or a Facebook or an Oracle, things are going to change.   And they are going to change for the better of the new owners, not the customers.   So make sure that you have a backup strategy in place, because you may not be hapy with the new boss.  In real life it's not like the Who promised that it would be -- the new boss AIN'T ALWAYS LIKE THE OLD BOSS.


My reaction to this news is obviously "great for the team, great for the investors, great for Facebook because they really believe this is a game-changer for them."  Haters gonna hate but you won't hear any knocks from me on the team for giving up too soon or the VCs for pushing the exit.  What fascinates me about this story is how they got to this big announcement in the first place.

Devin's take on it

Devin's take on it

First, it starts with product.  WhatsApp's founders had a vision, they even taped it to their desks.  They were maniacally focused on product from the start -- it had to work, it had to be clean and it had to be fast.  That's it.  No flourishes, no extras.  Just a great solution that delighted its users.  Which it clearly does.

Second, it had to scale.  They built a product with 450 million customers with only 50 employees.  Sure, maybe that's simpler in the mobile app market versus the enterprise software market, but still . . . well done.

Third, they had to get in someone's way.  Strategic buyers don't go around buying companies anymore.  They buy products that either 1) cause them pain or 2) give them a return on investment.  WhatsApp wasn't causing FB a whole lot of pain yet, but Zuck is thinking 10, 20 years out.  And he has the control to do what he wants.  Control has always been on the top of his list even as a venture-backed CEO and now as a public company.

Fourth, have more than one interested buyer.  It's tough to run a successful auction when there is only one person in the room.  You can only get top dollar when you have competition and rumors are that Google was interested at about $10 billion.  A good banker can help get you that last bit of value and it looks like Morgan Stanley did their job for WhatsApp's team and investors.  But if you don't have the first three on this list, even the best banker can't magically create interest when there isn't any.

When it comes to programming languages, avoid the long tail

A brief diatribe on "long tails" in programming languages.

RubyMine IDE

RubyMine IDE

I was thinking about programming languages the other day, specifically about choosing one particular language over another.  And, whether I care which language any of our companies plan to use for a given project.   The bottom line is I don’t really care as different situations likely warrant different choices.  But I am cautious about two things.  First, I am careful about steering clear of languages that are getting a little too long in the tooth.   Second, I don't want to be too far out in front of the language.  The only thing worse than coding in a formerly-was-popular-language is maintaining code that was written in a never-was-popular-language. 

Let's talk about old code first. 

Take COBOL for example.  Yes, there have been tons of great upgrades and advances in the COBOL language in recent years. (Thank YOU, Grace Hopper).  But it's an OLD language, born in 1959. And sure, the folks at Micro Focus offer a pretty advanced, visual version of COBOL with tons of bells and whistles.  Heck, I would hazard to guess that you could probably build some fairly interesting things with their COBOL platform (maybe even RESTful interfaces for your web applications).  To be fair I actually don’t know, but I am assuming they have kept the language pretty current.  So why I would not want our companies developing in COBOL?  I think it’s pretty hard to get your hands on good COBOL developers.  I don’t see lot of kids coming out of college wanting to learn COBOL.  Nobody is banging a drum to say that COBOL is something that they want to learn.  So whether COBOL is effective or not effective for building a particular application does not really matter at this point. I would argue that writing a COBOL program and the logic layer for some RESTful web services interface would probably work just fine.  It’s a fairly powerful language but the problem is finding people that know how to do it and want to do it.  Clearly this is an extreme example.  You are unlikely to choose COBOL as a language unless your company has a huge ongoing inventory of COBOL programs to manage already.

For my part, I have written a lot of CFML (Cold Fusion) over the years.  Not good code mind you, but code nonetheless. My friend and compatriot Alan Willamson cringes when he hears me say "programming in Cold Fusion", because I write a lot of crap.  Mostly throw away stuff, proof of concept stuff, the kind of code that shouldn’t be checked into SVN.   There continues to be ongoing investment in the CFML language, and not just from Adobe, but from a number of open source teams.  In fact, Alan and the rest of the BlueDragon guys have done a great job of providing an open source platform for CFML.  It's fast, it's free, and there is a ton of functionality built into the platform.  Still, I don't see too many newbie developers hankering to learn CFML.  For me, it's a go-to language for getting something done quickly.  BlueDragon is written in Java, and I can write Java code directly in a script block in CFML.  So it’s definitely the language I tend drop into when I have to do something incredibly quick.  (Ok, ok, I sometimes us Transact-SQL for similar, albeit uglier, purposes if there is data involved).  

 Powerbuilder, it's like your dad's rock music, only much, much worse

Most people aren’t going to want to program in CFML anymore and it has nothing to do with the capabilities of the language.  In the right developer's hands, you can use CFML for a data access layer and restful web service business logic layer and you can do some dynamite things with it.  It’s got enough object oriented capabilties to allow you to write code in a modern way.  (We can get into a whole other academic argument about this last point, but let's not and just say that we did).   So while CFML is still a powerful language, I'd really worry about how easy it is going to be to find developers that want to write CFML.  (And yet, we have a number of large scale CFML projects in our portfolio).   There are a whole bunch of dead languages that once had a massive following that I'd throw into this same category.  (CFML isn't there yet, but it is probably headed there).  Anybody remember PowerBuilder? It was clearly the dominant programming language of the go-go client/server days, maybe not as dominant as COBOL once was in the 70s and 80s, but close.  You can still buy PowerBuilder, it’s even got enhancements to handle server-side development. The thing is, who wants to program in PowerBuilder anymore?  When I am in a meeting with 25 year olds, most of them haven't ever even heard of PowerBuilder.   Much like kids don't want to listen to their parent's music, most developers don't wany to program in their parent's programming language.  Younger developers want something new.  Whether it’s better or not it doesn’t matter.  You can make favorable arguments in favor of a bunch of different "old" languages as far as feature/function is considered.   But as Bill Murray once yelled out in "Meatballs", It Just Doesn't Matter.  New developers are going to choose C# over VB.Net (even though both languages get access to the same set of features via Microsoft's CLR).  That battle is over.  To be fair, Visual Basic and the grandaddy of them all, "C", stil rank fairly high in Tiobe's programming language popularity chart. In the case of "C", I'd argue that system software still tends to be written in "C", so it will always have a following.   In VB's case, I'd argue that it's the long tail of legacy applications. Since software applications can have a fairly long life, programming languages tend to have a very long tail.  Nobody's really writing new stuff in them anymore, but there is still a ton of old software that needs to be maintained.  

New kids on the block

On the other end of the scale are new languages that might or might not catch on, such as Google Dart.   (Again, dear reader, I am not arguing either for or against Dart, just making the point that it is a relatively new language/platform and therefore does not have a large following of well-trained developers as compared to Java or PHP or Ruby as of this writing).   New developers don't really want to program in old languages, and I don't really want new developers building applications on a language that might not live very long.   There is nothing worse than having to maintain lousy code written in a language that never really caught on.   Dart could end up being the next PowerBuilder, or the next Ruby.  (But it might be the next Ada).   The problem with new languages for mid-market companies is cost.  The laws of supply and demand dictate that when you have a short supply of something (i.e programmers that know DART) then it's going to be really expensive to pay those people.   And you're going to get outbid by the larger corporations and the venture-backed companies in Boston, Austin and San Francisco for DART talent.


The other problem with the leading edge is that you still have lots bugs (or missing features) in these products.  You are still "debugging" the language to some degree. They can't do certain things (like maybe connect to your favorite database).   So you end up waiting around for the "complete solution" as Geoffrey Moore would put it.   Furthermore, most new languages lack a set of well-understood "best practices" early on in their lifecycle.  The code that you write might end up needing to be rewritten to achieve scalability or reliability.  The bottom line is that I don't want to skew too far back or too far forward when it comes to programming languages.  You don’t get the benefits out of being out on the edges -- at least in the middle market. Beyond that, I don't really care.

In the end, you have to make a choice

 I tend to skew toward open source languages these days (or really low cost languages at the very least).  PHP, Ruby, Python, Java and JavaScript are all good choices.  (Let's leave frameworks and libraries for another discussion -- that's right, I'm talking to you Node.js).  All of these platforms are relatively hot, so kids coming out of school know them, people are interested in coding in these languages and yet there is mindshare around them so that you can build a decent platform doing it.  What about proprietary languages, C# or Objective-C?  Well, if you are already a heavy Microsoft shop and plan to stay that way, then I'd say have at it with C#.   With Objective-C it's a little more complex, because you are unlikely to write server-side code on the Apple platform.  If you want to write iOS applications, then you are going to have to write in Objective-C, but you will also be writing code in at least one other language.    

Personally, if  I had to start something new today for a "greenfield",  would I code to the Microsoft platform?   Probably not.  

In summary,  I am sure I am going to be flamed all over the place by everybody with an axe to grind for disrespecting their favorite language.  Remember, I am not arguing the point that one language is better than another, or that one platform is superior to another.  And let's leave a more detailed discussion of task-specific-solutions, such as "R", for another day.   If it can do the job and you can easily find people to write the code, well, then that's good enough for me.

But if the only folks that can program in it still remember 300 baud modems, or only five geniuses in the world are familiar with it, then I'd politely suggest that you might want to consider something else.

If I was going to start building something new?  Java and C# are fine choices.  Ruby seems to be going up and down in popularity, but I'm having lots of fun tinkering with Ruby.  My one bias against Ruby is that our hometown of Chicago is the hub of the Ruby-on-Rails mafia -- where Ruby is the solution to any problem.    Python seems to be on everybody’s short list.  Google's a big Python shop, and all of the things you can do with the Google App Engine integrate easily with Python.   Generally speaking, open source tends to be a better choice if you have got a green field because all of your cloud-based platforms are supporting any number of open-source programming stacks.  

Just try not to be too far out on the edges.

-- Jim Milbery