Recoding America with Jennifer Pahlka

Join hosts Murray Robinson and Shane Gibson in a conversation with Jen Pahlka, founder of Code for America and author of “Recoding America”. They discuss the current challenges faced by governments in providing efficient digital services and how agile product development can drastically improve outcomes.

Key points in this episode:

• The current state of government digital services: Governments at all levels often produce poor quality online services, such as healthcare.gov in the US, that are not only costly but also complex and user-unfriendly.

• The root of the problem: Government is often hamstrung by a rigid, hierarchical, risk-averse culture. Everyone involved tends to add rules and requirements to shield themselves from blame.

• The potential solution: Jen explains that there is an agile product development patterns gaining traction in government which yields much better outcomes.

• The path forward: Jen believes the agile approach should be implemented in every bureaucracy to better serve citizens and foster innovation and efficiency.

Tune in to gain insightful perspectives on improving government digital services and the role of agile patterns in this change.

Read along you will

  Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson. 

Jen: And I’m Jennifer Pahlka. 

Murray: Hi Jennifer. Thanks for coming on today.

Jen: Happy to be here. 

Murray: We want to talk to you about your new book, recoding America, which is about digital transformation with the US government. I’m interested in talking to you about this because a lot of us have worked in bureaucracies which sound quite similar to your experience in government. Let’s begin by getting you to explain a little bit about who you are and how you got to this point in your life.

Jen: Yeah, I’m not a technologist. I actually studied American studies or liberal arts in college. The joke is what do you do with the American Studies degree while you start an organization with America in the name. Not much else other than going to academia. My first job out of college, I worked at a child welfare agency. I was the secretary. But I did get to see a little bit of how some of the public sector works and how critical it is that it does work, especially in an area where, kids’ lives are at stake. 

I went traveling around Southeast Asia for a year early in my career and when I came back, I landed in San Francisco just when the dotcom boom was happening. And I think at that time, everybody ended up in technology. I ended up in tech media for many years running the Game Developers conference. And that’s how I got to know programmers and, programming methodologies and also designers and musicians and artists that help create video games.

I left that when I had my daughter and came back into working with this Web 2.0 conference at the time when that was big and that was very exciting. You had the beginnings of Twitter and Facebook and Google around the same time, and pretty quickly it became clear that these principles and values of Web 2.0 were going to be applied in the context of government.

And that’s when we started something called Gov 2.0, and it was in researching what gov 2.0 should be that I came up with the idea that became Code for America, the nonprofit that I started and ran for 10 years. And I got a crash course in how government works when we were trying to figure out, how to apply these lightweight, agile user-centered approaches that were transforming the consumer world. How would you really apply those in government. And that’s how my journey into government began.

Murray: Tell me about Code for America. 

Jen: So our initial idea was that we would have tech people come into city governments for a year. And do things in a fast, lightweight, agile, user-centered way. And we actually had a lot of success with that. We ended up having some fellows who did amazing work on the benefits application for food assistance. This team had just done this incredible project that was helping people who normally had to go through a 212 question online application to apply for food benefits. And now were able to apply in about seven minutes on a mobile phone with just a handful of questions. 

We ended up deciding that working on long-term projects, like how you would apply for food assistance or how you would get your criminal record expunged, or how you to apply for Medicare or Medicaid services would have longer term impact. Today, the organization doesn’t use this one year fellowship model. But it still is essentially in the business of helping governments understand how to serve people better through online technology and using that technology to get the outcomes that we really intended from these services.

Murray: Why did you go to the White House and what were you doing there? 

Jen: President Barack Obama was the first president to have a Chief Information Officer and a Chief Technology officer. His second CTO was Todd Park. He was watching Code for America and said, we need that here in the federal government, and invited me to come help run the Presidential Innovation Fellows.

When he called, I happened to be visiting the government digital service in the uk and was inspired by what they were doing and reverse pitched him on the notion of an American version of the g d s and after six months of saying no said yes, I’ll come, if we can do our American g d s. I have a lot of Enthusiasm for the fellowship model, but the idea that you had full-time, long-term people doing, real work at the center of government instead of just visitors for a year, was more appealing to me at that point. So that became what we now know as U S D S, the United States Digital Service. It didn’t actually launch until two months after I’d left because it takes so long to get stuff done in government. But proud to say that organization is still making a big difference , in the federal agencies.

Murray: All right, your book is really about why people should care about government digital services and I’m wondering if we could start by getting you to tell us a story about the concrete boats. 

Jen: This was when I was working, in the White House trying to set up U S D s. And one of the ways we were getting support for it was to just show people what kinds of engagements we would do.

We had a problem with our Veterans Benefit Management system at the time. This is a system run in the Department of veterans Affairs. It was running very slowly and I recruited a team of technologists to come do what we now call a discovery sprint. How can we, spend some time just figuring out what the problem is? And the very first day of this engagement, I had my two colleagues and we were working with this senior executive from the VA and asking him all these questions.

First thing he said to us was, Thanks so much for coming. I’m glad the White House sent a team to confirm that everything is okay. And I found out later that in his mind, everything was okay because he had redefined latency as anything over two minutes. So if you clicked on a button in this V B M S and waited one minute and 59 seconds, you were not to report latency.

So that’s an interesting and creative solution to a latency problem. But as we were asking him, why did you make this choice over this choice, why does it try to do this and not do this? He continually said, I don’t know. You’ll have to ask the program people or you’ll have to ask the procurement people.

And I pushed him on it and said, you’re quite deferential here. And he said, yes, I’ve spent my career teaching my team not to have an opinion on business requirements. If they ask us to build a concrete boat, we’ll build a concrete boat. And I said, my goodness, why? And he said, because that way when it doesn’t work, it’s not our fault. It was a gut punch for me. I had come across the country, left my family for a year to get, technologists a seat at the table. I wanted them to be able to have more of an opinion on business requirements. And here was this senior leader saying, no, that’s just not what we do. And of course at the time in the US approximately 18 veterans a day were committing suicide. Many of them having not gotten access to those benefits that we promised them when they go into the military. And so it seemed like quite a abdication of responsibility for something that is actually have enormous, human suffering, that comes out of that abdication of responsibility. And so it, to me, put words to what I had seen before in other parts of government that I hadn’t really been able to articulate.

You have this very heavy requirements process and when you let all of that weight accumulate on a project, it becomes a concrete boat and it won’t float when it ships.

Murray: Presumably , he had spent his whole career delivering systems that didn’t work. So his whole, career was spent on how do I avoid the blame for it inevitably going wrong. 

Jen: I think that he had learned that was the way to succeed. And though I was really dismayed and I think just a little bit shocked by it, I do understand that we have created a system in which he is incentivized to behave that way. And so I ultimately don’t blame him. I blame the system that creates that behavior.

Murray: But how had he succeeded? What was his definition of success? 

Jen: I never asked him that question, but I guess what I would observe is that he was quite a senior official.

Murray: So he was able to rise to senior level in the hierarchy despite a long history of delivering bad systems, because he’d always been able to show that it was somebody else’s fault and he was just doing what he was asked to do. 

Jen: Yes, and I think that there are so many people who are able to weigh in on the requirements for a system like that, then the end of the day there really is nobody to blame. I think it’s a very common thing in government to blame the contractor.

Shane: So I remember a story of a, research project that was done with a bunch of monkeys in a cage and a set of bananas and a fire hose. And of course, the monkeys jumped up. They grabbed the bananas, and so they sprayed them with icy water. And they did that long enough that the monkeys knew, go for the banana, get cold, stop doing it. Over time, they removed monkey after monkey and replace them with new monkeys. And it became the cage culture, that when a new monkey came in, the first thing they’re gonna do is go, ooh, yummy banana. They go to reach for the banana. The other monkeys go, if they touch that banana, we’re getting wet. So they’d stop the monkey. And after a period of time, everybody knew, don’t touch the banana.

I’ve spent quite a lot of my time working with government in New Zealand, and I’ve seen lots and lots of people come into government as a career because they have a preference to help people over helping a big bank make more money. They go in, they try their best, and then over time they just get beaten. And so in this idea of digital transformation and the agile world of, fail fast or try something, if it doesn’t work, you’re gonna learn and then try something different.

It doesn’t tend to line up with the whole blame culture that government gets by people outside of government. As soon as, a government agency experiments if anything goes wrong, then everybody’s up in arms cuz this thing failed. How did you find that balance of people trying to do right, wanting to experiment and find things that help citizens help their customer. But they gotta be really careful around this whole area of blame 

Jen: So I think one of the things you’re speaking to is what I call in the book, the Accountability trap. Public servants are held accountable to process and to checking the boxes and, Meeting the requirements even if the software doesn’t work, there’s never a requirement that says the software will work.

It’s never a requirement that says the software will work for a particular set of people in a particular set of circumstances. So , it’s easy to get mad at them for not getting that outcome, but that’s not what they’re held accountable to.

We do see public servants who break that mold, who do the right thing, even though the culture is telling them not to saying, don’t go grab for the banana. And I think that the book really is an exploration of how and when do those circumstances emerge.

Is it just that, the people who do the right thing, even if it’s not exactly the right procedural thing to do, are just smarter, better, more, braver people and I think that is of course part of the answer, but there’s no hope of change if it’s just all reliant on the hero.

There’s gotta be circumstances under which you create those conditions. You really have to stop spraying them at the end of the day. Now the problem is, even if you took , that spraying of the ice water away, they still wouldn’t jump for a while. They have been trained that way.

I think there’s just a question about how we create these environments in which we still go for the banana and I spent a lot of time in the book talking about teams that do and how they support each other and reward each other for that behavior. And ultimately the book isn’t written for the people who are, in that unfortunate metaphor, jumping for the banana, I’m writing for the people who are spraying them with the water. Stop doing that. Those people are the people who do oversight functions in government. So it’s legislatures, it’s inspectors general and accountability office. It’s legislative analysts office. It is, of course, the press, which will jump on a small failure without understanding the context of that failure and the way that, that failure might be getting to a larger success. And ultimately it’s the public. If we buy into that and we don’t recognize our own role in creating that accountability trap, then we are just still spraying those monkeys with the ice, and it’s our fault in the end.

Shane: So how often do you see the successes celebrated? Over here when I wanna re-register my car. I go on a website. I authenticate myself, I select the car I put my credit card in. It sends me an email and a couple days later in the post comes a little piece of paper that I stick my windscreen. It’s an amazing service. Compared to the old days, where I would’ve had to go to a post office and wait in a line and fill out a form. And so that’s great. Do I yell out on Twitter? Hey, this is a great service. No, I just expect it. 

Jen: It is a conundrum of public service that you can’t get around. Do you applaud when you drive on a, road that doesn’t have potholes on it? No, we just take it for granted. If the train comes on time, are you like, yay, the train came on time? No. You notice if the train doesn’t come on time. I’ll give you an example. I live up here in fire country in California and in the winters we have to burn the debris. We make, these burn piles and you have to burn them before it gets to the fire season and you have to get a permit. And we’ve just moved up here, so I didn’t know how this was gonna work, but you go online and you fill out a form and it just automatically sends you the permit. And, maybe that’s not a difficult thing to do, but, when I heard permit, I thought going to an office and waiting and all this stuff. So I, went on Twitter and said, thank you. And I tried to find the Twitter handle of the Cal Fire Department so that they would see that I was impressed with this and grateful and not take it for granted. But, how many people are gonna do that? Not that many people. 

Here in the us when President Biden was elected, one of the first sort of, little things that he did was send four covid tests to every family. And of course to administer that, they put up a website and everybody expected it to be miserable, but it wasn’t. It took 11 seconds, you got your test a couple minutes later. And that was the first time I really did see celebration by lots of members of the public. Wow, I really expected this to suck and it was fantastic. And it was an opportunity to talk about what choices did that team make so that it was a delightful experience. And and I think to take a moment at that point and say, this wasn’t a predetermined outcome just cuz it was a simple thing. There’s a million ways they could have made that, a half hour forum that you needed to fill out. There was a million ways that they could have failed to have that be scalable be accessible, be available in different languages, and they made choices. And so you have to spend a lot of energy looking at how they got to make those choices, set priorities, and do it in the right way so that we don’t just take them for granted.

Murray: Yeah. If we take a systems thinking lens to this systems thinking, people like to say that the system is perfectly designed to produce the results that it produces. For example it’s difficult to get onto the employment benefits scheme in Australia and quite easy to get kicked off. It’s quite difficult to even get somebody to speak to you on the phone. It feels like it’s deliberately designed to be dreadful so that they don’t have to pay as many people. 

Jen: I know in the US context that is sometimes true, but I have seen many more examples of where they are not intentionally trying to keep you off of the service. So I have a chapter in the book about snap delivery, which is Supplemental nutrition assistance program. It’s our food benefits. Where I know for certain that the state of California very pro welfare state was trying very hard to increase its participation rate, which basically means yes, more people who are eligible for the service should be on it.

And yet because everybody could add, questions to the form and requirements for the process, and nobody could subtract them. There was essentially no, what we would call product manager that the form became, really impossible to use. And so people experienced it as an intentional barrier. But that certainly wasn’t the intent of the policymakers. It certainly wasn’t the intent of the leaders of that department. And it certainly, I don’t think it was even the intent of the, people literally implementing the form.

And I have heard that phrase about systems many times, but I think the way that it is actually not indicative of what I see in government. I have dozens of examples of what I call culture eats policy. And so basically you have a policy intent. It’s, pretty clear. Let’s say in this case, let’s get more people on this benefit or great example in the book is this intention by our federal CIO council to have technology be more interoperable across agencies. So they put out these guidelines in the 1990s that included having an enterprise service bus be an example of interoperability and then that gets translated through the bureaucracy with more and more rigidity every step down until it ends up being called a requirement in all software in the Department of Defense, even though it was never intended that way by either Congress who called for this interoperability, or the people in the CIO council who wrote this federal enterprise architecture. And then they put an enterprise service bus where it’s absolutely not only not needed, but deadly to the project.

And what they create is not only less, interoperable software, but in fact just software that will never work. I’ve a story about an E S B essentially killing a very expensive multi-billion dollar software project in the Air Force because the people interpreted it as necessary as a requirement required by law.

Of course it isn’t. But that’s just one example. I think of the perversion or inversion of policy intent by the culture that implements it. If you asked for X, what you get outta the system, once it falls through this hierarchy, which makes it more rigid at every step down, what you get is the opposite. And so I’m not sure how that adage about systems getting the outcomes that they intend quite plays with this. I think my lesson is in a certain way, the actual opposite of that adage.

Murray: Yeah, I’ve seen a similar thing in the auto industry where there’s certain compliance standards and the compliance documents have a set of examples in them that you may choose to use to meet the compliance standard. And when I was discussing it with management in the context of doing agile, they said, no, we have to do this. And we got an expert in to advise on it and he said, no, you don’t have to do any of those things. Those are just examples. There’s a objective and a set of principles and you need to show the auditor that you’ve met the objective and the principles. You don’t need to use these examples at all. There are agile examples, but you do need to be a little bit careful about which compliance people you get in. Cause some compliance people only know one way of doing it and will mark you down because you didn’t use the standard way. Whereas others who are more experienced will say, sure, that’s a good way of doing it. I’m happy with that.

Jen: Your audience may appreciate the way that plays out in cybersecurity. We have a law called the federal Management Systems Act, fisma, that details 300 different security controls that a team could use to secure the application. And it is absolutely clear if you go read fisma, that those are examples. You’re supposed to have a skilled security team. Choose from among those examples and possibly use other controls. Things change over time. But you’ve got compliance people who don’t know what these things mean at all, and it has to, descend through many layers, many different parts of the bureaucracy. In practice, every security team in federal government has to do all 300 of those controls. At the expense of spending time more on the ones that are actually gonna be useful at the expense of testing, at the expense of red teaming and all the things that would actually secure your application, get shoved to the side in the service of just checking literally all 300 boxes. There’s so many ways in which this is really destructive to the outcome and , totally opposite to what the authors of the law intended.

Murray: And the reason that they’re doing those 300 plus checks is because they feel that they will get attacked if they miss one?

Jen: Yeah, so very common scenario is you have a pretty good security team. And they say, here are the 15 that we need to really focus on. Here’s a thoughtful security plan for this application, but it’s not their call. There’s compliance people who have to sign off on this thing before it’s gonna go live. And there are people above them and there are people above them. And none of those people have any idea if those are the right 15. And they know that if anything goes wrong, they’re gonna get called in front of the Inspector General, or the government Accountability office, or Congress or whoever, and they’re gonna be asked, why did you sign off on this? Clearly it was, security control 285 that should have been in place and you are the one that signed off on skipping that one. And so you’re in big trouble. And because they have no actual technical knowledge or expertise, it’s really hard. I would be also in a difficult position. I’m just trusting that team. That the 15 they’ve told me that are the right ones. Are the right ones. And there’s just more than one of those people there. It’s a vetocracy in which everybody who touches this would have to agree that this plan was okay. If any single member attached it says Nope, I don’t I’m not gonna take that risk. That one down vote kills the whole thing.

Murray: But what sort of trouble can people actually get into though? 

Jen: Oh, that’s a good question. People do get in trouble, and I don’t wanna minimize it. When I went into government, I heard this all the time, you could go to jail for that. Really. I don’t think many people go to jail for what I just talked about doing. Or, I don’t wanna get fired or I don’t wanna end up on the front page of the Washington Post.

The reality is that while people’s careers do get harmed by taking risks there’s also probably less risk in it than the culture talks about. I spend a lot of time in the book talking about this woman, Yadira Sanchez at the Centers for Medicare and Medicaid Services and the team that she works with who do take those risks. And actually, frankly, far bigger ones than the ones we’re talking about.

And they have a culture of supporting each other around it. And because they get the outcomes that we all wanted from, those choices. C m S Centers for Medicare and Medicaid Services is the agency that administers our healthcare system for the elderly and for the poor. It’s enormous. And what they’re charged with doing, is making a system that doctors are gonna have to use. And it’s not a problem if it’s complicated for those large healthcare systems. They just train up new people and have lawyers and expensive Software developers to make new EHR systems for them.

But these small, medical practices, a sole practitioner who’s a doctor is very much affected by complicated software that takes a lot of training. That is, the way that they have to file their quality data or file their billing. And, this team pushed back on the regulators and the policymakers in their agency and said, no we can’t have, nine different definitions of a medical group that’s too complicated for people to use.

And , they fought those battles and won them, lots of them like that. Later on, for instance, she’s asked to do quarterly data dumps of this pharmaceutical data.

So there’s an ecosystem in the medical world that’s gonna consume that data and do things with it. And Congress has asked her to do these quarterly data dumps, but she knows that an a p I would be a far better way to make that data available to the ecosystem. And she just goes to the, stakeholders and says, this is a better way to do it. We’re gonna do that and everybody’s happy. And that’s a far bigger risk. She, in that case, is literally not doing what Congress said. She’s doing what Congress wanted her to do, but she’s not following the letter of the law. 

So if we can see public servants making, taking those sort of risks and being rewarded for them, then we start to change that narrative of the monkeys and the banana and the ice water that Shane talked about. But we have to have those examples of taking far bigger risks and getting rewarded for them instead of getting punished for taking tiny risks that don’t even matter. Doing the right security controls instead of all the security controls shouldn’t even be risky, but it’s the culture that makes it risky. So talking about taking risks and being rewarded is part of how we change that culture.

Shane: You mentioned the word product manager a little while ago, and the agencies I’ve worked with were running in a fixed mindset, waterfall process where there were a bunch of requirements that had everybody’s wishes and success was tick the boxes. Very rarely when we gathered those requirements did we ever talk to the end customer. We never went and talked out to the citizens of the service. We talked to the senior management, or we talked to subject matter experts that were internal to us, but we never talked outside the agency. And one thing that I’ve seen in New Zealand is a change where that skill or role of a product manager seems to be turning up. Where there is a person who is now starting to talk to citizens and our customers starting to figure out what the outcome we want to achieve is what the intent is.

Start to bring some of that product management behavior in. Yes, we get less checklist requirements, but that’s not actually what’s changed. It’s this culture of we have an outcome we want to achieve. How can we work as a team to achieve that outcome? And the product manager takes ownership of that outcome in trying to achieve it.

That example you had seemed like product management behavior to me in terms of, okay, you want the data every three months, that’s your outcome. You’ve told us the checklist is do an extract every three months. But actually as a product manager, I can do it as a an a p I give it to you every day, every week. You still have it every three months if you want to, but I’ve got a better service. A better outcome for you as a customer if you wanted it. And I’m still delivering what you actually asked me for. So are you seeing that product management thinking coming into agencies?

Jen: I think it’s the biggest vector of change I see. And this woman, Yadira Sanchez, who I profile in the book, who goes from, never having heard the word agile, never having talked about user-centered, never having heard about the idea of product management. She gets exposed to it through healthcare.gov, which, was a big it disaster that happened in 2013 when I happened to be working in the White House.

So I was around it quite a bit and it’s my boss who brought in a team of developers to help get the site back up. And it’s through that team that Yadira gets exposed to these practices of which product management is one. And then becomes I’d say the best practitioner of it that I’ve seen. She’s good at it in part because she has such deep relationships within the agency where she works. And that gives her, I think, some of that boldness to make those decisions. I think what she would say and what others have said is project management is very highly valued in government because there are so many requirements that need to be filled. You need a lot of project managers and they have to be very skilled because there’s such a lot of work. But if it’s the art of getting things done, product management is the art of deciding what to do. And I’m not sure whose fault it is that it hasn’t been anyone’s job to decide what to do.

You just did all the things. And yes, when Yadira Sanchez decides she is a product manager instead of a project manager, and of course no one gives her that title, she just decides she’s gonna be that. Later on she advocates for that title and now she hires many wonderful product managers into government. In fact, a lot of the best product managers I know want to work for her. But when she decides she’s going to act as a product manager, that is I think, the biggest moment of change. And it not only has changed her, it has literally changed c m s, which is an enormous government agency.

Murray: I do agile product and project management for organizations. So in other words, I focus on outcomes instead of requirements and agile instead of waterfall. And I had a recent experience where I was doing that and it was going well because I had the support of the leaders that I was working for. And then there was a change of leadership in the IT department and they brought in some new people who are highly bureaucratic, traditional, very defensive, very waterfall. Suddenly everything I was doing was completely wrong. Every element was under the microscope and I just had to leave. 

Jen: That sounds horrible. 

Murray: Yeah, so it strikes me that Yadira can only do what she does because she has strong leadership support. And if her leaders changed to traditional, bureaucratic, process oriented leaders, she would be forced back into traditional ways of working or have to leave. I can appreciate that an individual could be brave in the public service, if they’re gonna get hit over the head with hammers by their managers, they’re gonna stop pretty quickly.

Jen: I think that’s true, and I think she would say that c m s is not entirely friendly to agile and product management yet, so there’s still a lot of work to be done. I think she’s exceptionally good at showing the folks above her why what she wants to do is going to be better. We’re talking about someone who’s been there for 25 years now and I really wanted to make her the hero of the book because there’s such a focus on folks coming in from the outside having an impact with agile practices. And I think it’s the folks who’ve been there 25 years who can have a bigger impact. And I think she is less at the whim of a new manager because she’s been there a really long time and she’s got a reputation. And I think she has helped trained the people above her. 

The other reason I think that the people above her are largely supportive. And again, the whole agency is not completely changed. There’s this area of change that spread out from her that’s getting bigger. But two years ago she estimated that 25% of CMS is operating under a agile product management framework now. And not perfectly everywhere for sure. 

The other thing is healthcare.gov was such a big public failure that the leadership of that agency is now, much clearer that doing things the checkbox way can lead to real disaster. So there’s a culture there of more acceptance of this kind of way. Because the notion that doing it the way it’s always been done is the safe way was disproven with healthcare.gov. It was in the headlines for six months, Congress called CMS to testify in hearings like practically every week. It was a real problem. And I think that created that environment for her.

Murray: Yeah, and it cost hundreds of millions of dollars for the first very bad attempt, didn’t it? 

Jen: Sure. But so does everything else. That’s not unique. They weren’t upset about the money. I mean, think about the story I told with the E S B. This was at the Air Force. I didn’t really tell the whole story. That project was literally billions of dollars over a budget and they still couldn’t remove the requirement for the E S B. And nobody seemed to mind that much about the billions of dollars spent.

Murray: So how do we change the culture of these organizations so that they can do things in a more, agile outcome focused, customer focused way.

Jen: There is not one place you can go to see that agile framework working very well. There isn’t a place where I think that’s been the focus that we can say, here’s the playbook to follow. So I think we have to take the approach that we’re going to try things, see what works, and adjust along the way. I would start with the role of leadership. Leadership and oversight can spend too much of their time working on what is failing and not enough. Lifting up the stories of people like Yadira who made it work and did the right thing. So you have a culture that’s focused on what’s gone wrong and everybody in the agency knows what bad looks like, but nobody knows what good looks like.

So I would first myself make sure that me and my senior team we’re spending our time finding the bright spots and telling those stories and saying, we value these public servants. We value that they took a bold step and did what was needed, not what exactly what was asked for. I would go to the Inspector General and the Government Accountability office and try to influence them to do the same. And I would go to the legislative oversight, whatever committees are responsible for the evaluation of my department’s performance and say, here’s what I think you should be looking for when you evaluate this agency. And here’s where I think you could spend some time elevating what works instead of dwelling on what hasn’t worked. And, then you’re going to need to be tolerant of small failures in order for us to get large successes. And so when you see these small things happening, please understand that if you harp on them and continue to create this culture of risk aversion, you will be part of the reason we are not succeeding instead of part of our success. 

So I wanna spend some time with the folks that work for me in that department. But mostly I wanna change the environment in which they feel they have to work, which means changing the incentives around them and creating more air cover for the Yadiras to feel empowered and for those who get in Yadira’s way with, more and more compliance and process to see a better way to do their jobs.

Murray: So what do you do with the executives and senior managers in your team who are taking the opposite approach? Like they see you coming in and making heroes and they’re, they’ll go, ah, Jen, it’ll be gone soon and it’ll be back to the way it was. We’ve seen it all before and that never works. I got to my position because I’m an expert in applying the policy and documentation so that I would never be blamed for producing concrete boats. What do you do with those people? Do you fire them?

Jen: Often you can’t fire them. But that’s I also don’t think it’s necessarily the right response. I think first and foremost, you have to listen to them and you have to say, let me understand where you’re coming from. You have a vision of what success in your job is, and you have gotten to that conclusion authentically because you have been punished. Tell me how you have been punished for taking risks. Tell me why you think what I wanna do is crazy and really validate it. Because people don’t change when they don’t feel understood. If they feel like I’m not listening, that I don’t actually understand that the risks are real, they’re gonna just dig in further. I wanna kind of meet them where they are and validate that their concerns are real before we can get anywhere.

I want them to understand that I don’t think their concerns are unfounded. And that I recognize in them a strong desire to serve the public, a real diligence and thoroughness and dedication to their job. And that I want to help them take that diligence and thoroughness and passion for public service and see some ways that they might possibly channel that a little bit differently. But it’s gotta start with them feeling listened to, or we are absolutely just going to clash the whole time.

Murray: What about changing their key success criteria? Because it strikes me that executives do what they’re rewarded for and avoid what they’re punished for. So if you change the system or rewards and punishments for them and the sets of measurements you use you might be able to get a very big change in behavior quickly if they believe it.

Jen: Absolutely. The challenge with that in government is that the real ways in which they’re evaluated are not in your control. It’s not like there’s a bonus plan that you get to change the success criteria for. And as you said, they know that I won’t be there forever. So you really have to make them just believe. That is the criteria for their success. They’re still bound by the civil service rules. I can’t change those. They’re still going to be promoted according to the s e s schedule. These are ways of hiring and promoting that go across government that are not in the control of a department head. Or even, a cabinet secretary. So I have to have them believe that their career somehow will be better and that they will be happier people, that they’ll be more satisfied with their job, that they’ll go home at night and be proud to have worked in this agency. I have to appeal to a bunch of things that are not really about what’s on paper for this to succeed.

Murray: What is the role of the agile values and principles in this sort of change? Do you think it has a role? Is it helpful?

Jen: Do you mean like the actual principles in the Agile manifesto?

Murray: Yeah. Not Scrum or safe or anything, but the values and principles. Do you think Agile is helpful here? Is that what you are proposing that people work in an agile way?

Jen: Yes, I am. But it’s not any particular flavor of Agile. If you do standups, that doesn’t mean you do agile. If you have a backlog, it doesn’t mean you have Agile. When I talk about Yadira Sanchez; this program which is very burdensome on doctors. The legislation says that doctors who take only a very few Medicare patients is exempt from it. But the regulators are saying you’re gonna have to run them through the program first, and then you can exempt them after the first year, which is bananas, because that’s putting this whole burden on them for a year on only to find out that, they don’t ever have to do it.

And she pushes back on that and fights the fight to say I know you think I’m just here to get the code written, but I’m here to make this program work and it won’t work if you do this. You will drive doctors out of the program. The congressional intent here was to improve the quality of care and not degrade it. That’s more agile to me than whether you do standups, or any of the trappings of agile. 

I talk in the beginning of the book about the ways in which folks in bureaucracies don’t stand up and say, look, I have some information here that is really pertinent to whether the implementation of this law or policy is going to be faithful to its intention and you need to listen to me.

And when people don’t do that, it is not just that they are not practicing agile development, it’s not just that they are doing waterfall development, it’s that they are caught in a much larger waterfall of government. 

It’s waterfall when the people in the lower rungs of an hierarchy have no voice to those above and only do what the folks above them tell them to do even when the end result of that makes no one happy. You get the outcomes that are opposite to what, the policymakers intended. They’re not happy either. It’s not like it serves the folks at the top, at the expense of the people at the bottom. It literally serves no one. So yes, I think agile is valuable as a methodology for development, but I think the notion that Waterfall is destructive to the public good in a much larger sense is the main point.

Murray: Yeah. All right, Shane, shall we go to summaries?

Shane: All right. This has been a bit of a personal one for me. I started my career working in government, right at the bottom. And I’ve spent a large amount of my career working with agencies, typically in an external or transitory role rather than a permanent one.

I prefer to work for organizations that are gonna do good if I can, compared to organizations that are just gonna make money. But when I work with those agencies, this whole environment where anything that goes wrong, they get blamed. Anything they do well we ignore as citizens. It just gives me a massive amount of admiration for people , that work in there every day just trying to do good. So when I hear of stories where, somebody’s taken the 212 question application and reduced it down to minutes on a mobile phone, those are the things we should be celebrating because we’ve enabled people that use that service to get the benefit that we want ’em to get.

And I’m with you around Gov UK and gds in New Zealand. We’ve adopted a lot from that organization and the fact that they were such trailblazers in this new way of working within government and as a digital service and their ability to share, their ability to go out and actually travel the world, helping other government agencies around the world adopt things that have worked for them, that’s an amazing change globally that I think lots of people don’t know about. 

So this idea of fail fast it’s not something government agencies can do. Oh, we just spend a bit of money on MVP and, learn some stuff. But in a government organization we can’t do that. 

And the other thing is, in a government organization, our customers are captured. They typically don’t have a choice of going and buying that service from anybody else. So often we ignore them because we don’t have to talk to them, because if we don’t talk to them, nothing bad happens to us, it just happens to them. 

This whole idea of product thinking is really important and can make a big change. When I’m working with a large organization and I’m coaching a team, and that organization still has a fixed mindset, it still has a hierarchy. It still runs on checklists. It still behaves in a traditional way from, a factory in 1950. Often we’ll see that team adopt new ways of working and be really successful, but they typically hit an organization wall, at some stage . And so what we often talk about is this idea of a heat shield. This idea of a person that manages people above them gives the team time and space to be successful. And then you gave us some great examples of that happening within agencies where those leaders are enabling their teams to be successful. 

One of the key themes, that I got outta today is that actually people that are making those changes in those organizations are brave people. And so we should celebrate when something works for us and it’s an amazing experience. We should tell people about it because they need that good feedback. 

I love the idea that the product management way of working is coming in. So this idea of changing from a checklist requirements to a set of goals. Let’s give them the space to say where they can work and let them get on with it because they’re good people and that’s why we hired them.

We’ve had a few people come on the podcast talk about mission command. Moving away from a set of steps that a squad needed to do to an objective and the boundaries, with what what the rules are, and then letting them get on with it.

And so what I’m hearing is that starting, happening outside those defense organizations to let a team understand what good looks like, what the boundaries are, and get on with it. But for me, large traditional enterprises and government agencies feel the same.

They have all the same problems around scale, ways of working hierarchies and I don’t see them as particularly different. It’s just a large organization problem. Maybe with the government agencies the blame culture from outside their organization makes it worse. But one of the benefits is government agencies aren’t competitive. So that ability for them to share knowledge, actually share people. So we see that in New Zealand now, where people are starting to be seconded across agencies for a year or two to cross pollinate some of that learning. And that’s having massive success. So that idea of sharing, like the gov.uk people have done is one of the benefits of government agency over a corporate, so no bank’s ever gonna go share their IP with another bank, typically because they compete, but we don’t have them in government.

Jen: A shout out to the team at the public digital that’s doing a lot of that sharing. They’re former gov.uk and GDS folks mostly now over at this group that are traveling the world. So look ’em up. Public digital. 

Shane: yeah. And if you are struggling as an agency, go find another agency that seems to be doing well, and go and ask them how go ask for their help because they’re able to share that knowledge and do good at a global level. We need to celebrate the successes more than the failures if we can. Murray, what do you got?

Murray: Yeah, I thought your book was very interesting and I discussed it with my wife who is a director in our public service here. I’m trying to get her to read it. She’s too busy battling the day to day bureaucratic fires that surround her right now. But yeah, it was very interesting exploration of why there are so many enormously expensive it digital system disasters within government in America. It happens everywhere around the world. And I found a lot of similarities with what happens in banks and telcos and any large old conservative organization that works in a traditional hierarchical siloed way. They all have the same sort of problems. It’s just that they’re a lot worse in the government because the government’s so big. And you talked a lot about the accretion of systems over time and policies and processes makes everything super complicated. You get the same thing in banks as well, although, as you say, government is worse. You could come away from this feeling quite depressed in a way, but I like your stories, about how people have successfully changed things, whether it’s Yadira Sanchez and the work she was doing with health. All of the massive improvements that happened to fix healthcare.gov. There’s a lot of things that could be done, and there’s a lot of very dedicated people in the public service, but I agree with you that it’s the culture. The culture and the processes, what gets rewarded and what gets punished in order to rise to the top of a government department you’re spending your career avoiding getting blamed for things and working out how to operate the system so you can get something done. If you read the right hand side of agile, which is what not to do, that’s what government does.

So focus on processes and tools, contracts, documents, and following a plan is everything that big bureaucracies do, and the result has always been quite bad outcomes for customers, clients, even legislators. And I see focusing on the other side, people and interactions, working products, collaboration, and responding to change as being much more effective way to work.

Agile is only part of it, though. I agree with both of you that a product management mindset is absolutely critical as well. And I think. Those two tie very well together. If you just do agile by itself, you end up taking an order taking mindset. So the product management view of the world is critical. Understanding your objectives, your outcomes, what’s desirable for your clients, what’s valuable to your organization and what’s technically feasible. And balancing all those things. Doing continuous discovery and continuous delivery together with empowered product teams, scaling up through trial and error and finding out what’s working for you and scaling by continuously improvement, I think is a much better way to go than implementing safe or some of those other massive monstrosity processes cuz they don’t produce the Agile outcomes we’re looking for. In fact, I believe that the Department of Defense had a big memorandum on how they didn’t want anybody to be using safe cuz it doesn’t produce the outcomes that they were looking for. Do you know about that?

Jen: I just know about the real preponderance of what we call fake agile. I’ve heard bad things about safe. In fact, one of the things I did with the Defense Innovation Board, we wrote a document, official government document called the Agile Bullshit Detector.

It’s incredibly popular. It’s most popular thing we did in that entire board. It got discussed on Reddit and stack Overflow because basically, there started to be this thing like, oh, agile is good. And the vendors would just put the word agile on the proposal and then that one would get chosen and it wasn’t agile at all. And that’s very destructive to actual progress.

Murray: I certainly see an enormous amount of that. In fact, I’d say most of the agile I see in large organizations is traditional waterfall with the requirements written in epics and stories in a really confusing way, and with the development done in sprints, but it’s actually not agile at all and it gives real agile a terrible name cuz it’s probably worse than what they had before.

Jen: We’ll look up the agile bullshit detector and see if it’s useful. 

Murray: I’m glad we talked to you. I came away from, reading your book thinking, it would be good to work for government and to do things to help the community. I would really like to do that, but I think my tolerance for all of the bureaucracy is just too low. I’ve avoided working for government because of that.

Jen: You should go work for yadira Sanchez. There are these places in government now though, where you can go do product management, agile, user centered, and if you have a lower tolerance, but you have that desire to, serve the public good. I would encourage you to seek out those places.

And as Shane said, it is changing. It’s changing everywhere. But you don’t wanna go into those, one of those places where you’re just gonna beat your head against the wall. Know your own tolerance, for the frustration, but also know that there are places where that frustration will be a little lower, and where your ability to tap into that good feeling of doing something for the people of your country, and the public good is gonna be incredibly rewarding.

Shane: Just, watch out. Murray, don’t go for one of the large digital transformations, by the shiny suited consultancies doing safe, where you’ll spend three years of your. Life and hundreds of million dollars making the process worse. Where the poor frontline worker for that agency moves away from one system with 50 screens to three systems and 16 spreadsheets, and that’s called success. So yeah, just find the one where you’re a yeah. Where you’re actually making the world a better place. And it’s really rewarding.

Jen: Yeah. Yadira does not have any of those. There’s no multimillion dollar project for transformation there. She’s just doing it. Yeah. you, gotta find that. That’s where you should be spending your time. 

Murray: I don’t know where to find something like that in Australia. I haven’t heard of anything. 

Shane: When you go there, look on the walls and if you see those bullshit posters with all the buzz words then you know you’re in the wrong one. If you find some good people doing some good work and making shit happen, then you know you’re in a good one. That’s typically my test.

Jen: If you see sticky notes instead of posters, you’re in the right spot.

Murray: Yeah. I find that the organizations that are doing this for real actually employ their own software developers. They’re not outsourcing it to Deloitte, who outsource it to a company in India who outsource it to another company. They actually value it enough as a capability to have it in house.

Jen: I think that’s true, but I also see teams that have enough technical and product management expertise in house that they can hire well outside, but they tend to be hiring smaller firms. They’re not doing it all, but I would agree they have to have a core competency inside of product management and to some degree engineering and certainly user research. But then they’ll hire extra people doing all three of those things.

Murray: Yeah. All right. So you, you’ve got a new book that’s just come out called Recoding America, which is what we’ve been talking about, 

Jen: Please read the book. It explains so much. It’s an easy read. It’s not a policy book. It’s a romp through fun bureaucracy stories. And also I have a website, recoding america.us, where I just put some of the ways in which folks can follow up. It won’t be very helpful in terms of things like how you go into public service, but some of the other stuff is pretty largely applicable. Obviously very much written for an American audience. But check it out and you can reach me on that website if you’ve got some comments or feedback or suggestions.

Murray: Great. Thank you for coming on. Really appreciate it, Jennifer.

Jen: Thank you for having me. It was great to talk with both of you, and I look forward to hearing about your new job marie.

Murray: Thanks.

That was a no-nonsense. Agile podcast from Murray Robinson and Shane Gibson. If you’d like help to create high value digital products and services, contactMurray@evolve.co. That’s evolve with a zero. Thanks. For listening.