Enterprise Change Management 101

A portion of our recent work with Home Depot highlights a common misconception in the tech industry: that software alone can change people’s behavior. It’s more common in the enterprise world, but many startups think along the same lines. If creating technology is what you’re good at, it’s only natural to want to do that to try to influence change.

Unfortunately, the world doesn’t work like that.

In the enterprise world, when that fails, it can be really tempting for someone at the top to wield their stick of power and say “use this software now” or “do things this way now”.

It’s a short-sighted fix.

That’s like asking people to get in a boat with no compass, no life jackets, no defenses against pirates and sharks, and no explanation about where the boat is headed. Would anyone want to get in that boat?

Here’s how it should actually work.

image

Your goal is to bring people from Today Island to Future Island. This requires 3 different components:

1. Vision

In the words of Antoine de Saint-Exupéry, “If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”

Vision could otherwise be called sales and marketing. This is your pitch. Your goal is to inspire people to want to go to Future Island using a strong narrative for change. Like a politician, you can go positive or negative. Either way, your goal is to create a gap between Today Island and Future Island that makes Future Island look 10x better.

Keep in mind your pitch is going to be different depending on the audience. For each different audience segment, you’ll need a pitch that creates that 10x gap. Don’t forget to Start With Why!

2. Safety

One of the reasons change is so hard is because people fear leaving the relative safety of Today Island.

“I’ve been on Today Island a while and everything’s been fine so far - why leave? There are sharks! What if the boat sinks?! What if Future Island isn’t what you say it is?!!”

You need to reassure your audience members that Future Island and the journey to it is safe. This starts with discovery. Talk to the people who’d be affected by the change and ask, ‘if you did XYZ instead of ABC, what would you be worried about?” Drill deeper with follow up questions like, “And why is that bad (or good or confusing or whatever)?” and “What happens to you if that happens?”

Be prepared for people to lie. Don’t worry, it’s usually not on purpose. Try to discover their true pain, even if they won’t say it. Oftentimes, true pain can be embarrassing or career-inhibiting if verbalized.

Note: this is really hard. Don’t beat yourself up if you don’t get it perfect. Just putting in the effort to listen to people might be enough to make people feel safe.

Next, your job is to create things to make those worries go away. It could be as simple as talking it out. Or it could be new incentives, training workshops, a new structure, or something else along those lines.

3. Support

If you’ve sold your vision and your audience members are feeling safe, they’ll be asking, “How?” That’s a great place to be! Now your job is to support employees with the tools and training they need to make the journey to Future Island a successful one.

If software is your boat, don’t forget the other tools people need on an ocean voyage. Like directions! In our analogy, directions = training. It could be training on the software tool itself, personal growth training, or tactical training about how to make the change.

A Final Note

Some people won’t get in the boat on the first trip. That’s ok, you can come back to the late majority once they see others enjoying Future Island. And the ones that will never get in the boat, even after the change is a validated success? Hopefully they’re few and far between. If not, go back to step 1.

comments and more changemanagement enterprise

View State in Angular 1.x

Almost every web application has pages with search capability. The parameters of the search are typically reflected in the URL’s query parameters. However, manipulating these query parameters can often be tricky in Single Page Web Applications. In most cases, developers want the client-side router to route based on the path and not the query parameters, since there is typically a one-to-one correspondence between paths and controllers.

There are a few requirements that users expect from their URLs

  1. Users should be able to copy a URL (with query parameters) and share it with someone else, who should see the page exactly the same way
  2. Users should be able to navigate back and forward as the query parameters change and have the page contents reflect the query parameters

AngularJS makes getting and setting URL query parameters easy with their $location service. However, if you’re not careful, the query parameters and $scope variables can easily get out of sync and then the browser’s back and forward buttons will no longer work as expected. To ensure the query parameters and $scope variables are always in sync, make sure:

  1. $scope variables are always a reflection of the query parameters. Use $scope.$watch on $location.search() to watch for query parameter changes and then update the $scope variables.
  2. changes start by updating the query parameters. Use $location.search(search, paramValue) to change query parameters, which will then change the $scope variables.

Here’s an example of a page that shows a list of users that can be filtered by group:

The hypothetical pages below would display the list of users based on the URL string:

comments and more

Why Saves Are More Real Than Any Other Closer Stat

image

Originally posted by enformadefotos

From time to time I notice things in “the real world” that can be further explained with behavioral economics. Today’s topic is baseball’s save stat.

Ask any baseball stathead their thoughts on saves and the value of closers and you’re sure to get a scornful response.

Announcers and sportswriters continue to question why teams’ seemingly best relievers are only used for save situations. Teams lose games without ever putting in their best reliever, and then that same pitcher “saves” a game 4 days later that the team very likely would have won anyway.

Surely, most front offices today (sorry Phillies fans) are using better methods to evaluate relievers. And surely this new information can be used to optimize how arms in the bullpen are used.

Yet the save stat prominently lives on and bullpens are still managed around it. Why?

Humans Aren’t Computers

Humans don’t act in their own rational self-interest. They don’t make logical decisions, they make emotional ones that often come from an irrational place. There are countless cognitive biases always in effect, and the rationality of a decision is bounded by the information we have at the moment we make it.

What’s going on in the case of closers, the save stat, and the decisions around those 2 things is a result of Prospect Theory. Prospect Theory is very interesting in itself - I recommend you click that link and read about it. The two components relevant to the context of this article are:

  1. Losses hurt more than gains feel good. The effect is about 2.25 times more powerful. For example, according to the irrational human brain, avoiding a $5 surcharge feels equal to getting a discount of $11.25.
  2. Humans are risk-averse when there is a high probability of feeling a gain, and they are willing to overpay for certainty. For example, given a 95% chance to win $10,000 or 100% chance to obtain $9,499, they’ll take the $9,499 (and probably even less) even though the expected payout of the first scenario is $9,500.

The End of a Baseball Game is Prospect Theory at Work

When it’s the end of a game, and it doesn’t feel certain that a victory is at hand (a reasonable cutoff for that feeling being a lead of 4+ runs), managers, GMs, fans, and players alike are all willing to overpay for the certainty of not feeling a loss. So in comes the closer for the save. This is normal, risk-averse, human behavior and it’s not going to stop until teams are managed by computers or Phil Ivey.

How about close games? Why are closers saved for when a team is ahead? And why aren’t they used in the 7th inning with no outs and Mike Trout coming up with the bases loaded?

Here are the possible outcomes of a baseball game ranked on a “feeling scale” from most powerful to least powerful.

  • -4.5: Losing when you thought you were going to win
  • +3.25: Winning when you thought you were going to lose
  • -2.25: Losing
  • +1: Winning
  • 0: Game suspended due to rain

Pitchers can’t create a win (from the mound, at least). They can only not lose. So the 2 losing scenarios govern a manager’s bullpen decision-making in those close games.

Technically, a pitcher can’t “not lose” in the 7th inning as there are still 2 more innings to play. In that moment, there are all kinds of unconscious calculations a manager’s brain makes in the background to help him quickly decide how to optimize the use of the bullpen to not lose.

Whatever those calculations are, the decision is usually the same: the closer’s butt stays glued to the bench and in comes a non-closer reliever. And the real reason why, no matter what the manager says, is that he’s optimizing to avoid the greatest loss possible: losing when you thought you were going to win.

It’s fair to reiterate that this isn’t something managers are consciously doing. They aren’t calculating odds of victory (or not losing) and choosing a reliever accordingly. This is all happening unconsciously based on thousands of years of evolution that has turned us into loss-avoiding scaredy cats.

Saves = Loss Avoidance

So why is losing when you thought you were going to win so painful? Any loss sucks. It feels crappy. But when you thought you were going to win? That feels much worse! Why? It’s because your point of reference changed. You already felt and accounted for the gain of the win. So now instead of feeling one loss, you’re feeling that loss PLUS the loss of the win you thought you had. Major bummer!

The save stat is simply a representation of loss avoidance. Closers aren’t paid to accumulate saves. They’re paid for what the save attempt represents: an opportunity to increase the certainty that a team’s stakeholders won’t feel the pain of losing what, in their mind, is already a win. In other words, they aren’t paid to get saves, they’re paid to not get blown saves. This differs from what non-closer relievers are paid to do and, as we’ve already learned, humans are willing to overpay to avoid the loss of a near-certain gain.

That’s why saves and blown saves matter. They’re the best metrics we have to describe the reality of the irrational human brain of baseball’s decision makers.

What do the numbers say?

I used Spotrac’s Free Agent Tracker to get a list of all the free agent reliever signings from 2012-2015 (2012 is as far back as it goes). I used FanGraphs to filter the list of relievers to those with a SD-MD% of over 60% in order to remove the relievers signed for middle-innings mopop work. Depth relievers aren’t signed to not lose. Last, I compared the average annual value of the remaining closer contracts to the non-closer contracts to get a ratio of how much closers are valued over regular relievers.

I averaged the 4 ratios and it comes out to 2.91. To be honest, I thought it’d be more like 2, as the value of relievers signed to not lose (2.25) is half of those signed to not lose when you thought you were going to win (4.5).

This variance might be due to small sample size, incomplete data, using the wrong data, or perhaps I just don’t know what I’m talking about.

What do you think? Do you agree? Have a better idea of how to do the data analysis? Is this all a bunch of fuff?

comments and more prospecttheory baseball saves closers behavioral economics

An Intro To Flexbox

Here at Rocket Whale, we practice design driven development. We fight for every pixel to ensure our users experience their application in its full glory. Fighting for pixels can be a tedious battle, however. For example, below is a landing page with a 2 column x N rows layout with a combination of text and images.

image

Before flexbox, we would use Bootstrap 3 to layout this page with its responsive grid system. It was easy to lay things out. However, each screen size (xs,sm,md,lg) required nudging the margin manually to get the image to line up vertically with the text. In our example that could require 12 different margin-tops. How tedius! And then someone alters the paragraph text, which then moves the text onto the next line, which means now the centering is out of whack! That’s whack!

Take a look at the HTML framework code below

With flexbox, the text and images center up magically! With less HTML nesting! We still need to cap the screen width, like bootstrap does with their .container .row .col-* CSS heirarchy, but that can easily be done using bootstrap’s @screen-*-min width variable (if you have the luxury of using LESS). Also, we frequently like to alternate the text/image positioning from left/right to right/left and we can now just do that by using row-reverse.

comments and more bootstrap

Backbone Relationships

On almost every project where we use backbone (which is most of them), we inevitably come across the following problem: How do we mirror the has_one and has_many relationships (that Rails does so well) on the client with backbone?

We’ve evaluated several available options, but haven’t found much success. Backbone.Relational gets slow with large data sets and is a huge memory leak, unless you manage it.  backbone-associations just isn’t powerful enough to cover most of our use cases.

Last week, I decided to roll my own solution: backbone-relationships.  It has worked extremely well for most of our uses cases (see the README), which are shipping data from the client to the server.  It still needs to be built out to handle the nested_attributes situations, but we’re waiting for a use case to drive that.  Give it a try!  Let us know what you think!

comments and more backbone

Rocket Whale Art

We had some cool art drawn up for us by the amazing artist behind our t-shirts and I thought it’d be a good idea to show off some of his work.

Here are the results, all framed and everything!

image

Wouldn’t this look great on a kid’s t-shirt?  Some day…

image

Our current t-shirt design looks fantastic as a sketch!

image

No, he’s not high, he’s just sleepy. Like me, the Rocket Whale is not a morning person (whale).

image

How does his body fit in the rocket? Magic, I think…

@tom_odea

comments and more rocketwhale

Score This Shirt at the ATL RUG Meetup

Tonight at the Atlanta Ruby User Group meetup, our very own Sam Duvall will be talking about the exciting new changes in Ruby 2.0 along with a tutorial on push servers. We’ll also be giving away a few of our spectacular hot-off-the-press t-shirts. And if that wasn’t enough, we’ll be sponsoring some drinks afterwards at Cypress St. Pint & Plate.

Sounds good, right? Great. Come get nerdy with us.

image
comments and more