Five Rules for Competing with Giants

I’ve spent my career competing, for the most part successfully, against companies from 10 to 1,000 times bigger than my own.  Thus, over the years, I’ve developed some rules that can help maximize your odds of success when competing against giants.

  • Concentrate force.  The easiest way to be bigger than your competitor is to focus.  While Oracle was around 100x our size when I joined Business Objects,  our BI team was bigger than theirs; in 1995, we had nearly 300 people who did nothing but BI.  Focus can be about either product or market.  At Mark Logic, I believe that Endeca is around 2-3x our overall size, but by my estimation Mark Logic is 3-4x bigger than they are in our core markets of media and government.  While Autonomy is more than 10x our overall size, I believe that we may be bigger  in media and government (for relevant use-cases), and I’m nearly positive that we’re bigger in the dead center of our markets:  STM in publishing and intelligence in government.  Focus is hard because there are always people who are more obsessed with the opportunities you’re not pursuing than with those you are, so have a clear sense of your growth goals, decide rationally if you can meet them with your chosen focus areas, and then jettison those who can’t get with the focus program.
  • Be the best.  I like to say that no sane person wants to buy software from a startup.  Most IT folks sleep much better at night buying from the mega-vendors, even if they feel like they’re getting gouged on price.  People buy from startups not because they want to, but because they have no choice.  How can you give people no choice but to buy from you?  Solve one problem better than anyone else in the world.  Those are easy words to say, but they’re very hard to do.  Ask yourself:  what is the one problem that we can really solve better than anyone else in the world.  That’s what the VC cliché “world class” means.  Most startups aren’t honest with themselves in this department; they tell themselves white lies about where they can realistically be the best.  The result is they overextend and end up with three or more mediocre products instead of one great one.  Sometimes this is driven by greed for more addressable market; sometimes it’s driven by fear and the desire for diversification.  Remember the Andrew Carnegie quote:  put all your eggs in one basket and then watch the basket.
  • Split pins.  Most technology strategists are familiar with Geoffrey Moore‘s “bowling alley” model which says that startups should view markets as bowling pins, using one market to knock down the next.  This model encourages startups to skip through markets hastily, like American travelers skipping through countries in Europe (e.g., If this is Tuesday, it must be Belgium).  Instead of skipping pins, startups should split pins.  Without sounding too cosmic:  look for micro-alleys within bowling pins.  When I started at Mark Logic, I thought “publishing” was a pin and that all publishers were basically the same.  When I focused on publishing and looked not just for similarities among publishers but also differences between them, I learned that STM, education, news, market research, credit/financial, legal, trade, and B2B publishers were all different.  I like to say that all beagles look the same unless, of course, you’re a beagle.  By splitting pins instead of skipping them, you learn more about your customer’s needs, can serve them better, and — best of all — typically discover that the market you were about to skip over is about 10-100x bigger than you originally thought.
  • Hire stars.  Giant-fighting startups are not places for the weak or mediocre.  You need a team of aggressive, high-energy people who understand the mission and are ready to make the sacrifices required to win.  High-growth startups are lousy places to learn on the job.  That’s why the VC model gives nice chunks of equity to experienced managers with safe jobs in big companies.  They want to lure them into the startup and compensate them for the risk in so doing.  In the end, VC’s are not risk takers; they are risk eliminators.  They try to isolate all risk to the fundamental innovation and do so by setting every other lever of the business to standard. (See Chris Dixon’s recent post, Don’t Be Creative About the Wrong Things, for more.)  That’s why you need to build an A-team and be sure the people on it are scaling with the company.  Rest assured, even if you’re not asking the “can they scale” question about your team, the board is asking it about you.
  • Work together.  I’ve seen too many startups with divisive, prima-donna-laden cultures where staff meetings devolve to finger-pointing contests.  “I was the top salesperson at SAP and I can’t sell this stuff unless it works.”  “Well, I was the smartest guy at Harvard and my technology is so wonderful that a monkey could sell it.”  On and on.  This doesn’t work.  When you’re competing with giants you need the extra advantage that comes from brilliant people — working together — to solve problems.  All of us, when working in a functional group, are indeed smarter than one of us.  It took years to get this lesson through my head.  I first got it doing an exercise at a leadership program where each individual rank-ordered a list of items required for wilderness survival.  Then we broke in about 8 groups of 6 and re-did the exercise.  The worst group score beat the best individual’s score, and one of the individuals was a Brigadier General in the US Army.  Years later I discovered The Wisdom of Crowds and learned it again.  While it may sound hokey, teamwork is an amplifier of talent.  That’s why All-Star teams don’t do well in sports:  while each individual may play superbly; they just don’t play together.

Veterans vs. Up-and-Comers in Startups

The conventional Silicon Valley /  venture capital (VC) wisdom is that startups should not bet on first-time managers in just about any position, but particularly at the executive team level.  It’s best captured by the statement:  a high-growth startup is not the place to learn how to do your job.

This is the conventional wisdom because, while counter-intuitive to some, VCs are not actually risk-takers, they are risk-isolators.  A typical VC is trying to isolate risk down to one thing:  the unique value proposition behind the startup.  Those value propositions can vary considerably:

  • Sometimes, it’s about the technology.  Mark Logic, for example, is a technology disruptor.
  • More in vogue these days, it’s about the business model.  Salesforce disrupted the on-premises, perpetual license business model with SaaSMySQL disrupted the traditional license model with open source.
  • Sometimes, it’s about both.  My friends at Clearwell will rent you an appliance that includes an innovative e-discovery application.

But the point is that VCs are trying to isolate risk down to the one key value proposition.  They do that by setting every other lever in the business to standard.  For example, per the conventional wisdom, a SaaS BI business model disruptor should:

  • Hire standard managers with experience in big BI companies, and use equity to lure them from their cozy jobs.
  • Develop a standard BI application/product that contains the features users expect.
  • Build a standard enterprise sales force, hiring salespeople from the established BI vendors
  • Implement a standard BI partnering strategy, with the usual suspect technology and systems integration partners
  • Devise a standard marketing strategy, typical of those used by other BI companies but with a key emphasis on the unique value proposition.

Like most VC wisdom, at the first order the approach makes a lot of sense.  At the second order, however, it presents some problems.

  • It encourages cronyism, where the first such experienced manager knows a whole clan of other folks who also are looking for jobs, often for the same reason he or she was (e.g., recent of acquisition by Oracle, a new CEO, a strategy shift).  While one of the benefits of hiring experienced managers is undoubtedly their networks, I’ve seen this work out both quite well and spectacularly badly.    The key issue boils down to whether you are hiring drivers or passengers.  Was the company from which you’re hiring successful because of these people, regardless of these people, or indeed in spite of them?  Are you hiring real results drivers or people who, Fooled by Randomness, have great resumes and think very highly of themselves, but who are incapable of solving your company’s problems?
  • This cronyism often creates a divisive environment that drives out your top existing talent.  As the “Company X” mafia takes over, they typically show insufficient respect for those who got the company where it is, ridicule some past practices, and talk boisterously how easy it’s going to be to fix all this.  While problems in operational practices are easy to spot and fix, this approach overlooks the startup’s need for process maturity (e.g., size relative to Company X) and the startup’s strategic position in its market.  I remember when the experienced (manufacturing-oriented) managers from ASK took over Ingres (then a ~$200M company) and decided that implementing a heavyweight quality process was the answer to our problems.  In reality, our problem was strategic:  in a land-grab market we’d made some poor technology choices (e.g., Quel vs. SQL) that hampered sales and we had been too conservative about grabbing land.  Just as the Ingres executive team’s only hammer was technology, the ASK executive team’s only hammer was process.  Neither, unfortunately, was called for given the company’s situation.
  • It limits career growth for talented up-and-comers within the company:  either individuals with management potential or existing managers with executive staff potential.  If every new management job will be filled by an experienced outsider, then insiders quickly feel trapped and unable to advance in their careers, making them — particularly the more ambitious ones — more likely to leave the company.

The answer to managing all this is, of course, balance.  Both the CEO and the executive team need to take some calculated risks in betting on up-and-comers in a number of posts.  This generally will cost the CEO some political capital (debited at promotion time and never credited back, even if the up-and-comer is highly successful), but will help him or her retain both institutional memory and some key people for the future of the company.

Having a stronger-than-usual preference for up-and-comers, I’ve developed a few rules for managing this process.

  • Always do a external search.  You can turn the dial on how hard — from a check-the-network or calling a few contingency recruiters all the way up to a retained search — but you should always expend energy to see “who’s out there” so you have a sense of the market in making the veteran vs. up-and-comer decision.  You owe this to yourself, your board, and your shareholders.
  • Run up-and-comers through the same process as the external candidates.  The only exception here is when you are restructuring in which case many people may be changing roles without following an interview process.
  • Keep a mental balance of how many up-and-comer chits you have used and how many you think you have left.  You need to view them as a scarce resource, because they are.
  • Ensure the up-and-comer is “all in.”  If you are going to bet political capital on someone they can’t either be [1] telling you what you think you want to hear or [2] be unsure of whether they can do the job.  You should only bet on up-and-comers who are certain they can be successful, and so certain that they will probably quit in the not-too-distant future if not offered opportunities.
  • Limit up-and-comers’ ability to bet on other up-and-comers.  Force them to prove they merit their posts by demonstrating how they can bring in veterans.  This is a both a solid practice and a great test.  The worst outcome is that your up-and-comer hires no veterans for his team and you end up with a whole multi-level hierarchy of inexperienced people.  (I’ve seen this happen, too, though happily not in my department and it’s one heck of a mess because there is typically no organizational awareness that anything’s even wrong! )

The Database Tea Party: The NoSQL Movement

Adam Smith’s invisible hand never rests.  Just five years ago, the database market looked like a static, three-player $10B/year oligopoly where the primary forces were inertia and profit-taking.  Today, we have two major forces disrupting the comfortable stasis that has developed over the past 30 years.

  • One force is DBMS specialization:  while the general-purpose RDBMS is useful for a broad range of applications, it is optimal for few of them.  The RDBMS has slowly become expensive bloatware that is functionally a jack of all trades, master of none.  MIT’s Michael Stonebraker calls the RDBMS a one size fits all solution.
  • The other force is NoSQL, an organic and rapidly-growing industry movement away from relational databases, driven by a number of factors including both technology and cost.

The purpose of this post is to share my thoughts on NoSQL.  Make no mistake, like the Tea Party Movement, NoSQL is a rebellion; just look at the name.  But like most demonstrations, not everyone is marching for the same reasons.  Here are some of the things I think various members of the NoSQL crowd are marching against:

  • Table-oriented, 1960s-era database technology:  RDBMSs were designed for handling data and short-text fields, necessitate mapping programmatic objects to tables (i.e., the impedance mismatch), and require the use of an increasingly stone-age query language, SQL.
  • Scalability:  relational databases were not designed to handle and do not generally cope well with Internet-scale, “big data” applications.  Most of the big Internet companies (e.g., Google, Yahoo, Facebook) do not rely on RDBMS technology for this reason.
  • High prices and the heavy-handed treatment of customers:  both stem from the underlying oligopoly and the lack of credible alternative suppliers
  • Closed source:  the inability to customize the internals of the DBMS engine to meet specific needs
  • Bloatware:  ironically that while RDBMSs are perceived as light in requirements that matter (e.g., scalability), they are  also seen as over-engineered for features that don’t.  (ACID transactions are a favorite target in this department.)
  • DBA supremacy.  For years, corporate DBAs called the shots on where strategic data assets would be stored, and thus how they would be accessed.  This created headaches for the programmers of the world who, in response, have done as much as possible to abstract away the database (e.g., Ruby on Rails).

On the flip side, there are things the NoSQL crowd are fighting for:

  • Open source, implying control.  The ability that open source software provides to customize product functionality.
  • Open source, implying free.  The often-flawed notion that the absence of software license fees results in a reduced lifetime cost of ownership.
  • Coolness, or the “I want to be like Google” effect.  If Google’s got BigTable,  Yahoo’s got Hadoop, and Facebook’s got Cassandra, then we should build our own, too.  Our app is hard; we’re smart guys, too.
  • Vengeance, or the “I’m so mad at Oracle that I’ll do anything” effect.  Yes, some folks are just plain mad enough at Oracle to either go write their own DBMS, or take on the support of a very low-level infrastructure technology.

So, if you’re considering a NoSQL solution — a class in which I include MarkLogic — you need to figure out what you’re marching against, what you’re fighting for, and ultimately what will meet your needs at the lowest total cost of ownership.

My first recommendation to detect and, where applicable, kill off the coolness effect.  Google is swimming in money and PhDs.  They can build anything they want regardless of whether they should and, right or wrong,  for Google it just doesn’t matter.  So unless you have Google’s business model and talent pool, you probably shouldn’t copy their development tendencies.

Heck, I get the coolness attraction.  I think infrastructure software is cool, too.  That’s why I was an OS geek early on and have spent my career around databases.  But I surely don’t think that F1000 companies and government agencies should build their own DBMSs, nor fall into the trap of thinking that open source low-level stores are a free and easy way to avoid Oracle license fees.  Cool shouldn’t be in the equation.  Technology suitability and total cost should be.  Period.

My second recommendation is to orthogonalize the open source question, making it independent of functional requirements.  (This breaks if source customization is a requirement, but remember that requirement is often fictional:  most open source users don’t customize.)  If you’re struggling with an RDBMS on a given application problem you shouldn’t say:  we need an open source, NoSQL type thing.  You should say:  we need to look at relational database alternatives.  Those alternatives include a open source database projects (e.g., MongoDB, CouchDB) and distributed computing frameworks (e.g., Hadoop), but they also include commercial software offerings such as specialized DBMSs like Streambase (for real-time streams), Aster (for analytics on big data), and MarkLogic (for semi-structured data).  Don’t throw out the commercial-software-benefits baby with the RDBMS bathwater.

My personal take on this issue is that:

  • Relational databases, like the mainframe in 1985,  are entering the Autumn of their lives.  They won’t die quickly and mainframe isn’t dead today, but their best days are behind them.
  • Our kids will see SQL the way we see COBOL.  Some people can’t stand when I say this, but I think they’re in denial.  There is no logical reason to assume that the relational database and the SQL language are the endpoints in database evolution.  Yes, Larry Ellison is powerful.  But Adam Smith is more so.
  • Our kids will see no data/document dichotomy.  They will just see digital information.  We need to understand and remember that the data/document dichotomy is an artifact of the limitations of the tools and technologies with which we grew up.
  • Some of the NoSQL hype is an over-reaction to the database oligopoly.  I believe there are organizations out there who should be using alternative commercial databases, but instead are using open source NoSQL-type projects due to coolness, anger, or a mistaken belief that open source always has a lower total cost of ownership.  I believe rationality will return to these people.  One day management will say:  “Holy cow!  Why in the world are we paying programmers to write and support software at this low a level?”  (This is potentially avoidable if you can mentally project yourself into the future now and imagine how you will look back at the coming three years.)
  • Some of the NoSQL hype is a valid reaction to the technological limits of relational databases and the impedance mismatch in programming on them.

In the end, I think it’s great that the NoSQL movement is happening.  It’s awakening people to traditional RDBMS alternatives.  It’s making people understand that they don’t have to write big checks for commodity software.  It’s helping people solve problems that they can’t solve, or solve efficiently, on relational technology.

My axe to grind is simple:  just because you’re throwing out Oracle, don’t throw out all DBMSs and all commercial software with it.  Take a breath.  Look at all your alternatives.  Study total costs and technology applicability.  And make your best decision.

Interesting Writings on NoSQL

How To Make a Great Corporate Blog

I’m happy to report that Kellblog was featured prominently in a story yesterday on Business Insider entitled How To Make An Awesome Corporate Blog.

I provided the first tip: throw “corporate” out the window.

That’s because,definitionally, I don’t think there are great corporate blogs. There are only great corporate bloggers.

  • If you really want a “corporate” blog, try a “news and events” RSS feed instead. It will be less work and more directly meet the information need.
  • If you want a ghost-written CEO blog, stop. It won’t work. Give it up. (And read this post for more.)
  • If you want coverage in the blogosphere, appoint smart people to engage with existing blogs/bloggers by commenting.
  • If you really want your message, or some aspects of it, out through blogging, then find one or more people in the organization with the skill, time, and desire to write a blog that will indirectly benefit the company. For example, Timo Elliott at SAP writes such a blog, BI Questions.

The complete tip list is:

  • Throw corporate out the window
  • Who should write the blog? Everyone
  • Your content should go beyond your business. (I get cited here as well.)
  • A blog is not about marketing (but good ones can end up doing just that)
  • More content guidelines
  • Get personal
  • Encourage customer interaction
  • If you can’t do these points, then don’t have one
  • Awesome blogs to check out

I get another nice excerpt in the middle.

Whatever you do, your blog should not be “an advertisement for the company or a regurgitation of company news and press releases,” Kellogg warns.

The full story is here. For those really interested in corporate blogging, you should check out what Debbie Weil has to say on the subject.

Coming Friday 1/29/10: Kellblog!

As I have discussed a few times in the past, I want to rename the Mark Logic CEO Blog in order to accomplish a few goals:

  • Get a shorter, pithier name that will be easier for people to write and talk about
  • Get a more normal, blog-like name that will hopefully increase citations and in-bound links
  • Get a name that better reflects the content of the blog. While the blog certainly contains some pro-Mark-Logic posts, the majority of the content is not typical “corporate blog” fodder

Toward these ends, I am pleased to announce that on Friday, January 29th, 2010, the Mark Logic CEO blog will become Kellblog.

  • Site readers will automatically be redirected to the new domain: www.kellblog.com
  • Feed subscribers using the proper Feedburner feed will need to do nothing, since — for the time being — the feed address will remain http://feeds.feedburner.com/marklogic. (At some future point, we’ll switch the feed, but we have plenty of other work to do first.)
  • On Friday, February 12th, 2010, I intend to cutover to a fresher, crisper, simpler design to provide the blog with a new, and more contemporary, look.
  • I also intend to switch work-related tweets to a new account @kellblog, as opposed to my original Twitter account @ramblingman, from which I no longer expect to tweet. So, please follow @kellblog right now!