Transcript - Paul's speech for Public Service Innovation Month 2015 (July 2015)

Presenter: Good morning everyone. Thank you all very much for coming. Some of might have seen Paul earlier in the week when spoke at an IPA event, but many of you wouldn’t have, and you can’t hear this message too often, and you’re going to hear it often. And it will evolve, inevitable. The executive agency, the Digital Transformation Office, formally began in our portfolio on the first of July. Of course, there’s been a team of people seconded to work at it since late last year. So Paul has come in at a really interesting stage. Decisions have been made about strategy, but there’s a lot of implementation detail that Paul is looking at and trying to work out, added to that vision that the government had for the DTO, into an operating reality. For Paul himself, he comes to this job with a really interesting background. He has this mixture of private sector in both the large, multinational corporate end, and private sector in the start-up end. He has public sector experience; he’s worked in line agencies in the United Kingdom government, and he’s worked in the central Government Digital Service in the UK as well, so he’s seen the DTO-type activity from the edge, and from the centre. He’s something, as I said on Tuesday, of a citizen of the world. You might think at this stage that he’s a Pom, but you’re about to find out that he’s a most unlikely Sam Dupont, and we’re sure as hell not going to talk about the cricket, Paul. That’s one thing I can say for sure. So please join me in welcoming Paul Shetler. 

Paul Shetler: Thank you, Drew. So this is where I come from, from the States, actually, and I moved to the UK about 13 and a half years ago for a variety of different things. I’d like to talk about the DTO, though, and why we’re here. That’s sort of the one question that everybody sort of wonders, ‘Well, what is this DTO, why are we doing digital government, what’s the importance of it, who are all these people, what are they doing?’ And I guess the first, most important question to answer is, we’re here because people are online. People went online for the last 20 years, 25 years, depending on how far back you go, whether you’re an Internet pioneer or not, the fact is an awful lot of people are online, increasing amounts of their lives are lived online, whether that’s through social networks, or whether that’s publishing, or whether it’s buying coffee, or going on holiday, or buying books, or whatever. Increasing amounts of activity are online. That’s the way that we interact with each other, increasingly mediated online. And people’s expectations of services online, including government services, are shaped by their others, right? So, you’re used to a certain level of service whenever you buy something, and then you find another one, you make comparisons. So just some stats [gesturing at slide]. This actually does show, yeah, people are online. Should be no big surprise here. 92% of Australians use the Internet. About 50% of those are using a tablet computer. And a lot of people do shopping, it’s sort of shopping, maybe commerce, and service provision, which actually informs an awful lot of people’s perceptions of online. And some exemples of that. You know here [gesturing at slide] we have, you know, Amazon, Uber and a bank, but you could put up anything else, Expedia or, you know, gosh, you know any one of a million different e-commerce or service systems. And you’ll notice a few things about them. They’re almost always associated with things that are pleasurable; they’re almost always things people seek out - they’re not things that are usually chores, but things you want to do. So you want to go on a holiday, you want to buy a book, you want to buy a video game or something like that, you’re going to go online pretty much to buy it. And actually, that might be increasingly the means by which it’s delivered to you as well, right? So it’s not just the buying of a physical thing, but also the delivery of a digital thing, digital becoming the primary channel for delivery of products and services. They’re clean, they’re simple, they’re well-designed, not much gets in the way between you and meeting whatever need it is that those apps or service provide. Because if there was something that got in the way, you’d probably go to another one, right? Because they operate in a competitive marketplace. If they didn’t do that, they’d go out of business. So you could, for instance, book a trip to go somewhere online, Expedia, or whatever, Kayak. 

But if you then went from that to find out what you need to do when you get to the other country, maybe from Australian Government websites, right, because trusted sources of information, you’d have a problem. Because all that simplicity just went out of the window. Now you’ve got a whole bunch of different sites to look at. You’ve got a lot of information which you need to know, or you think you might need to know, which is fragmented across all these different sites, which look different, which tell you different bits of information. Learning how to use one doesn’t help you know how to use the other, because the only thing they have in common is that they have nothing in common, alright? And you never really know if you’ve got all the information you need, because it’s not typically approached from the question of what the user needs. It’s that, ‘Well, the Department wants to get this information out, this agency wants to get this information out, it’s a piece of policy to publish this particular thing,’ but actually, if you look at it from the standpoint of someone who’s making a trip, and wants to find out what they need to do in terms of foreign currency, or something like that, where do they go, to get all of it, to make sure they got all of it? They have to have in their head either all that information already, and then they’re just double-checking it, or they have to have some sort of map of the way government works. You know, that I go here, here, here, here, here, here, and here. And then be able to sort of navigate different ways of doing things. And if you think about that, that’s kind of crazy. It’s kind of -kind of cooky. There’s no business actually that really operates that way, right? If Amazon did that, or Uber did that, you wouldn’t use them. If you had to go to 15 different websites to buy a book from Amazon, you just wouldn’t do it

So it’s not just me saying this. Here some surveys [gesturing at slide]. 55% of Australians said they have problems when they’re using an Australian Government website. Now consider that most people’s lives are lived increasingly online, and yet so many of our users have problems when they use our websites. And when they have problems using websites, typically what’ll end up happening is either they won’t get the information they require, in which case, if there was some policy information for putting it out there, it might be obviated, because you won’t be able to tell them, they won’t know it, or they’ll call a call centre, or go into a drop-in centre, or something like that, in which case you have failure demand: ‘I wasn’t able to get it through this channel, so now I have to address it through another channel’. And the problem with that is, it’s very expensive. We need to do a lot better. It’s very expensive, and it’s not really acceptable, in the age of Uber, AirBNB, Amazon, and things like that, because people - we’re all used to it right? I say ‘People,’ I should say, ‘We’. We in this room are all used to that. And we’re all public servants. So everyone in this room has dedication to public service, everybody in this room cares about the people who we’re serving, we all do, we’re all here. In many cases, we’re hamstrung by the ways that we are forced to communicate out to the outside because of the way we organise our digital presence, and because of the tools that we use to work, whether they’re machines that you can’t, whether they’re PCs that you can’t use to print a document with, or that you can’t connect to a projector, or, you know, you can’t send an email, or you can’t copy a URL, or something like that, all of which I’ve seen in my three weeks since I’ve joined. We need to do a lot better, because we can’t meet user needs if we’re working that way. And if Amazon or anybody else tried to meet user needs by asking people to ‘Please take a PDF file, print it out, and send it to them via post, and then have somebody read that PDF file, type it into a system, and then maybe copy and paste data from a few other things after the human API,’ they would go out of business tomorrow. They couldn’t possibly handle - couldn’t possibly handle the demand. So we need to do a lot better. 

If we do, you start seeing some of the benefits. These [gesturing to slide] are simple financial benefits, quite apart from making really happy users, we can also save an awful lot of money. This is from a report that came out on Monday, some of the interesting takeaways from that. But a digital transaction costs about 40, 40 cents, 41 cents. Telephone costs 16 times that much, $6.60. By post, $12.79. And if you’re doing it face-to-face, it costs about $16.90. This is from the Deloitte study that was just published. So you can see that not only is it not even a really good user experience, it’s also really expensive. We can lower the cost, and we can provide better services. We can do better for less, because in many cases the high cost is the high cost of doing things not as well as we could, or not as well as we should. 

And our opportunity is huge. Our opportunity is huge. So not only can we save a lot of money, but we can also start restoring public faith in government, because one of the biggest problems that every government is facing around the world right now is lowered budgets, less money to spend, increased demands, and the fact that many citizens are saying, ‘My gosh, can’t you do better than this? Everyone else seems to be able to do better than this. Gee, why can’t you do better than this?’ And there’s a drip, drip, drip of inadequate service; it’s the death of a thousand cuts, that undermines public faith in government. That is why we’re here: to fix that. It’s not a policy issue, it’s a delivery issue. Everybody in this room cares about that. All public servants care about that. We’re doing our best now to work with you to fix that. 

The vision that’s been laid out for the Digital Transformation Office, and the ambition that Australia has, is to get rid of that need to carry that map of government in your head. So you, as a citizen, we as citizens, don’t need to know that to - when I have a baby, I have to go to this Department and that Agency, I have to talk to this Agency in this state, and then do something in this locality, in this particular order, and if I don’t do that right, things might go wrong. But no, I just want to have a relationship with government, because people think of government as government. People really do. In our own departments, we might think of departments as our departments, I certainly think of the DTO. But actually, where do Australians go? And that’s what people think of us. So we need to start representing ourselves back out that way. That is how all online experiences are perceived by their users, and that’s how they’re all presented now. So we have an opportunity to do that, we have an opportunity to fix service across channels, an opportunity to radically redesign and radically improve the citizens’ experience of government, and put Australia in the forefront. Every other country that has tried doing this has had a more limited ambition, I think. If you look at what happened in the UK, they’ve done great work. GDS working from the centre, worked with departments to redesign both the experience of using the web, in government, so the publishing platform, so when you wanted to find information, it all looked the same, it was all consistent, it was all organised in the same way. Knowing how to go on, you know how to use the entire site. No longer do I have to figure out 1,300 different websites. I have one website. That’s absolutely brilliant. And they started working on fixing the actual services, the transactions, the interactions, when you want to get something from the government, right? But that was only central, and an awful lot of what happens in the UK is done by the NHS, which is not part of that, in terms of GDS, nor is all the work that happens in the localities. In Australia, we want to go beyond that. We want to provide a framework so that people actually can have user journeys across departmental, agency, state boundaries. That’s huge, because that’s how people get to have that relationship with government. 

The other thing we want to do is move beyond the idea of a digital channel that speaks of it as separate to everything else. So keeping in mind that actually sometimes, things do need to be done face-to-face, and when I do that thing face-to-face, it needs to be reflected by the digital channel, so I don’t have things perhaps happening in separate little silos of government that don’t know about each other. That’s also how we’d be able to drive channel shift, right? If we want to realise the financial benefits of digitisation, we need to own all the channels, we need to be able to do service redesign across all those channels, we need to make it a great experience, and we also need to steer people towards the digital channel as the channel of choice, and provide assisted digital service for those who cannot or will not use the digital channel. So the opportunity is absolutely huge, both in terms of user satisfaction, which is the number one thing, and in terms of cost, which hopefully should fall under that. 

And the way we’re going to get there is by doing things a little bit differently. So at DTO, our slogan is ‘Users first’. So you can have a brilliant policy, but unless actually users choose to use that, the service you’ve decided to implement that, the policy will be obviated, it doesn’t matter. If people don’t use it, it doesn’t happen. The only way you get people to use what you want to do is to do what they actually need. Service has to be focused around the needs of users first, not of government departments, not of government agencies, not of particular bureaucracies, but of the actual users who use them. We need to actually talk to the users, see what they do, not only ask them questionnaires, not only get feedback that way, which we then can interpret however we want, but actually see what they do when they use the service. What do they actually do? How do they actually act? Don’t ask them questions always, also watch. See what it’s like for them. And have some empathy and some humility when we do that, because we don’t necessarily always know what’s best for our users. We need to let them let us know. 

Thinking big and starting small. So that kind of a vision of government as government, rather than of state, local or department, or agency, or whatever, is a really big vision, it’s bigger than any other vision that’s out there right now, and we’re not going to get there by trying to do it all at once. We’re not going to get there by trying to boil the ocean. We’re going to get there by doing small things, delivering them very quickly, and then iterating them, changing them, improving them, making sure that they actually do meet user needs, and then continuing to do that as we go on. So it’s a large, it’s a long-term program. We’re not going to say it’s all going to be delivered at once, because it won’t be. We can deliver it over a period of time in chunks, slices and increments. That’s the only way to get things done, right? You can’t wait to deliver everything before you deliver anything. And in doing things and getting things up quickly, we’ll actually have a chance to see what works. 

And that brings us to the next point. So the DTO is all about quick delivery. Mike Bracken from the UK liked to say, ‘The strategy is delivery’. And that’s quite right. Delivery lets us cut through the morass of strategy and policy options, and looking at edge cases, and ‘What ifs’, and so on, and all the ‘What-aboutery’ that can happen, but actually focus on what people actually need, how are they using it, what’s actually happening when they have the service, how can we watch them and learn from them, so we can provide the best possible service for our users? That is why we’re here as public servants, so we can provide the best possible services for the people of Australia. You can only do that by getting things out there quickly, so we can see what people actually do. Remember, if somebody’s having a baby, or somebody needs to visit somebody in prison, they don’t have a year for us to figure out our act. We have to deliver quickly. We have to deliver in human time scales, and not geological time scales. 

Once we’ve done that - once we’ve done that, we have to iterate and improve rapidly, so iterate wildly. That might mean improving the service one, two, three, four, five times a day. That’s the kind of time scales we’re talking about, that’s the kind of time scales our commercial - that’s happening in the commercial world. Google does hundreds of updates a day to their software, right? Amazon updates their hundreds of times a day. We need to be able to start doing that. We need to think that way. In the UK, where I came from, that is how our teams worked. We were able to do that, and deliver great services quickly. That’s how we learn from our users, and that’s how we make changes. It also means that when we deliver a small, incremental change, or an incremental service, people don’t say, ‘Oh, well, you’re just going to walk away from that, and screw you’. Think about how traditional IT tends to work: there’s lots of promises made up front, big grand specifications, and then something is delivered at the end, which meets a certain amount of those specifications, there’s usually a certain amount of disappointment, people say, ‘Oh yeah, well, guess what? We didn’t really understand everything about it at the beginning of the project. Now, we’re going to have to make some change controls.’ Our idea is to get rid of the change control, have change control be subsumed into the process. We’re not actually delivering something and then walking away from it; we’re constantly improving it. That way people know we’re darn serious when we’re talking about minimum viable products, and they understand that we are sticking to what we’re doing. 

And that leads to the final idea, which is, we’re not delivering projects, we’re delivering products. And there’s a big difference between that. So a product has a beginning date, and it has an end date. And at the beginning is when you typically know the least amount about what’s going to go wrong, and what the needs really are. It’s when you think you know everything, but actually you know the least. And every single moment after the beginning of that project, you’re learning a lot more. You’re learning what does work, you’re learning what doesn’t work, right? And then, at the end of that, you’ve delivered something which might be 50%. What we’re saying is, we’re delivering a living, breathing product which we deliver quickly, which we iterate constantly, which is not something which we just walk away from. It doesn’t have an end debate. At some point, we may say, ‘Well, we’ve met most of the user need, we’ve reached into a steady state,’ at that point we can move it to maintenance. But it’s not a beginning and an end in the traditional way of doing things. It’s a product with an evolution. 

I’ll give an example of what I mean, because this might seem really abstract. So when I was at Ministry of Justice, I was responsible for delivery for four of the government’s exemplars, and I had about 16 other large, you know, digital products, which we were delivering. Some of them were informational services, some of them were transactional services, but it was a portfolio of 20 actively developing products, all of which were released very rapidly within a 20 week timebox. So from our perspective, from the team’s perspective, the product manager, who’s the person who’s responsible for that, had to deliver something which was certified as ‘Live’ by GDS, sort of the central digital team. That meant that they had to have something out to the public for actual view and use within about eight weeks, and then we put it through Beta, the motor period, and the lumber period. And there were stage gates where we would check, and say, ‘Did you meet these various criteria?,’ right? So getting something out in that kind of timeframe - eight weeks is a bit different than the usual IT timeframe - means that you have to think radically differently about your stuff. 

So here was one exemplar. This is for Civil Claims. For people who are not aware of what Civil Claims is, it’s basically when somebody wants to go to court, to get money from somebody else, in the sense of, ‘You owe me money,’ or wants to get you out of their flat, to repossess a flat or something like that. So it’s a claim against another person that’s not a criminal claim. It doesn’t involve the state trying to prosecute somebody, it’s somebody who wants to get money from somebody else. There’s a lot of them. Well, the team had signed up for the exemplar to do ‘Civil Claims’. That meant everything, right? And that’s what the initial expectation was: all Civil Claims in the UK would be done in a digital manner, and they would be delivered that way by the end of March of this year. So I joined in January 2014. And the team at that time had no idea how they were going to deliver this, because that’s massive. So this map just sort of shows, what could be called the service map, and it shows all the different entry points where people can actually start the process, who needs to act in the process, what the documentations are, the different bits of information, what the flows are, and so on and so forth. And you can see it’s fairly complicated. And there was really actually no way that something like that could be delivered in one big bang. And in fact, my product manager at the time was, you know, rather concerned that there was no way he was going to be able to do that. The team didn’t know how that was going to happen. And I had to go back to my manager and say, ‘We can’t deliver this within the timeframes you’re talking about, we have to take a different approach’. And the approach we decided to take was that we would look at what bit of functionality could be provided, or what user need could we beat, within a real short time frame - 20 weeks, all the way through. And we realised there were a few, where we had a lot of users, and a very particular problem, and therefore we could do that, we could just deliver that, focus on that particular thing. And then we could add another bit, and then we could add another bit, and then we could another bit. And that’s the approach we took, and that’s how we got that out certified ‘Live’ by GDS in 20 weeks, the product continues to be iterated, and, as time goes on, more and more bits and pieces of this map get filled out, until finally the whole thing is done. You can think of it as, rather than putting your entire library of books up at once, just think of it as putting up a shelf and a few books in there, and then you add more and more and more until the entire bookshelf is done. Every single time you do that, though, you actually meet a real need. That’s the important thing. You’re not just putting something out there that people don’t use. Every single bit of it has to be something which provides real value to users, and that is part of the art of product management, that is why product management is a discipline in its own right, and why it’s not project management: because we have to understand the needs and understand what will actually work, and how those things can be put in a particular order to make sense to a user. That’s the approach we took, and that’s the approach we take in the DTO. We often get people who believe very strongly in quick delivery, iteration, and meeting needs. 

So, DTO, we are a month old. I’ve been with DTO for a couple weeks, about two and a half weeks. You know, we’re all about digitising Australian Government. We’re a team of part managers, delivery managers, user researchers, interaction designers, developers, technical architects, web op engineers, and so on and so forth. We’ve got pretty much all digital specialities inside the team, as well as some more generalist and policy experience, to make sure that we can remove obstacles to digitisation. And we work closely with other departments and agencies, and increasingly states and localities to deliver our services. That’s who we are, and that’s what we do. 

We think Australia can become the best in the world, absolutely the best in the world, at delivering digital public services. We have strong support through Cabinet, from our Minister, and from all the departments we’ve spoken to. Everybody’s quite keen to have this happen, including in the states and the localities. Every single conversation has been quite positive, which is a little bit of a change from what I was expecting a little bit. I’ll be honest about it, when I joined the Ministry of Justice, my initial conversations weren’t nearly as positive as these. I don’t think the thirst was nearly as strong there as it is here. There’s a very strong demand in the public service and in the public itself for this, and it’s been great to see. It’s been really, really good to be part of the best. 

We work a little bit differently to other government departments, but we’re hoping that we can start sharing some of this way of working outside. We work in multidisciplinary Agile teams. So every team, every product team, has a product manager. And in that team, there’s also a delivery manager, so somebody who’s responsible for removing obstacles and making sure the product actually moves ahead, we have the user researcher, so somebody who’s actually looking at examining users and how they’re actually - what their needs are, and how they’re using the product, what we need to change. This user story said, ‘Well, as a user, I need to be able to log in, and I need to be able to log in with certain credentials’. Is that actually working, or is it not? If it’s not, that user researcher won’t sign off on the story, it’s not considered done. We have interaction designers to make sure that the entire service works in an intuitive manner for user direction, getting things done, developers actually writing the code, and so on and so forth. But the unit of delivery is the team. It’s not like this particular person’s responsible for this particular thing, and no one else has anything to do with it. If the thing doesn’t work, it’s the team’s responsibility, the entire team. You can’t point fingers and say, ‘It wasn’t my job, I didn’t do that’. It changes the way you work, it removes hierarchy, and it means that people actually do work together in the very best possible way. 

We work in the open - really important, really important. We’re not sitting in a tower writing a policy document without talking to people or anything like that, which I’ve seen certainly in the UK. We are starting from the standpoint of user need. We are starting from the standpoint of actually talking and watching users, working with users in the open to understand what they are, what those needs are, delivering software as an Alpha, then a Beta in the public. So yes, stand it as an Alpha, and have some people use it, and see what happens. It is in production, but it’s Alpha. Stay open as a Beta so anyone can use, and it’s in production, and we can change that, and we will change that with every single sprint that comes along. It’s very, very different to the way that government IT is usually working, but that is the direction our colleagues all around the world are taking, and that is how we will be working. We’ll also be releasing all of our code on GitHub as open source, and that’s really important for a number of reasons. Firstly, because the taxpayers have paid for us. All our work is funded by taxpayers, doesn’t come from anywhere else. And taxpayers have a right to use our code, and to share it. Secondly, because departments need to start sharing and using each other’s code. It cuts costs, makes things cheaper, and it makes things better, because things are shared, and they start looking the same, and acting the same, and when you use one, you know how to use the other, you don’t have to be formally trained for each separate thing. It’s really, really important. Thirdly, because a lot of countries around the world are dealing with very similar kinds of problems, and we should also be able to use code developed on other places, and share our stuff back out. And it’s, again, better, cheaper, more consistent. 

That’s because we’re part of a worldwide movement. So everyone’s probably aware of the GDS, and the departmental digital teams in the UK. There’s also 18F and the US Digital Service. There’s the work that’s happening in New Zealand, where the mantra is now, ‘Digital by default,’ there’s the work that’s happening in Singapore, in Israel, in South Korea, in Estonia, in the Netherlands, and so on and so on and so on. It is a global movement because all governments are facing very similar problems. Many of us are facing budget issues. All of us are facing the same user satisfaction issues. Every single government’s facing those. We can learn from each other, and we are learning from each other, we’re working with each other to deliver the best digital government possible in each one of our countries. 

We’re doing it with departments, we’re not doing it to departments. Massively important. This is not us coming by and saying, ‘Everything you do is rubbish,’ because it’s not. There’s a lot of brilliant stuff that’s been developed in Australia. It’s a question of finding what the best practice is, and sharing that, making it consistent across departments. We have some ideas on how digital services should be developed, and we’ll be sharing that. We’re also welcoming input from other people or other departments to work with on that. The Digital Service Standard has been released, and we’d like to get comments on that, we would like people to start looking at that, we’d like people to start using it, and see what actually happens when they do use it, so we can understand what we need to change. It’s released as an Alpha, so we eat our own dog food, right? We don’t just release a Standard and say, ‘That’s the Standard,’ we say, ‘That’s an Alpha of the Standard,’ because we don’t know everything at the beginning of the process. We’re finding things out as we do them. We road test them, and then we approve them, including our own standards, including our own thinking. In the case of the Digital Service Standard, the users are people who are also developing digital services in the departments, and we need to understand, ‘Are we doing the right thing there? Does it meet their needs as well?’ 

So we’re asking people to join us. Anyone that’s interested watching this livestream, contact us at We are looking for open support. Thanks.