How all these unprofitable companies sustaining high valuations:
bending reality today has three elements: a vision, fast growth, and financing.
A few firms other than Amazon have defied the odds. Over the past 20 years Las Vegas Sands, a casino firm, Royal Caribbean, a cruise-line company, and Micron Technology, a chip-maker, each lost $1bn or more for two consecutive years and went on to prosper. But the chances of success are slim. Of the current members of the Russell 1000 index, since 1997 only 37 have lost $1bn or more for at least two years in a row. Of these, 21 still lose money.
The single biggest one is the move to public cloud, and this is where Docker is focused today. This is the number one area that we are putting all our investment in. We have this great container platform that allows you to do a lot of things, but just like any company, we need to pick an area of focus and for us, helping customers take legacy apps, moving them to the Docker platform, and allowing them to run it on any infrastructure because it’s hybrid cloud world, does a couple of things — it drives massive savings for customers, typically 50 percent cost reduction in a cost structure, but it also opens up real opportunities for the customer and our partners to innovate within that environment
Also, this is an insanely good example of a fluffy leather chair conference interview, plus, The Channel filter.
Where does the 50 percent savings come from? A few different areas. The biggest is, honestly, in the mass reduction in number of VMs [virtual machines] and that’s not good or bad, it’s just the reality. The other is that there is a massively increased density factor on compute, and so we can put a lot more workloads on a fewer number of servers. If you are a [company like] Nestle, and you are going to take a bunch of information and business systems and move it to the public cloud, doing a one-to-one move is not necessarily all that advantageous.
When I joined Docker I had a good conversation with someone over at Microsoft that said ‘I’d love to partner with you.’ His view was, the more people move to Docker, the more business they get on Azure. In fact, for every dollar we generate, he generates $7.
Momentum and the EBIT(A) chase:
we’re growing at 150 percent-plus year over year and expect that to continue for at least another few years. I’m hoping to get to profitability in mid-2019, and that’s important
I was CEO of the Wireless Industry Association and I was proud of the job that I did. But the least proud moment of my public policy life was when I opposed the commission’s efforts to allow people to take their phone numbers with them when they switched from, say, AT&T to T-Mobile. [When arguing against this policy], I couldn’t go out and say, “We think it’s a really bad idea because in the current situation consumers are trapped with their carrier and can’t leave us without giving up their phone numbers.” That’s not a real winner. So the argument I made was, “This is going to take money that should be spent on infrastructure and expanding connectivity.” I regret that argument. Saying, “It is going to slow down our incentive to invest,” is everybody’s first line of defense. It’s balderdash. The reason you invest is to get a return. Companies don’t say, “Well, I’m not going to invest because I might trigger some regulations.” Their question is: “Am I going to make a return off of this?” Broadband is a high-margin operation. You can make a return off of it. The facts speak for themselves. Since the Open Internet rule was put in place, broadband investment is up, fiber connections are up, usage of broadband is up, investment in companies that use broadband is up, and revenues in the broadband providers are up, because people are using it more.
– Tom Wheeler
There’s two good points here:
1. When people have a high churn rate between services, it may be annoying from a “lazy”/predictable perspective, but it means there’s more chances to sell old and new things to them when they switch.
2. Complaints from companies that amount to “this new regulation/tax/etc. will make us not want to invest” are largely crap. Companies have to invest in new businesses or they die. Whatever the friction, they’ll figure it out, and if they can’t, they can die so that new players can have a go. Businesses don’t need to be eternal.
At the top of the year, companies are setting their IT agendas. Most high level executives seem to be lusting for “digital transformation,” but that phrase is super-squishy. In my Register column this month, I offered my advice on what it should be: simply “digitizing” existing, manual work-flows by perfecting how you do software.
This, of course, is the core of what I work on at Pivotal; see my wunderkammer of knowledge, the soon to be PDF’ed “Crafting your cloud native strategy,” for example.
What do these opportunities look like in businesses? Here’s a chunk that cut out of the piece that provides some examples:
A project to “digitize” the green card replacement program in the US provides a good example of the simple, pragmatic work IT departments should be curating for 2017. Before injecting software into process it’d “cost about $400 per application, it took end user fees, it took about six months, and by the end, your paper application had traveled the globe no less than six times. Literally traveled the globe as we mailed the physical papers from processing center to processing center.”
After discovering agile and cleaning up the absurd government contracting scoping (a seven year project costing $1.2bn, before accounting for the inevitable schedule and budget overruns), a team of five people successfully tackled this paper-driven, human process. It’s easy to poke fun at government institutions, but if you’ve applied for a mortgage, life insurance, or even tried to order take out food from the corner burger-hut, you’ll have encountered plenty of human-driven processes that could easily be automated with software.
After talking with numerous large organizations about their IT challenges, to me, this kind of example is what “digital transformation” should mostly about, not introducing brain-exploding, Minority Report style innovation. And why not? McKinsey recently estimated that, at best, only 29% of a worker’s day-to-day requires creativity. Much of that remaining 71% is likely just paid-for monotony that could be automated with some good software slotted into place.
That last figure is handy for thinking about the opportunity. You can call it “automation” and freak out about job stealing, but it looks like a huge percentage of work can be “digitized.”
Check out the full piece.
“Too often, organizations are myopic. They only look for growth in the customer base they already serve. But by looking for nonconsumers and exploring what they are trying to accomplish — rather than focusing on their personal characteristics, purchasing patterns, or product preferences — organizations can discover the potential for new growth.”
The Docker forking hoopla is providing an interesting example, in realtime, of how open communities figure out monetization.
#RealTalk: Open communities are not immune to C.R.E.A.M.
One of the most important decisions an open source community makes is where and how it will make money. I always liked Eclipse’s take because they’re mega clear on this topic; the ASF plays this goofy game where they try really hard to pretend they don’t need to answer the question, which itself is an answer, resulting in only the occasional quagmire; Linux has a weird situation where RedHat figured out This One Cool Trick to circumvent the anti-commercial leanings of the GPL; MySQL has a weird dual licensing model that I still don’t fully grasp the strategic implications of; RIP Sun.
The role of standards plays another defining role when it comes to monetization. Think of Java/J(2)EE, vs .Net, vs PHP (a standard-less standard?), vs HTML and WS-*. vs, the IETF/ISOC RFC-scape that defines how the internet works. While not always, by far, standards are often used tactically to lesson the commercial value (or zero it out completely) of any given component “lower” in the stack, pushing the money “up” the stack to the software that implements, uses, or manages the standard. Think of how HMTL itself is “of no value” (and was strategically pushed that way early on), but that the entire SaaS market is something like a $37.7bn market, part of the overall $90.3bn that, arguably, uses HTMLas one of the core technologies in the stack, at the UI layer, (along with native mobile apps. now).
The dynamics of how open source, standards, and the closed source around it are defined and who “controls” them are one of the key strategic processes in infrastructure software.
The Docker ecosystem is sorting out monetization
Right now, you can see this process in action in the Docker ecosystem. Product management decisions at Docker, Inc. are forcing the community to wrestle with how ecosystem members will make money, including Docker Inc. itself.
By “ecosystem,” I mean “all the people and companies that are involved in coding up Docker and/or selling Docker-based products and services.” Actual end-users play a role, of course, but historically don’t have as much power as we’d like at this stage of an open communities formation.
End-users have to vote with their feet and, if they have one, wallets – whether wearing expensive loafers (enterprise) or cracked sandals (paying with nothing but the pride of ubiquity) – which, by definition, is hard to do until a monetization strategy is figured out, or completely lumped all together.
Looking just at the “vendors,” then, each ecosystem member is trying to define which layers of the “stack”‘will be open, and thus, free, and which layers will be closed, and thus, charged for. Intermixed with this line drawing is determining who has control over features and standards (at which level) and, as a result, the creation of viable business models around Docker.
Naturally, Docker, Inc. wants as big slice of that pie as possible. The creator of any open technology has to spend a lot of nail-biting time essentially deciding how much money and market-share it wants to give up to others, even competitors. “What’s in it for me?” other vendors in the ecosystem are asking…and Docker Inc.’s answer is usually either some strategic shoe-gazing or a pretty straight forwardly the reply “less than you’d like.”
As a side note, while I don’t follow Docker, Inc. as an analyst any more (so I’m not mega up-to-date), it seems like the company consistently puts the end-users first. They’re looking to play the Tron role in this ecosystem most valiantly. This role doesn’t, really, conflict at all with elbowing for the biggest slice of the pie.
Similar to Docker Inc’s incentives to maintain as much control as possible, the “not-Docker, Inc.” members of the ecosystem want to commoditize/open the lower levels of the stack (the “core”), and leave the upper layers as the point of commoditization. This is the easiest, probably most consistently successful business model for infrastructure software: sell proprietary software that manages the “lower,” usually low cost to free, layers in the stack. From this perspective, not-Docker, Inc. members want to fence in the core Docker engine and app packaging scheme as the “atomic unit” of the Docker ecosystem. Then, the not-Docker, Inc.’s want to keep the management layer above that atomic unit for themselves to commercialize (here “orchestration,” configuration management, and the usual systems management stuff) . But, of course, Docker Inc. is all like “nope! That’s my bag o’ cash.”
And while I personally consider the orchestration layer the key to the container paradigm, the right approach here is to keep the orchestration separate from the core container runtime standardization. This avoids conflicts between different layers of the container runtime: we can agree on the common container package format, transport, and execution model without limiting choice between e.g. Kubernetes, Mesos, Swarm.
We saw similar dynamics – though by no means open source – in the virtualization market. VMware started with the atomic unit of the hypervisor (remember when we were obsessed with that component in the stack and people used that word a lot?), allowing the ecosystem to build out management on-top of that “lower” unit.
Then, as VMware looked to grow it’s TAM, revenue, and, thus, share price and market-cap, it expanded upward into management. At this point, VMware is a, more or less, the complete suite (or “solution” as we used to call it) of software you need for virtualization. E.g., they use phrases like “Software Defined Datacenter” rather than “virtualization,” indicative of the intended full-scope of their product strategy. (I’m no storage expert, but I think storage and maybe networking?is the last thing VMware hasn’t “won” hands down.)
“What, you don’t like money?”
All of this is important because over the next 10-15 years, we’re talking about a lot of money. The market window for “virtualization” is open and wildcatters are sniffing on the wafting smell the money flitting through. Well, unless AWS and Azure just snatches it all up, or the likes of Google decides to zero the market.
We used to debate the VMware to Docker Inc. comparison and competitive angle a lot. There was some odious reaction to the idea that Docker Inc. was all about slipping in a taking over VMware’s C.R.E.A.M. At one point, that was plausible from a criss-cross applesauce state of the market, but now it’s pretty clear that, at least from an i-banker spreadsheet’s perspective, VMware’s TAM is the number your doinking around with.
Figuring out that TAM and market size gives you a model for any given ecosystem member’s potential take over the next 10 years. That’s a tricky exercise, though, because the technology stack and market are being re-defined. You’ve got the core virtualization and container technology, then the management layer, and depending on if you’re one of the mega-tech vendors that does software and hardware, you’ve got actual server, storage, and networking revenue that’s dragged by new spend on “containers,” and then you’ve got the bogie of whatever the “PaaS-that-we-shall-not-call-PaaS” market becomes (disclaimer: that’s the one I work in, care a great deal about, am heavily incentivized to see win, and am rooting for – roll in the bias droids!).
I skipped figuring out the market size last year when I tried to round-up the Docker market. Needless to say, I’d describe it as “fucking-big-so-stop-asking-questions-and-ride-the-God-damn-rocket.”
Looking at it from a “that giant sucking sound” perspective, most all of the members in the Docker ecosystem will be in a zero-sum position if Docker Inc moves, and wins, the upper management layers. Hence, you see them fighting tooth-and-nail to make sure Docker Inc is, from their perspective, kept in their place.
[T]he art of strategy based upon situational awareness remains one of those topics which are barely covered in business literature. The overwhelming majority depends upon alchemist tools such a story telling, meme copying and magic frameworks like SWOTs. It is slowly changing though and every day I come across encouraging signs.
Other than the “why don’t you tell me how you really think” tone there at the end (hey, I clearly have nothing wrong with that kind of dismissive style), that fits my experience working on strategy.
Your strategy team is forced to freeze time at the launch of the process, looking at their industry as an unchanging process (value chain diagrams, anyone?). As most strategy work takes 3-6 months at best (if not a year to year and half to fit into the corporate budget cycle and then get through The New Years hang over: no one really starts working again until February, then the business units have to plan, allocate budget, and execute), you’re behind: you’re looking at an understanding of the world that’s around a year out of date.
Worse than this, strategy teams are rarely given the tools (time, money, authority, and staff) to actually test out any theories, let alone learn from adapt the results of those tests. There’s no room for OODA/PDCA/lean startup, small batch thinking20.
Centralized strategy in a large company is weird in how unhelpful it can be for industries that are constantly changing or threatened by competitors. Like so many other corporate functions, the fix looks to be shortening the cycle time and getting as close to the actual work and customers as possible.
That’s a long way from the drab cubes of strategy drones and the luxurious double cubes with round tables of their bosses.
Source: What makes a map?
Rumors are HPE is looking to sell of some older software assets, Autonomy, Mercury, and Vertical. Acquisition prices from Bloomberg:
- Autonomy: $10.3bn in 2011
- Mercury: $4.5bn in 2006
- Vertica: ~$350m in 2011
It’s that bugbear cloud, James over at RedMonk, said back in June in his report on the company’s big conference:
Make no mistake – Cloud is a forcing factor for pretty much all of the issues facing incumbent enterprise suppliers today. Cloud is putting pressure on all enterprise software markets – applications, hardware, networking, security, services, software, storage etc.
That said, I’d theorize that these are all reliable businesses with reliable customer bases. Their revenue may be declining and they may not be all “SaaS-y,” but for the right price PE firms could probably do alright.
…or: “Knowledge work is a lot more like cloud than traditional IT.”
Of course, it is most certainly not in the interest of knowledge workers to go to their bosses and declare that they have “spare capacity.” At best, they might then be judged in performance reviews as having an easy job and being not very productive. At worst, the bosses might decide that these employees could be cut. Thus it is to every knowledge worker’s benefit to look busy all the time. There is always a report to write, a memo to generate, a consultation to run, a new idea to explore. And it is in support of this perceived survival imperative that the second driver of productivity—knowledge transfer—gets perverted.
The rest of the piece is good stuff. Notice how much of the thinking follows the same pattern of opex vs. capex thinking of cloud, and the somewhat similar notions of continuous delivery. I’d also add that if you follow a small batch (smaller amounts of work delivered more frequently, rather than big projects delivered once), you’re given more opportunity to re-allocate your “knowledge workers” to different projects. As the author points out, this means you have to rejigger how HR/roles and responsibilities work; staff policies don’t currently favor moving people from project to project like you see in (management) consulting.
Couple this with the “you need to constantly be coming up with new businesses” pressure from Transient Advantage, and you have good operating theory.
So here we are, as of this writing a good twenty-nine years after the “hatchet job,” and Kodak has declared bankruptcy. The once-humming factories are literally being blown up, and the company’s brand, which Interbrand had valued at $14.8 billion in 2001, fell off its list of the top one hundred brands in 2008, with a value of only $3.3 billion. 6 It really bothered me that the future was so visible in 1980 at Kodak, and yet the will to do anything about it did not seem to be there. I asked Gunther recently why, when he saw the shifts coming so clearly, he did not battle harder to convince the company to take more forceful action. He looked at me with some surprise. “He asked me my opinion,” he said, “and I gave it to him. What he did beyond that point was up to him.” Which is entirely characteristic of scientists like Gunther. They may see the future clearly, but are often not interested in or empowered to lead the charge for change. Why do I know this story so well? He happens to be my father. —The End of Competitive Advantage, Rita McGrath.
You don’t get a sudden, personal turn like that in business books much. It evoked one of the latent ideas in my head: much of my interest in “business” and “strategy” comes from dad’s all too typical career at IBM in the 80s and 90s.
Sometime in the early 80s – or even late 70s? – my dad started working at IBM in Austin on the factory floor, printed circuit boards I believe. He’d tell me that he’d work the late shift, third shift and at 6am in the morning, stop by 7-11 with his buddies to get a six pack and wait in the parking lot of the Poodle Dog bar for it to open at 8.
He moved up to management, and eventually into planning and forecasting. All for hardware. I remember he got really excited in the late 80s when he got a plotter at home so he could work on foils, that is, transparencies. We call these “slides” now: you can still get a that battlefield-twinkle out of old IBM’ers eyes if you say “foils.”
Eventually, he lived the dictum of “I’ve Been Moved” and went up to the research triangle for a few years, right before IBM divested of his part of the company selling it to Multek (at least he got to return to Austin).
As you can guess, his job changed from a long-term one where his company had baseball fields and family fun days (where we have an outdoor mall, The Domain now) to the usual transient, productivity harvesting job. He moved over to Polycom eventually where he spent the rest of his career helping manage planning and shipping, on late night phone calls to Thailand manufacturers.
In addition to always having computers around – IBM PCs of course! – there was always this thing of how a large tech company evolves and operates. At the time, I don’t think I paid much attention to it, but it’s a handy reference now that I spend most of my time focused on the business of tech.
I’ve been working on a series of blog posts on “the cloud native journey.” I put that in quotes because it’s admittedly a cheesy marketing phrase. The point of it is: if you’re looking to start using all these new cloud-based ideas for improving how your company does custom software development, what’s that look like. You know, what’s the “journey.”
All four parts are now up:
- The introduction to the series
- The Purity & Tyranny Of A Blank Screen: The Greenfield Journey – see also a recording of my webinar on this section, also the slides.
- Dealing With The Stuff That Makes All The Money: The Legacy Journey – check the recording of the webinar on this section, too. Also, the slides.
- The Cloud Native Journey: Enterprise Transformation – check out the recording of the webinar on this part. Also, the slides.
There’s also a PDF of the whole thing if you prefer that format.
Tell me what you think of it!
I always like a good three p’s explanation:
We found three key elements that consistently drive innovation: people, processes and philosophies (what we call the 3Ps). We found that highly innovative organisations built their people, processes and philosophies around five fundamental “discovery skills”. Innovators ask provocative questions that challenge the status quo. They observe the world like anthropologists to detect new ways of doing things. They network with people who don’t think like them to gain radically different perspectives. They experiment to test new ideas and experiences. Finally, these behaviours trigger new associations which lead them to connect the unconnected, thereby producing disruptive ideas. An organisation’s investment in and ability to leverage these three facets of innovation sets it apart.
I had lunch with Israel Gat yesterday. Lobster bisque in a sourdough bread bowl, to answer your first question. We were talking about the concept of a “software defined business” (and I was complaining about how HEB needs more of that, if only to get digital Buddy Bucks).
Well, over the next 3 years, I think much of the marketing efforts in tech will converge on exactly that. This is what tech companies will try to sell and the “thought lordship” they’ll try to deploy into the market. I think it’ll actually be to the tremendous benefit of customers, not just a hustle. Soon the egg will become a chicken, and the chicken will start making demands on the egg. Which one is egg and chicken? Indeed! One can never tell the causation directionality in these things.)
Why will tech companies focus on software defined businesses as a growth driver? Well, it’s kind of the only area for growth, at least interesting growth. Keep in mind that if you’re a big, publicly traded company, you have to grow, you need to find new money sources. Last year’s revenue can’t just sit there, staying stable. Otherwise you’re toast because investors will want to allocate their money in companies that are growing, not shrinking (they’ll dump your stock, and but another). This is true for any business, but very true for technology companies.
Here’s my rough sense of revenue streams tech companies will have:
1. Consumer churn.
You know, you get a new mobile phone ever 2-3 years. Instead of subscribing to a cable package, you subscribe to HBO Go. (You sort of end up paying the same amount, but who’s paying that close of attention when there’s so new Game of Thrones episodes to watch?) You buy subscription services. Games.
Basically, the “not enterprise” market. This is what most tech press covers and talks about; it’s (sadly?) what we think of as “tech” now.
There’s growth in here, but it’s a totally different space than traditional, let alone “enterprise” tech. Microsoft finally seems to have figured this out, but meanwhile Apple, Google, and Facebook are gobbling up all the revenue and growth…not to mention all the new companies that have come along.
2. How much more ERP can there be?
Businesses still need a lot of software, but I’d argue that “systems of record” are probably well saturated at this point and low growth. This used to be the fuel of the tech sector, but if everyone has a system of record in place…how much more more spend can there be there each year? (I’m sure we could look up some IDC or Gartner numbers about single digit growth in these markets.) Not much. One area of interest is shifting over to SaaS, or:
3. Rip-n-replace cloud.
“Well, I guess I need to replace all this ‘legacy’ stuff with cloud.” You know in storage, compute, and maybe networking. There’s lots of hardware and infrastructure software churn here. In the software category, I’d put migrating your on-premises ERP/systems of record stuff to SaaS here as well: moving to Salesforce, Successfactors, etc. In a squishy analogy, things like Adobe transforming from licensed sales to subscription sales.
This is a long term play with lots of cash; for businesses though: do they end up with anything net-new? Have you actually tried to use Salesforce? It removes the hassle of having the manage your own CRM instance, but you still have to manage how your company uses the application…otherwise it’s baffling what’s going on in there. My point is: the company ends up kind of back where it was before the great rip-n-replace, just more optimized IT, with hopefully HTML5 and native mobile apps instead of Flex.
4. Software Defined Businesses.
Here, companies are looking to create new custom written software that helps run their businesses in new ways or creates entirely new business models. It’s the thing we at Pivotal target, what you see coming out of the IBM/Apple partnership (mostly – some of it just the next step in the great rewrite the UI every decade journey of green-screen->HTML 1.0->Flex->HTML5->Swift), and it’s what will benefit us people most: companies get new businesses and, thus, growth themselves, us individuals get companies using software more to hopefully make working with them suck less. You know: Uber and all that.
There’s lots of “drag” (secondary spending) that gets to #3 above: you know, you’re gonna need a platform for all that stuff, and the hardware and services around it…but instead of just ending up with the same IT-driven capabilities, you’ll have new capabilities in your business.
So, if you’re a tech company, and you’re looking at the 4 sources of cash and growth above, the fourth option looks pretty good. #1 means competing with Apple, Google, and Facebook and then a dog’s breakfast of lower margin goods below the UI layer. #2 and #3 are good, known quantaties, but probably with single-digit growth, if not tricky waters to traverse in the lower cloud infrastructure layers.
Then you look at the other option: a wide open field of possibilities where you “go up the elevator” and avoid the Morlocks. Large tech companies have to do all of these, of course, but I suspect you’ll see most of the razzle-dazzle spread on the fourth.
Those cigar makers have nothing to do with this, but cool picture, huh?
I’ve talking with an old collegue about pitching a developer-based strategy recently. They’re tryin to convince their management chain to pay attention to developers to move their infrastructure sales. There’s a huge amount of “proof” an arguments you can make to do this, but my experience in these kinds of projects had taught me that, eventually, the executive in charge just has to take a leap of faith. There’s no perfect slide that proves developers matter. As with all great strategies, there’s a stack of work, but the final call has to be pure judgement, a leap of faith.
“Why are they using Amazon instead of our multi-billion dollar suite?”
You know the story. Many of the folks in the IT vendor world have had a great, multi-decade run in selling infrastructure (hardware and software). All the sudden (well, starting about ten years ago), this cloud stuff comes along, and then things look weird. Why aren’t they just using our products? To cap it off, you have Apple in mobile just screwing the crap out of the analagous incumbants there.
But, in cloud, if you’re not the leaders, you’re obsssed with appealing to developers and operators. You know you can have a “go up the elevator” sale (sell to executives who mandate the use of technology), but you also see “down the elevator” people helping or hendering here. People complain about that SOAP interface, for some reason they like Docker before it’s even GA’ed, and they keep using these free tools instead of buying yours.
It’s not always the case that appealing to the “coal-facers” (developers and operators) is helpful, but chances are high that if you’re in the infrastructure part of the IT vendor world, you should think about it.
So, you have The Big Meeting. You lay out some charts, probably reference RedMonk here and there. And then the executive(s) still isn’t convinced. “Eh,” as one systems management vendor exec said to me most recently, “everyone knows developers don’t pay for anything.” And then, that’s the end.
There is no smoking gun
If you can’t use Microsoft, IBM, Apple, and open source itself (developers like it not just because it’s free, but because they actually like the tools!) as historic proof, you’re sort of lost. Perhaps someone has worked our a good, management consultant strategy-toned “lessons learned” from those companies, but I’ve never seen it. And belive me, I’ve spent months looking when I was at Dell working on strategy. Stephen O’Grady’s The New Kingmakers is great and has all the material, but it’s not in that much needed management consulting tone/style – maybe his upcoming book on Oracle will add to it.
Of course, if Microsoft and Apple don’t work out, don’t even think of deploying all the whacky consumer-space folks out like Twitter and Facebook, or something as detailed as Hudson/Jenkins or Oracle DB/MySQL/MariaDB.
I think SolarWinds might be an interesting example, and if Dell can figure out applying that model to their Software Group, it’d make a good case study. Both of these are not “developer” stories, but “operator” ones; same structural strategy.
Eventually, they just have to “get it”
All of this has lead me to believe that, eventually, the executives have to just take a leap of faith and “get it.” There’s only so much work you can do – slides and meetings – before you’re wasting your time if that epiphany doesn’t happen.
Hey, I’ve not only seen this movie before, I’ve did some script treatments:
Chief Executive Officer John Chambers is aggressively pursuing software takeovers as he seeks to turn a company once known for Internet plumbing products such as routers into the world’s No. 1 information-technology company.
Cisco is primarily targeting developers of security, data-analysis and collaboration tools, as well as cloud-related technology, Chambers said in an interview last month.
Good for them. Cisco has consistinly done a good job to fill out its portfolio and is far from the one-trick pony people think it is (last I checked, they do well with converged infrastructure, or integrated systems, or whatever we’re supposed to call it now). They actually have a (clearly from lack of mention in this piece) little known about software portfolio already.
In case anyone’s interested, here’s some tips:
Don’t buy already successful companies, they’ll soon be old tired companeis – software follows a strange loop. Unlike hardware where (more or less) we keep making the same products better, in softare we like to re-write the same old things every five years or so, throwing out any “winners” from the previous regime. Examples here are APM, middleware, analytics, CRM, web browsers…well…every category except maybe Microsoft Office (even that is going bonkers in the email and calendaring space, and you can see Microsoft “re-writing” there as well [at last, thankfully]). You want to buy, likely, mid-stage startups that have proven that their product works and is needed in the market. They’ve found the new job to be done (or the old one and are re-writing the code for it!) and have a solid code-base, go-to-market, and essentially just need access to your massive resources (money, people, access to customers, and time) to grow revenue. Buy new things (which implies you can spot old vs. new things).
Get ready to pay huge multipules – when you identify a “new thing” you’re going to pay a huge multipile 5x, 10x, 20x, even more. You’re going to think that’s absurd and that you can find a better deal (TIBCO, Magic, Actuate, etc.). Trust me, in software there are no “good deals” (except once in a lifetime buys like the firesale fro Remedy). You don’t walk into Tiffany’s and think you’re going to get a good deal, you think you’re going to make your spouse happy.
“Drag” and “Synergies” – not gonna happen on any scale that helps make the business case, move on. The effort it takes to “integrate” products and, more importantly, strategy and go-to-market, together to enabled these dreams of a “portfolio” is massive and often doesn’t pan out. Are the products written in the exactly the same programming language, using exactly the same frameworks and runtimes? Unless you’re Microsoft buying a .Net-based company, the answer is usually “hell no!” Any business “synergies” are equally troublesome: unless they already exist (IBM is good at buying small and mid-companies who have proven out synergies by being long-time partners), it’s a long-shot that you’re going to create any synergies. Evaluate software assets on their own, stand-alone, not as fitting into a portfolio. You’ve been warned.
Educate your sales force. No, really. REALLY! – you’re thinking your sales force is going to help you sell these new products. They “go up the elevator” instead of down so will easily move these new SKUs. Yeah, good luck, buddy. Sales people aren’t that quick to learn (not because they’re dumb, at all, but because that’s not what you pay and train them for). You’ll need to spend a lot of time educating them and also your field engineers. Your sales force will be one of your biggest assets (something the aquired company didn’t have) so baby them and treat them well. Train them.
Start working, now, on creating a software culture, not aquiring one – the business and processes (“culture”) of software is very different and particular. Do you have free coffee? Better get it. (And if that seems absurd to you, my point is proven.) Do you get excited about ideas like “fail fast”? Study and understand how software businesses run and what they do to attract and retain talent. We still don’t really understand how it all works after all these years and that’s the point: it’s weird. There are great people (like my friend Israel Gat) who can help you, there’s good philosophy too: go read all of Joel’s early writing of Joel’s as a start, don’t let yourself get too distracted by Paul Graham (his is more about software culture for startups, who you are not – Graham-think is about creating large valuations, not extracting large profits), and just keep learning. I still don’t know how it works or I’d be pointing you to the right URL. Just like with the software itself, we completly forget and re-write the culture of software canon about every five years. Good on us. Andrew has a good check-point from a few years ago that’s worth watching a few times.
Read and understand Escape Velocity – this is the only book I’ve ever read that describes what it’s like to be an “old” technology company and actually has practical advice on how to survive. Understand how the cash-cow cycle works and, more importantly for software, how to get senior leadership to support a cycle/culture of business reneweal.
There’s more, of course, but that’s a good start.
Finally, I spotted a reference to Stall Points in one of Chambers’ talks the other day which is encouraging. Here’s one of the better charts you can print out and put on your wall to look at between meetings:
That charts all types of companies. It’s hard to renew yourself, it’s not going to be easy. Good luck!
Using RedMonk logic: companies tend to keep what they consider their competative advantage closed source; Google keeps their dev toolchain closed source; Google’s ability to more productive in development (the primary point of a dev toolchain) is a core differentiator for Google. QED.
The reality is that it is only the `cash cows’ that are really important—all the other elements are supporting actors. It is a foolish vendor who diverts funds from a `cash cow’ when these are needed to extend the life of that `product’. Although it is necessary to recognize a `dog’ when it appears (at least before it bites you) it would be foolish in the extreme to create one in order to balance up the picture. The vendor, who has most of his (or her) products in the `cash cow’ quadrant, should consider himself (or herself) fortunate indeed, and an excellent marketer, although he or she might also consider creating a few stars as an insurance policy against unexpected future developments and, perhaps, to add some extra growth. There is also a common misconception that ‘dogs’ are a waste of resources. In many markets ‘dogs’ can be considered loss-leaders that while not themselves profitable will lead to increased sales in other profitable areas.
I suspect the prevalent “slow follower” mentality within the public IaaS companies that are chasing AWS will continue. So too will the confusion about their inability to catch up with AWS, let alone pass them by. At the end of the day, this is about inventing new ways to provide better and more resilient computing infrastructure to the Global 2000. Trying to beat AWS won’t get you there; you need to take the path of innovation and creativity
“These old technologies are holding us back. They’re anchors on where we want to go,” he said. “We find the things that have outlived their useful purpose. Our competitors are afraid to remove them. We try to find better solutions – our customers have given us a lot of trust. In general, it’s a good idea to remove these rotating medias from our computers and other devices. They have inherent issues — they’re mechanical and sometimes break, they use power and are large. We can create products that are smaller, lighter and consume less power.”