CIO Strategy: What is IT Modernization?

• Introduction
• IT modernization at the USPTO?
• IT modernization challenges in the federal government
• Information technology procurement and IT agility
• IT modernization and the cloud environment
• Culture change and IT modernization
• IT modernization and talent management
• Using IT modernization to improve customer experience
• RPA and IT modernization
• Business transformation and IT modernization

This transcript was lightly edited.

Introduction

Michael Krigsman:  We hear the phrase IT modernization. We're going to explore this topic with the chief information officer of the U.S. Patent and Trademark Office.

Thank you to our sponsor for this episode. Productiv is a SaaS management platform that unlocks the power hidden in your SaaS applications to bring you higher ROI, better team collaboration, and lower license costs. Visit productiv.com to learn more.

IT modernization at the USPTO

Jamie, IT modernization, what does that mean for you at the U.S. Patent and Trademark Office?

Jamie Holcombe: Modernization takes on many meanings to many different folks. To us at the U.S. Patent and Trademark Office, what we're trying to do with modernization is to bring all of our applications up to the Internet standards of today. That would just mean that modernization is actually just bringing things to currency, but that's currency in the commercial marketplace.

As an example, every night when you go to bed, you put your cell phone on your nightstand. Overnight, you'll get all those applications updated almost seamlessly without even thinking about it. In the morning, you come to accept the fact that you have new additions, new versions, and new functionality without even having to do anything.

Heretofore in the government, that has not been the case for most of its IT systems. We need to modernize and bring up our old legacy systems to that sort of expectation that's been done in the commercial world, whereas modernization in the commercial world might actually mean going far and above what currently exists.

Again, IT modernization means different things to different people. For us, we're trying to bring us from the old into the new, into the current.

IT modernization challenges in the federal government

Michael Krigsman:  Give us a sense of why that has historically been such a challenge to be at the leading edge in the government.

Jamie Holcombe: For the right reasons, we have, in the government, a duty to ensure we comply with all the laws. The government creates laws, so we should comply with them. If you're in the government, you should comply with your own laws. That just makes sense. However, there are so many laws and so many compliance attributes that sometimes, most often, we get caught up in a very lengthy procurement process.

Now, I don't mean to pick on anyone or anything. I'm a former Army soldier and I know that when we put the requirements out for a tank, ten years later we actually see those requirements on the battlefield. Well, in an IT world, that is just not adequate. It is unacceptable. You need to put out those requirements almost simultaneously when they're said because, in six weeks or six months, they will be overcome by events and you don't need those requirements anymore.

When you put a procurement process on top of such a fast-paced moving requirement set, it just doesn't work. Traditionally, we have a system that doesn't work for itself. In fact, it feeds on itself and it creates chaos.

What I've been trying to do is introduce a 30-, 60-, and 90-day plan in anything that we do, in any effort that we take forward. In other words, if it can't be done in 90 days, don't do it. It doesn't make sense.

Now, at the end of 90 days, what you really need to do is figure out if you've gotten forward, if you've created any progress or success.

So often in the federal government, we're always worried about failing. Well, if you fail small and you learn from that failure, it's a good thing. It's only when you continuously fail, that's bad. Now, if you fail and didn't learn your lesson and fail again on the same lesson, that's really bad.

One of the things that we have to make sure of in the federal government and going forward is the theory of sunk cost. Just because you spent so much money on a certain thing doesn't mean that you have to keep throwing money at a problem that doesn't exist anymore or at a system that just doesn't work anymore. It doesn't work for the new requirements. Don't throw good money after bad.

It's very easy to say, but it's very difficult to do once you have that commitment. All of that motivation and all that momentum going forward and then, all of a sudden, it's like, "No, it doesn't work anymore. We don't need this big thing." It's very difficult in the federal government to admit failure, but we have to do it consistently in small, little increments.

Information technology procurement and IT agility

Michael Krigsman:  Is procurement complexity the primary obstacle to being more agile, more responsive, just faster, in general, in the government?

Jamie Holcombe: Well, I've always said and I have all my little signs ready to go, "Better, cheaper, and faster: it's always what we're trying to do." It's not so much procurement as it might be compliance.

As an example, we have some new security compliance requirements that are coming up in the federal government which I am all for. We need to be secure in the new age of cyber hacking and the new age of everybody trying to steal everyone else's intellectual property.

That doesn't mean that we should create such a huge obstacle in compliance that a new innovator, a new startup, a new creator of cybersecurity, therefore, has a disincentive because it can't comply with this huge base of security requirements. The only place that you could do that is with an established company who is usually very stodgy and set in their ways.

What we want is the innovation and the creativity of new entrepreneurs to come into the marketplace and for us to hone those skills and, yes, fulfill the different security requirements but maybe not the heavy requirements that are really being purported in all of those procurements. It's not necessarily procurement as much as it is compliance.

Michael Krigsman:  What is the answer then, because those compliance requirements still exist?

Jamie Holcombe: Yes, it is and that's why reasonable people need to be in charge. It's easy to say, "We can't because of this, and we can't because of that," but I've always maintained that we're Americans. The last four letters of American is "I can."

I want to know what we can do, not what we can't do. We can get ahead reasonably if we allow the biggest security requirements and ensure we comply with those. Then the little, minor ones, the subtle ones, the ones that might not make a difference, we need to work on those.

We shouldn't shut off creativity right in the beginning. We need to hone that creativity and bring it within our walls. Then nurture it so it grows and it becomes stronger and stronger.

IT modernization and the cloud environment

Michael Krigsman:  From a technology standpoint then, are there specific IT modernization patterns or technologies that you're focused on?

Jamie Holcombe: Very much so. What we're trying to do is take the old legacy client-server base and bring it into the new Internet zero trust architectures where we have microservices and loosely coupled tools and applications as our base. One of the design principles that I'm trying to instill in the folks is the fact that if you deploy it today, I better be able to rip it out next week because a newer tool, a better tool might come forward.

One of the procurement requirements right away for any new application or new tool is, how do I export my data out of your tool so I can put it in somebody else's new tool? If people are saying, "Well, you'll never want to do that. We want to become sticky with you so that you'll never want to lose us," that's the type of vendor you do not want to be located with because we need to be open, especially in the federal government, to different, new tools, to different ways to do business.

The best thing that we can do now is create architectures that are open for the future. That's the only way to future proof things. Yeah, use what works now but be open to what can work better in the future, also more efficient and cheaper.

I say that because the promise of the cloud is huge in the federal government but it is just a promise or a potential. We really do have to look inside at our requirements, realize that some businesses require trucks to get things shipped back and forth. Some businesses might require a pickup or a little car. You have to decide how much you need.

Just because a public cloud offers all these great services doesn't mean that you can use them. Some of us can use those services and that's when we really need to figure out how best to be efficient and timely in the use of, in the case of the federal government, the taxpayer.

In the case of the USPTO, we are fee-funded. We take those fees to heart that we need to use them and wring out the most value that we can using the least amount of money. That's because we want to ensure that the engine of our economy keeps going and we incentivize people in the beginning, young entrepreneurs, people with great, new ideas, old entrepreneurs who have great ideas. We should not have high hurdles in the beginning.

Only if you are able to participate in your patent or in your trademark should that be the fees that we collect. We do collect fees throughout the life of your intellectual property. Because of that, I wish the federal government would take that to heart as well with our taxpayer dollars. There are a lot of things that we could do to squeeze the most money out of those dollars.

Michael Krigsman:  Are you entirely funded through the revenue you receive?

Jamie Holcombe: Yes, we are totally fee funded.

Michael Krigsman:  That's an enormous difference from other agencies in the government because, if you are not careful with the money that you're spending, then you simply won't have enough.

Jamie Holcombe: That is exactly right. We have to be very business-like in the conduct of our operations. That's why I say I wish everybody could be that way in making sure they get the best value for the buck.

Culture change and IT modernization

Michael Krigsman:  We have a question from Twitter. This is from Arsalan Khan. He makes the point that it's great to have this kind of service-oriented architecture mindset but it requires a change in culture and, as we know, governments are notoriously slow to adapt. What about that aspect of it?

Jamie Holcombe: As I said before, I am prepared. What I do is, I'd handed out these poker chips amongst all the crew. It says "Culture Shift" on these poker chips. We have a culture shift within the USPTO to the point where, on the back of the poker chip it says, "Act now, be bold, and simplify. A, B, and C."

Wait a minute. You don't spell simplify with a C. Hey, you'll remember it, though. I'll tell you that.

Anyway, the reason we're doing that is because we all need to think differently about how we approach our jobs and how we're doing our workflow. My challenge to all the IT staff is, if you have a process and it's ten steps, I challenge you to take three or four of those steps and automate them with robotic process automation. Make sure that you save the time and then can use your analytical ability to even make things better, cheaper, and faster.

That's where the culture shift comes in mind. Use the commercial wins to our advantage within the federal government.

Michael Krigsman:  It sounds good, but how do you get there in practice because, as Arsalan said, the government is notoriously slow to react and respond?

Jamie Holcombe: The way we are doing it is, we went from a project management office-based environment into a product category management scenario. We've taken 158 different projects and we've mapped them to 30 products, 3-0.

Now, as you can well imagine, USPTO, there are four product lines. The first two: number one is patents; number two is trademarks. Number three is the back office: finance, HR, legal, procurement, et cetera. The fourth is the IT infrastructure and all the things that are common services with IT. We have those four product lines and, within each, there are about eight products.

You asked me, how are you doing this? The biggest change we're making is in our product teams, those 30 product teams. Eight product lines are led by a business owner, not an IT program manager. They're led by the business and the business owner needs to make those business cases, those decisional tradeoffs, and understand what is in the backlog and what you're going to do in the agile dev sec ops methodology that are moving forward every two weeks at a sprint. We are truly embracing agility and doing dev sec ops to the point where we're delivering business value every sprint.

Now, one of the things I said before about 30, 60, 90. If you can't do it in 90 days, it can't be done, don't do it. We're making sure that every quarter before, we have the plan that we're going to execute. You execute harshly and hardly and make it happen.

At the end, you have the ability to look at what you've done and whether you've succeeded or not. If you failed, it's okay because then you know what not to do again. You adapt. You don't do the failures and you continue doing what is successful and what works.

You have to have objective measures to do that. It's the hardest thing in the world. Time is easy to measure. Dollars are easy to measure. Business value is very difficult to measure. We're moving to the TBM, total business management, and the financials to the point where the business has to describe, yes, that amount of time and money was valuable because we produced this.

I will say that we have an advantage with patents and trademarks. We have productivity metrics. Our examiners need to award or reject in a certain amount of time and we try to take that tendency—that's the term of war—we try to crash that time down as much as we can while still giving the best quality.

Can you imagine that an examiner, who is either a lawyer or an engineer or both, has to figure out if this is a unique and novel concept? In other words, that no one else in the world has ever said this before and, as an attorney or engineer, you have to sign your name to that. That's what they're doing. The duty to do that and do the due diligence it required to search around the world is immense and we're trying to make those things better, cheaper, and faster.

Michael Krigsman:  How do you handle projects that, by their nature, are long, complex, and beyond 90 days? Just for example if you were implementing ERP, how would you fit that into the approach that you're describing?

Jamie Holcombe: Well, I will say, you know, you notice the alarms going off. [Alarms] It said, "ERP. No. Our survey says, [failure buzzer]." That is definitely the old way of thinking to have old, monolithic, enterprise systems that are very brittle is very difficult.

Now, if your system is very flexible and it allows things to be loosely coupled, that's fine. There is nothing wrong with that. But the ERP systems of yesteryear created stickiness to the point where you never want to pull away from them because it's so difficult. It's so costly to change and you don't want to do that. What we're trying to do is create microservices to the point where we can plug and play in an architecture that's open to the Internet and still has security around it.

Michael Krigsman:  At the end of the day, let's not call it ERP. If you're implementing a system that involves your financials and you have HR integrated together, you still have a complex system regardless of what you call it.

Jamie Holcombe: That's right. Well, what you need to ensure is that everyone has a good understanding of the APIs, of the integration points, and what that service does so that you're able to pull it out and plug in newer and better ones that come along. If you have an ERP system that's flexible—again, I'm glad for that—flexibility means everyone understands the integration points. When you have inflexible system, what it is, mostly it's proprietary. It's customized.

You don't have the standards and you have to physically go in and figure out what some other programmer did 15 years ago with the little statement, "This gives you that." You're like, "What the heck does that mean?" There is so much code that's written like that. We have to do the open standards, not the customized and closed standards.

IT modernization and talent management

Michael Krigsman:  For developers who have been working in the government for 10, 20, 30, maybe 40, in some cases may be longer who grew up in a very different technology paradigm, shifting this kind of thinking is really hard. What do you regarding the talent management issues and the HR issues associated with this?

Jamie Holcombe: It's incumbent upon leadership to make sure that we're reskilling those workers who have the will and the desire to be reskilled. Now, if you're in IT in the federal government, you know that you need to be continuously figuring out the new methods, the new architectures because we have been through this, as you said, over 40 years, right?

The fact of the matter is, if you kept on programming in COBOL, except if you work for the IRS, if you kept programming in COBOL, you might not have a good job. Well, that's not true. There might be a little COBOL programmer's book.

Boy, do they have a lot of work to do because the iron boxes still work very well but that's not the new things that are going on, especially over the Internet. The COBOL servers right now that are very tried and true are in the background just doing those black-box services. But if you want to be part of the new development and the new creation, you have to take into account all of the new technologies, so you're constantly reinventing yourself.

Now, if you don't have a person that wants to do that, that's fine. They should be allowed or able to keep on maintaining that old system. But that's dependent upon less and less as you move further and further in the future.

Again, retraining and reskilling, you can only do that for the desire and will that's required. If you don't have that desire or will, you're not going to be able to reskill.

Now, I say that too because I was so surprised when I got to the USPTO. The average tenure for a worker there is about 22 years. You're saying to yourself, "My goodness. Aren't you supposed to retire in the federal government after 20?"

These guys are staying until, like, 35 and 40 years. The reason is because you get a great sense of accomplishment in fulfilling your duty to award or reject a patent and award or register a trademark. It really does have a bottom-line effect on the economy.

Because they're doing that, because they're making America great, what we're doing then is making sure that these people always have the best tools to do that. That's where I'm trying to encourage people with a mission concept, somebody who is attracted to complete the mission and help the economy rather than just make money because life is a lot more than just making money.

Michael Krigsman:  We have a couple of really good questions from Twitter. How has your IT staff responded to these IT modernization efforts?

Jamie Holcombe: Like all large groups of people, we have a normal distribution. I would say 25% to 30% have really embraced the new ways of working. We call it NWOW, the new ways of working. We can even put a hashtag in front of it if we want, but those people who have embraced it have found a lot of lighthearted and fun jobs and challenges in front of them.

We have some that are lagging behind, that are very naysayer like. "It'll never work. I'm going to outlast you." Right?

Then you have the solid middle who are saying, "Well, I think it'll work but I'm not so sure." Based on that, we're trying to make sure that we get all of the converts to come over to the new way.

Now, a new way is not good unless it's continuously being evergreen. One of the big things that people need to learn is you can't just put a system in and let it go forever. That's not what happens. You have to be continuously turning it over, cultivating your farmland, letting some of the land lay fallow, learning new skills, putting new seeds in. That way, you can use the analogy of farming and many other things to keep growing each season and getting better yields and more nutritious crops.

It's the same thing with applications. It's just that the folks that are doing it are actually listening to their customers, their users, and seeing, what's the intuitive way that I can use these tools to award a patent and register a trademark?

You've got to remember, everything needs to be that focused, that mission, awarding a patent or registering a trademark. Doing IT for IT sake is not good. We need to award patients and register trademarks.

Using IT modernization to improve customer experience

Michael Krigsman:  The work always comes back to that reference point of, what do our customers expect and want from us?

Jamie Holcombe: Exactly right. The measurement of that is very important. Who are our customers? We have internal customers. I've talked about the examiners, both trademark and patent examiners.

Most of our 13,000 people, 8,000 of them or 8,300 are patent examiners and 800 are trademark examiners. That is most of the core. We also have other users, the general public, who we'd like to give the same type of tools and the same type of new commercially successful uses out there so that they can search for patents on their own so that they can know how to do a trademark really quick.

We have two different customers: internal and external. I think that's true of most IT folks. We're trying to satisfy both.

Michael Krigsman:  This focus on customers is central to what you're doing, to all of your work.

Jamie Holcombe: Everything. Without the customer, we have no mission. We need to do that.

Michael Krigsman:  We have another interesting question from Arsalan Khan who says, "Have you collaborated with other agencies that are trying to innovate and do the same kinds of things as you? If so, are there any lessons there that you've learned?"

Jamie Holcombe: I believe that the government has the ability to share amongst itself without having to go out on its own. As an example, I have worked with a copyright office.

Oh, and by the way, the copyright office is not even in the same branch of government. They fall under the legislative branch under the Library of Congress.

The four parts of intellectual property—patents, trademarks, copyright, and trade law—50% of the intellectual property doesn't even go with the executive branch. It falls to the legislative branch on the copyright.

Now, trade law falls underneath the FBI and the patent office. What we do is we try to help the FBI understand how to enforce those laws. If anybody is out there trying to enforce their corporate intellectual property, of course, they can refer and go to the FBI for enforcement, but they can always come to the patent office and we can go over how trade law and intellectual property really can be used in your operations. Now, saying that, then we were also getting to your question, but we have to make sure everything is patents and trademarks.

RPA and IT modernization

Michael Krigsman:  We have another question from Twitter. You can see I lean towards the questions from Twitter because, very often, they're better than my questions and insightful. Keith Pigue asks about RPA and lessons that you've learned. What have you experienced so far?

Jamie Holcombe: We're using RPA and we have laid a core foundation much like the other government agencies. I want to get back to that question and put this question together.

GSA and DHS, there are a lot of folks out there using RPA. We're trying to use it as well. We're going through that norming, storming, informing area, and we're trying to get lessons learned from the other agencies so that we can create a more efficient core and foundation of RPA to be used throughout the organization.

I have a start small, grow large, crawl-walk-run mentality. We can actually help other agencies in the beginning but, right now, we're in the scaling part of that RPA journey.

I say RPA journey because, just like quality, right? Quality was the big word back when, but quality should be in everything you do. Much like if you're doing any process that's very rote or clerical or administrative, it is a candidate for RPA.

Why put brainpower to work when an RPA unattended robot can do this for you? It frees up your intellectual capital to do other things.

That's where we are with RPA. We're trying to scale what we currently have and learn from other agencies much like the other question was asked.

Michael Krigsman:  Any employee concerns about this that RPA will displace jobs?

Jamie Holcombe: We're not making buggy whips anymore. The reason is because progress dictates that we move to the next level.

I don't think, in IT, we have many people worried about them taking over their jobs because there's so much work to do. There's just way too much work to do to be worried about losing your job because what we're trying to do also is not worry about the position but, rather, worry about the goal, the role that you play, and the results that you get.

If more people thought like that, no matter what position they're in, you need to go out and get these results done. That's another part of the culture change that we're trying to ruminate because the roles change over time. Your position could remain the same but you may be playing a different role.

One day you might be playing a more business-oriented role. Another time, a more technical role. Whatever role it is, you should be trying to get to the results as quick and efficient as you can. I think it's a cultural change, again.

Business transformation and IT modernization

Michael Krigsman:  Tell us more about this shift from a project-oriented culture and mindset to a product-oriented. It seems like that kind of gets into the heart of what you're talking about.

Jamie Holcombe: Yes, it does. I started with accountability is with the business owner. The product owner is a business guy. But you have to have the technical leader assist, consult, advise, and guide the entire team forward. Without that good technical lead, you're not going to get the results that you want or need.

Then you also have to have the actual developers, testers, the database gurus, the administrator, the system admins who really know how to eke out the most you can from a compute. Everybody has a role to play and, in the product teams, what we're trying to do is to get more of the team-oriented approach rather than throw it over the wall and let him do it; rather than individual work that's never seen the light of day because it goes from A to B to C and C never sees what A did because it only gets what B did.

We have to create a team environment where, "Why are you doing it like that? Look at over here."

"Oh, I didn't know you could do that." Then you learn from one another.

It's not just a mentor/mentee or an apprentice and apprentor. What you have is the ability for the team to learn from one another in business and technology.

Now, one of the big things too is, without the financial case for things, how can you say it was cheaper? You also have to have, on that product team, the support personnel that are required, someone with a finance understanding in how the business case worked, someone with a procurement and logistics standing. How can we get this that we need that we don't currently have internally to the product team?

The team is where everything comes from. Then the success of the enterprise will be based on the strength of your teams.

Michael Krigsman:  Another question from Twitter. How do you scale the skills required for updating IT, staff, users of IT services, and IT modernization? USPTO is a large organization, so how do you scale these innovation skills and cultural mindsets?

Jamie Holcombe: All right. Bing! I'll say, "Bingo!" That is the hardest thing to do.

Why? I'll give you the ideal and this is the academic book, ivory tower answer. That is, whatever team you have, you can augment it with contracted resources that have those skills.

They come on board. They teach. They coach. Then they move on. Meanwhile, your team then is able to pick up the operations and maintenance and maybe future business value tweaks on the development, monetization, and enhancement of things.

Now, what's the practical nature of that? Huh? That is really tough because we might not have enough people who want to learn new things. Remember, it takes that will and desire to want to learn those new things and you can't learn everything at once.

If you have a problem with electricity or you have a problem with plumbing, well, you need an electrician to fix one thing. You need a plumber to fix another. You can't be both at the same time.

The scaling part is really tough because you don't have all the resources you need and you try to augment them with vendors. That's the best I can do there.

Michael Krigsman:  What's next? Everybody is working from home right now. We don't know what the future holds. How are you managing that?

Jamie Holcombe: We had the examiner core mostly working from home. Of the 9,000, say, examiners, about 7,800, before COVID, every day would go downstairs to their home office and start their work.

Now, that doesn't mean they got up at the same time every day. You could do your work whenever you want. That laid the core of the foundation so that when COVID did hit, we were able to take the other remaining 6,000 workers and were able to put them on the backbone by scaling up, getting the licenses needed, both software and hardware, and we had just doubled our bandwidth because we were attempting to move to the cloud.

Serendipity, right? Some things happen for a reason and we were prepared.

This is great. We are currently operating with over 14,000 simultaneous VPN connections every day. We have over 1,200 WebEx meetings every day.

Our productivity numbers for the examiners are through the roof. When you look at the analysis and figure out why, well, there's no place to go. Nobody is taking summer vacation.

What we want people to do then is to start taking some summer vacation. We know that the burnout is going to start happening unless people get away from this isolation and actually take a break. Even a staycation might be needed.

Get outside. Get some vitamin D and that sunshine. You've just got to get out and exercise and make sure you stay healthy.

We want all of that to remain going forward. We could remain in this maximum telework for an indefinite amount of time and we will never miss a beat. But, for the rest of the economy, I know there are some things like transportation, the airline industry, hospitality, restaurants, hotels, and so forth where I am really looking forward to getting back, getting people back, keeping socially distant, and making sure that we protect one another but, at the same time, get the engine of the economy rolling again.

Michael Krigsman:  For your work, you can go on pretty much forever as you are but, obviously, that's not the desired state because we need the economy to come back.

Jamie Holcombe: That's exactly right. Just because it's good for me doesn't mean it's good for others and we really need to think about that. So, one of the things we did on our uspto.gov website, we have a new area called Patents for Partnerships.

What it's highlighting is the fact of inventors, creators, and business folks looking for other businesses to license and use these ideas out in the industry. It is COVID-19 related because, whatever the inventions, whatever the creations, whatever the solution is, we want that to get out to the public as soon as possible so that we could take advantage of it and solve these really hard problems.

Michael Krigsman:  Can we finish up by sharing with us three lessons you have learned in this IT modernization journey?

Jamie Holcombe: One, don't think you know the answer. [Laughter] If you start out with preconceived notions that this is the way to go, I guarantee you will be wrong. And it's a good thing, too, because you never know what people can invent, can create, can innovate.

We threw open these ideas and said, "Hey, what do you think?" The solutions that we got back were phenomenal. Don't assume you know the answer.

Number two, you have to have a stabilized and secure core or base. Without that, you're not afforded the opportunity to modernize because you'd be always doing the operations and maintenance of things and they're always falling apart. You need to make sure that your core infrastructure is stable and secure.

I guess, finally, the thing is, don't accept that your contracting officer is telling you it's going to take more than 90 days. That I call B.S. With the right leadership and guidance, and the right inspiration and will, you can get almost anything done within 90 days. Those are my three.

Michael Krigsman:  All right. Anything that I have not asked you that we need to talk about before we go?

Jamie Holcombe: Continuing the theme of engine of the economy, we need to get back to work and we need to find separate ways. If we're going to stay isolated, we need to invent and create innovative solutions to get back to work, to do travel, to create hospitality, to get back out onto Broadway and watch the plays, to go back to our theaters feeling safe and secure. We need to overcome the fear of this COVID by solutions and real facts.

I'm really looking forward to doing that without exposing anyone to the COVID-19. We've got to make sure that we're doing the right things and getting back to the economy.

Michael Krigsman:  Well, I'm definitely on that train with you. Jamie Holcombe, CIO for the U.S. Patent and Trademark Office, thank you so much for being with us today on CXOTalk.

Jamie Holcombe: Thank you so much for having me, Michael. It was my pleasure.

Michael Krigsman:  Everybody, thank you for watching. Before you go, please, please subscribe to our YouTube channel and hit the subscribe button at the top of our website and we will send you our excellent newsletter. Have a great day, everybody. Check out cxotalk.com. We have great shows coming up and we'll see you again next week. Bye-bye.