Tag Archives: point guard

Our brand is worth everthing

I don’t know how many times I’ve heard that statement. Too many, I expect. Unfortunately it usually means that engaging with the root cause of the problem we’re trying to solve is too awkward or uncomfortable, so it’s time to reach for the magical (technological) pixie dust. The glib, absolute statement thrown onto the table is a flag that the root cause of the problem is cultural, or even a leadership issue. Solving the problem is going to require a bit more than a little technology delivered by smiling consultants.

Every couple of years I seem to come across another glib “Our brand is everything”. (Though, at the moment the rise of cloud computing is providing more “but its not secure” glibness than anything else.) I’ll be sitting around a table with some senior IT and business folk talking about a broken manual process. More often than not it will involve a workflow based on emailing spreadsheets around the team.

The risks are fairly obvious. Aside from the double entry problems and the risk of lost orders, there’s always the chance of litigation over an implied contract in some casually sent email (or tweet). There’s also the risk for a disenchanted insider sending something they shouldn’t to someone they should not.

After wandering around the issue for a little while, we start discussing possible solutions. My first question is usually something like “What resources are you willing to commit to solving the problem?” It’s at this point that the comment is thrown onto the table; usually in earnest. “Our brand is worth everything.”

Rather than go to the effort actually trying to engage with the problem we’re dealing with, the statement indicates the desire for a magical cure-all. If we sprinkle magical technology pixie dust over the problem then it will just go away.

Technology can only ever go so far to solving a problem. We can use technology to speed something up (swapping paper shuffling for bit shuffling). Or we can use technology to stop specific things from happening (i.e. enforcing governance policies). We can’t use it to prevent something we never imagined.

Most interesting problems — like the manual workflow example — are rooted in peoples’ behaviour, and only have a small technology element. While the action, the bad event might change in each instance, the intent behind the action is probably the same. Even if we were given a blank cheque (which is probably the next thing I should ask for), we can’t hope to make more than a small dent in the problem. It’s like squeezing a ballon in your fist. Each time we push in one bulge, another one (or two) pops up in a different gap.

If we want to have a significant impact, then we really need a mandate to change the way the organisation works. Are the organisations own policies actually incenting employees (or partners, or customers) to work against the best interests of the organisation? (Like the point guard mentioned in the No-stars, all-star{{1}} article.) Do the existing IT solutions cause more problems than they solve? Just why did the problem happen in the first place?

[[1]]The no-stars all-star @ The New York Times[[1]]

Even a mandate has its limits though. Ultimately the behaviour of an organisation is determined by the behaviour of its leaders. The behaviour that caused the problem was a result of the culture created within the organisation.

The most useful tool to solve this sort of problem is the time and attention of the leadership team, along with a willingness to admit that no one is perfect, that mistakes will happen, and a sincere desire to improve the organisation.

When someone drops “Our brand is worth everything” on the table these days, I like to point out that bad things can happen, and will always happen. We can use technology to trap a few things, but the only long term solution is to create an environment when everyone involved — all the way from employees through partners, channels and customers — is naturally inclined to do the right thing.

Yelp seem to be learning this the hard way{{2}}. Accidents will always happen, and speedy and considerate response is acknowledged as the best we can do. However, creating a culture where “doing the wrong thing for the wrong reason” is accepted will eventually get you in trouble that you might not be able to get out of.

[[2]]Inside Yelp’s “Blackmail” Lawsuit: CEO Stoppelman Seems to Hate His Advertisers[[2]]

And hence we arrive at the real problem. A brand’s worth, after all, is a measure of what people think of an organisation; both customers buying your products or services, or the investors who want to know where you”re going. When bad things happen, and sometimes they happen quite regularly, the only real long term solution is to change the way we manage the organisation so that the root cause is no longer present. This means the people at the top need to change what they are doing. And give that the rules of IT have changed{{3}}, and we need to change with them.

[[3]]Some new rules for IT[[3]]

People don’t like change. (Or do they?)

I seem to be having a lot of conversations at the moment around whether people (you, me and everyone else) like and embrace change, or whether they resist it. The same question arises for companies. Like a lot of these questions, I think it depends. As individuals we don’t mind change, given appropriate circumstances. Organisations also want to change (and in today’s business environment it seems to be a question of changing or becoming irrelevant). However, people in organisations are usually strongly incentivised to dislike change, especially if they want to make that next repayment on their new mortgage. Fixing this, and creating a culture that embraces change, means changing the way we think about and structure our organisations and our careers. It means rethinking the rules of enterprise IT.

Every time a conversation comes around to the topic of change, I’m always reminded of a visit I made to a Toyota factory something like a decade ago. It’s so long ago now that I can’t even remember the reason for the visit, but that’s not the point of this missive.

Toyota, like most businesses, loves change. (Many large companies reorganise so often that change seems to be the only constant.) Change, embodied in the development of the Toyota Production System, was what took Toyota from the bottom of the global car industry to the top. Change is also why many of us have moved companies, following jobs as our employers reorganise their operations. For some of us, change is an opportunity. For many though, change is the tool of the man as he tries to disrupt our lives. Change means unwanted relocations, pay cuts, career stalls, or the need to shift jobs when we don’t want to. Change is something to be resisted.

What was interesting about my visit to Toyota though, was the attitude of the workers on the shop floor had to change. They didn’t hate it. They didn’t even resist it. They actually arrived at work each day eager to see how work practices had been changed since the end of their last shift.

A Toyota assembly line circa 2000.
A Toyota assembly line circa 2000

The concrete example I saw of this was the pre-sorting of seatbelt parts into coloured tubs. Apparently only a few weeks earlier the parts had been arranged on a wall. All hooks and dangling parts, like your Dad’s tools in the shed. When a car came down the assembly line a worker would select the parts appropriate for the car model, and then attach them to the car. Each seat belt had roughly four parts, so that meant there was three unnecessary decisions. Unnecessary decisions usually mean mistakes, mistakes waste time and money, and there were a number of mistakes made.

One day a member of the shop floor team had had the bright idea of pre-sorting the seat belts to avoid these mistakes. Some coloured tubs were sourced (some of the shop floor team drove to the local Walmart with a little petty cash), parts were sorted into tubs, and they gave the idea a trial run. Selecting seatbelt parts for a car now only required one decision: which tub?

The idea was a huge success; error rates went down dramatically. I hear that it was even taken global, and implemented in most Toyota factories around the world. (Though being around ten years ago, and with today’s rapid pace of change, I expect that the tubs have been superseded by now.)

What’s interesting about this story is that the change originated on the shop floor, from the assembly line worker who were actively looking to improve operations, rather than from head office as part of a reorganisation. Some of the improvements I heard about even resulted in the elimination of jobs, with the workers redeployed elsewhere in the factory. Workers weren’t just changing how they did something, they were also changing what they did. Change was what made the work interesting and engaging for the workers, rather than being seen as an oppressive tool used by the man.

I think we can safely set aside the idea that works don’t like change, as this story is not an isolated incident. Why then, do so many people resist change? Why, for every Toyota factory, there is a story like the UK newspaper industry, where workers (and unions) resisted change for decades, until Rupert Murdoch came along.

Rupert Murdoch, destroyer of unions, and good Melbourne boy
Rupert Murdoch, destroyer of unions, and good Melbourne boy

The problem is not people or organisations, but people in organisations.

People are funny things; they tend to do what you incentivise them to do. There’s an excellent article over at the NY Times, The no-stars all-star, which talks about measurement and incentives in basketball. We often talk about “what gets measured determines what gets done” from an employee incentive point of view, but this article puts some real meat on the bones of that argument.

Shane Battier, the no-stars all-star
Shane Battier, the no-stars all-star

As the article says (on page two):

There is a tension, peculiar to basketball, between the interests of the team and the interests of the individual. The game continually tempts the people who play it to do things that are not in the interest of the group.

A little later it goes on to mention (on page three):

A point guard might selfishly give up an open shot for an assist. You can see it happen every night, when he’s racing down court for an open layup, and instead of taking it, he passes it back to a trailing teammate. The teammate usually finishes with some sensational dunk, but the likelihood of scoring nevertheless declined. “The marginal assist is worth more money to the point guard than the marginal point,” Morey says.

The point guard’s career is defined by the number of assists he makes (among other metrics), and he’ll try and increase the number of assets even if it’s not in the best interest of the team. After all, teams come and go, while he has a career to maintain.

Once you place a person into a role you have put them on a career path which will determine their attitude to change.

Usually we take an operational approach to defining roles, rewarding people for the volume of work they are responsible for. Career progression then means increasing the amount of work they are responsible for, regardless of what this means for the company.

Measuring a project manager in terms of head count or revenue under management will give them a strong preference for creating ever bigger projects. It doesn’t matter if the right thing to do is create more, smaller projects, rather than run a programme of a few major projects as we have in the past. Your project manager’s career path is to increase their head count and revenue under management. And they do have those private school fees due soon.

Just like the point guard, change that will prevent career progression will be resisted (remember those kids in private school), even if it is counter to the company’s best interests. Which makes the current transformation we’re seeing in IT all the more important, because if we set the wrong incentives in place then we just might be our own worst enemies.

We can’t force a square peg into a round hole; nor can we force our existing employees to take their current roles and careers into a new organisational model. They just don’t fit. Take IT for example. We can’t expect many modern IT departments to spontaneously modernise themselves, transforming into agile business-technology engines under their own volition. It’s not that the departments don’t want to change: they do. Nor are most of the employees, as individuals, opposed (remember the Toyota example). But the combination of people and organisation will repel all but the most destructive boarders.

It’s interesting how other games, games other than basketball that is, have structural solutions to this problem. One solution is the line-up in baseball. From the NY Times article (page two, again):

“There is no way to selfishly get across home plate,” as Morey puts it. “If instead of there being a lineup, I could muscle my way to the plate and hit every single time and damage the efficiency of the team — that would be the analogy.”

Solving this problem in IT means rethinking the rules of IT.

The game of IT has, for the last few decades, been determined by the need to deliver large, enterprise applications into the IT estate. Keep the lights on, don’t lose orders, and automate anything that hasn’t yet been automated. Oh — and I’d like my reports accurate and on time. IT as the game of operational engineering. It was these rules that drove the creation of most of the roles we have in enterprise IT today.

However, this has changed. Decisions are now more important than data, and the global credit crunch is driving us to reconsider the roles we need in IT. We’re trying to reinvent our IT departments for the modern era – I even posted about how this was driving the need the need to manage technology, and not applications – but we haven’t changed the rules to suit.

If we want out people to embrace change, as the people on the shop floor at Toyota did, then we need to provide them with roles and careers that support them in the new normal. And this means changing the rules. Out with the more – more applications, larger projects, more people – and in with the new.

So what are the new rules for IT?