Bypassing Bureaucracy to Innovate Through Digital Transformation

Insights from Cheow Hoe Chan, Government CDTO of Singapore’s SNDGG

Inspiring innovation from public sector leaders

How can public sector organizations develop a culture of experimentation and deliver impactful citizen services while navigating the inherent challenges of bureaucracy? Join Cheow Hoe Chan, Government Chief Digital Technology Officer of Singapore, as he shares how he has driven digital transformation across the Singaporean government over the past decade.

Transcript of the conversation

Featuring Cheow Hoe Chan, Government CDTO of Singapore’s SNDGG, and Tom Soderstrom, Enterprise Strategist at AWS

Think big, start small, move fast

Cheow Hoe (02:13):
We all tend to think of innovation as something huge, moon shot, things that are going to shape the earth, but actually it's not about that, right? Because digital transformation's all about constant innovation. And therein lies the challenge. How do you start building an organization, a culture, that allows people to keep doing that, especially in the government context where it's not natural, where bureaucracy prevails and red tape prevails?

Tom Soderstrom:
I was Chief Technology and Innovation officer for IT at NASA's Jet Propulsion Laboratory. One reason that I came to AWS was to build this Chief Technologist organization with a belief that the public sector can be at least as innovative as the commercial sector, if not more.

Cheow Hoe:
One of the biggest challenge in the very beginning was to bring in the right people. Most governments don't have innate capabilities and outsource 95% of their projects. So, it's quite hard to be innovative when you really don't have the right people and the right culture. So I think the first thing we did was really to bring in people from all walks of life; the private sector, different parts of the public sector, startups, big companies, small companies, because I think it's diversity that creates a culture of innovation.

Governments are inherently conservative, which is a problem in many ways. So if anyone gets the sense that you're doing something that will blow up the government, nobody's going to help you. That's why I believe in one of the most important mantras, which is, "Think big, start small, but move really fast."

Governments are used to big projects. Every project is a hundred million dollars, $200 million, $500 million. And when you have a project this big and it fails, it's extremely obvious, very conspicuous, and the public will know about it. So these projects are not meant to fail. But you and I know that innovation is about failing. If you can't fail, then everybody will be very conservative. They'll just outsource the responsibility and pray that they'll deliver it someday, whether it's three years or five years from now and they probably rotate out of the position in the first place. So I think that's really the context which inhibit innovation.

How to develop a culture of experimentation

Tom Soderstrom (05:52):
How did you get that culture where it's okay to experiment?

Cheow Hoe:
It's really about getting people to come up with ideas on how to solve a problem and give them two constraints: very little money and very little time. The problem with government is the other way around. You give them a lot of money and you give them a lot of time, and both cases leads to catastrophic projects. So if somebody comes to us with a good idea, we might give them $50,000 and three months. Show me something.

So we do that and then they come back after about two, three months and then they show us again. And if it's not working out well, we kill it. They actually have to do a postmortem. What are the lessons learned? But more importantly, if that prototype or that idea has any kind of traction, then we will actually give them more time and more money. That's how you progress.

So you're funneling it up whereby you have 30, 40, 50 projects and then all of a sudden it goes to 10, 15, and then the real proof in the pudding is when we reach a certain point after maybe about six to nine months that we think it's not bad idea. They have a limited prototype, looks pretty good. Now your job is to find an agency that's willing to work with you to actually implement it. This is the third part, which is very important, because a lot of times many of these hackathons and everything don't see the light of day. They look good, everybody's so happy about it, there's the great stuff, but that next step is the most important. Would you find a buyer? Can you find a buyer?

Tom Soderstrom:
I like the way you're thinking of the government agency as a buyer.

Cheow Hoe:
They have to buy in, they have to support it, they have to think that it makes sense for them. And if they can find a buyer, we want the agency to co-fund the projects. When you have skin in the game, people are a lot more committed to get things done and then when they're successful then comes the real rolling out to other agencies and productizing it to a point whereby it becomes sustainable.

Fall in love with the problem, not the solution

Cheow Hoe (10:06):
I’ll give one example. One of the agencies which runs the 995 line, they dispatch the ambulance for emergency services. Now these guys are really under stress. The problem was that ambulances couldn’t get to the patients in time because 70% of the calls would be cardiac arrest. You’ve got 10 minutes. If you don't intervene, the guy's gone. So my guys did a simulation to figure out the travel time, doing peak hours, non peak hours, all that stuff. We mapped it out and during the peak hour, 10 minutes buys you about two kilometers or two and a half kilometers because of traffic lights and traffic jams. Doesn't get you far. So the only way to is deploy thousands of ambulances, which you can't afford, right?

We spoke to the head of the department and then one young guy came said, "Why don’t we crowdsource lifesaving?" He said, "We need to get volunteers. We build a simple app, we get volunteers, people with Red Cross training, doctors, paramedics, et cetera, who are off duty, and if they're anywhere near that case we will give them notification and they can choose to go and help."

So it's a very simple idea. Three people did the program in about four months, and we launched it as a pilot. Initially I was very depressed because there was only about a hundred volunteers. But then the first life was saved and it came out in the papers, and today that app has about 130,000 volunteers. So all of a sudden you are really blanketing the country with volunteers who can actually intervene first, stabilize the person before the ambulance comes.

Tom Soderstrom:
And what an amazing thing for the person who came up with that idea.

Cheow Hoe:
He's still part of the team. Young developer. He wasn't the most senior. In fact he was the most junior guy. So I think the value here is that when you start listening to people, actually the senior people normally don't have good ideas. It's really the young guys on the ground who are more connected.

Tom Soderstrom:
So it's really important to fall in love with the problem, not the solution because the problem persists. And so many times we found that the original problem, the original solution, it's supplanted by a better solution.

Cheow Hoe:
And the improvement part is very interesting. The initial app was very simplistic, nothing much more than that. Then we started learning that we should also put location of AED machines in Singapore. So we put exactly where they are so that the volunteer can find it. Then one improvement that kind of shocked me the most was that they started putting a 995 button on the app itself. And I said, "Why do you do that?" Again, user story, right? They realized that it's better to put a 995 button on the app and you call using that rather than the phone. Do you know why? When people call, they're panicking, and they give the wrong address.

So, to me these ideas are important because you start with something small, but it becomes something more complete as you go forward. And that's what agility is all about. It's really not about going out there and building this huge application tomorrow morning and spend 50 million bucks doing it.

Moving government workloads to the cloud, securely

Cheow Hoe (17:29):
The cloud is a journey. It's not a destination. When we first started the cloud journey, we did something very simple. We took all the unclassified and content websites and we just created a commercial cloud. Why? Because nobody was against it. Because it's not sensitive, it's public information. Then comes the next set of workloads. That's where the tricky part comes in. Those will contain customer data or citizen data, etc. Privacy becomes a problem. Then we evolved this thing called GCC, Government and Commercial Cloud, but it's still the commercial cloud, but we had three or four restrictions on it. One was that the data must be Singapore, but that was simple. We simply use the Singapore region.

And the reason why data has been in Singapore for those things is because one of the challenges of cloud is the total lack of transparency. So if your data is not residing in Singapore, let's say your data is residing in Tokyo for example. When something happens, which law is it subject to? It's a big problem. But if it's in Singapore, it's subject to Singapore law. So if let's say somebody wants to sue the government for breach or privacy or whatever it is, the law applies. So that was a very important consideration and it's not because we are paranoid about data. It's about the applicability of governance and law and legal restrictions on data protection.

The second thing we had to do was to make sure that you understand that most government systems are still on-prem at the time. The customer facing part is probably in the cloud. So the question is, how do you ensure that it communicates safely? The third thing that was very important to us is that we were still using a lot of vendors. A lot of vendors are not cloud native. So how do you ensure that there's a baseline security every time you implement? Because you and I know as a cloud practitioner, that the biggest challenge of security in cloud is misconfiguration. We don't configure it well, anything can happen. So that's why we brand it as government and commercial cloud. With that we were then able to move the next batch of workloads onto the commercial cloud. It just gets more difficult, whereby you start talking about highly sensitive data, mission-critical workloads. We again wanted another level of protection. Higher transparency, more resiliency, survivability, security, right?

Tom Soderstrom:
And every government shares these exact same issues.

Cheow Hoe:
Today Singapore has moved about 70% of our workload onto the cloud. No one can claim that, basically. And the reason is because we're serious about it. That's about thinking big, but we started really small. It started simple and small and evolved.

"The cloud is a journey. It's not a destination."

Advice for government leaders

Tom Soderstrom (24:05):
Now, if you were going to give some advice to other leaders in government, what would be some of the advice to these future leaders and current leaders?

Cheow Hoe:
The digital journey or the journey of the cloud, et cetera, these are huge commitments. It's not something you do in one year. So the commitment has to be there and the support from the senior leaders has to be there. Because if that is not there, then chances that it will fail quite high. That's number one, right? Very important. I think the second thing then is really about the fact that you need to build capabilities. Governments today, most governments, really don't have the capability; and if your leaders and your managers or your people don't have the capabilities, you would not be able to make those decisions because technology is complex. Knowing the substance from the form is very important as you go forward.

Tom Soderstrom:
Oh yeah. So I think these are very important things that people need to do, and that's what we did from the very beginning.

Cheow Hoe:
I don't think leaders should be managers. You don't manage. You do. You have to be with the team, you got to do it. Because pure administrative management doesn't get you this far in the first place. So, you've really got to get your hands very dirty because that shows accountability, it shows commitment, which I think is so important.

Listen to the podcast version

An audio version of this interview is also available on the AWS Conversations with Leaders podcast. Listen by selecting your favorite podcast link: