Innovation and Digital Government

Michael:         

(00:02) The federal government as we all now is enormous and that means that federal government projects, IT projects, any kind of project operate at a scale that a few of us have any experience with. And today, and episode number 114 on CXO-Talk, we’re going to get a glimpse behind the curtain into federal government IT.

I’m Michael Krigsman, and I am here with my friendly and fabulous co-host, Vala Afshar. Hey Vala!

Vala:   

(00:40) Michael how are you? It’s great to be here. It’s a privilege to have Mark Schwartz, the CIO of US Citizenship and immigration services as our guest for episode 113.

Michael:         

(00:54) Mark how are you?

Mark: 

(00:55) I’m doing great, looking forward to this.

Vala:   

(01:03) You would think after 113 episodes we would have a more clean handoff…

Michael:         

(01:09) Yeah, and I’m not going to mention to people that you just suggested to Mark that his agency find a way to deport me for weeks so you’d have a good blog to write about. I really appreciate that support Vala.

Mark; 

(01:21) Yeah, I’m hoping my ethics people aren’t listening here.

Michael:         

(01:25) We take that back, we take that back.

Mark: 

Thank you!

Vala:   

(01:27) Mark, tell us briefly about your professional background.

Mark: 

(01:30) Sure, I’ve been with the Federal Government now for all of five years, which is about how long it takes to figure out how to do a procurement and hire a person. Before that I was a CIO of a small/medium size company in the Bay area. Before that CEO of a small software company. I have a computer science degree from Yale University and a Master degree in philosophy. I was telling you before also from Yale and an MBA from Wharton.

(02:02)The philosophy degree is very important because it gives me the ability to argue with anybody about any subject.

Vala:   

(02:10) I’d like to see that with Michael during the show but we’ll move onto the next question, because Michael doesn’t have a philosophy degree, but he loves to argue.

Michael:         

(02:19) Somehow this is going down the wrong path. But Mark, tell us about the agency and give us a sense of the size, and the scope, and the mission and what you do.

Mark: 

(02:33) US Citizenship and Immigration Services is part of the department of Homeland Security. It’s one of three component agencies that deals with immigration in one form or another.

(02:43) We are the ones who do legal immigrations to the United States, so we process applications from people and petitions from companies that are trying to get people immigration benefits.

(02:57) We process about 7 million applications a year for one thing and another. We do applications for naturalization, applications for green cards, refugee status, asylum, foreign adoptions and a whole range of other things like that.

(03:15) The other organizations that you’ve probably heard of, which are not us are Immigration and custom enforcement. Those are the ones who would deport you if infact you were deportable and customs and border protections. Those are the people at the border and at the airports who check your passports and let people into the country or don’t.

Michael:

(03:36) I’m just going to officially say I’m not deportable.

Mark: 

(03:42) Yeah, really glad to hear it.

Michael:         

(03:44) So I think we’re good on that account. But maybe share with us some of your major IT initiatives that you’re working on.

Mark: 

(03:53) Well we have one very big one which is the one that gets the most attention; it’s a project to turn all of our paper based processes into electronic processes. Well it’s a very large effort because we are so paper based at this point. Infact they say if you stack up all the paper that we receive each day, it would make a stack that is about 1.8 times the height of the Statue of Liberty and that’s our daily incoming paper.

(04:27) So our processes are very paper based. Applications come in that way, they get adjudicated that way. Eventually it turns into a card or a piece of paper. What we want to do is work electronically, allow people to send their applications online and have them processes by our adjudicators electronically and cut down the movement of paper and provide better customer service and better national security.

(04:55)That’s our big you know, monstrosity of a project. We also have smaller initiatives though that I think are really interesting, maybe more interesting to me.

(05:05) One is an initiative to rethink all of our interactions with the public, whether it’s in person or online and make them more user friendly or customer friendly, make them better at conveying information and think of them as parts of digital services, as parts of an end to end process that is facilitated digitally.

(05:30) So we call the effort my USCIS, and a third one that I’ll mention is I guess a lot of companies a lot of other agencies have a similar problem for apps, where you have a geographically dispersed workforce and a lot of things going on in a lot of locations, and you have under the radar people building rouge applications or little IT projects that the central IT group doesn’t know about.

(06:04)So we’ve come up with I think a really unique way to both support the business needs behind those things and at the same time to make sure that all of our applications are sustainable, secure, maintainable. And that has to do with creating a very rapid application development, pipeline platform, small decentralized teams of developers who can work quickly a decentralized governance process, and sort of a crowd sourcing approach where we harness the talents of everybody around the agency and do hackathon days and do small quick win projects.

(06:47) Those are the three I’ve mentioned offhand.

Vala:   

(06:50) That’s incredible that’s very innovative and inspiring and exactly the type of thinking and leadership that hopefully all CIO’s are adopting. In one of your blogs Mark, is called Thoughtful IT and your LinkedIn profile describes you as innovative. So what do these descriptions imply thoughtfulness and innovation in terms of your approach of being a successful CIO?

Mark: 

(07:20) This is going to sound a little bit funny because somebody who calls themselves innovative does not sound like the most humble person around. But I think of it as a sort of a kind of humility. I like to think that I don’t have all the answers and innovation to me, has to do with figuring out what the right experiments are or what the right learning process is to solve problems.

(07:45) So  you know one of the patterns that you see a lot of in the government is something is repeated many many times and it becomes set as the way of doing things and I’m sure it doesn’t just happen in the government. And that leads to what I consider to be sort of a kind of pride. You know, we have our way of doing things and this is the way in and we know all the answers.

(08:11) And by innovative I mean the willingness to look at a business problem with fresh eyes, knowing that you don’t know all the answers, and trying to do good experiments that you can learn from that will help you find a creative solution or better solution than you had before.

(08:31) I think also in terms of cross-pollination of ideas. I think it’s good to be out all the time, looking at new ideas, seeing what other people are doing, bringing experience from other disciplines – not just IT as idea starters. And generating a nice pipeline of sort of things, things to try, new approaches, new ways to think about things.

(08:56) in order to really make that work is a CIO. What I found I need to do is create an environment where experiments are not only encouraged and tolerated, but where you reduce the risk and the cost of doing experiments.

(09:14) So for example, one of our big initiative has been moving to the public cloud. And as we move to the public cloud, we can standup infrastructure at a very low cost and with very little delay, and try and experiment to tear down the infrastructure immediately.

(09:32) So that reduces the cost and the timeframe involved in doing an experiment a lot and it help encourage I think innovation. So that’s what I’m striving for.

Michael:         

(09:42) This is pretty interesting because as you’re talking, these attribute that we tend to associate with start-ups or at the very least with smaller companies especially inside the private sector. So how do you manage to conduct this type of culture change in a sense within the content of this very large federal bureaucracy?

Mark:

(10:10) Yeah, I think of myself and I think of the rest of my management chain as servant leaders in the classic serve agile sense. So I have teams who I want to encourage to be innovative, take tiny little risks as experiments to learn from. And my job is to clear away all the impediments, and that’s the way I like my middle management people to think about it too.

(10:40) There are lots and lots of impediments, most of them can be handled by somebody who has good experience in the government and who knows how to work all the levers, talk to the right people, and get the right support.

(10:51) And I don’t want the innovators, the experimenters, the creative people to have to worry about those things. I want them to focus on the business problem and finding the solution to it.

(11:04) So I find that I spend a lot of my time doing that, working with let’s say oversight bodies on how they should be overseeing progress and so that they are not getting in the way. Or finding ways to get contracts in place that will support the innovation, or planning ways to hire the right people – whatever it takes. That’s the role of management and leadership I think.

Vala:   

(11:30) You had an experience as a CIO in IT in both the federal and private sector. Talk to us about some of the major differences. Of course, Michael start the show with a scale as one, but aside from scale and perhaps the complexity of the size of stakeholders, what are some of the other differences.

Mark: 

(11:53) I think the second thing you just said is probably the big one for me. In government there are so many stakeholders, do anything you do. And so many different interests represented, and the result is there is a lot of risk adverse behaviour. You have a lot of people who can find problems with anything you do, a lot of people who can veto ideas. And a lot of people that you have to please, and they are all coming from different points of view. And just when you think you’ve pleased all of your stakeholders and there’s another oversight body looking at what you’re doing, you know just layer upon layer of it.

(12:34) Of course, in private industry you have oversight as well or a governance process that substitutes for it. You have a number of stakeholders typically, but there is nothing like the scale and the scope of the stakeholders for government IT projects I’ve found.

(12:53) You’re working in public to a much greater degree and the federal government and I think that’s good, that’s our responsibility. We have a responsibility to the people of the country, and we have a responsibility to the other branches of government. We have checks and balances, and everything we do has to be high transparency and has to be acceptable, or has to be presentable in a sense. You know it has to work when you have people looking over your shoulder all the time,and that takes a little bit of getting used to.

(13:33) Also the government has values that are not the same as private industry, and those values are a very important part of how we decide what creates business value. For example, there is a veteran’s preference in hiring. Well, the government thinks that the veterans deserve special consideration and it’s an important thing. We don’t generally apply a veteran’s preference in the private sector – and I’m sure that some companies do. In the government it’s required for a very good reason.

(14:10) Similarly with procurement it’s an important value for the government to be fair when competing contracts. Fairness is a very important value under the Federal acquisition rules. In private industry, well if you want to do a contract you can invite your favorite couple of companies and ask them how much they’ll charge you and just make a decision, without worrying about if you’re being fair to every other company that’s out there. So those are probably the biggest factors that are affecting day-to-day.

Michael:         

(14:41) So how do you manage, how do you balance some of the things that you have to do in order to on the one hand respect the cultural attributes as well as the regulations that you were just talking about. And at the same time run an agile organisation and actually get IT projects done that at the end of the day, fulfil their mission and aren’t going to be vastly late or vastly over budget or you know be watered down and trivialized by the time they’re done

Mark: 

(15:16) This is where I get to argue with you. I’m not happy with that formulation. The way I look at it you’re always trying to add business value in everything you do, and in the private sector business value often means competitive positioning, revenue generation things like that.

(15:37) There’s no reason to think that in the federal government that the business value is defined the same way. Right, we still want to create business value, but the things that create value in the government – obviously competitive positioning is not a big thing. Revenue is not a big thing. Mission accomplishment is a big thing, like a lot of nonprofits for example. But there are other values in the government, fairness and the procurement process, fairness in the hiring – you know all of these other things. And to me those add value in the government context, and all we are trying to do is generate value by taking into consideration all of these different things.

(16:15) So it’s not you know creative IT systems that do the things IT systems do, and these other values get in the way. They’re not in the way, they are values you know, just like creating mission value and accomplishing their mission.

Michael:         

(16:31) But at the same time then we read stories of these – you know not inside your agency but in the states…

Mark: 

Of course not!

Michael:         

(16:42) Well that goes without saying, but in other agencies and state governments, you know there is a project he in Massachusetts that’s been running for 19 years and you know at some point you have to sort of get the things done. And you’re doing all of the stuff with dev apps and agile, so obviously you have a strong desire to achieve specific outcomes as quickly as you can.

Mark: 

(17:12) Yes, so let me reframe that one as well a little bit. Just because our projects are trying to create all different sorts of value, that doesn’t mean that they are doing it in the most effective way or in the most lean way.

(17:29) I sometimes talk about lean bureaucracy – how do we create a lean bureaucracy? Is there a contradiction in those ideas? And I think this is exactly the point, the bureaucracy has all of these values, you know there are a a lot of rules. Complying with the rules is considered important, the other things I talked about are considered important. But there are lean ways to accomplish all of that and there are Bloated I guess is the word. Bloated ways of accomplishing all of that; bloated is bad, lean is good, but the goal are still just fine, they are the given they are the goals.

(18:10) I think our challenge really is to figure out how to make government IT lean, without necessarily be changing what the government values and making sure that we are delivering all of those things. Does that make sense?

Vala:   

(18:26) It does and we’ve had you know extraordinary federal CIO is. We’ve had Dr David Bray of FCC, Dr Lisa Johnson of the Whitehouse, Casey Coleman of GSA, yourself. One common, my observation in that you are accessible, your collaborative, you’ll open to ideas. Just the fact that you guys are all on Twitter is a sign for me, you have this inclusive approach where you are welcoming feedback and you are volunteering your time hoping to teach and be taught, so there is definitely a common thread with all of what Michael and I consider successful CIOs in your space.

(19:10) But you must have lots of challenges, so can you share with us, you know one or two things that keep you up at night and then maybe just innovation of velocity, you know a lot of the what we call the consumerisation of IT people expect to have the same powerful tools at work as they have at home. You have to balance security and access ability and all of that, but what are some of the challenges that you face today and keep you up at night?

Mark: 

(19:38) None of the things you just said. I think the people should have the tools they have at home, I think that’s a great thing. I think we have great ways to remain secure and not have to worry about security, in fact I think we can improve, and improve, and keep improving our security posture, so those things don’t worry me so much.

(19:58) I I talked a little bit about risk before, and a lot of the thinking in the government goes around how to reduce risk. We are very paranoid about risk, and sometimes it leads us to be shortsighted. We reduce one risk at the cost of increasing all the risks, or we are afraid to take a risk where you pretty much need to if you want to not be overspending.

(20:28) For example, we know that it reduces risk if we can deploy releases to production very very frequently. That actually reduces risk because it means each time you’re deploying something, it’s a much smaller thing, and there are a few opportunities to break stuff, you’re getting feedback more quickly so you don’t risk going off course and developing something that nobody is going to want to use. It’s a huge risk reducer, but getting acceptance to deploy frequently can be really hard in our environment because people are worried about different sets of risks. So what if something goes wrong in the deployment and how do we know that you’re going to continue and finish all the other features, and you know all of these other things that worry people, that prevents us from doing the things that actually reduce risk. It’s a lot of these big trade-offs right.

(21:31) We have risk, let’s say we are working with a contract and were not happy with their performance, so we should switch to a different contractor obviously. But the argument will come up, well we don’t know about the new contractor, so there is a big risk their if we switch contractors and who knows what kind of performance we are going to get.

(21:53) I think the risk is to stick with the contractor that you know isn’t performing adequately, and that’s a very high risk to. But our approach to risk is so complicated and paralyzing in a lot of cases.

(22:09) I’ll give you another example. We often have these lists of high risk programs in the government and the implication is that those are bad programs, that risk is a bad thing. So it is viewed as a list of bat programs, high risk.

(22:29) We’ve had some of our projects rated as high risk because we had an aggressive schedule, and there was a high-risk that we would not meet that schedule. But is that bad? You know, there is an easy solution. I could lower the risk of my project by making a more leisurely schedule and saying that we are not going to finish for four years instead of one year. But is that the behaviour we want to motivate? You know, yes it would be lower risks but that’s not a good thing.

Michael:         

(22:59) So it’s basically a matter of balancing of what you are trying to accomplish off what is realistic, but then you have a set of expectations that you’re managing.

So on the subject of oversight, because you work in a very compliance rich environment so to speak, and you’ve written about this. How would you recommend that oversight the structured so that it accomplishes the compliance goals, but at the same time is not an impediment to innovation within IT?

Mark: 

(23:43) So let me again throw out a few different ways of thinking about it, and we’ll see which one works for all of us. So maybe an extreme view I’ll give you, is that just like I think management should be servant leaders and should be removing impediments, arguably oversight should be the same.

(24:05) The people who actually know how to run a program, who know how to run a project other people who are running the projects. The oversight body doesn’t have as much experience at actually running the project. It isn’t hands on and doesn’t know all of the ins and outs of all of the decisions that are being made, and trade-offs that are being taken.

(24:22) So just like when I have a team of developers, I want to be a servant leader and let them drive things you know, and trust them. They are closest to the action, they can make the best decisions in most cases, and I want to have a sort of light weight oversight of them and clear away obstacles.

(24:41) May be oversight in the government should have more of a servant leadership posture, where the programs themselves know what needs to be done. Oversight is trying to find potential obstacles and clear them away.

(24:56) I like this view, and not only because it would make my life easier in a lot of ways, but also if you think about the impact say of cancelling a project, I think a lot of the time oversight bodies think of a success for themselves in terms of cancelling feeling projects.

(25:21) And a failing project to me is the worst thing that can happen because then you have a business need that is not being met. The project that was going to meet it is being cancelled.

(25:32) With more of a servant leader attitude, the goal of the oversight body would be to figure out how to make the program to succeed. You know, what obstacles would need to be removed, what changes need to be made, and support the program in achieving its objectives rather than, well we are going to show that we are doing our job by cancelling the program ones it becomes unsuccessful.

(25:56) So maybe that’s a sort of extreme view, let me give you one that may be be a a lot more palatable and it has to do with waste.

(26:05) I think everybody can agree that waste is bad, so oversight processes always impose extra work on a program. It might be documentation, it might be those classic source of ways that just waste time. You know, you can’t go forward until we have a review, and we can’t schedule the review right away, or the papers that you need approved are sitting on somebody’s desk and you have to wait for them to approve them.

(26:31) there are always costs involved in an oversight process, and my question always is, how can we reduce those costs, how can we make the most leanest possible oversight process that still satisfies its goals of oversight.

(26:50) And to me the burden needs to be on the oversight process, because there is no other way to control for that. Oversight bodies have immense power to add requirements onto programs.

(27:02) The burden should be on the overseers for each burden that they impose on a program to show, or to at least know why that burden is adding value in the oversight process.

(27:14) So if we have let’s say a requirement to produce 100 documents for every release, which sometimes we do have and those documents are long documents. Those writing the documents, reviewing them, and approving them that’s a huge cost to the program, that’s a big cost but always flies under the radar. Well, every one of those documents should be investigated to see what value is adding versus the cost of the document, and could we do without it and shorten it or whatever it takes to make the whole process leaner

(27:49) The strange thing in our environment is that I don’t really see anybody overseeing the oversight body, just to say are you really doing your job in the most efficient way that is causing the least deliverance of the programs, right that’s a little strange.

(28:07) I think oversight should be about applying best practices, and this becomes tricky in our environment because what we think of as best practices is often what we have just done in the government for a long time. And having done it for a long time it gets registered in a big book or whatever it is, this is the best practice.

(28:34) If it’s not the best practice, then we are imposing bad things on programs right. It’s a very risky – to use the word risk again, it’s very risky to tell a program that you should be doing things this way, because if you are wrong about the best way to do things then you are actually costing something and increasing the chances of failure and so on.

(28:58) So oversight bodies have a responsibility I think to be up on what are the latest best practices, what is known to be the best way to manage risk, to reduce time and reduce cost and all of those things. And I don’t think that is particularly perceived as a value in our government environment.

Vala:   

(29:21) You’ve written a number of blogs about these last two topics, cancelling successful projects is your extreme view, which actually makes a a lot of sense to me. And who’s watching the oversight – I’m going to shift the conversation a bit towards innovation. Last week we had Tim O’Reilly, the CEO of Reilly Media, and when we talk to him about disruptive innovation he said look, the word disruptive alone is just cheap thinking in my mind. Really, people don’t try to be disruptive. The most successful innovators are just simply trying to add value.

So, in the spirit of innovation and adding value, what do you do specifically as the you know the lead innovator, the CIO in terms of cultivating a culture where you know, it’s okay to ask questions, if it’s okay to experiment, and if it’s okay to improve the process over time.

Mark: 

(30:14) I can’t really claim to be extraordinarily successful on all of that. It’s a constant struggle. We have a culture where people are afraid to experiment, and don’t tend to go to the outside to learn new things. Often don’t do a lot of research, we often afford to send people to conferences, or to participate in forums where they might learn a lot about what is going on right now.

(30:48) So, it’s a constant struggle for me. How do you encourage people to take those risks and experiment and think creatively. Going back to Tim O’Reilly’s point, I agree but with maybe a couple of small reservations. I think it’s different people in different situations, and what a leader has to do is read the situation and figure out what’s going to work. And sometimes what’s going to work is incremental movement, general small changes that add up.

(31:23) Sometimes it’s extremes, sometimes you know you need to shake people up to get them thinking differently. Whatever is going to work is going to work, and I see it more as an experimental thing where you try something and see if it’s effective and then you change how you’re doing it.

(31:41) One thing that I have come to believe I think from my experience at USCIS is when you are trying to move in a strong direction like agility or dev ops or something, there are a lot of forces that are trying to get you to only go partway, you know to do it incrementally. And I have found it useful to not give in so easily because it confuses people about what the objective is. So we’ve had a period when we were moving from the waterfall approach on our big transformation project to a more agile approach.

(32:23) And people said well, let’s bring the change. Let’s do something that is agile like the first. And to me it was a disaster, but it was wimping out, like people are confused, what should be be doing. Where I find it to be more useful to set that vision, here’s where we are going, get me there and then if they say well, we can only go this far now okay, I can live with that. We are going to meet moving incrementally, but at no time should anybody be confused about where I’m trying to get us. You know what that vision is and they know that I’m going to keep coming back and pushing for that final vision and they know that if they come up with creative ways to get as there, that I’m going to support them and love it.

(33:14) So I can’t say I totally solved this problem, but my belief is that it has to be done with this sort of intellectual integrity you know, here’s where we going and that’s that.

Michael:         

(33:26) You know, let’s talk about digital government. You actually wrote, what you term a manifesto for digital government, so maybe tell us briefly, what do you mean by digital government and definitely what do you mean by a manifesto for digital government.

Mark: 

(33:45) So this is actually a nice segue there, because this is my attempt to say very clearly where I think we should be heading and there are a lot of steps to get us there. My digital manifesto eventually I think got superseded by the digital services playbook that was created by OMB and GSA and a bunch of other people working together.

(34:10) The intent is very is very similar, digital services playbook here are the plays that you should be making to lead to what they are calling digital government. For me, digital government is really about focusing on the customer, the end-user, the recipient of government services, and working backwards from a user centric approach to what we are doing. In some cases it is actually digital, you know it has to do with our online presence for delivering services. In other cases the online service is just a piece of the value delivery chain.

(34:51) And the question is, let’s say we have adjudicators who are human beings and are making decisions on people’s applications, but it’s a digital services question on how we can optimize the results, the customer friendliness, the customer services, and the entire services by supplementing by what those adjudicators do with digital services with information technology.

(35:15) So I don’t think there is a precise definition here, but it has to do with the user centric terms, rather than government centric terms as we are designing things. Often, if you go to a government website you’ll see it organized by the orb chart of the government agency basically.

(35:37) If you want to find something what you have to know is that the quality assurance branch or is it the testing and independent verification branch. Somebody coming to the website from the outside of course doesn’t know those things and shouldn’t care. They want a question they want answered.

(35:55) So, digital services to me are about thinking in terms of what does that look like to that outside person, what’s the user centric view of it. How can we use digital technology to provide better services or at least customer orientated services?

(36:14) So, I think that’s where it’s coming from. In terms of the little manifesto that I put together and the digital services playbook their very similar actually. A lot of the elements overlap but some of the implications of trying to move in this direction are that you need to develop services very quickly because you need to be getting user feedback all the time. If you are going to be user centric you need to do a little bit of work out there and get feedback, move on, and change things if necessary.

(36:48) I think that leads to an attitude of leanness you know, in order to reduce your cycle time, or just the time it takes you to get each incremental feature out to the public. You have to think where are the sources of waste in your value chain, in your delivery chain, how can you eliminate them, and how can you do continuous improvement on your process.

(37:09) In order to do the kind of user centric design that I’m talking about, you need to work with end users. You need to understand how they think. You need to get experienced user experience, specialists who are very good at working with the way users behave and figuring out optimal solutions for them.

(37:32) So, all of these things have to come together, if what you are shooting for is good digital services. And the little manifesto that I put together and the digital services playbook are both intended to flesh out some of those things that have to come together.

Michael:         

(37:45) And how do you adopt an attitude of leanness and essentially what you are saying is what an outside in perspective where you are using a customer’s views and needs as a reference point for the activities that you undertake. How do you do this within a context of a government and a bureaucracy which historically has not adopted that point of view and one can even say – and I’m sure it’s not intentional, but sometimes it seems almost actively rejects that point of view.

Mark: 

(38:19) In some cases that make sense, you know let’s go back to your deportation.

Michael:         

Let’s not go there please

Mark: 

(38:30) Yeah, I think this is a great topic and Vala said so before. So you know, if you were to be arrested or detained by immigration and Customs enforcement. They might put you in a detention center. A detention center has a lot in common with a hotel, right. Basically they’re giving you beds and services, meals – whatever. A hotel would think of customer service in that context, right. They might want a survey of the people staying at the hotel and find out what appeals to them and those kinds of things.

(39:04) But I don’t think that’s an appropriate model for a detention organisation like that, right. They are not about serving the customers and asking what they want. So, you have to take sort of a border view of what we mean by customers and what we mean by users in this context.

(39:25) But I think there’s an ultimate target for who you are providing this service for in each case. Maybe an ISIS case, and I’m not an expert on their situation, but they are serving the public of citizens you know, and ensuring the integrity of the immigration system. That’s like what we do also. And the customers for that are the ones that you want to tailor your service for. So there’s always of some customer involved I think, and some element of working backwards and figuring out what the right value chain is to deliver the service that the customer needs or wants.

(40:08) So, in terms of working within a bureaucracy, I think a good part of the problem – it’s not about bureaucracy per se, it’s about doing really big programs with a waterfall approach. Because you know if you’re going to do a big IT project and you are going to try to get all of the requirements upfront before you start it, the only way you can do that is by asking people what they want. Or looking at the business and trying to figure out what’s going to work and it’s all speculative to a large extent. You don’t really know very well that’s a lot of risk and whether that what you’re going to build is, really what is going to work with the users or to facilitate the outcomes that you want.

(40:57) As we move to a more agile, more dev ops, more of a continuous delivery approach, the opportunity and feedback increased dramatically. And what we can do is working with a user and showing them something and saying is this what you mean. We done design prints with users on some of our software where we talk to them a little bit about what their needs were and then show them three hand drawn sketches you know, of what it might look like and said, what do you think of these. You know, give us feedback on each of these.

(41:33) And then based on that feedback, redid the three sketches and said how does it look now at the feedback based on that. And said which of these do you think is the best approach of the three, and the users have chosen one, and then we prototypes it and made a clickable version on the screen that they could use, and got their feedback again and based on that feedback flipped the design to look something that looked right. Then built the functionality and then put it out there for people to use.

(42:04) All of that, that whole process of going back and forth with the users to sus out the preliminary designs, we’ve done that in 48 hours because we can turn these things around so quickly. That’s the way you get to understand user needs better. And bureaucracy is not necessarily an obstacle to that.

(42:25) There are some places where there is challenges. We have for example, paperwork reduction act that says, when we want to create a new user interface essentially, a new information collection whether online or on paper, it has to go through an approval process. The approval process requires public notice and a certain amount of comment created, and reviewed by an organisation within OMD.

(42:54) So, the process of putting out a new form on-screen or on paper can take one year or 18 months sometimes, even making changes to one and it has to go through that process.

(43:07) So, I think a lot of us, or a lot of people at OMB and a lot of other people involved in the digital government initiatives, are looking at ways that we can within that process get this rapid feedback, or asking it whether there is a way to change in the way the process is implemented will be sonot necessarily the laws behind it to facilitate that kind of back and forth. So there is an area I guess where you can say that bureaucracy might make it a little bit difficult to do the things I was talking about.

Vala:   

(43:38) Mark do you have work with start-ups

Mark: 

(43:41) I used to.

Vala:   

(43:42) So at your IT organisation do you invite start-ups.

Mark: 

(43:51) Not particularly. You know when we put out a procurement, when we’ve put out a solicitation, often we are repeating it within an existing government vehicle. So, VHS has, there is a set of contractors on that vehicle. When we have put our request for proposal it goes to the contractors on that vehicle. So often that doesn’t reach the start-up community, there is a lot of overhead in getting yourself on a vehicle like that. And I think that’s an unfortunate consequence of the way we do the procurements.

Vala:   

(44:28) What advice do you have for established vendor’s who are on your approved list, as they try to demonstrate value and their solutions to you – from a CIO perspective, you know what turns you off when someone is pitching a solution to you.

Mark: 

(44:46) A lot of overhead. So mostly we are doing procurements for development services, or some other kind of technical services. Let’s say software development as an example. What I want the proposal from the contractors to look like is a bunch of developers and testers and other people who hands on are creating value. And the amount of other stuff management, overhead, administrative overhead, other costs, I want that to be almost nothing you know, absolutely minimal. I want the complete focus to be on actually getting things done.

(45:30) I have the same approach sometimes with my staff. We have oversight and governance bodies and things that usually are oversight governance bodies, and I keep encouraging them to be hands on with everything they do. So our architecture enterprise, architecture folks who would often be in a position of saying, you have to do it this way. You know, you have to run changes by us so we approve them. Instead, I have them creating reference architecture as proof of concept, developing things that can be reused by development teams and things like that.

(46:08) The focus for me should always be on actually creating product, creating value and anybody else who has to exist should be in a position of servant leadership if possible.

Michael:         

(46:20) Well this has been a very quick 45 minutes, and we have been talking with Mark Schwartz, who is the CIO of the US Citizen and Immigration Services. Mark, thank you so much for taking the time today.

Mark: 

(46:41) Thank you I enjoyed it.

Vala:   

(46:43) Market you were terrific, thank you sir.

Mark: 

(46:44) All right, thank you. Citizenship and Immigration Services that’s the way.

Michael:         

(46:50) Did I get it wrong, sorry about that.

Vala:   

(46:53) And he was reading it!

Mark: 

(46:55) I was wondering if you guys were going to fight it over on whether this was 113 or 114.

Michael:         

(47:01) This is episode 113.

Vala:   

(47:06) You know I was hopeful that my blog title was, my co-host got deported, but we’ll get to that later.

Michael:         

(47:12) You know I have a passport, I pay my taxes. I am totally good. I am just saying that in case in the body has any doubts.

Mark: 

(47:24) I wouldn’t want to have to explain to my security folks why I was talking to you if you were deportable alien.

Michael:         

(47:30) Yeah, and your security folks did a thorough job of checking was over before they agreed for you to appear on CXO-Talk. And we would expect nothing less by the way. So everybody did a great job and you’re here, and we are very grateful. I am Michael Krigsman and my co-host is Vala Afshar and Vala, next week we are going to be joined by Mark Sunday, who is the Chief Information Officer of Oracle.

Vala:   

Thank you Michael, thank you Mark.

Michael:         

(48:08) Everybody, thanks for joining us, Mark thanks so much and we’ll see you next time everybody.

 

US Citizenship and Immigration Services (USCIS):           www.uscis.gov           

MyUSCIS                                                                                  https://my.uscis.gov/