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.
Jamie, IT modernization, what does that mean
for you at the U.S. Patent and Trademark Office?
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.
Give us a sense of why that has historically
been such a challenge to be at the leading
edge in the government.
For the right reasons, we have, in the government,
a duty to ensure we comply with all the laws.
The government creates the 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.
Is procurement complexity then the primary
obstacle to being more agile, more responsive,
just faster, in general, in the government?
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.
What is the answer then, because those compliance
requirements still exist?
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.
From a technology standpoint then, are there
specific IT modernization patterns or technologies
that you're focused on?
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.
Are you entirely funded through the revenue
you receive?
Yes, we are totally fee funded.
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.
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.
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?
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.
It sounds good, but how do you get there in
practice because, as Arsalan said, the government
is notoriously slow to react and respond?
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.
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?
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.
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.
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.
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?
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.
We have a couple of really good questions
from Twitter.
How has your IT staff responded to these IT
modernization efforts?
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.
The work always comes back to that reference
point of, what do our customers expect and
want from us?
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.
This focus on customers is central to what
you're doing, to all of your work.
Everything.
Without the customer, we have no mission.
We need to do that.
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?"
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.
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?
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.
Any employee concerns about this that RPA
will displace jobs?
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.
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.
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.
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?
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.
What's next?
Everybody is working from home right now.
We don't know what the future holds.
How are you managing that?
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.
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.
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.
Can we finish up by sharing with us three
lessons you have learned in this IT modernization
journey?
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.
All right.
Anything that I have not asked you that we
need to talk about before we go?
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.
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.
Thank you so much for having me, Michael.
It was my pleasure.
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.
