NOEL:  Hello and welcome to the Tech Done Right Podcast, Table XI's Podcast about building better software, careers, companies and communities. I'm Noel Rappin. If you like the podcast and would like to encourage us to continue, please follow us on Twitter at @Tech_Done_Right and leave a review on iTunes. iTunes reviews really do help people find us and we appreciate your time and effort.

Today on Tech Done Right, we have an unusual and I hope a special show for you. We're expanding our scope beyond companies and communities and onto using software to build better countries. Our guest today is Andy Slavitt. Welcome to the show, Andy. Would you like to introduce yourself?

ANDY:  Hey, Noel. It's good to talk to you. I'm a recent Obama official and currently, enjoying my baby-brief retirement.

NOEL:  Let me put a little bit of meat on that. Andy spent the last two years as the acting administrator for the Centers for Medicare and Medicaid under President Obama, which put you in charge of Medicare, Medicaid and Healthcare.gov and I believe, a significant chunk of the federal budget, more or less. Correct?

ANDY:  You found me out. Yeah, that's right. I believe the fun fact there, Noel is about a trillion dollar budget, which is about 25% of the federal budget.

NOEL:  Yeah, that's unimaginable. Before that, you were placed in charge of the recovery effort on the Healthcare.gov website in 2013 and 2014. You've been a very public advocate for patient care over the past couple months both during the transition and during the current debate on the changes to the Affordable Care Act. Today, I think you're on MSNBC and C-SPAN, is that correct?

ANDY:  Yep. I'm heading back to Lawrence O'Donnell tonight so if you're still awake, you can watch me again.

NOEL:  Yeah. Those are not traditionally our feeder shows. Our green room snacks are not as good. I'm sorry. I should say also, we're taping this on March 13th. The Republican bill is being debated, has not yet been passed. You are probably listening this in the future, where unknowable things may have already happened. Who knows? We're expecting the Congressional Budget Office's official scoring on the current bill to come out possibly even while recording. If we leave that in, you might get Andy's surprise and shock.

ANDY:  Very exciting.

NOEL:  But as much as I would love to talk about healthcare policy, this is a technology podcast and ever since you got involved -- we're related -- I've known you forever. That's why you're here in case people are wondering why and how this actually comes about. I've wanted to talk to you about Healthcare.gov for a long time. We've never really got the opportunity. To talk about what that project was like from your level, from the inside at the highest level and then maybe a little bit more broadly about the intersection of technology and government and what it means to have a public policy that needs software in order to be implemented.

Maybe you could start by giving a little bit of background. According to our metrics, we do have some listeners from outside the United States so maybe you could give a little bit of background on what the Healthcare.gov was set up to do and how you became involved with it to begin with.

ANDY:  Great. Thanks. The CBO score did just come out and this will not be in anything interesting to your listeners because they will not be in suspense but it did come out just as you predicted. You know, Healthcare.gov was probably the scariest thing, truth be told, that I ever did. I don't know if you have the experience of ever saying yes to something without I really knowing what you were saying yes to or even exactly why you said yes. But the situation was like this. People may remember 2013, there was a big public launch of the health insurance exchanges. There was a lot at stake and the things that felt like they were at stake to me were the President had staked his domestic legacy against this Senator Kennedy who recently passed away had spent his entire career as had many presidents trying to get health reform done in the country and lo and behold, it all came down to a crappy technology launch.

I think for many of your listeners who have launched important technology projects and are part of launching important technology projects, that sort of feeling when you've got a fairly public project and you've got something in trouble, multiplied by a thousand, multiplied by every eye in America on you and literally a daily press conference with hundreds of reporters. That was sort of the situation. In the midst of that, I called the administration and said, "I would be willing to help," and little did I know that I was probably the only person that called and if it wasn't just me it was the organization I worked with.

NOEL:  [Laughs] They said yes suspiciously quickly?

ANDY:  Yeah, they said yes suspiciously quickly and in fact, the funny part, Noel is that two days later after they agreed to work with us and I should just spend a minute saying that, "My pitch was the following: You have a technology problem. You're not alone. This happens all the time but my prediction is you don't have a technology problem as much as you have a management problem." In other words, there's a very solvable set of technology solutions for what probably ails you but you're not going to them unless you figure out how to manage this project differently. I'm more than happy to come in and do that but only two conditions: one is I really can't do it by your rules, just for simply because I don't know them and second is I will treat it like my own problem. I'm not a consultant. I run a very large organization and I can bring people and resources to bear.

Of course, this is the funny part. After they said yes and we said, "Great, we'll help," two days later the White House had a press conference, they announced that I would be doing this and then they announced that it would be fixed within five weeks, which was never part of our conversation.

NOEL:  I think a lot of people listening to this are going to be able to relate to having deadline set for impossible projects outside their control.

ANDY:  Right, of course. The first time I heard it was at a public press conference when I was watching it on TV.

NOEL:  Let me back up a half step and just to set the stage on this. The Affordable Care Act radically changed the way the healthcare was delivered in the United States and one of the pieces of that was that people were going to be able to buy healthcare, even people who are not covered by their employers are going to be able to buy healthcare on these insurance exchanges that where potentially states were going to be allowed to set up their own and if they didn't, the federal government through Healthcare.gov was going to allow people to purchase insurance through online, through the Healthcare.gov website. That rolled out, I think October 2013. Is that correct?

ANDY:  Yep.

NOEL:  And it was immediately... But you were involved with it before that a little bit, is that true?

ANDY:  Yeah. I had the following familiarity. I had bought a company and I ran a health-care company that is called Optum and it was, I think about 40 billion dollars and we had a subsidiary that had a contractor that was on one part of the project and the part that built something called the data services hub, which was essentially a service that called different government agencies to get information when someone needed it. That part was not the problem. The problem was the other part of it so I had a passing familiarity enough to be connected to the project but really my involvement didn't begin in any substantive way until October 2013.

NOEL:  You touched on something that I was really curious about and the healthcare launch was immediately a problem and within the technology community, it became a little bit of a hot potato. We'll put a link in the show notes I sent you a link about an article from Bob Martin, who again some of the people listen to this one will know Uncle Bob Martin who had this sort of incendiary article about how this was the worst technological disaster since the Challenger explosion. He was a little bit sort of cranky about that but that was the tone or at least one of the arguments within the technology community --

ANDY:  What was the argument, say that again?

NOEL:  He made a number of arguments. His primary contention which I thought was unfair was that the problems with the website indicated that nobody involved really cared. I don't think you can separate this from sort of a libertarian critique of doing this at all and a sort of libertarian critique of what government work is like. But it seemed to me at the time and what I want to understand about this is I imagine there's a tremendous amount of complexity in creating a project like this that we don't even see, we don't understand coming from the outside of it. I guess my first question is what did you think the problems with the application were when you signed up with it to fix it and did that turn out to be a reasonable understanding of what the issues were?

ANDY:  Yeah. Look, I'm sort of Occam's Razor believer, at least. I think you asked a question in an interesting way because we sort of start with our own beliefs but my theory which turned out to be the right one, was really just poor organization. Big project -- I know we all have been a part of them -- unclear who does what, multiple vendors, deliverables coming in at multiple different times, not singularly well-coordinated and managed. I think there were some other things, one of the contractors wasn't awesome, some of the reference architecture that was picked was novel, some of the technology pieces hadn't been done at this scale before so they were trying to do a new thing and I think they could have if it was incredibly well-managed, run and organized and executed and the reality was we all now this now which is wasn't.

Once that was fixed and we know I have this five-week window to do most of the work and there was more work to be done for sure after the five weeks. But getting that right fixed, in my mind, 75% of it, I think we also brought some very talented people, very talented technologists to help out. As I think you know, you can fix a lot of things with a small group of people if they're smart, work well together and that's also to me about organization and management as well.

NOEL:  There's a couple of different direction I want to go on that. How does something like that, a government project on that scale structured? When people are originally are signed on to do parts of that, are those bid out in piecemeal? Was the problem that each individual piece of this was bid separately and they never actually hired somebody to do the coordination? What is the process for even just selling? Like who is in charge of requirements for a project like that size? How are those disseminated? I'm asking a ton of questions and I should probably let you talk now.

ANDY:  I wasn't there when it was conceived but I can tell you what I observed, which is that they bid out different pieces to different contracting organizations to deliver different pieces. They didn't have a general contractor or systems integrator. The government played that role on its own and they were just a lot of dependencies. Then I think you had the reality that you have in every project but I think on steroids, which there was a drop-dead deadline, there was a fixed set of resources and I'm sure it felt for the people on the project, at the time, again I wasn't there, that the specs were moving around continuously because the specs in this case began with the regulations. They would be issued in regulations, were issued accordance to a schedule of public input and a bunch of other things.  

I'm sure if you were on the project, you could have named a bunch of different factors that felt like they were contributing, I would roll it all up and say, "Things probably could have been managed differently" But look, I would tell you that your role and what you do in a turnaround is different than in just sort of the normal management of a project. You have liberties in a turnaround to do things faster, to cut corners, to break rules, to bring in talent, to spend money, to do a bunch of different things, whatever those things are needed. I can speak to fixing it better than I can criticizing the people who screwed it up.

NOEL:  I guess that the way that I think of managing software projects, it's sort of axiomatic that you can't fix a project that's behind schedule by throwing people at it. Based on my smaller scale understanding of how projects work, when Healthcare.gov came out and when the initial launch had such problems, I think that myself and a lot of the people that I was talking to about the technology of it, really were skeptical. I do remember seeing that five-week deadline and thinking like there was just no earthly way that that was possible. Were the problems not as deep as they seemed to be? Was the rescue effort larger than anything, sort of it would have to almost be on an unprecedented software scale?

ANDY:  Yeah. It's the right question and is really the heart of the matter. I got there October 24th. I didn't have a conversation with my wife until, I think November 12th or 13th. I literally wasn't even able to spend a few minutes to pick up a phone and call her. When I called her, what I said to her was, "I think I've made it worse." She said, "You couldn't have possibly make it any worse." I said, "No, I made it worse. I stepped in a creaky boat, put my foot in it and now we're taking on water," and we were actually further behind two weeks in, than we were when we began. The reason was, we were on let's say, "Release 8." By that time we were on Release 10 or Release 11. We've actually got to a point where we're literally doing a release at night, which is amazing.

NOEL:  That's very common in open source web software but that scale of enterprise software is pretty impressive.  

ANDY:  It's crazy. By the end, we did become a well-oiled machine but that's what gives away a little bit of the plot. At the point that we did 12th, not only the two releases we put in have to get backed out. We had to back out an additional release. We found out of course, at the same time that the hardware was unable to support the software. We didn't know that until we put in, I think it was Release 12.

What I did and I firmly believe that I did it because it was the only thing I knew to do was that everyone had a million ideas and wanted to sit in a room and talk about how to change the architecture and be smarter and all that. I said, "We're not going to do any of that. We're not going to work smarter. We're going to work hard and what I mean by that is we have 6000 defects and we have in effect, 36 days so I know how many defects we need to get out in a day. We're going to bring in enough high quality bodies to be able to each get out, whatever it was, to get out ten to twelve defects a day. We're going to start at the front end of the system then we're going to go backwards and we're just going to basically plug. Then we're going to get to a point where we're going to have some decisions to make. That was my judgment. We're actually just going to plow through this and get momentum and I believe that was important because I also knew what would have sadly happened which is that every time we got rid of one defect, we would find two and that happened for a while so we sat there, with literally more total defects a few weeks in than we had begun.

Eventually, that's the point at the time when I called my wife and said, "I just screwed this thing up." We got a whole bunch of new hardware, we had to get it delivered and shipped and installed just in time barely testing some of it after Thanksgiving. But eventually, we started to get past the horizon where for every bug we'd take out, we would solve two or three. I had committed to the team that that would eventually happen. I had committed to them because I needed to believe it as much as anything else.

But eventually, you started to see that due to hard work, things are started to clear and it was right around that point in time and we were making hardware improvements to the system because we were realizing that it couldn't handle nearly the load that was going to be on the system once these things were cleaned up, that we did start to say, "Ok, now is the time to work smarter," and we only got to maybe a few days before Thanksgiving, we were probably at Release 34 or something like that and said, "Let's identify the 65 most important defects to get out."

All these people who had all these great ideas in a couple of side teams running and basically, we locked ourselves in a room and found the 65 most important defects for a user to get through the system. I would say that when we got to the end of November, not everybody, but the vast majority of the people were able to get through the system and get through it in a reasonably decent amount of time. From when the time I got there when virtually nobody could. I think really the order of it was work hard, first just because there's so much to do and we don't have time to debate, get some momentum then start working smarter and smarter and identify the problems along the way and be willing to fix them every day.

Of course, you know the environment, Noel. There's like three stand ups a day and massive amount of information, decision making, communication, badgeless culture. I reorganized everybody and where they created an office in Virginia for people to work on defects. I created an office in Maryland for people to work on operations. Moved people from their home court silos into those locations and that's when we started see real progress.

NOEL:  I have so many questions. First of all, I guess from a manager's perspective, this is an interesting takeaway for people who are on projects that are in trouble to have the initial thing you try and solve be not to try and fix all the problems at once in the perfect architecture but in some ways solve the immediate trust issue by making the immediate focus being able to get users through the system and have the first step be to try and build back up user trust. Is that the kind of thing you're talking about?

ANDY:  That's exactly right. Look, maybe someone smarter with different skills might have approached it differently. This is a reference architecture that nobody could understand. There wasn't any instrumentation on the site. You have to understand so nobody knew what was going on. The morale problems were massive. We had different contractors who were pointing fingers at other ones and people weren't working, people weren't showing up. I had literally had to hire two people to take attendance from one of the contractors just to literally make sure we had contractors, programmers there who knew what they were doing.

I guess it all depends on the state you're in. I don't know that you would necessarily be able to overgeneralize and take this to any project but I do feel like what you said is absolutely true. We had to run at that true north. Everybody had to know what that true north was. Everybody had to know how decisions were getting made so literally just setting up a process so at four o'clock everyday, people could review the defects. We could have testing time. We could make a decision of go/no go on the release that night. It could then be regression tested and all that and put it overnight. Takes the system down, take the system up put the back up and we got very good because we knew what was needed. I don't think we would have been able to do that if we would have tried to outsmart ourselves. I don't think we would have been able to get it done.

NOEL:  As a technology person, the temptation is always to try and fix the root cause first. Sometimes, that's not the right thing to do. Sometimes what you need to do is put the fire out first and then address the architecture.

ANDY:  I'm not sure if we even knew exactly what all the root causes were. We needed to get more people to bang on the system and we couldn't get anybody through the system so we had to clear out the clutter to even get to that point. So many things felt like luxuries like knowing root cause, knowing the root architecture and having the code documented. We had none of those things. It probably was good that I wasn't a technology person, Noel, because if I was, those things might have scared me off and I probably was not smart enough to know.

All I knew was 6000 defects, 36 days, get to work. I don't want to suggest that what you're saying didn't also happen. We had some very, very smart, terrific people. Mostly working on debugging the hardware and operational stuff. We got some great people from Silicon Valley, Microsoft, Google, etcetera who were doing a little side projects at the same time but it wasn't the main event. It didn't have a place in the decision making until we got closer to the end.

NOEL:  Would you characterize the defects as being primarily communication between different subsystems or they were primarily just code that was wrong? Was the requirements are poorly understood? Was it your integration that was poorly communicated? What kinds of things that you find yourself fixing more?

ANDY:  It was all of it. We had haphazard code that was a lot of it. Your first example, that interaction points between the subsystems, truthfully we didn't get a lot of that out until the second year or third year. Those are the stuff that just made the thing slower and inefficient and would cause 1% to 3% of the people to run into some time out loop. We didn't have the luxury at that point of worrying about those cases. I wanted to get 80% of people through the system, then 85%, 87%, then 88%. For me, that meant going at the upfront stuff first and going back and back and back and back.

NOEL:  It's an interesting strategy of trying to get as many people as far in the system as possible. I guess it sounds like you're saying you're doing that just partially that's your strategy so that you can learn more about the problems of the backend of the system that are being sort of hidden by the problems on the frontend.

ANDY:  Exactly. The biggest and best example of that is the best thing that happened to us was when the data center went down. I've refered to that earlier when I talked about what happened on the 12th -- my memory isn't exactly right, maybe 8th or 9th or something. When the data center went down for two days and we realized we didn't have the hardware, it occurred to me everyone there was panicked because the site was down, hard down. The silver lining, I think someone said to me, "Andy, you're lucky this happened now and not two weeks from now," and I said, "That was exactly right. Break it as soon as possible, figure out where to break it as soon as possible."

If you basically believe that smart people and good management will eventually solve the problems, what you need is enough time to solve the problems. That became one of the cultural values. By the way, we haven't talked about cultural stuff that much but the lessons that I learned that I think are broadly applicable, homerun, 100% of time, everything that I've ever done, that incentive and cultural lessons because no matter the situation and identifying problems and getting people to speak up about problems, it became a huge cultural rule.

We do a standup meetings. Someone would say they screwed something up, they would get a round of applause from the pit boss -- pit boss is the person who ran the standups --because that was what we were trying to encourage and people before, you don't want to be the one to cause a problem. They were like, "Something happened at 3:37 on the logs and somebody did something. Anybody in this room do it?" No hands go up. That's a problem because somebody did something. We got to figure what it was so we don't do it again. When people finally broke themselves of that. It was much, much better.

NOEL:  That's something I hear and I experience all the time as one of the differences between good organizations and bad organizations is the way they treat people who speak up about problems that they see or problems that they cause. The largest enterprise project that I've ever been involved at was at Groupon and we made a point of telling all the people that came in -- I used to run training for new developers there -- and we need a point of saying like, "You're probably going to do something that's going to bring the server down at some point. Everybody here has done it and it's going to happen again and you may do it at one point and what you need to do is fix it and not worry so much about hiding it."

ANDY:  That's a great thing to do because people feel like they can do better work that way and of course, problems are dangerous when they're hidden. They're not that dangerous when they're known.

NOEL:  What kinds of things do you do? First of all, how many developers and how many people were you dealing with at peak?

ANDY:  It was maybe in the mid to high hundreds.

NOEL:  What do you do in an organization that big to try and change the culture like as much as changing the software seems like a daunting task, changing the culture on my own experience, also seems like a daunting task. What kinds of things do you do for a group of that many people? Does it help that you're mostly bringing in new people? What sort of practices you put in place?

ANDY:  We didn't really have the luxury to bring in new people because the people that wrote the code because it wasn't well documented We're the only people that can fix it. That's why it was such a kind of a great cultural lesson because you had to take effectively the same sets of people. There are few things. One was badgeless. Basically, I don't care if you're from the government, I don't care if you're one of the contractors. I would say, "Which contractor you are from, you're on the same team," and we had to do things to model that but badgeless became like the key phrase and key buzz word but badge meaning what you wear around with your corporate identity on it.

It start to be confused for, you have the database people do the databases and the code and people do the coding and hiring people are hiring. But when I reorganized people's locations, we mixed them up. At our operating center, we had one person from every vendor and we had them available 24 x 7 that were available. At second year, we had HipChat but by the first year we created an open line that people had to be on at all times. If there was ever a problem, everybody was on that line and it was just people could sort of see that and then there was a lot of bad stuff in the media and I basically went to all the CEO's -- these are big companies like Verizon, Cisco and Oracle -- and said, "Look, you guys are going to have to stop talking to the media and you're going to stop blaming one another because from now on, anybody that takes a shot at anybody else is taking a shot against me. You take a shot against me, you're going to find out what happens."

"On the other hand, if you stop doing that, then I will guarantee you this. I will have your back. I have your back in the media and anything that goes wrong, I will take full accountability for and I will never point a finger so you screw something up, we screwed it up. I screwed it up. You choose you can play by those rules and everybody is together. We're all for one or if you have to choose to go it alone, you're going to get isolated and it's going to be painful."

We did press conferences every single day to report on progress and what was happening and give people confidence but also a realistic sense. I think those things plus when we finally broke through and made some progress. I probably should add and I probably should said this at the beginning, this wasn't like any old technology project. This is stuff you could believe in. This is giving people access to healthcare for the first time in their lives. People could be culturally and mission committed.

NOEL:  How long did it take before you felt like you were turning the culture around the way that you wanted? Was that something that took days, weeks, months?

ANDY:  I felt like we injected the culture pretty quickly with a lot of energy and really were able to model openness. You know this far better than I do so you can disagree with me but my perception is technologists, they want to be fact-based, they want to be problem solvers. It's unnatural for them to have the political cloak. Let's make sure we don't get the blame thrown on them. I think I lifted it up and I think it was easier because people went to their natural state. Now, I will say that some of the corporate management people were the hardest. I felt like the technology teams were easy to get to that cultural place because that's where they tend to live anyway. Correct me if that's not about right.

NOEL:  I think often the problem is that the technology people want to solve the problem before they even figure out whether they are solving the right problem.

ANDY:  I think that's right. I think if someone's saying what's the work and what's the most important work, that's what I was able to do. I mean the thing I heard over and over when I came in was we need someone to be in charge, who's going to be in charge so it was easy enough to say that I'm in charge and I know how to get a decisions made and of course, I didn't know the answers to any the questions that needed to get made but I know how to get those answers made and then I can get those processes set up and then people could really work.

The people that I had most difficulty with were, maybe one or two of the dozens of contracting firms, the management folks not being as on board or not being quite as giving us their talented and capable people. They were tired and there was a lot of finger-pointing went along but my perspective was whatever you do -- good or bad -- will be visible.

At one point, I did twice daily calls with the White House, reporting on just how that one contractor was doing. I had them on the phone and I would call it like I saw it. I had the CEO on the call, "You can have really painful calls from the White House or you cannot and if you're doing your best work and you have been solving every problem, those are going to be fine calls. But if you tell me you're going to do A and you don't do it and you would say you're going to have 15 developers on the project and you really have 11, you're going to have to answer for that."

NOEL:  Being able to bring in the White House as your hammer, behind the scenes, hammer is not an option open to many of the software projects that I've been on.

ANDY:  There's always usually somebody. There's some equivalent --

NOEL:  Right, that's definitely the right principle like we are altogether and...

ANDY:  It goes both ways, Noel. It goes to core motivation like I tell you, people are wired either one of two ways. They're either wired in a way where they don't want to get in trouble and they'll do anything they can to get out of limelight or they're wired in a way where they want to be able to boast about their work and have their work shown and known.

Once you figure it out at a project which way somebody is wired, which is someone is more wired, you know how to motivate them because the people who are doing a great job and are motivated the first way are like, "Great. We're going to have meetings twice a day," and people who just want to be out of the limelight and get their job done when they are doing a great job you say, "hey great you don't have to meet with me with me ever at all." But if you're talking to the second type of person, you do the opposite. You say, "Hey, you're not doing well so when you call me to get my attention, you're going to find it very difficult. You're going to be dealing with some other people and when you're doing well, you're going to hear your name and you're going to get to spend more time with me." People are motivated by different things and you have to know how situationally manage and motivate people and that is universal, I think.

NOEL:  You say, it took about two or three weeks for you to really feel like you starting to turn the ship around and feel like you're making progress. How long did it take before you felt like you could stand down to normal process and start thinking about some of the larger aspects of recovering the project or did it ever get there?

ANDY:  It's interesting because the software was used during open enrollment seasons. You had kind of a natural rhythm.

NOEL:  So you had a break after --?

ANDY:  Yeah so we could begin doing planning. The open enrollment season ended in January then we begin to get a team setup to do planning. For the next season and the next cycle, we would spend the summer doing development and the goal was, of course this time let's not do a release every day. Let's try to get all the releases done over the summer and let's think about what is we're going to do and it was great because it's the second time around. Of course, people were like they had their list of all 10,000 things that they wanted to do over the next year and the next lesson for everybody was, "Great. You're going to prioritize this list. We're going to put a person-hours against them." We're going to cut out 15% for me to own off the top and that 15% will be used for things we don't plan on, things we didn't expect or cool things we decide we want to do and then other that we're going to rank order everything and of course they're like, "Great, we'll get a room for three weeks and debate and come back and tell you with some kind of democracy consensus process."

I said, "How about not? How about instead, we decide what our one or two key priorities are? We group things into those key priorities. You explain the logic behind it to me and you come present it to me." I know they were modified consensus process where we think about what we're not thinking of and all that but we use a much more decisive sort of process.

NOEL:  You're acting as not just the manager but you're acting as the product owner or the person who owns the requirements.

ANDY:  Yeah. There were people who actually do that. I just helped facilitate these decisions.

NOEL:  What haven't I asked? I feel like there's got to be something that I don't even know to ask that has some cool story behind it or some interesting insight.

ANDY:  I think that there's a lot of the things that I think are universal truths from this thing or sort of culture and process. I think I probably can emphasize that we've brought in some really great people that did help us make lots of progress and change. I think probably the thing that was most interesting to me that I learned the most was when you're in situations where you have to take real risks and that's really uncomfortable.

I guess I'd say it this way. If they hadn't said you've got to get this done in five weeks that really ended up helping us frame what you could do, what you couldn't do and you could rule out a whole bunch of things. I think maybe if I were going to leave you on the last point, even if it's an artificial deadline and saying we're going to get everything done by a certain point in time, you'll make certain choices they may be the right ones, it maybe the wrong ones so you've got to pick it right. But that helps you get very deliberate and very intentional and rule stuff out and then take things in stages.

Another thing you just got to tell people who don't think you're going to get from here to the end of the tunnel, don't worry about the end of the tunnel. Worry about today and if today is so much for you to worry about, worry about this hour. If this hour is too much for you, worry about the next 10 minutes. Otherwise, you're paralyzed.

NOEL:  That dovetails really nicely with the kind of agile software management that I don't normally associate with government. The thing that I wanted to just quick ask you based on the thing you said, you said when you have a deadline, when you're in that kind of situation, you need to take risks. What part of the things you put in place or the processes that you try to do, what felt risky to you? As opposed to what felt like just a good idea that needed to be imposed on the project?

ANDY:  You know, taking down the system every night because you didn't know if it'll come up in the right order and there were just pieces that you didn't know how they were. Every time you change something, you didn't know how the system was going to react but you had to change it anyway. I slept up with my cell phone next to my pillow and there were a very few nights where it didn't ring with, "Oh, my God. Here's what we've learned."

But going back to what we talked about earlier people ended up getting really, really familiar with the system and it's sort of like didn't have all the right documentation, architecture and all of that but it had a bunch of people that have developed over five or six weeks or more, really good instincts so all that investment that we were doing and fixing the problem was also an investment in people who were like, "This part of the site, they should call Scott. He'll figure it out." That was crazy.

There's also career risks. I look back on it and I didn't have to make that call and my life would have been just fine and I ended up pretty much exposing myself to a problem that I realized going in. I did not resolve and at one point that I made worse. Those are the kinds of things that I was pretty well-developed in my career. People don't normally take those kinds of risk that late in their career.

NOEL:  I guess now the questions is I'm assuming that part of the reason you chose to take it on was the sort of the values alignment of it. You wanted to see this work because you wanted people to have access to healthcare. What about what you saw made you think not only is this something that I really want to have happen but I can make this work?

ANDY:  That is really an amazing question that I don't have a perfect answer to. I think sometimes you just do stuff because it needs to be done. I will say like the one point time the president made a comment, I don't think he was just referring to me but he was referring to people who helped out on the project and helped it turn around. The president likes to talk -- I'm talking about President Obama, not President Trump, now -- President Obama likes to talk basketball analogies. He said something in the effect of, "You know, some people like to have the ball in the fourth quarter and some people don't."

I think his perspective was that, if you like to have the ball on the fourth quarter, you're not necessarily sure you're going to win the game. You're not necessarily sure what's going to happen but you know you'd rather have it than someone else and you want to be in and that's what drives you. It's all kinds of risk in there. There's all kinds of reasons not to do that. It's pretty safe on the bench but there's nothing like it being at the core team, with the fourth quarter to use Obama's analogy.

NOEL:  Tech Done Right can be found at TechDoneRight.io or downloaded via iTunes or wherever you get your podcasts. You can send us feedback or ideas on Twitter @Tech_Done_Right. The Tech Done Right Podcast is brought to you by Table XI, a UX design and software development company in Chicago. We are 35 meticulous and curious minds with the 15-year history of building websites, mobile applications and custom digital experiences.

Find us at TableXI.com where you can learn more about working with us or working for us. Thank you so much to Andy for taking time out of his schedule to be with us. I really appreciated this conversation.

ANDY:  I do hope that the listeners get something out of it. Appreciated doing it. It was fun.

NOEL:  Okay, thanks. We'll be back in a couple of weeks with the next episode of Tech Done Right. Thanks.