While talking with Rahel Anne Bailie, we discussed the issue of the someone-else’s-problem effect, and the people’s tendency not to pay attention to the ripples resulting from their decisions.
Rahel: I’m really annoyed. You didn’t call me when you were writing the book. I have stories from other CMSes…
Rick: I know. I’m sorry. But I was already 35% over the target word count. I couldn’t have fit anything else in if I wanted to.
Rahel: I was wondering. I know the XML Press books are supposed to be under a hundred pages. And this one is over that. What happened?
Rick: I couldn’t find anything else to cut.
Rahel: Yes. I can understood that. And I have to say, for the record: I love the examples.
Rick: Thank you.
Rahel: Something that comes through really well in the book is the fallout that results from retraining people to use CMSes that don’t match how they do things. Change costs. It’s not just the technological change, it’s also the emotional change: “I’m used to doing things in Word. I don’t want to change the way I do things.”
I will usually tell my clients that if we’re not coming up with a solution that makes it easier for people to do their work, it’s not worth doing. Because, basically, people won’t use it.
Rick: Absolutely. It’s just a waste of money.
Rahel: Some years ago, I had a client – a government department – ask me to assess their content management system. At the time, it was a popular piece of software. My first thought was “this is so bad!” But it wasn’t the software – it was what the integrator had done with it. They has made some fundamental decisions…
Rick: Assumptions, yeah. I talked with Jeff about how those show through.
Rahel: In this case, they burnt through the budget and stopped. They said the budget was too small.
So, the client wanted to rebrand, but they couldn’t get to their logo, on their own web site. They sent the new logo out to everyone else to use, but on their own site, that configuration was hidden somewhere.
And then there was the problem with saving and publishing. You couldn’t save something part way through. And saving was publishing. You either had to finish what you were doing, and publish, or discard it.
Rick: I sometimes feel that feature persists in some of the more common open source platforms around today. Though only when editing. There is no save-edits-for-later. Only a republish.
Rahel: This was worse. As soon as you hit publish, everything was published. If somebody else was working on another piece at the same time, it got published in its incomplete form. They has loads of bad information out there, in the public domain. The sort of thing that, if it happened now to a commercial organisation, would trigger lawsuits.
I’ve talked to developers about this; I tell them they are notorious for putting in the easiest possible fix. And they say, “Well, why wouldn’t we? Our company isn’t paying us to build the gold standard. They’re paying us to build something good-enough.”
Rahel: And “good enough” is usually based on departmental goals. Not organisational goals.
Rick: It’s a classic case of Someone Else’s Problem.
Rahel: I have that situation right now with a client. They’ve told me what they will be measured on. I’ve tried to explain that it’s counter-productive to the bigger goal of making money. If we implement for this metric, Google will start de-ranking their content. They won’t be on the first page of results, which means they won’t be selling product.
The answer I get is: “We’re being measured on this goal. To be successful, this is what we have to do. If someone higher up comes along and changes the goal, we’re fine with that. But until then…”
They want to tick the box for successfully completing their jobs. They’ve been handed a set of success measures by people who don’t know better, and they have to run with them because that’s how the organisation works. They are not rewarded for pointing out the foibles of management. They are rewarded the following instructions, like a military unit.
Rick: It’s unbelievable.
Rahel: Right. They’re not squaddies. They’re supposed to be thinking these things through.
So, it falls to us, the consultants, to deliver the message. And then we hit that shoot the messenger mentality. We’re pointing out the problems, but they’ve already told the board – or the CEO, or whoever – what they’re going to deliver. And the technologists have confirmed that it can be done. And because the technologists have said it’s possible, it’s obviously a good idea.
Rick: Obviously. We all know that technologists are heavily invested in understanding and validating the business reasoning behind every request.
Rahel: Yeah, right.
It’s like: can you jump off the roof? Of course you can. Technically, it is possible. Does that make it a good idea? No; but it is possible.
These are otherwise great people. They are just trying to do their jobs and fall into line.
Rick: I’ve never understood that mentality. I suppose that’s why I have always known I would never make a good employee.
Rahel: When I was in my 20s, I would put things together. I would see the bigger picture. But when I raised it as an issue, the CEO would call me into his office and try to explain where I fit in. “OK, you know when you go to the ballpark, and you’ve got the players, the referees, and so on? And the people in the stands, and there’s somebody selling popcorn. If your job is selling popcorn, you don’t worry about the rest. You worry about selling popcorn.”
Rick: Compartmentalise thinking.
Rahel: Very compartmentalise.
But let’s face it, when you come in to work in the morning, do you wonder about what’s happening in the warehouse? It’s not on your radar. You’re thinking about the three PowerPoint decks you need to update, and the five people you need to talk to.
For all our talk about breaking down silos, we are all still very much focused on our jobs.
Rick: It understandable. On any scale, it would be inefficient for everyone to try to keep track of everything that’s going on.
In my role, I have to think wider than that. I’m always listening to conversations going on around me. I wonder… What are they talking about? Why are they doing? How does that factor in to what I’m doing?
Those of us in consultancy or management level roles have to look at seemingly unrelated factors and understand their consequences.
Rick: It’s the ripple effect. We actually watch the ripples.
Rahel: Yeah. We watch the ripples.
A lot of people are told that it’s not their job to watch the ripples; others are watching the ripples. You just pay attention to what you’re doing; you’ve got a large stack of work on your desk to get through, and if you’re off gazing at ripples, you’ll never get through it.
Rick: I’m not even going to think about how often the size of that stack is the result of not understanding the ripples.
Rahel: One of my favourite stories is: a while back, I was at the client’s site. They had stuck me at a desk in the corner. I was looking at structured content, and CMS stuff. And all of a sudden, I smell a photocopier going. It’s spitting out hundreds and hundreds of pages. So I ask about it.
And they tell me those are update notices that they send out. By post. A bunch of people in the mail room stuff envelopes for a day.
I say, “If you have a CMS, you can notify people automatically.” But some people only have faxes. (I said it was a while back.) I explained that the CMS can detect that, and fax those people.
They had no idea what the technology could do. They couldn’t see that the notices and my work were related. So it hadn’t occurred to anyone to tell me what was happening. If I hadn’t been sitting next to the copier that day, we may never have discussed it.
Even now, people don’t understand what technology can do. Or they rely on it overly.
Rick: Right. They don’t understand the balance of requirements, costs, and benefits. That you have to invest a bit more to get the infrastructure in place – and it has to be the right infrastructure. But once you do, it really pays off.
Rahal: Yes. So they end up being penny-wise and pound-foolish.
But there are examples of people who get it right, people who understand the ripples.
We were looking at managing product information for a sporting goods retailer. They were used to doing things in spreadsheets. It was cumbersome, but it’s what they knew. So we offered them three solutions. If they wanted to keep their existing processes, they could do that for $3,000. Then there were the $30,000 and $300,000 options.
Rick: That’s quite a spread.
Rahel: In the end, they chose the $300,000 option. Because, they said, it would be the cheapest solution. They looked at everything: the costs of using Excel, of maintaining the integration points and home-grown solutions. They factored it all in.
Rick: That sounds like a dream client.
Rahel: I know! The CTO factored all that in. She was so smart. She saw the advantages of being able to…
Rick: She saw the ripples.
Rahel: Oh yes.
They had seasonal printed catalogues: spring, summer, fall and winter. And it was in Canada, so French and English versions. Then they had the themed catalogues: camping or rock climbing, or whatever. This was serious personalisation, ten years ago. They saw that they could reuse. The rock climbing catalogue is a filtered view of the seasonal catalogue: keep the climbing shoes from the shoes area, and the gloves, and helmets.
But it didn’t stop there.
Rick: I’ve had clients recently who couldn’t even think this level of reuse.
Rahel: They understood that the product information could generate other output, too. For example, store signage. All those rack labels with model numbers and available sizes and colours. And hang tags for clothing.
They realised that if they took their twenty disparate systems and got it all working together…
Rick: As I have said in a few other discussions: turn it into one system. Where the system is the language that all the bits speak to each other. It’s the communication layer.
And this client understood the value of doing that.