Pivotal Conversations: The management perspective on transforming Allstate, with Opal Perry

I’m always interested to hear how management manages to change how software is done in large organizations – it can seem impossible! As ever, Allstate provides a fascinating stream of information here, and I was lucky to get the chance to interview Opal Perry there on how Allstate has been doing with all that cloud-native stuff.

Check out the listing on SoundCloud, and be sure to subscribe to the podcast if you like it.

Also, if you want to hear more, Matthew Curry and I had a similar conversation a few weeks ago at OSCON.

Coté Show: Getting over resistance to change

Matt Curry is back! In this episode recorded at OSCON 2017, we discuss the problems with getting people to change, from staff to management, private sector and government.

See the full show notes for the podcast subscription link and more doo-dads!

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:

When middle-management is screwing it all up – Pivotal Conversations

Whether it’s “DevOps,” “digital transformation,” or even “cloud” and “agile,” middle-management is all too common an issue. They simply won’t budge and help out. This isn’t always the case for sure, but “the frozen middle” is a common problem.

With a big ol’ panel of people (including two folks from RedMonk), we talk about tactics for thawing the frozen middle.

Setting goals is important for DevOps success

For my monthly column over at FierceDevOps I wrote about the importance of setting goals. I was motivated to write this by this point being repeated in Leading the Transformation many times, e.g.:

Management needs to establish strategic objectives that make sense and that can be used to drive plans and track progress at the enterprise level. These should include key deliverables for the business and process changes for improving the effectiveness of the organization.

It made me think that most of the corporate failures I’ve seen over the years were due to management being vague about what they wanted and what the team should be doing. Someone has to set the goals and, at the very least, it’s management’s job to make sure its done (they don’t have to do it, though I tend to think they do: they just need to make sure it happens).

Anyhow, check out the piece!

Team work bringing down the average

The workers were told, essentially, that they were to be rewarded for collective achievement rather than individually. So instead of maximizing individual satisfaction, which often comes through competition with other people, employees considered their impact on colleagues. The theory, which plays out in the results, is that with relative rankings, top performers reduce their effort to avoid hurting their co-workers’ egos and to prevent schisms in the team.

That’s kind of sweet actually. One would also think that the incentives are disconnected from the thing you’re trying to fix: if you had to pay for all that fuel yourself, out of your take of the margin, would you be more efficient or less? That’s probably unreliable as well. Also: you’d think these tricks of fleet management would be long solves, e.g., all that lore about UPS and Fedex trucks. But, there’s probably tons of ongoing change and variability in all that.

Also: notice the Big Data angle, the technology that enabled the study.

Team work bringing down the average

You want people to work as much as possible to push the product and company out of uncertain territory into profitability, right? Wrong. What you will do is push people to the edge of burnout and unhappiness. They’ll eventually leave your company.

From Open (Unlimited) to Minimum Vacation Policy

This is a management point I’ve been thinking about over the years: it turns out well rested employees are better long-term. I don’t think most (American) management believes that, at all.

The subtle point to make explicit here goes the other way: employees are work-gluttons if you let them be. They “over-eat” and can’t help themselves. Part of management’s job, then, is to help employees here.

Both management and employee are at fault, and there’s lots of work to be done.

Most of the hierarchy found in the traditional firm must be eliminated, and the walls between functional staffs must be destroyed. You can’t move fast, no matter how good the systems are, if turf fights among functions are the norm, and if even routine decisions must be processed through numerous layers of bureaucracy.

Tom Peters (via fadingcity)

Over some ribs and brisket the other days a friend of mine called this notion “management debt,” which seems right. The analogistic potential of “technical debt” is limitless!