Category: Four pillars

Over a decade ago, after a couple of years as Deputy CIO, I was appointed Global CIO of Dresdner Kleinwort in May 2001. Times were hard, and my brief was harder still: to reduce technology capital expenditure and operating expenses by 50% within eighteen months, while providing “leadership, stability and continuity” to the organisation. At the time the IT department was nearly 2000 strong and spent around £700m pa in capex alone. I was surrounded by many very talented people, and, largely due to their ingenuity and actions, we delivered the goods. I’m privileged to have worked with them, and even more privileged to be in touch with so many of them a decade later.

Some of the things we did were standard, like shutting down remote offices when we were retracting our presence from those regions, renegotiating contracts with core suppliers, stopping activities that were yesterday’s necessities but today’s luxuries, that kind of thing. A few were more non-standard: shutting down our offshore operations in India and Eire, changing our hiring policy to stop hiring laterals and increasing graduate intake, establishing a formal commitment to opensource and to start-ups.

But it all began with our trying to understand our cost and allocations structures. Easier said than done. This was because it was not enough for us to save the money, we had to save it in the right places. We had to reduce it very heavily for advisory services, heavily for equities-related asset classes and services, and less so for debt- and treasury- related activities. Which meant that we had to understand how our costs flowed from IT to each business.

For most of my life, I’ve worked in very large organisations, often as an “official maverick” but nevertheless part of an extensive and complex fabric. And for most of my life, I’ve been astounded by the incredible difficulty I’ve had in getting two questions answered: What do I spend? How many people do I have? Over the years, as my career developed in its own serendipitous way, I found myself in charge of larger and larger departments with bigger and bigger budgets. And answering these two questions became harder and harder.

Perhaps I should have known better. When I was in my teens, my father used to say that the only “truth” on a balance sheet was the cash position; everything else was a “conventional” representation of information. If you didn’t understand the conventions being followed, you had no ability to understand the information presented.

So there we were, at Dresdner Kleinwort, trying to understand how much we spent, what we spent it on, what was discretionary, what was not, why. Trying to understand how many people we had, who was permanent, who was not. Trying to understand the people we had who “didn’t exist”, because they were part of a service contract; they took up space, had kit, had desks, had phones and badges, but weren’t part of our headcount. Trying to understand and appreciate the people who weren’t there but were on the payroll: on sabbatical, on maternity leave, long-term ill, in dispute. Some were even certified insane….

It turned out that we “controlled” a relatively small proportion of the money in the first place, particularly when it came to capex, but true even for opex. Far less than half. A big chunk of our budget related to “sins of the father’, the depreciation associated with capitalised investments from prior years. Some of the money related to long-term contracts where we had no swing room. A portion related to guaranteed bonuses of staff hired in prior years, and a similar portion to the “month 13” payments that were standard in one or more of the operating units. And then there were the things we were legally obliged to do, the projects that related to legal and regulatory requirements.

Then came our allocations and overheads: as the largest shared-service department, we received the lion’s share of the shared-service costs that had to be allocated out, like premises and heating and lighting and insurances.

That didn’t leave very much. Our so-called “discretionary” expenditure was less than 20% of the overall cake. Which made the very idea of a 50% cut interesting to say the least. But we did it, nevertheless.

In that process, I learnt a lot about allocations, augmenting what I’d already learnt in other companies by then. Here’s a sample:

• One firm allocated all its IT costs according to the floor space consumed by each department, something that was easy to calculate. As a result, the investment bankers, the lightest users of technology at the time, were charged the bulk of IT costs.
• It made no sense to me, but apparently it was common practice for one cost centre to charge another. So IT costs for example, not only went direct to the business units, but also via other shared service units. Depended on who did the “sponsoring”; this was probably a throwback to some shared-service manager who wanted his cost centre to look as big as possible, for his CV. But the convention stuck. As a result we had strange anomalies: while our IT costs remained the same, the charge that hit the business unit differed, based on the particular allocation routes and keys used. What this meant in practice was that we “saved” the equities business more money if we took 100 people out of their direct support costs, rather than if we took 120 people out of those who supported equities settlement, whose costs were routed through operations. The idea that two people earning the same money and seated next to each other represented different levels of saving took some getting used to.
• Some labour was capitalised and some was not; if you reduced the headcount in areas where projects were capitalised, the savings took time to flow through. Capitalisation rules were also different for different classes of resource: it was assumed that contractors worked on projects 100% of their chargeable time, but permanent staff spent only 70% of their time on projects, or some such ratio. So the way the costs flowed looked different.
• Shared-service allocations were an art in themselves. In at least one company I worked in, as a result of successive waves of layoffs, there were large swathes of unoccupied desks. Some of these unoccupied areas were islands in the middle of occupied areas, and soon became informal meeting areas. Lo and behold, the areas were chained off and declared verboten, on the basis that you couldn’t use it unless you were paying for it…. even though the company was paying for it anyway.
• In yet another place, we found out that it was more expensive for us not to book a meeting room than to book one…. the allocation key for unused meeting rooms hit us harder than the used version.
• One of the odder effects we noticed was that of project delay. If you delayed the point at which you actually delivered something that went into production, then you delayed the point at which backlogged work-in-progress would start rolling out in capitalised form. [When we froze all code changes during the lead-up to the euro and similarly to Y2K, the monthly charges from IT went down dramatically, even though actual expenditure actually increased…]

By now you should have a feel for the level of complexity involved in allocating costs related to headcount and project and space and shared services in general, by accident and by design. I hope your experiences have been better than mine.

But all this pales into insignificance when you look at how IT infrastructure costs are allocated. Because now you have systems people interacting with accountants and usually a smattering of consultants as well, and between the three a truly Byzantine structure gets formed. When I looked at what happens in the allocation of data centre costs, hardware, storage, bandwidth, market data, and so on; when I looked at how per-processor licence costs were spread out; when I looked at how firewall and security costs were distributed across the organisation; when I saw how operations, maintenance, support and upgrade/fix costs were charged….. I developed a bad case of spreadsheet vertigo.

These experiences have influenced me, affected me, perhaps even scarred me. In fact I think there’s only one form of “allocation” that scares me more than IT infrastructure allocation. And that will be the subject of a post at a later date.

If you have to develop a conventional representation of the costs of your cloud, it’s not cloud.

If you have to create complex allocation keys for your cloud, it’s not cloud.

Cloud is when what you see is what you get, in the context of billing and payment.

Which is why I find all this talk of “private cloud” odd. By electing to retain hardware capital expenditure, by choosing to continue with associated maintenance and upgrade costs, by voting to stay captive within the prison of the related processor-driven licensing models, people are in effect choosing to stay in the world of complex cost allocation models.

Such cost allocation models are part and parcel of why firms find it hard to be agile, to be responsive to change.

In current economic conditions, business agility is no longer a nice-to-have, it’s a must for survival.

Companies that are “born cloud” have this in their DNA; others will have to evolve this capacity, and evolve it quickly.

It’s a tough world out there.

 

 

All projects involve change, an outcome of some sort that can be measured as a difference between the initial state and the end state of something.

All change involves risk. At a level of abstraction, project management may be seen as the means by which something is progressed from initial state to end state while mitigating the risks and while staying within given parameters of time, quality, cost.

For many years I worked in the banking sector, sometimes indirectly, sometimes directly. When I was at Dresdner Kleinwort, we “froze” the systems estate in the lead-up to the euro and to the Year 2000.

Nothing moved.

And nothing broke.

And no progress was made.

It used to be said that nothing is certain but death and taxes.

For some time now, there has been a third.

Change is now a constant. It may sound trite and soundbitey, but that does not alter the fact.

IT departments the world over have grappled with change all their lives, even when they masqueraded under names like MIS and DP. The quantum of change may have varied; the ratio of investment in change (as compared to investment in improving the status quo) may have varied; but change happened nevertheless.

Some changes are cultural, transformational, real shifts. Some changes are global, some sectoral, some geographical, some restricted to a given company or even department. Much has been written about change and the management of change. Much has been written about the agents of change. Much has been written about the toxins that emerge when complex systems are placed under the severe stress of change, and how to handle those toxins.

Over the years, people have learnt a lot about IT systems and change. How the change has to involve people, process and systems. How the change process needs to be designed with the right communications and training plans, so that the change is actually sustainable, and sustained.

This post is not about any of this. Or perhaps it’s about all of this.

The IT industry has always been about change. About progress. Quite often, the material value of the progress was intercepted by intermediaries rather than made available to end-customers. But there was always change. And value created by the change.

And resistance to change. Particularly in the enterprise.

Direct dial phones in the early 1980s. PCs in the mid 1980s. Nonproprietary “open” systems in the late 1980s, along with outsourcing. Internet connections in the early 1990s. The web a couple of years later, along with offshoring. Mobile phones around the same time, the mid 1990s. Web mail a few years later. Java, Linux, opensource software in the late 1990s; push mail around the same time. The cloud in the early 21st century. Social software a few years later. Tablets and touch more recently. Every one of these changes were vehemently opposed by the immune system of the enterprise, playing out the same cards in the same sequence: it’s not secure; it’s not robust; it’s too expensive to change; it breaks regulations. The same objections, in the same order.

Technology adoption tends to happen in three phases: substitution, increased use, embedded and differentiated use. So there is usually a problem to solve, something that is currently being done some other way, something that will be substituted and come to an end of its life. So there is usually an “incumbent”, a way of doing something, either as a formal function or as a workaround. And people are invested emotionally in that incumbent. [Especially those whose livelihoods rely on that incumbent].

Over a decade ago, Clayton Christensen set out the reasons for this incumbent reaction in The Innovator’s Dilemma, and continued with the theme in the rest of the series.

More recently, as I’ve seen the misinformation and disinformation thrown around about the cloud, I’ve been thinking harder about the decision process within organisations, and how incumbents mangle and mutate those processes. Much of what I saw reminded me of the core thesis in Pip Coburn’s excellent The Change Function, which broadly states that technology change projects succeed if and only if two conditions are met: there is a clear problem to solve; and the cost of the project is less than the perceived cost of changing from the status quo.

It’s now almost a year since I joined Salesforce.com, an incredibly exhilarating time, frenetic yet ultimately very fulfilling. Because I now see the possibility that end-customers will actually see the benefits of technology advances affect their wallets, actually put money in their hands, much like Skype did for long-distance telephony. We’re seeing the price of commodity infrastructure, both hardware as well as software, drop precipitously; and, unlike the past, we’re seeing those price changes benefit the customer.

More precisely, those customers who take advantage of the progress; for there are always some who buy the incumbent argument on security or performance or robustness.

The effect of this is to buy time for the incumbent; often, this time is used to influence regulators in order to buy more time. And the customer loses out.

Which is why, for the last three months or so, I’ve been spending time thinking about all this.

And I’ve come to realise something, something I thought I’d already learnt and internalised, but obviously something I have to keep learning.

The cloud is not just about flexibility of access to compute power and storage and bandwidth, or about avoiding the thankless tasks of software installations, maintenance and upgrades; mobile is not just about ubiquity of access; cloud and mobile, together, are not just about the ability to “shift time” and “shift space”; social is not just about getting closer to the customer, about valuing relationships and capabilities; open is not just about the transformation of innovation, about partnering, about collaboration across boundaries.

The cloud paradigm is about all of this.

And about one more thing.

The capacity to change. Designed as an integral function. Native.

Changing capacity, scale, coverage, product set, devices, whatever. The cloud is about launching products, scaling them up, scaling them down, discontinuing them. The cloud is about entering …. and exiting … markets. The cloud is about delivering services to the device of choice; even if it didn’t exist when the original design was made.

The cloud is about change. Not about the steady state.

IT before the cloud was all about preserving and maintaining the steady state. And that’s why so many projects failed, and will continue to fail. A conflict of philosophy, as the agents of change try to batter down the walls of the mechanisms implemented to protect against change.

The monolithic systems of the past, largely concentrated on the back office, were built to achieve entirely different objectives: stable, repeatable processes executed at the lowest cost possible, designed to rebuff change.

The cloud is about change.

If you don’t value the ability to change, if you feel you don’t need to change, and change rapidly, then you’re not going to value the cloud. Because your perceived cost of changing will exceed the perceived benefit.

Soon, TCO calculations will include the change premium, the cost of responding to change in market conditions and needs.

Soon.

But before that, a number of firms will die. Because of their inability to change in time.

 

I saw this video earlier today. I watched it again. And again.

I guess it may turn out that the whole thing was fabricated, that what I watched was an illusion. We live in times where such things are possible.

If you ask me, the video is real. But I’m no expert when it comes to declaring authenticity of such things.

But you know something? I don’t care whether the video was impromptu, staged or otherwise contrived technically. What matters is the message.

The iPhone/iPad generation will have such different views about everything around them as they grow up. Not just about the way they engage with information, the way they make use of information.

Old fogies like me are just getting used to using terms like visitor and resident rather than native and immigrant; I’m lucky, I have three children who keep me in touch with the millennials.

I guess I have to rely on my grandchildren to teach me all about the iPad Generation. And, looking at this video, I am so looking forward to it.

 

I didn’t know Steve Jobs. Like many others I’d seen Steve on stage a few times; we’ve been in the same small room once, but didn’t actually meet. Until this year, when I was at the iPad 2 launch on 2nd March: Marc Benioff had been invited, and he gave me the opportunity to go in his place.  At the end of the launch, Steve came off stage and talked with some of his guests. A nod, a smile, hello, and that was that for me.

I didn’t know Steve Jobs. So why am I writing this? Because I owe Steve a massive debt of gratitude, for teaching me, through the things he’s said and done, some very important lessons over the years. May his soul rest in peace. My thoughts and prayers are with his family; I was 22 when my father died, 31 years ago.

Those of you who’ve known me for a while will also know that for nearly a decade, my personal email address has been [email protected]; similarly, you would know that I’m @jobsworth on Twitter and jobsworth on blip.fm and in a few other places.

There’s a reason for that. A reason why I called myself jobsworth. It all began with a secret project we ran at the bank I worked at, seeking to switch the whole institution from Microsoft to Apple. Secret projects, especially at investment banks, came with codenames. As project sponsor  I could choose the name. And the name I chose was Project Jobsworth.

Why Jobsworth? First, to pay tribute to Steve Jobs, who had inspired not just me but many of my friends and colleagues at the bank, with what he’d done at Apple and NeXT and Pixar. And, as a play on words, to be able to smile when we faced the opposition we knew we would face, the immune system, the inertia, the bureaucracy, the “jobsworths”, as we sought to overturn the Microsoft dominance. Therein lies a tale.

I was privileged to have many talented people working for me there, and the majority were Jobs fanboys. A good number had worked on NextStep while working at a previous place, and were excited about the imminent launch of OSX. There were strong opensource roots in us as well, so the James Gosling idea of OSX being “Linux with QA and style” appealed to us. We’d had enough of the security problems with the incumbent, coming on top of poor trials with SQL Server 2000 and the SPV phone. A number of us had also gotten ourselves iPods, there was a real buzz going. So we went to the management of the bank with our plan. They were only prepared to fund a trial; we were allowed to replace up to 10% of my department’s desktops, to experiment with them and to come back with a formal and detailed feasibility report.

For a number of reasons we couldn’t go beyond the trial. But that’s not germane to this post. What is germane is what I learnt as a result, about Steve Jobs and the way he thought.

The first lesson came to me when we kicked off the project. I visited Infinite Loop a few times, and wondered if Steve would get directly involved. [It was during that time that I connected with Dan Gillmor, then with the San Jose Mercury, and briefed him on the project. I’d met Dan a little while earlier, and the idea was to run an exclusive on the bank’s “big switch” once we got going].

When I queried the possibility of meeting Steve to discuss the project, I was bemused by the response. Apparently Steve wasn’t one to get involved in markets that had CIOs in them, he preferred to deal direct with “real customers”. So, ironically, by proxy I learnt the first lesson: focus on the end-customer in everything you do. From that day onward it changed how I viewed the CIO’s role: I tried to find ways of getting out of the way, of making sure the engineers doing the real work met and worked closely with real customers. In large organisations that upsets people whose role is to be that filter; yet the more I thought about it, the more I saw how it worked at Apple, the more I knew it was the right thing to do.

The second lesson came as we continued with the project, when I met the Apple CIO and he talked us through how his department worked. At the bank we prided ourselves on punching above our weight, using a welter of ways to deliver value at a cost substantially below industry benchmark. For example, in desktop services, we used to have one person per 38 traders, while the competition hovered nearer the 70 mark. Apple were slightly better than us: one per 400. Yup, an order of magnitude better. And as the CIO told me the story I learnt more about the importance of keeping the device simple and easy to use, moving the complexity to the server. Everyone was busy “standardising” the device, going “lock-down” on it; the secret was to keep the edge simple and convenient. [This was a theme that Jobs repeated, much later, in an interview with Steven Levy in Newsweek in October 2006, excerpted here: “One of the biggest insights we have was that we decided not to try to manage your music library on the iPod, but to manage it in iTunes. Other companies tried to do everything on the device itself and made it so complicated that it was useless.” So lesson 2 was to focus on simplicity, not on standardisation.

The third lesson was in 2007. By this time, Apple could do no wrong, and the company was moving from strength to strength. One of the questions I was repeatedly asked was how come I could be an opensource devotee and a Jobs fanboy at the same time. I wondered about it myself, but I wasn’t giving up my Mac or my iPod and had every intention of getting the iPhone. So I pondered about it. And then I saw this interview with Steve, “Thoughts On Music“. And reading it, many things became clear to me, or at least clearer. His perspective on the music industry, the pointlessness of DRM, his [then] reasons for implementing DRM nevertheless, the whole essay proved very instructive. The bit about the industry continuing to sell unprotected music via CDs while arguing for protection in a digital world really got home to me: at the time 90% of the music sold was via CD; even though the ratio has changed, dramatically, since then, the point continues to hold. Copy protection has its pros and cons: what Steve’s essay taught me was to view the industry (and many others) with an important change of perspective, to look very carefully at the analog state of “copy protection” in an industry before designing for the digital world. I’d never liked region coding on a DVD, believing it to be the single stupidest technical design decision I’d come across. Now I understood why I felt that way.

The next lesson came a little later, when I re-read the 1985 Playboy interview with Steve. More things became clear. For example, Steve didn’t start off not dealing with CIOs, both at Apple as well as at NeXT he sought the business end of the market. So it wasn’t an animus against CIOs per se. Similarly,  I was very taken with the story of Steve, Andy Warhol,  the Mac and the boy: “Older people sit down and ask, “What is it?”, but the boy asks, “What can I do with it?” Reminiscent of Sugata Mitra and his Minimally Invasive Education.

But the real lesson, one that stuck with me when I first read the interview, one that was refreshed by my re-reading it, was to remind me about the purpose of education. The way Jobs said it : “…. Western rational thought is not an innate human characteristic. It is a learned ability. It had never occurred to me that if no one taught us how to think this way, we would not think this way. And yet, that’s the way it is. Obviously, one of the great challenges of an education is to teach us how to think.”

Much later, sometime last year, I read this article by Steven Johnson, an author I admire and respect. In it Steven, a confessed devotee of open platforms, looks at the success of the App Store and comments eruditely on it. And while reading it, I realised again just how Steve Jobs thought relentlessly about the customer and simplicity and convenience in everything he did. And then I realised that all my previous lessons were just one lesson. Concentrate on the customer. Everything else follows from that.

I’m lucky. I work somewhere where this is practised. I work for someone who knew Steve personally, and the influence shows in the focus on the customer.

I’ve been a Jobs fanboy for a very long time. And I will continue to be one as long as I live. Steve Jobs, thank you for the way you changed the way I think. Thank you for being part of my education.

[Note: This is a follow-up to a post I wrote yesterday, which you can find here. Based on the comments, tweets and messages I’ve received, I felt it was worth adding this little coda. And I wanted an excuse to link to one of Joe Cocker’s fabulous versions of the Beatles song.]

 

There are many gratifying things about my job: one of the most enjoyable aspects is that I get to meet a lot of people and to listen to what they have to say, to learn from those conversations, to distil and refine that learning.

When people have come and engaged me in conversation about gamification, there’s been a lot of passion about the whys and wherefores and why nots.

And a little wistfulness.

Yes, wistfulness.

You see, the hype made it sound as if gamification was a knight in shining armour come to rescue the damsel in distress, the drudgery of work. And while they knew this was somewhat unlikely, they hankered after it. They wanted work to be fun.

This is what prompted me to speak about “not putting the lipstick of gamification on the pig of work.”

If work sucked, we needed to fix that. It wouldn’t happen through superficial tools and techniques. It needed something far more drastic.

I’ve always enjoyed work, even when I’ve fouled up, even when things haven’t gone the way I’d have like them to go. Because I see everything as a learning experience, and, quite often, I learn more from my mistakes than I do from my successes. Esther Dyson used to sign off her emails with “Always Make New Mistakes”, a principle I love.

So for the wistful among you, here’s one way to make work fun by borrowing techniques from gamers and the gaming industry, a “gamification” that requires radical changes to be made to the workplace.

Like getting rid of the blame culture. What if we could move to a world where Edison’s “I have not failed, I have found 10,000 ways that do not work” is implemented as a work principle?

Some games give you the facility to pause and resume later, some give you the facility to record and replay. [Now this tends to be more common in single- and dual-player games than in MMORPG, for obvious reasons. But the principle remains valid].

What if we could pause, resume, record, replay work? What if someone else (peer, mentor, leader) could sit with you and say “You see this? You see where you went wrong? Here’s how to do it next time round” ?

You know something? We’re not far from such a time and place. Activity streams have their supporters and their detractors, but one thing is sure: they’re here to stay. And, if we learn to use them properly at work, then we’re going to start seeing early versions of activities that can be frozen and resumed, started and stopped, saved and replayed.

If we do it right, that’s the end of the blame culture.

With a little help from my friends.