Mulesoft to IPO with $187.7m revenue in 2016, losses of $49.6m

The San Francisco-headquartered business revealed it pulled in $187.7m last year, up 170 per cent from its $110.3m in revenue in 2015. Gross profits were just over $138m from $78m, and net losses decreased to a piddling $49.6m, down from $65.4m the year before.

Another take from Barb Darrow, inc.:

Mulesoft has raised $1.5 billion in venture funding from such backers as Lightspeed Venture Partners, Hummer Winblad, and New Enterprise Associates.

Man, that’s a lot of money poured into it since 2006 – “G round.”

Link

Cull your rules and regulations, or be frozen by them

screenshot-2017-02-25-09-21-23

Instead, the post emphasized new ways NASA is thinking about acceptable risk for these launches. During the space shuttle era, launch sites were governed by some 2,200 safety requirements. NASA worked to “strip down the expensive rules and came up with just 500 core safety requirements for launches.”

But, the post notes, ”at commercial launch sites, there are only 55 safety requirements.” This “underscores perhaps the single biggest difference between NASA and its commercial partners: risk tolerance. NASA likes to have next to none, and pays for it, while the companies tend to embrace calculated risk as a way to iterate and learn while still developing their products.”

This a major point in companies fixing up their software process: you probably have all sorts of rules and regulations that no longer apply. Just like with managing a legacy application portfolio, you have to aggressively manage your compliance portfolio to eliminate rules that no longer apply.

Matt Curry covers this point with a funny boat-metaphor at the start of his brand talk from last year. You also hear some cases of federal agencies forcing this culling by simply not following the rules and seeing if anyone complained: the compliance equivilent of just turning off old, dusty servers to see who’s using it.

Link

Often, people just won’t change, or, there is no magic to thaw the frozen mind

Under the auspices of “how can we DevOps around here?” I’ve had numerous conversations with organizations who feel like they can’t get their people to change over to the practices and mind-set that leads to doing better software. The DevOps community has spent a lot of time trying to gently bring along and even brain-hack resistant people and there are numerous anecdotes and studies that doing things in DevOps/cloud native/agile/etc. way not only make businesses run more smoothy and profitably, but make the actual lives of staff better (interested in leaving work at 5pm and not working on weekends?)

Still, for whatever reasons, the idea of “the frozen-middle” is reoccurring. In government work, there’s often the frozen-ground” with staff throwing down their heels as well.

Most of the chatter on this topic is at the team level, and usually teams in already flexible, new organizations (like all those logos on scare-slides in presentations from people like Pivotal: UBER! AIRBNB! TESLA! SOFTWARE-IS-EATING-THE-WORLD, INC.!) If you’re already in a company that can change its culture every year, the pain of these “frozen” people is almost nil in comparison to being in government, a 50-100 years old company, or otherwise “in the real world.”

Right here, I’m supposed to establish empathy with these frozen people to get them to change. I should stop calling them “frozen people” and treating them like “resources,” and think of them as people. That is all true, but what do I do after I’ve cavorted with them in empathy splash-pads for months on end and we still can’t get them to configure the firewall so we can do the DevOps? What do you do with enterprise architects who have become specialists in telling you how impossibly fucked up everything is? How do you work with all those “frozen middle-managers” who are acting as a “shit umbrella” (or maybe in this case, a “rainbow umbrella”?) to all your fanciful DevOps notions?

There’s one last ditch tactic: money and firing. When it comes to changing the culture in a large orginizations, this is the big hammer that upper-level management has. That is, the middle-manager’s manger is the one who has to tools to fix the problem. By design, the surest, easiest, sanctioned way to change behavior is to change cash pay-outs and other compensation based on not only the performance of people (management and staff), but their willingness to adapt and change to new, better ways of operating. That is: you reward and punish people based on them doing what you told them to do, or not.

There’s all sorts of “little and cheap” things to do instead of bringing out the big hammer:

  • Giving out acrylic trophies, showering people in attention from high-level execs
  • Fame and glory internally and externally
  • T-shirts (no, really! They work amazingly well)
  • Sanctioning goofing off (“we may have a 15 day holiday policy, but, you know, you should leave work at 4 every day and don’t log vacation”)

Matt Curry covers most of these management-hacks in a great talk on changing large organizations. But let’s assume those aren’t working.

At this point, “leadership” (middle-management’s management) needs to reward and punish the unfreezing or freezing. If middle-management changes (“unfreezes”), they get paid more. If they don’t unfreeze at least their pay needs to freeze, and at “best” they need to get quarantined or fired (as a tone-note, back when I was young and the idea of getting “laid-off” or “RIFed” started being used I reprogrammed myself to only ever say “fired” in reference to loosing your job: those soft, BS words obscure the fact that you’ve been, well, fired – so, feel free to s/// whatever more HR-correct phrase you like into there).

If you look at the patterns of change in most companies going cloud native, they do exactly this. Organizations that successful change so that they can start doing software better set up separate “labs” where the “digital transformation” happens. These are often logically and physically separate: they often have new names and are often “off-site” or well hidden, in the skunk-works style. They do this because if they stay mentally and physically in the “old” system, they end up getting frozen simply due to proximity. The long-term, managerial strategy, here, is an application of the strangler pattern to the “legacy” organization: eventually, the new “labs” organization, through value to the business and sheer size, becomes the “normal” organization.

The staff process they use – almost as a side-effect! – is to only move over people who are willing to change. I’d argue that “skills” and aptitude have little to do with the selection of people: any person in IT can learn new ways of typing and right clicking if the company trains them and helps them. We’re all smart, here.

What happens is that you cull the frozen people, either leaving them behind in the old organization (where there’s likely plenty of work to be done keeping the legacy systems alive!), or just outright firing them. That’s all brutal and not in the rainbows and sandals spirit of DevOps, but it’s what I see happening out there to successfully change the fate of large organizations’ IT departments.

You don’t really hear about this in cheery keynotes at conferences, but at dark bars and (I shit you not) in quiet parking garages I’ve talked with several executives who paint out this unfreezing-by-attrition process as something that’s worked in their organization. One of them even said “we should have gotten rid of more people.”

This pattern gets more difficult in highly labor-regulated industries – like government work and government contractors – but setting up brand new organizations to shed the frozen old ways is at least something to try.

And, barring all else, as I like to say, if nothing is working, and people won’t actually change, Pivotal is always hiring.

If that’s too grim, don’t despair! My buddies have a much light-hearted, hopefully whack at the problem in a recent discussion of ours:

Software Defined Talk: Docker is just cheap VMware, right?

Our new episode is up, from this past Friday:

There’s tell that some people just look at containers as a cheaper way to virtualize, eschewing the fancy-lad “cloud-native stuff.” We discuss that idea, plus “the enterprise cloud wars,” and also our feel that Slack is actually a really good tool and company.

Listen directly, subscribe to the podcast feed, and go check out the full show notes, which has a web player as well.

The problem with the “DevOps tools” category, and the RightScale Cloud Survey

There’s always some good year/year stuff in this survey. I’ll have to check it out soon.

Meanwhile, some coverage from Serdar Yegulalp:

“DevOps tools”:

This category is going to be increasingly weird to cover. Here, what they really mean are “containers and container orchestration tools…oh, and configuration management tools.”

Arguably, you’d put something like Cloud Foundry in there if you have a gumbo of three different software categories, each used by people who want to follow DevOps practices and get the benefits of improving software. We haven’t put public numbers recently, but back in September of 2015 Pivotal Cloud Foundry had $100m in annual bookings, and the growth has continued.

Here’s how 451 characterized our customer base and foot-print out there:

While Pivotal Labs’ early success was among startups, PCF was designed for organizations needing to increase velocity and change their application delivery process, which appeals to large enterprises. About 90% of Pivotal’s revenue comes from enterprise customers today. The company reports that its number of paying customers is in the hundreds, with average deal sizes in the high six-figure range. It also says most of its customers are using PCF on top of VMware’s IaaS offering. AWS is currently in second place among PCF deployments with Azure as a close third that is gaining momentum among the Fortune 100.

All of that means: Pivotal Cloud Foundry has many customers running in production (with the resulting revenue) and, I’d argue, much market share. If you throw in IBM and MicroFocus/HPE’s Cloud Foundry distro revenue, plus OSS use (like at 18F), you’ve got a large chunk of Cloud Foundry usage out there, which should translate into a large chunk of “doing software better (with DevOps)” marketshare for all of Cloud Foundry.

¯\_(ツ)_/¯

Like I said, coverage will be weird for awhile as people sort it out. Kind of like “cloud” was in 2009, and pretty much every “PaaS” category now, though it’s getting better. I’m looking forward to what they sort out in the new(ish?) DevOps practice at IDC.

More coverage of the survey:

Private, public, hybrid:

One key trend RightScale’s tracked over 2014, 2015, and 2016 has been the use of private cloud through OpenStack, VMware, and related products. This time around, while private cloud adoption hasn’t fallen off a cliff, it’s edged down: 72 percent of respondents this year run a private cloud, versus 77 percent last year and 63 percent the prior year. Hybrid cloud has shown a similar trajectory of 67 percent in 2017, 71 percent in 2016, and 58 percent in 2015.

After margin of error, pretty slow, but a good enough pace I guess.

Make no mistake: AWS is cloud king, and it’ll safely remain that way for a long time. But Microsoft Azure has made remarkable amount of progress in the last year. In 2016, only 20 percent of respondents were running apps there; this year, it’s 34 percent. With enterprise users specifically, the growth was even more dramatic, from 26 percent to 43 percent.

And, Oracle and DigitalOcean:

Azure’s growth isn’t coming at the expense of business from other cloud providers. Oracle Cloud and DigitalOcean, the two decliners on the list, didn’t have enough business to lose in the first place to constitute Azure’s jump: respectively, 4 and 5 percent in 2016, and 3 and 2 percent this year.

Now, of course all this hinges on what exactly they mean by cloud, what the sample base is (just RightScale customers?), etc. But, anything that’s multi-year is useful.

See also Barb’s brief coverage, e.g.: “Azure, meanwhile, saw a bigger jump with 43% of respondents on Azure now, compared to 26% last year.”

Source: Docker’s tops for devops, AWS is the cloud king, InfoWorld

People (say they) will spend more on clothes that actually fit

It’s a sore point for many shoppers, who are ready and eager to spend more on designer clothes if only they were available: 78% of respondents in a recent survey of plus-size shoppers said that they’d be willing to spend more money if designers offered more options, and 80% said they’d likely purchase an item from their favorite designer if that designer made plus sizes.

File under “if anything, more money. Plus, bonus: morals!”:

More and more designers and retailers seem to be waking up to that fact. The market for plus-size women’s clothing is over $20 billion, by some measures

Link

Software can accelerate the stresses of transient advantage

From Snap’s S-1, via Ben:

In a world where anyone can distribute products instantly and provide them for free, the best way to compete is by innovating to create the most engaging products. That’s because it’s difficult to use distribution or cost as a competitive advantage—new software is available to users immediately, and for free. We believe this means that our industry favors companies that innovate, because people will use their products.

Link

White men to women and minorities in tech: We just DGAF

Less than 5% of white men surveyed said they considered a lack of diversity a top problem. Three-out-of-four respondents were unaware of any initiatives to make their companies or portfolios more diverse. And 40% of male respondents were sick of the media going on and on about it.

Meanwhile, in political land:

the more privileged you are, the less that oppression personally affects you, the less urgency you perhaps have to get involved in the fight.

And:

According to Shireen Mitchell, activist and founder of Digitalsista, much of the reason women of color are so often on the front lines is because it’s work that needs to be done, and they don’t see anyone else stepping up. “Women of color are always taught to build community to get things done, and in my opinion, most white men are taught that they can only succeed if they are the ‘savior’ for the community. With this mindset, they know they can’t really do that job when it comes to inclusivity because of their inherent bias.”

As those stats on hiring above show, there’s plenty of room for white men to try new ideas out, e.g.:

That leads to white people, especially white men, waiting to act until they feel they will be acknowledged and congratulated for their work. “What we need is for them to take initiative, grow from being uncomfortable and making mistakes. Use their privilege to elevate those who are taking the lead and not add to taxing or using their labor,” says Mitchell.

Link

Sprinkling Internet on NGO’s don’t work

At first, you’re like, “oh, another piece where someone makes fun of us nerds and misunderstands our damagingly sarcastic way of saying everything that belies the privilege we all live under.” Then you’re like, “oh, this is actually a good piece.” E.g.:

Human rights work attempts to prevent the abusive deployment of power against those who have little of it. While technology might disrupt some power structures, it might also reinforce them, and it is rarely designed to empower the most vulnerable populations. Human rights defenders are innovative, and they have used software to do work it wasn’t designed to do, such as live-streaming police violence against civilian populations to press for government accountability. But perpetrators of mass violence are innovative too. Software alone is unlikely to provide clear human rights victories.

And, especially:

Assuming that adopting the tool is feasible, do the benefits this tool provides outweigh the cost of disrupting your existing workflow?

People rarely consider that, in all walks of life.

Source: Tech folk: ‘Move fast and break things’ doesn’t work when lives are at stake