The new power of the cybernetic employee

Mark Pesce of FutureSt Consulting considers how work gets done differently in the new mobile enterprise.

Interview conducted by Alan Morrison

Futurist Mark Pesce heads his own consultancy called FutureSt, lectures at the Australian Film Television and Radio School, and is an honorary associate at the University of Sydney. He co-invented the Virtual Reality Modeling Language (VRML). In this interview, Pesce sheds light on how enterprises are adapting to the way workers in a cybernetic system do their work.

PwC: One of the main points we’re making in this issue of the Technology Forecast is that the enterprise workforce is really a cybernetic system, with workers becoming inseparable from the devices and the personalized information clouds they bring with them. How should enterprises adapt to accommodate these cybernauts?

MP: What’s happening is that the cybernauts are bringing their own mind-set. If you took away the device, the mind-set would persist, and it does. You can think of Web sites as devices. Corporations can block Web sites, but that doesn’t actually change the way people are thinking.

Cybernauts don’t really respect the layout of the information flows as dictated by a hierarchy. That is the core first principle that you need to work from. The information flows they use probably don’t have anything to do with the hierarchy of information flows that have been established over the organization’s lifetime.

Toffler called this the adhocracy 40 years ago. We’re now seeing what the adhocracy looks like and how it has been facilitated, because everyone is now walking around with the equivalent of 1980s Cray supercomputers in their pockets. Everyone now has tools to manage that. The CIO must come to terms with the fact that everyone is walking around with significant IT capabilities. People don’t think of these as significant IT capabilities, but they are.

That then changes the equation. What is the CIO doing? The CIO was responsible for protecting, preserving, and defending the corporate data and for providing a way for the corporation to access that data. He or she still needs to do that, but in some ways that’s become significantly less important because everyone walking into the organization is bringing their own IT infrastructure and all of the powers and capabilities that that gives them.

There will be arguments between these various IT capabilities. One set of IT capabilities will tend to inhibit another set of IT capabilities. We don’t really have any good mechanism in place for arbitrating that. Maybe that’s where the CIOs need to start thinking. How do you arbitrate? When an employee comes in who is better connected than anyone else in your entire organization, how do you arbitrate with that person’s capabilities? How do you allow them to deploy those capabilities meaningfully without impacting your own organization?

We find this now with Twitter. Twitter has been the paradigmatic example of how organizations can spring holes in their fabric because people will just start Twittering about all sorts of stuff.

Some organizations have still not established social media policies, which to my mind is almost an impeachable offense. The ABC here in Australia has basically gotten it down to four lines:

Do not mix the professional and the personal in ways likely to bring the ABC into disrepute.

Do not undermine your effectiveness at work.

Do not imply ABC endorsement of your personal views.

Do not disclose confidential information obtained through work.¹

But of course, just tell people this. These are rules of thumb. They are common sense, but people need to know it, and the organizations need to know it. And a lot of times when this doesn’t happen, the organizations get in huge amounts of trouble.

Organizations have spent a tremendous amount on collaboration tools, but aren’t employees just going on the Web and using what’s there, because those tools are simpler and more powerful?

One time I was brought in to persuade a vice chancellor of a university to embrace Web 2.0, because the university’s own IT department was not taking advantage of social media and the students themselves were going to use external resources. I had to show the department this conversation was happening without them, because they were not providing a place for that conversation to take place. The IT department strictly controlled the Web sites that could be handled through the university. We did a survey and found that 60 subterranean Web sites were being run by different programs in the university, because they needed a wiki so they could share their work with colleagues on the other side of the world.

When the IT department is not providing the solutions to people’s problems, people will immediately go outside because such a wealth of things is available. People are constantly saying, “Oh, look at this great cool Web site! That solves my problem.” And they’ll start using it.

So the IT department now isn’t just managing for itself—it’s competing against all of the rest of the Internet for its users, the same as any normal portal Web site would be.

How should we think of tablets like the Apple iPad? Are they primarily for data consumption?

We’re just at the beginning. In 10 years’ time, we will not be thinking about the tablet primarily as a consumption device, which is where Apple and [Steve] Jobs think it is. By 2020, after we’ve had 10 years to evolve how we manipulate that interface, we’re going to think of tablets as consumption and creation devices.

How should the CIO think about the mobile applications environment as it is changing?

The easy way out is to grasp the HTML5 bull by the horns, because then you have something that will be cross-platform and that will work on your PC, your tablet, your smartphone….

Is that the default if you don’t have a lot of resources to dedicate to this?

I would think so. How many examples of amazing HTML5 applications are we going to have to see before we understand that, yes, you do lose something if you’re developing an app that’s platform specific versus HTML5? Generally, for mobile applications, what you lose by developing for a specific platform will not be significant because the devices have locative capabilities and they have full HTML/HTTP capability, which is basically what you’re going to need. You might not need fancy access to the camera, for example, although you might need some access to the camera. There are tagged images you might need, for example, but you can send people out to the field with a simple app to take photos that they will upload to a database. That stuff is easy. But for data entry and data analysis activities, I think the organization should be looking at HTML5. That’s the foundation for the next 10 years.

One reason the Apple iPhone app culture developed was because HTML had become rather retarded and stultified, in that there were no major improvements from 1996 on. The app culture on the iPhone was the real kick in the pants. It was the competition HTML needed to go to the next level. But now that it’s there, it would be wise for people to think about their deployment strategies around HTML5.

Srini Koushik of Nationwide [see the interview on page 44] thinks the mouse and keyboard interface is going away and being replaced by the multi-touch interface. Is it?

Gestural interfaces will evolve over the next 10 years. I don’t see gestural interfaces as being fundamentally incompatible with HTML5. It will take some time for them to become fully blended. In 2015, we won’t be having this conversation, because they will be fully blended. We already have some of the JavaScript hooks in HTML5 for gestural interfaces. We’ll just see more of them. Apple, Google, and HP will be pushing very hard to do that because that’s going to be a core foundation for Android, iOS, and webOS.

So HTML5 will take care of, perhaps, 80 percent of enterprise needs?

Perhaps it’s 90 percent. HTML is your low-hanging fruit. So you’ll think about how to farm out your 10 percent to a tiny little app that’s not going to take much development time to deploy, but does just this one thing that you can’t do in HTML5.

The nice thing about the app culture is that it has radically rethought what the app should do. It can do one thing. It does it well, and you’re out. As opposed to Battleship Word, which has grown and grown and grown and grown? It’s the exact opposite methodology.

Will native apps silo the data and inhibit sharing in the process?

Native apps use HTTP. They may use a socket, but probably not. Here’s the way to think about an app. An app is basically a really well-engineered UX [user experience] in front of Webaccessible data. An app does one thing really well. An app is the front end, rather than anything that has to do with the ontology of a data set. It will become problematic if everyone thinks about an app as a silo of its own stuff, rather than a nicely engineered UX to a set of data.

When does it become necessary to develop native apps?

An app provides a user experience that is difficult or impossible to provide via the Web. The temptation with the app is to remove functionality rather than to increase it. Consumers will reject that. They expect any app to have the same functionality that the Web does plus what the Web can’t do—not less.

Some Web designers have definite biases toward particular technologies. Should enterprises be selective about what development tools they offer?

There’s no one right way. You need to offer multiple methodologies. This is the part where the CIO becomes involved. Rather than saying that this is the right way to do it, offer the data up and allow the communities that use that data to project that data as it’s best for them. That’s a policy decision, not a design decision. That’s the essence of mashup culture. Google has been very good about that. Behind that simple interface is a whole set of APIs [application programming interfaces] that allows you to use the data almost any way you like.

Are mashups a leading indicator of how work might change given these kinds of developments? More people able to do more kinds of reporting, with less need to go to IT for reports? People who don’t have developer skills but are able to step in that direction?

I’d love to see something like Google App Inventor or a similar tool for iPhone like Titanium that allows you to write an application in HTML or JavaScript and then compiles it into Objective-C. When you get tools like that, you significantly decrease the barriers to entry. App Inventor allows you to program Android by dragging block components into place. They use it as a teaching tool, but with it, an IT department could say, “Here’s the corporate data, and here’s a couple of blocks. Put the blocks together the way you want for your division.” Over the next 10 years, those tools are going to become more pervasive, the quality will go up, and the ease of use will go up.

It won’t be a weird decision or a hard decision for an IT department to make. IT can say, “Here’s the data. We’re not going to mandate how to use it.

Here are some tools. Here’s what our designers think you want to do with it, but you folks can go make them.”

Will this lead to more app sprawl and a more pressing need for app rationalization?

Because the app itself is generally just the viewing controller, the model [in a Model-View-Controller, or MVC, scheme] doesn’t change. Even if an app ages, the data that the app is manipulating is in the corporate data center, and it’s fine. So if an app ages out, you’re not losing anything, even if you discontinue support for that app or if there’s an operating system revision and that app no longer works.

The more a company can hew to that idea, the safer it’ll be. You’re never going to be completely safe. Of organizations running Windows, 60 to 65 percent are still running XP, even though Microsoft said the company will stop supporting it. It’s that same problem, but I think it’s proliferating much more broadly. The problem being, of course, that a data migration from XP to Windows 7 is difficult, and there will be losses. But if you’ve done your app strategy right, it shouldn’t be a lossy transition. But again, that requires policy—architectural policy, not so much design policy—around “Here’s how we expect you will work with the corporate data. If you don’t do this, it will be bad.”

Is the big shift really entrusting more power to more people, which implies the need for policy changes and more training?

Review policy will be important. You do still want to say, “Hi, send us your code. We’d like to look at it because we just want to see if you’re doing things that aren’t going to come back to bite us in two years.” There will need to be a review process. But you’re empowering users to work with the corporate data as they want to. Yes, it requires more training and trust, and it requires more policy.

What’s the implication for talent here? What kind of people do organizations need to attract, given the trends you’ve just described?

We’re getting to the point now where more and more people—for example, those coming out of university—have a smattering of Web skills. If that means they can get a better job in accounting, that opens up the doors in ways we weren’t thinking of before. It allows us to tweak the requirements a little bit. It does mean that organizations need to communicate the new requirements to the education sector, so that students are getting the necessary credentialing before they come out and work.

But often the students are picking up these skills informally as much as they are from formal coursework.

Absolutely. They’re picking it up on the street. But teaching someone the MVC model? That’s not rocket science. Implementing it beyond a certain point requires some training, but teaching people how to build something that doesn’t break when you start changing things—that’s a course that someone could easily get in their college education. It’s a course that could be called something like “Corporate Data Systems.” If people are going into finance or administration or marketing, then this course should be part of their curriculum, just to give them that background. Then, when they’re exposed to this stuff at the office, they know what they’re doing.

Should enterprises look for people who are different from the kinds of people they’re used to looking for?

It’s going to be a bit of both. Those different people are starting to come through the door. There’s a bit of a mismatch, because in some ways those employees aren’t being fully utilized. And that’s probably leading to some dissatisfaction on the job as well, because they feel they have a set of skills that’s broader than what they are engaging by playing with Excel all day, or whatever it might be. And so it’s almost the strategy for employee retention more than anything else. If you want to retain them, the more you can keep them entertained with tasks that challenge them, the better.

One thing we didn’t touch on that’s relevant: the quality or nature of IT policy as it addresses what’s outside the organization. What happens when employees are going more exterior than interior for their information?

What that means is that those chains of authority and hierarchy inside the organization are bypassed [as discussed earlier]. It also means those employees are building chains of authority for themselves that exist only partially inside of the organization. Organizations as we’ve known them aren’t at all prepared for that. Everything becomes much more fluid and fungible in that environment. But that’s part and parcel of what happens in 2010 when your 22-year-old college graduate walks into work and whips out his smartphone. That’s who that person is now. They’ve got chains of connection that are inside and outside—on Facebook and LinkedIn, as well as inside the building.

The way that the organization counters that is through digital social networks inside the organization. Inside the organization, those are networks of expertise. The CIO needs to get on top of that, to be one of the key catalysts for that transition. That data is immensely valuable to the organization because it’s creating a force to pull employees in, even as they’re intent on building outward. It provides the internal force that employees will need, because otherwise they’re going to tip the ship over.