Kelly Taylor, State of Colorado

All right, here we are, another episode of Breaking Changes. I’m pretty excited today. I’ve got an old friend of mine that I’ve worked with several times across government API issues in federal government, and now Kelly Taylor is the director of Colorado Digital Services. Welcome, Kelly.

Hey, Kin, thanks for having me.

Yeah, thanks. I’m glad we could make this work. We were going to try to make this happen at another time, but I guess the internet was melting down, and so we were able to flex and find this other slot to make it all work. But let’s dive in. What’s the Colorado Digital Service?

So we are a small team of product managers, designers, engineers, kind of bureaucracy hackers that work for Governor Polis on some of the state of Colorado’s toughest, most unusual software problems. It’s a fork from the US Digital Service. I just copy-pasted a bunch of ideas and experiences over and applied it here in Colorado. It’s been really interesting, because we started the team as state employees within the larger Office of Information Technology here in the state, a thousand-person agency in the state, and we were really hoping we could work on some meaningful things. A couple months into starting the team, COVID came along, so a lot of our work is focused on public health, on the COVID response, on data interoperability and that vein. So it’s been a pretty crazy experience. Now, here in the state, we’re 70% vaccination rate and our numbers have mostly come down, so we’re starting to get a chance to work on some of the other priorities of the state of Colorado government, which has been really great.

Nice. So why, in the context of Colorado but other states, why does a state need a digital services group like this?

Well, one of the interesting things about the digital service model is it’s a tour-of-service model, meaning people come into the government for some sort of tour of service, like six months up to two years, and that’s how we do it here in Colorado. There’s other states like New Jersey that have digital service teams, and it’s nice because what it does is gives the opportunity to the broader tech ecosystem. Here in Colorado we have our Boulder-Denver tech corridor with a million awesome startups and Techstars and Foundry Group, and lots of headquarters for a bunch of cool tech companies. You have a lot of the cybersecurity stuff in Colorado Springs and Fort Collins, and it’s this huge tech community. It gives folks in that community this nice interface to come into government to help with all the experience they’ve gained in the private sector and apply that to some government problems, and then roll back out to the private sector, or maybe like me, fall in love with government and continue on working on government problems. So the model’s super cool. It’s something that you saw start about ten years ago in the UK with the formation of the GDS, the Government Digital Service there, and then the US Digital Service came about after the crash and rescue of healthcare.gov. Since then there’s a huge ecosystem of a variety of different ideas and ways that tech people can plug in and help.

Yeah, it’s a powerful model. To set some context, a little bit of history on how Kelly and I know each other: I worked in the Obama administration as a Presidential Innovation Fellow, so this is 2013, and I had the pleasure of working with a lot of the smart people who were behind the US Digital Service as well as 18F. Speaking personally, as this West Coast Oregon, I grew up in Oregon, I grew up very libertarian, honestly anti-government. I went into the tech sector in the 90s, late 80s, early 90s, really did a lot of startup work, really didn’t have much interest in government, didn’t care about government, really didn’t believe government was needed. And then I went and worked for the Obama administration and it changed my tune. It not only left me, similar to you, loving government and the problems and the scope of problems, it gave me a new appreciation for how this country works, or often doesn’t work. So anybody listening to this, any of these digital services models, what works for you, I highly recommend it if you can step away from your career for a while, because it will change your view of the landscape. It will change how you see the world and the role of government, and I would say that tango between the public and the private sector I think is really key. So you touched on it briefly. What kind of stuff did you do at US Digital Service while you were in DC?

So at the US Digital Service there’s a bunch of different teams within the broader US Digital Service, and so I was on the healthcare team working for the Centers for Medicare and Medicaid Services. I had come from IBM Watson Health and Alchemy API and a couple of things like that, so my background is as a product manager, and so I started working on API type of problems there, of course, hence this podcast. In the government, just like in the private sector, you see these types of APIs, like transactional APIs or open data APIs, or PHI/PII type of APIs where government’s the data holder. So I worked on a program called Quality Payment Program, which is when doctors submit information to the Center for Medicare about the quality and the type of care that they’re providing, they get paid at a higher rate, they get reimbursed at a higher rate, so it’s worthwhile for doctors to submit this data. But submitting the data is cumbersome, so we worked on an API that could integrate with electronic medical record systems that allow doctors to automatically submit data to CMS. So that’s an example of transactional stuff. But most of my work there was on an API called the Medicare Blue Button API, and this is a concept that started about a decade ago from people like Aneesh Chopra that talked about how the Centers for Medicare and Medicaid, they hold Medicare data, CMS administers Medicare in the United States, 45 or so million people, 10,000 new seniors come onto the program every single day, and every time a senior goes to the doctor, the doctor bills Medicare for that. So CMS has this huge data store of insurance claims, same with the VA. The VA provides care to veterans, same exact situation, veteran goes to VA hospital and the VA pays that insurance claim. So those are the two places that people like Aneesh Chopra pushed to make data available to veterans or seniors on Medicare. And that experience looked like an end user, a veteran, a patient, a senior on Medicare, logging into a portal like mymedicare.gov and downloading a CSV of their data. So that started a decade ago, and when I came along, the chatter at CMS and the US Digital Service team and a bunch of smart people was, hey, we should turn this into an API, because it’s not having access to the information that’s powerful, it’s being able to share it with apps and clinical trials and your doctor and so on that makes it really powerful. So that started down the road of building this Blue Button API while I was there. So that was the majority of the work over a two-year period at CMS in the US Digital Service.

So who are the consumers of that API? What gets built on that API?

When you think about the healthcare industry, it’s like pharma companies, healthcare and doctors, fitness, be-healthy types of things, and it’s an array of all of those types of companies, big and small. So we have had companies that run clinical trials. They would integrate with the Blue Button API. So a patient is going to enroll in a clinical trial, and the old way is that company saying, all right, let’s get history on you, let’s get all sorts of information. The new way is the patient shares their five years of their Medicare claims history with the trial software, and so now the trial understands what procedures they’ve had, what prescription medication they’ve been on, and so on. So it’s just a very quick way. Same with electronic medical records. A patient is in the waiting room, they’re handed an iPad to check into their appointment, and certain electronic medical record vendors have integrated with this API, so the patient could touch to connect their information and now their physician has five years of their claims history. These use cases often go to the personal health record, like Apple Health. You connect, and today Apple Health integrates with hundreds of electronic medical record providers like the University of Colorado, right down the street here, and soon we’ll hopefully integrate with claims using something like the Blue Button API and other private health insurance claims APIs. That gives the end user, like me and you and everybody listening, all their information on their phones. So that stuff’s very powerful, especially on the phone, you can start sharing information with other apps, which is very powerful. This is an interesting area, because like with many APIs, you can talk all day long about the various use cases, which is really fun. With the Blue Button, in the early days, clinical trials, EHR integrations, and then lots of startups, that was our first cohort of companies we had as we were building the API. We had a couple hundred companies that were experimenting with it, and then an API like that, it’s interesting because as you go from sandbox to production, there’s a process there of giving companies access to personal health information. So that couple hundred companies goes way down to more like 50, 100 companies that have been vetted and gone through the process. But it really was a nice range. So you would see things like a Medicare beneficiary wanting to go from traditional Medicare to a Medicare Advantage plan, which is a different type of health insurance that gives them different types of benefits. There was like cost calculators and various things. So you want to determine, you want to understand, the best plan for you, you connect your existing five years of your claims history, and whatever calculator you’re using can say, hey, based on what you just shared with me these last five years, here are the best plans for you. There’s a lot of that kind of shopping calculator stuff that we saw in the early days as well.

So you touched on it a little bit, going from sandbox to production. What were the biggest challenges in rolling out an API like this, because it sounds like a no-brainer, but knowing the devil’s in the details, what were the biggest challenges of opening up that API?

So in government, APIs in general are new, and that’s a generic statement, but they’re relatively new at CMS. There were a couple teams that were building APIs with business partners, but this idea of an API that’s public to any developer that wants to use it, that sits on top of very valuable information that needs to stay secure, that’s a big new thing for government, and now many governments are, at all levels, federal, state, local, starting to build APIs like this. For us, I think the biggest challenges were policy-related things, where the first question when you meet with a lawyer from HHS or the Centers for Medicare and Medicaid was, okay, how can we make sure that we can trust the people who we’re giving access to this information, the third-party developers? It’s an interesting question because ultimately it’s up to the patient. There’s lots of legislation. One example is HIPAA, the HIPAA right to access, that says patients have a right to access their information. That’s why you can walk into your doctor’s office and walk out with a CD-ROM of your MRI of your knee, that kind of classic example. An API is no different. So a big part of this was proving the case that an OAuth experience is very similar to a digital signature, so that should count as a patient saying, yes, I authorize this third-party app to use my data. So there were lots of meetings like that. And the third-party app developer vetting process was also brand new, so I looked around at how different companies did this, like how Dropbox does it is very different than another company. Sometimes it’s based on just general usage. I think Dropbox was, you had to have 50 users connected to your sample app and then it could go to production automatically, very different than an app store experience where your code is being scanned. So on our team we came up with our own process, which involved the team vetting the application, the dev team plus folks from CMS, security folks, and we had developer guidelines and parameters. So for example, you couldn’t resell the information, things like that, and as long as someone met the criteria and we felt good about it, we would go ahead and give them production access. Now, one interesting thing that’s happening is how you scale that. So I mentioned Medicare, all of the information from 45 plus million people comes into one spot, and so you have one team that oversees that. But when you have programs like Medicaid, which are now building very similar APIs, 50 states, every state has multiple Medicaid plans, so you’re talking now hundreds and hundreds of Medicaid plans. So if you’re a developer at a startup and the goal is to serve the Medicaid population with home delivery of prescription drugs, clinical trial enrollment, personal health record, whatever the thing is you’re doing, are you now having to go to hundreds of developer portals, manage hundreds of API keys and so on? So that’s kind of the next chapter of all this stuff, where it starts to get really interesting.

Yeah, so a lot of unknown unknowns in there. That policy stuff always surprised me, and how, when I first started doing developer portal stuff at the Department of Veterans Affairs, a fundamental part of doing your API is asking developers to do little things for you. Hey, we need help with this, hey, can you do this? And then I remember my boss telling me, hey, you work in government now, you can’t tell people to do things for you, that’s not how it works in government. I’m like, but little things like that always tripped me up. And all the way to, I think we did a benefits questionnaire iPad app for disability claims and helping reduce friction for veterans getting care. We replaced it all, mapped it to the legacy system, we’re going to shut off the legacy system, this new iPad app was great, and then we found out that the funding for it was done through an act of Congress, and if the legacy app went away the funding went away, and so we couldn’t maintain the iPad app because the funding disappeared, and we hadn’t done the homework on it. So just all these little gotchas that I learned so much in the process.

Yeah. One of the most striking moments in this Blue Button API we built was the lead engineer on the team, Sam Ginsburg. The first thing that he did as we started working on it was start looking at the contract, understanding the budget, understanding where the money was coming from. And I was like, aren’t we going to dig into the code and figure out what’s going on here and start going, let’s write some user stories and let’s do some user research? And he was like, none of that matters until we’re sure and we understand deeply how this works. And that is a core concept in working in government. Most of the private sector experiences I’ve had, besides the startup world where you’re really looking at the books every single day, the money would just kind of, you could just go do things and the money was there, and if the executive wanted you to do that thing, you were never tracing the budget back to the source, it was just like, okay, I guess that’s what we’re going to do next on the road map. Whereas in government you really have to understand the funding streams. So when we started the Colorado Digital Service, I started with a friend of mine, Matthew McAllister, who had worked for President Obama for five years and really understood the ins and outs of how government worked, and that was key, because he could understand all the things that we had to do, whereas I was like, let’s just go build stuff and try to solve problems. He understood how to structure it right for success, and that’s super key.

Yeah, that’s an important quality and skill. I still have lots more to learn on that front. So was the Blue Button, did it achieve its objective, or is it like an ongoing rolling thing?

It’s ongoing forever, and that’s what’s been interesting about talking to folks in the state of Colorado about our own API efforts. These are not just, hey, let’s just quick build it, they will come, and we’ll move on to the next project. You put things out there in the world and they will be used forever, especially when it comes to things like personal health information. So with the CMS Medicare Blue Button API, we intentionally started small, we gradually added more and more third-party app developers that we approve for access, as I was saying, and we went from a couple hundred Medicare beneficiaries that had connected their data to an app to now tens and hundreds of thousands. So that ship is sailing, and they continue to iterate. As the FHIR spec continues to mature, the API has to continue to update and match the spec, and the team is still strong and lots of great things are happening. One of the interesting things that came out of this, which is also pretty unique to government, is as this Medicare API came out, the administrator of Medicare at the time said, hey, we’ve done this now for Medicare, I would like regulation that regulates state Medicaid plans, Medicare Advantage plans, these plans on the exchanges called QHP plans, to also do this. So this shows you the value of government. Government sometimes has these really unique roles. One is, sometimes government can help push standards forward, sometimes government can use regulation to create data liquidity and do things that the market is not doing. So that’s what CMS did, they introduced this patient access and interoperability rule that said all of the various insurance plans that CMS oversees, like state Medicaid, must build these APIs. And it’s not just the claims as I mentioned, but there’s also other things like provider directories and other things that help healthcare data move around the system. So that in my view has been the biggest success. Yes, lots of people are using the Medicare Blue Button to have access to their information and share it with whomever they’d like, but it also has really moved the industry forward, which is wonderful, because it takes moving it forward on all these different fronts when it comes to health data interoperability to make progress, because it’s such a gnarly ball of spaghetti.

Well, and I would add a third mention is the precedent set by the patient access and interoperability rule, the regulations coming out of CMS, is influencing other industries as well. Similar to how PSD2 in Europe, which is a financial and banking regulation out of the European Union, it’s influencing regulation here in the US. I just did an episode where we talked about exporting PSD2 apps and processes to Latin America, to Mexico, Brazil, Colombia. So this type of regulatory currency really is shifting the landscape in healthcare for sure, but it’s much wider. So how does, where does the FHIR specification, the Fast Healthcare Interoperability Resources, which is a standard, it’s a mouthful and a standard, where does that play in with the new CMS rules?

Well, it is the standard that the healthcare industry has some moved to and some moving to. It is specified in some of these regulations. With interoperability of anything, the standard plays the key role, right, because without the standard things can’t gracefully and smoothly move around. So it was really interesting while I was at the US Digital Service working with CMS to watch the government’s role in standards development. It’s something I knew nothing about, I’d never worked in standards development before. And what government, they invest in standards development. So an example is the Office of the National Coordinator, which is the part of HHS that oversees electronic medical records and things like that. Like a 15-million-dollar grant from the ONC is what created SMART on FHIR, which is now a key piece of how third-party apps run on top of electronic medical records. So it’s interesting seeing CMS provide funding for teams to build, to be a part of FHIR working groups. In the FHIR standard, just like many standards, there’s these various resources, so there’s the financial working group that oversees the health insurance claims resource, and there’s resources for every part of healthcare. To watch CMS invest, that was a really cool thing, code samples, documentation. When you look at the FHIR documentation, there’s all sorts of use cases and things like that. And there’s a couple of people that are heroes in my book, Mark Scrimshire and others, that have spent their career making progress on this narrow part of the standard that opens up, it enables this opportunity for all sorts of things to work on top of the standard. So it was cool seeing government be a participant in that ecosystem, and there’s many others too, like all the health insurance companies, they were all working on it, and it ends up being this great group of people that are moving this part of it forward.

Yeah, again, I think that provides a model for how to move other standards forward within other industries. I’m going to be doing a few of these episodes on the ACCESS Act, which is one of a suite of legislation that Biden’s pushing through right now, and it’s going to rein in the tech sector a little bit and apply APIs. But I would love to see the model that was applied to FHIR applied there and make it a nice balance between public and private sector and get all the folks at the table and do it well. Because I was involved at HHS in the early FHIR conversations, because it was being used at Department of Veterans Affairs, and I didn’t hold out a lot of hope early on, because it really felt like a strong, heavy-handed government play. But then over the years, and then watching you, I really saw really smart people take it in the right direction and find the right balance to end up where we’re at today, which I think is respected, it’s getting traction. I think this regulation is the latest wave of it. I’m seeing it get adopted in the travel industry as far as a COVID-19 pass, vaccination passport, I’m seeing talk of Europeans starting to adopt it even though it’s a North American standard. So I think it’s pretty healthy, and I think the CMS rules are really just putting a lot of fuel on that fire. So that’s good to hear that it’s evolved out of the Blue Button work. So what does this mean, taking it down to your world now, what does this mean on the ground in Colorado, how does this play out?

Yeah, well, a lot of the things you’re mentioning are part of our day-to-day. We touched for a second on the role of government, so government as the data holder. Government, for example, has all the immunization data in each state rolls up to a central immunization registry that each state government manages, so we have our immunization information system here in Colorado. So do we have an immunization API? Because this is information that belongs to the patient, so a patient should be able to easily access their immunization information. You see this in a variety of different ways, from a digital vaccine credential to logging into some sort of immunization patient portal to view your records. My kids just, we’re halfway through the summer here and they’ve gone to a million different summer camps, every single one of them I’ve had to fill out the same forms, paper forms, fax in forms. I should just be able to share their immunization records with that camp using some sort of API experience. Vital records, these are things government is the data holder on, lots of different things. I think that we’ll see government unlocking a lot of this data for interesting uses moving forward, especially things like the CMS regulation, this patient access and interoperability rule. You mentioned the word precedent before, that’s what it does. So our Medicaid team now is working on compliance with this rule like every other state is, so we’re building these APIs, and that is going to show the 17 other agencies in Colorado that are not Medicaid the pattern, the playbook. It’s like, okay, here’s the developer portal, here’s how we handle API security, here’s how we’re thinking about identity and all these things, and so you’ll start seeing more agencies around the government outside of healthcare start doing this as well. So here in Colorado, our team specifically, we’re working on a couple of really interesting things. Colorado voters passed a paid family leave program in November, so this brand-new program will likely be an API-first type of approach, because it’s a type of program that integrates with lots of businesses. So watching the state government look at the problem that way has been super interesting. We continue to work on child welfare, which is a whole other API discussion, where you watch multiple agencies interoperate, so when child welfare, it’s the Medicaid agencies involved, shares data with the Human Services agency, shares data with community providers, with corrections, this big ecosystem of internal APIs, and watching that get more and more sophisticated here has been very interesting too. So those are a couple of things that we’re involved with that hasn’t been the COVID craziness of the last year and a half.

Yeah, well, I mean it shows the power of APIs from my vantage point. I think this is very much a healthcare API discussion, but it really shows the importance of interoperability when it comes to all of these areas. And in a mobile world where we’re dependent on our mobile phones, why are we still faxing to the summer camps, why are we still emailing and doing this? It’s because government is traditionally, I would say, five to 15 years behind where the rest of the sector is when it comes to a lot of these things. So it’s not just modernization of government, it’s reduction and reducing the bureaucracy and improving on processes and all of that. So it’s super important. So in Colorado, how much of this is government, how much of it is private sector stepping up to make things happen?

When I first moved to DC to join the US Digital Service, I barely knew anything about government, and I walked in expecting Dilbert gray cubicles, software engineers working with maybe older programming languages, and really what I found was no software engineers, no product managers, no UX designers. It was a program manager or a deputy director, or a project manager in charge of a multi-million-dollar effort that was really high stakes. And the private sector’s role in building government software, vendors build a lot of the government software, and one of the trends that you’re seeing, you referenced five to ten, fifteen years ago, I think that’s exactly right. You just look to 2011, look at the sophistication of APIs across all industries, and you looked at the evolution of product management, that was like a new thing, people were talking about agile software development like it was a new thing still. And that’s very much how the day-to-day feels, but what you see in government is job titles like product manager, UX designer now coming into government. So that’s been a really good thing, and you’re seeing that it creates government being a better customer to the private sector companies that are building software on behalf of government. So a lot of people talk about big government, and government can’t deliver, and all the criticisms of government, but really what you see is understaffed. The civic, the govtech people I see, they work harder than anybody I’ve ever worked with, including startup-world folks. They’re working usually two jobs, so they’ll have their full-time role, like visiting clinics or distributing vaccines, but then they’re also a product owner on some team. So they are overworked because there’s not enough budget to fund those folks, but then a lot of the budget goes to the software that the vendors build. And so what we think is one of the secrets and the keys to making government work better is strong product ownership, starting to see developer evangelists in government and roles like that, strong UX in government that helps the government understand better about, become better at, building software. So that’s the unemployment insurance systems, child welfare systems, these huge systems that are never going away, that’s what you see. And then the second part of the private sector is this massive ecosystem that wraps around government, whether it’s a network of community health organizations that actually provide these services to folks, or it’s the development community that is building apps and various things that help people, or it’s the citizen scientists. Things like in COVID you saw a ton of that, where people were using open data, they were building vaccine finders and all sorts of amazing stuff, COVID trackers came out of the COVID pandemic. So that’s this wonderful ecosystem that wraps around government.

Yeah, and you really touch on a number of things that are near and dear to my heart as far as my shift and how I see government, and I know you probably deal with this. Oregon, where I grew up, is very similar to Colorado, and trying to explain to people how government works, and once you have that realization and that intimate understanding that these are human beings working in these government offices, like you said, they’re often short-handed, they don’t always have the skills that are necessary to understand where things are at today in the modern ecosystem. They have the skills to do their job, but as far as APIs, the cutting edge with APIs and developer portals, once you realize, oh, to see the change that I want to see in government I need to step up, government’s run by us. And trying to explain to people that the reason why it appears dysfunctional is because there’s not enough of us stepping up and doing this. Back to the calling people from the tech sector to join these digital services, it’s because they don’t have your, I’m talking to our audience, your DX skills in government, go bring them there. There’s a reason the developer portals don’t have the developer experience that we’re all looking for. So that’s a very important aspect of doing this. You hear revolving door when it comes to government a lot, but I think the digital services for me are the next generation, version two or three, of that revolving door, and people coming into government and then going back and coming and maybe staying and doing this. So it really is a relationship. And then the other part I try to advise folks on is, if you run a startup, spend the time to find out what it takes to sell your services to government. I’m doing this with Postman right now. Right now our free product gets used there, but we do a lot of advising and consulting, and we’re on our track for FedRAMP, which is to get certified to sell to government. But I think there’s just so many doorways that you can get involved. So when it comes to the state level, because I think for a lot of us the federal government is still very far away, DC is far away, but how can people get involved in just APIs in general or tech in general in Colorado? What are some good ways for people to step up?

Yeah, so in Colorado we have a pretty strong open data program. We have this competition called Go Code Colorado that’s run by the Secretary of State’s office. Our chief data officer is an awesome advocate of all things APIs, and we have developer.colorado.gov, which continues to progress, and like I mentioned, the Medicaid API is coming soon. So that’s how you get involved. I would say today it’s mostly open data. Colorado does a great job publishing open data. This next chapter of transactional APIs, PHI/PII type of APIs, that’s not fully baked yet, that’s coming, that’s like over the next five years as you watch that mature. One observation of going from federal government to state government is just how disconnected things are, first of all. That was a shock actually. The state feels like the state and DC feels far away, and when I was in DC, Colorado felt far away, and we never talked about what was going on in Silicon Valley or anything, it was all about what was happening right there in DC. And that’s a mistake. You actually see some legislators and Congress and so on talking about how to fund teams that help glue together different parts of government, which is very interesting. So I came to state of Colorado, and one of the things that we worked on right out of the gate as COVID hit was the contact tracing system. In Colorado we have 64 counties, and of those 64 counties we have 53 local public health agencies. So some counties team up and create a local public health agency, and that’s really as close to the end user, if you will, you can be. The local public health agency is the one that is doing the real work of helping people, and all the other layers contribute to that final thing where the local public health agency is running that vaccination clinic or whatever. So all the counties, in order for contact tracing to work right, when I’m here in Denver and I go skiing in Summit County and then I come back to Denver, I’ve now traveled across three or four counties that day, and so counties need to be able to interoperate. It’s such a great example of the different layers of government, because the state of Colorado can only do so much. In state government it’s really about the counties and what the counties want to do and how the counties work together, and it continues to layer down. So as people get involved with government, think about it that way. It’s not just going to the US Digital Service or 18F and moving to DC or working remotely for one of those groups. It’s your cities, the city of Denver has a great team, and counties. There’s all sorts of efforts like Code for America, where they have brigades in every city, there’s a Code for Denver, there’s a Code for Boulder, Code for Fort Collins, Code for Colorado Springs. There’s groups like the US Digital Response, which is a group of like 6,000 engineers and product managers and UX designers that are helping government at all levels. There’s a bunch of stuff, a bunch of different ways you can get plugged in.

Yeah, I second that. A lot of folks I think over the last few years have kind of gone back home trying to figure out how they can do things at a local level. I second what you said about the open data kind of being the doorway and the gateway to a lot of this world. Start small, visit your local, whether it’s your city or your county, I would recommend at that level even over the state or the federal, and pick one data set, build something, build a visualization on it, clean it up a little bit, publish it. If it’s a CSV or if it’s a spreadsheet, publish it as JSON on GitHub, tell the story of it, maybe do a presentation around it, and then get to know the ecosystem and understand, well, who published that data, what’s being done with it, how can I help reduce load there. And then you’d be surprised what you learn, and you would meet people, you’ll learn processes, you’ll realize that there’s human beings in your local county office, not the nameless, faceless things I think the media and a lot of public want you to think. So definitely start small. So what sort of skills are you guys looking for with digital services, as you guys are looking to evolve your team and help other stakeholders be more successful? What kind of skills are needed most?

Yeah, so for our team it’s product, UX, and engineering, and it’s really broad. Especially for engineering, as you come in, a bad fit is, hey, I’m really good at this one language and I’m going to come in and help, because it’s more like, in the state of Colorado we have 300 what we classify as enterprise applications. So these are things that are multiple millions of dollars, tens of thousands or more of users, over 300 of those, so you see every single language in every single platform across the state. So that’s our team specifically, but across the government you see a really strong need for product management. I think that data science and DevRel are the next two job titles you see in government. One of the big problems in government, one of my big soapboxes, is the job titles are miserable. So you have business analyst number four, and what they really want is a product manager. Business analyst number four is a position for $41,000 a year, and what they really need is a product manager for $150,000 a year. And by the way, this person is going to be in charge of a $50 million program. So it is so out of whack, and that’s one of the things our team has really been advocating for, is to modernize. This is every team, all these digital services teams and so on, this is changing now in government. So I think that you start seeing more data scientists come on, and DevRel I think is going to be a new frontier. We talked a lot about the FHIR standard, some of the other things, but that is just one piece of it. That’s the foundation, but then, wave a wand and the state of Colorado has a couple of APIs, then what? Now this business side of it all is, I think, going to be a big challenge for states, because vendors can build, vendors can map data to FHIR, vendors can provide APIM, vendors can provide security and operations and all of that, but it needs to be the state that provides the evangelism, the product leadership, the product vision to align with the programs and the legislation and the people they’re building for. So that I feel like, and that’s every level of government from federal all the way down to the smallest town, will be experiencing this I think over the next couple years.

Yeah, I can’t second the DevRel thing enough, and I owe you some work in this area. I’m going to do some segments on this, trying to pull out other folks that I know who do evangelism, developer relations, in government, and then some folks in the private sector who are leaders. We were talking before we started the show about Adam DuVander, who was on one of our episodes before and has a book called Developer Marketing Does Not Exist, but he’s a DevRel expert, and the importance of storytelling, the importance of connecting with people. I didn’t realize until I went to government, I knew this in the private sector but I didn’t know the benefit of this in federal government and all levels of government, is just having someone who will show up to meetings and then cross-pollinate ideas against other groups, connect people, hey, did you know so-and-so is working on this over there and you should talk to so-and-so. I started going to Department of Commerce gatherings, tech gatherings in DC, and someone would get up from an API group within Department of Commerce and say, hey, we’ve done this API project, it’s been great, we’ve gotten a lot of attention, but we’ve only gotten two real actual users of it, and we’re probably going to deprecate the API after a while because we just didn’t get the demand we were looking for. And then someone in the audience goes, I’m with the National Oceanic Administration and we’re one of those users, please don’t deprecate that API, because it’s super critical to this program and this program and this program. And they didn’t know, they didn’t talk. And that’s an example of how developer relations is pretty powerful. So if someone’s listening here, you don’t have to have hardcore tech experience and be a coder to do developer relations, it really is a people job. So I would love to explore that, and I’ll probably be reaching out to you in the future, Kelly, to talk more, get some of that. Because I want to create some content that people can watch. I know healthcare providers, government agencies, many are trying to figure all this out right now, and they just don’t understand, why are documentation important, what do developers need, all of that. So it’s a pretty critical area. And I would suggest people check out the VA, the Veterans Administration has a project called Lighthouse, so if you Google VA Lighthouse you’ll find some really cool stuff, and then developer.cms.gov and bluebutton.cms.gov, that’s good examples of what’s happening today.

And I think that that’s going to be the model. The Blue Button team, since the very beginning when I was involved, we have a full-time developer evangelist on that team, and that was one of the keys to success. So I totally agree with you, Kin.

Yeah, those are great models, thanks for sharing those, I like those. So zooming back out a little bit, getting back to, I would say, the Kelly of all of this, why do you care about APIs so much?

These technologies and these approaches that can create these combinatorial effects, as Eric Turner from Alchemy used to say, these things that unlock more ideas, I’ve always been drawn to that. Some of my first real experiences with consuming APIs, there’s a company in Boulder called Gnip, one of my favorite companies ever, that became the Twitter data team, and companies like that, where we were building a social media monitoring platform way back when, and just being able to go into Gnip and, okay, I would have an idea coming into work and go and then partially build that idea by the afternoon, that really has stayed with me for now a decade later. So that’s really what draws me to this type of thing. The more I’ve been involved with this stuff, the more I’ve got involved with the government stuff, this idea of data that belongs to somebody else being held somewhere and not being available, that doesn’t feel right at all anymore. And as you look across the world, you can see a bunch of examples of that, whether it’s the data from your car, your own personal health information, the data from your house. All of that stuff is gradually starting to unlock, and this data liquidity is happening everywhere, and I think the fundamentals of APIs and how it stitches things together is what’s making that stuff possible. So I continue to be drawn to it.

Yeah, you touched on the heart of the part that keeps me interested, but I also get disillusioned sometimes. The phrase API economy is used to describe this, and over the last decade I hear that word get used a lot, and most of the time it’s applied directly to an API, meaning you build an API, people will come, and you’ll generate revenue, and the world’s better off because of it. That’s not the API economy in my mind. It’s the things that multiple APIs enable, that exponentially, that innovation, that growth, that entirely new things. It’s how Twilio, Twilio has done fine selling SMS services, but it’s the gig economy, the sharing economy, the services that got us through COVID that were built on the Twilio API. It’s the COVID notification, it’s my vaccination center being more organized because of COVID, because of the Twilio API. It’s that type of enablement that I see as being the API economy, and that’s what keeps me paying attention to this, is what’s that next thing, what’s going to happen, what’s someone going to do that I didn’t even think of, and I’ve been thinking about APIs for a long time.

So I second that, and I think the role of government here, the government will never build, I always call this functional APIs, I’m sure that’s the wrong phrase, but the stuff that we were doing at Alchemy API and then IBM Watson, these, it performs some sort of function when you hit the API, whether it’s NLP or computer vision, image tagging or whatever. I don’t ever see the government having anything like that. It’s more like the government is going to be the transacting-with type of stuff, making it easier for businesses to do things, maybe tax-related things, who knows, and then the government is the data holder, unlocking. I think that’s going to be the role of government, with open data stuff kind of as a sidecar, moving forward.

Yeah, agreed. So, more on the personal level, you live in Colorado, where’s your favorite place to hike in Colorado?

Well, we’re here in Denver, right down the street from Boulder, where Chautauqua Park in Boulder has been my love for 30 years now we’ve been here, it’s pretty crazy. One of my favorite people in the world, Susannah Fox, who was the CTO of HHS years ago and kind of the person that got me into the government stuff, just from a quick phone call, we had a hike there the other day. She was in town on vacation, so one of the nice things about living in a place where people vacation is people are always coming through, so you get to meet up and bump into and go hiking with folks as they travel through places like Boulder.

Yeah, I’m in a place where people come through, in the Bay Area, but it’s not for the nature, it’s the other side of that, so I have to work harder at that balance, but the Sierra Nevadas is a quick drive for me, so that’s similar. So how do you balance your world in technology with nature, and find that balance for you and your family?

Yeah, so for us, the COVID stuff, just like everybody, was a very interesting year, and with our team we were able to do some outside hanging-out time, which is really nice, and we do try to. The government stuff, the work-life balance, has been the biggest struggle I’ve ever had working in government, because I always tell people that are coming into government or thinking about it, one of the crazy things about it is the relevancy. So I wake up every morning listening to our local NPR station here, and it is stories about things that I’m going to be working on that day, and you’re surrounded by it 24/7. If you meet up with friends, they ask you about state of Colorado government things, family asks you. So it’s kind of like the startup world, where it basically becomes your identity. So here in Colorado, getting outside, skiing, hiking, running, all of those things have continued to be key always, and that’s true for our whole team, we all have our own activities like that. But it is a thing, especially in COVID, especially in public health. One of the stories this year across the United States has been the burnout of public health civil servants, whether it’s harassment, which we had here in Colorado, to total burnout, this feeling of ultimate responsibility of everyone around you to be vaccinated, to be free of COVID, all these things, it’s taxing. So we do constantly talk about it on the team. This afternoon is our staff meeting here for the Colorado Digital Service, and we’ll check in with each other, and we have all sorts of techniques using emojis and animated GIFs and things like that we use to communicate with each other about how we’re feeling. But it is super important.

Yeah, it’s tough, and I would say I have a lot of friends in the tech sector, I’ve had a few check-ins with folks that are burning out and saying, oh, I’m done with the tech sector, and I’m using that as an opportunity to say, you know, one, checking on them, hey, how are you doing, make sure you get some time away, but also, hey, have you considered maybe going working on some more meaningful problems, and government could use your help. So I’m using it as an opportunity there. But I want to be honest with folks about that, these challenges exist on both sides of the tracks. But it’s all about that balance. And in government, one of the most interesting things is you’re building for everyone, and so that’s been fascinating. Every single person you pass on the street is probably interacting with a government system, and so the health equity questions, the accessibility stuff, it is foundational to everything you work on. And then you square that with scale. One of the efforts that we worked on was called exposure notifications with Apple and Google. You turn this on, it comes baked into the Apple iOS settings, and it’s an app you can download from the Play Store on Google, and two and a half million Coloradans activated this on their phone, and it was used tens of thousands of times. When someone would test positive for COVID, they would use it to notify people that they had potentially exposed. So you walk around and everyone I talk to has turned this thing on on their phone, they’re using it. So this scale, and that’s just in the state. When you go to the federal government, you’re talking about the whole country, you just keep going up and up in scale. So it is definitely not, take a quick break and go from the tech sector to government, it’s more the other way around, where it’s like, hey, would you like to come make less money and have a tougher job? But the thing about it is the impact and the mission, the purpose.

Yeah, I think that’s the angle I’m trying to get is the purpose, definitely. It’s not more pay, it’s definitely not less work, it’s the purpose and the meaning, and trying to find why are we doing this tech, because that’s the biggest challenge or struggle I’ve had with technology, is why am I doing this, why am I making an impact, and when I went to DC, that scope you talk about, I was just blown away. I mean, I worked at big tech companies and the scope is much, much greater. And another part of this too is, with government, we always describe it as this relay race, because you work on something like the child welfare system, and it’s your turn to make a difference, and you make a difference, and then you hand it to the next person, and now it’s their turn, and that’s how things will be forever. So it gives you this interesting perspective, like as we’re ramping up various API efforts here, I know that this is the beginning of something that in 10 years I’ll be checking back on. I had an interesting experience at the HIMSS conference, big healthcare conference, where when we launched the CMS Blue Button API, people would come up to me, we were doing booth duty, and they would be like, hey, I just wanted to say hello, I worked at CMS eight years ago and we helped get the Blue Button going. And it just really reminded me that it does take a village, and it is all of us, and it’s a journey, it’s definitely a journey.

Well, thank you. I’m stoked to have been on this journey with you, and our paths keep crossing, and I’m guessing they will continue, but I want to thank you for your time today. Great conversation.

Thanks, Kin, appreciate it. Enjoy the rest of your day, and hope you get outside and enjoy some of that beautiful weather.

Will do. All right.