Matt, welcome to the Evolve Radio podcast. Thank you so much
for having me, Todd. Alright. So we'll get started.
Just a bit of background and intro for yourself, your history in the
MSP, and the company that you're operating in now.
Yeah. Definitely. So today, I'm a cofounder
and COO of Thread. But in a former life, I was an
operations professional with an MSP by the name of Richard
Fleischman and Associates, RFA for short, based out of New
York City. And so they focused on financial services
companies, hedge and private equity, primarily
joined them on the the compliance side back in, like, 2013,
2014 when the SEC decided that they cared a
little bit about cybersecurity, not enough to regulate it,
but certainly enough to issue guidance and guidelines. And so
that was an interesting time to be starting your career, in technology.
Promoted through there into account management, so I had about a 100 funds
underneath of Eden, and then on through the ops tree to, to chief of
staff. Excellent. So an operator by
nature, so we're we're fast friends, I think, because of
our our views of business in that that respect for sure. Got that
right. Alright. So, some of your your
background, I'm I'm I'm I am curious, like, we we maybe talked a bit about
this in in some of the lead in as well, but,
you what about sort of the operations side of the business as you
were kinda growing up in in in the MSP that you worked at?
You know, eventually you sort of get pulled out of some of the technical things
and I suppose like maybe if it's relevant, compliance is a very
specific type of technical work. Right? Like it's not like a lot of other
things. It's more sort of governance, very procedural.
Did you were you always sort of wired towards the operations side of the
business? Was that of interest? And and sort of how did you get pulled further
into the business side of things versus the technology side?
Yeah. So I didn't have a technical background at in school. I
actually studied English. I had a technical writing minor.
And, that's that's how I ended up being in in kind of
a documentation heavy role like a business analyst,
slash compliance analyst with the MSP. And I found
it a very helpful way to get a really strong foundation
layer, in terms of technology. I didn't know what a
Cisco ASA was. I didn't know what a switch was. I I didn't know
anything about UTM and, you know, MDR and EDR and all the
good stuff, all all the good acronyms that we could throw out there. And so
it was a great education for me in that,
you know, we would have a technical due diligence service whereby
we would audit a hedge fund's environment, document it,
and then present it back to a prospective investor of theirs to
say, this is how they're protected. This is how they're secured. This is how they're
backed up. And this is what they're doing in terms of, BCDRS.
And so for me, it was a great education in that sense, like I
said. But it evolved into migrating from
an in house, ticketing system to ConnectWise
manage, for for the business. And so I I really
dove deep into, well, how did the workflows that we're doing in the
existing system map to manage, and how do I
help to migrate the business from from this to that. And so I think
that was really my directional,
evolution, I would say, into the the ops side of the house.
K. Interesting. Yeah. So nontechnical background
and now working in a very, very tech heavy industry. So did did you find
the learning curve on that sort of heavy or, like, especially in the account management
phase? I imagine there was a point where you were kind of faking it till
you make it type thing and learning enough in the background. Oh, yeah.
Yeah. So I I remember on my first day, actually,
I I walked into into a conference room, and it
was the man with his name on the wall, Richard Fleischmann,
with my future boss, our c COO at the time,
Johan, and our CTO and, like, the whole c suite. And we were
putting together an RFP proposal response.
And so, again, that was another way to really get a good understanding, lay the
land for, like, how do you position technology as an
advantage for your prospective customer in the future?
So the the combination of those two items, I found to
be super, super helpful. But, also, when you got
to the the account management, side of things, it's it's about
understanding where the technology estate is today, you know,
where where there are gaps, if there are gaps, and then helping them navigate
to what it should look look like in the future, whether it's a cloud
based environment or upgrading their SAN, so on and so forth.
And, it was a really it was a great broad education again without kind
of having to get too too deep. Yeah. Awesome. Okay.
Cool. So, you know, you've you've, like,
what what was the transition, I suppose? Like, you you were working there and
then, you guys got sort of went off
and created this product originally ChatGenie for people who sort of recognize that
name and now Thread. What was that transition look like? Like how did you
go from, you know, account manager into non technical
background working inside this this MSP to, you know,
starting, you know, a very a very sort of, like, MSP
centric, software company. It seems like a pretty pretty dramatic
change, of course, I think. Yeah. Yeah. Definitely. And so,
after I was promoted out of account management into operations, I was
running the ConnectBlaz stack for for the company, with with
help of a few folks. And so I really got to see
how the the business, like, relied on it and
interrelated on the platform very intimately.
And so I started to engage with the community a little bit looking for solutions.
Maybe there were there were shortcuts for me to be able to, you
know, use it as leverage for the business at scale.
And I I wish, that I had found evolved
management, back then and and known more about Todd King, because it would
have, saved me some steps. But, but at the time,
that's when I started to really fall in love with the MSP channel
and community, you know, going on Reddit, seeing
posts from from Ray or Sydney and the the, OIT VoIP
folks. But also at the at the
time, Mark Goliath, who's the CEO of Thread
rejoined RFA, and we shared an
and that's when we decided to to launch, what would become ChatGenie.
Awesome. K. Cool. So, you know, my introduction to ChatGenie
was was I think sort of, like, a similar need
than that that, you know, I think maybe you guys are trying to fill and
maybe verify this for me. But, whenever I would talk to
organizations about chat, the like, all of the options out
there were very sort of sales centric. Right? There
wasn't a lot of sort of, chat options. And for me,
like, the reason that I loved, chat is is way back in the day
we'd use this product, Bombgar, that I guess still exists,
but, you know, it's it's extremely enterprise. Like, the the amount that we
spent for the box that had to sit in our office to kinda manage this
stuff was obscene. Like, it was very, very, very expensive
for what we were trying to run. And every time like, I
loved using chat, but I just didn't find it really
applicable or cost effective, it didn't integrate with any
of the tools. So, you know, when I finally found ChatGenie, I was like, well,
great. Like, here is an MSP tool that actually fits into all
the things that you're already utilizing. That was a real game changer for
me. So, you know, you guys started as that.
I guess the transition to thread and sort of what you're building
much beyond, just a chat interface for
tickets. Maybe you can sort of start there of the sort of the history
and then the transition of the company. Yeah. Definitely. And
we started from almost like a chat ops lens. We we just wanted to
connect the internal ticketing system and the internal,
collaboration platform together so that, you know, we saw the
people were talking about tickets in in Slack, but then had to
replicate all of that data back into the system of
record, which was the PSA. And we felt like, you
know, above and beyond the duplication of effort that there were there
would or could be opportunities for automation, you know, triggering
a a workflow based on an approval, things of that nature, right
from where you you're you're living and breathing every day, which is the
the collaboration platform.
We brought it to IT Nation, IT Nation Connect as
it's called now, when we decided to, build the
MVP. And we we showed it to other MSPs, and people
were like, oh, man. This is awesome. You know, we love this. But we're moving
to Microsoft Teams because Teams was then bundled into the 365,
suite of products. So we're like, okay. Great. Back to the drawing board.
We then built the team's integration, brought it back the next year,
and was like, oh, man. Awesome. Let's check this out. And then COVID happened and
everybody dispersed, both customers and,
MSP, like, the the the technicians. And
then that's when we really had a big realization, which
is nobody's and you had come to it before us. It sounds like nobody's
really solving for the the customer to MSP
collaboration, and experience in a way that integrates
natively with the stack and connects to the system of record. And so
that's when we set out to raise a little bit of funding and, ultimately
became Thread. K. Very cool. So you kind of alluded
to working inside of, the the chat
platform. Right? And I I think generationally and just sort of
operationally, like, we see this this change happening. I'm
curious sort of your you you gave sort of one, piece there around,
like, the the the having notes in system of record because you're a
100% right. Like, you see so much discussion about
issues happening in the chat platform that is not captured anywhere else, you
know. So, the only notes that you have is,
escalated, talk to a couple of people about this. You know? Here's the
resolution that I found. It's like, okay. What happened offline? Like, now we have no
information, but there's all this discussion that happens in the chat plan, but the platform
outside of that. So I think having that information actually captured in the ticket
is is huge. What are some of the other advantages you think
of operating inside of the like, a Teams
or a chat platform like that instead of inside the
PSA? Yeah. It's a real time interface,
and you're having real time conversations. So I think that's that's one major
advantage. The other is that, and the reason that we landed
on chat as, our web, so to speak, or where we
wanted to add a lot of value to the to to the MSP
community is that it's, it's real time, but
also it's it's, you know, ordered in time and
it's text and and database. It's something that you can integrate,
well into, unlike email where it's like a
a turn based strategy game, and chat or
phone, which is more of like a m m m o r p g
or like a a real time game where you you get your, your
squad together and you attack these these problems as they come up.
And, you know, for us, that means there's a lot of opportunities to,
again, trigger workflows, whether it be on the the customer side
or within the MSP, because it is integrated.
It meets people where they work. K. Cool. And
I guess this is timely as well because, like, I had a I had a
conversation with a client, yesterday about sort of, like like, how do we
actually integrate chat to to our current workload.
And you've kinda shared with me before, something you're releasing which
will be in the wild by the time this this, episode goes to air. So
it's it's safe for us to talk about it. But, one of
sort of the interesting parts of this is, like, there's some there's there's there's some
ideas around how chat is engaged in and where it's
relevant as far as a support modality. Right? So Mhmm. Incidents
versus requests, just sort of the quick, sort of,
dictionary definition for people. Incidents are things like something is broken.
I need help with this. A request is something like, hey. Could you do this
for me? It's not actually some like a something broken or something I
necessarily need immediately, but it's it's something that needs to be sort of planned
for to get done. And historically, I guess,
like, chat makes sense for things that actively need to happen
because, like you said, it's it's an active engagement. It's a it's
a a sort of a form of synchronous engagement with someone to
ask and it feels sort of like timely. And maybe that
doesn't feel as relevant for, just putting in, like, an
onboarding a user or an you know, changing equipment to a
different office or, you know, scheduling something to happen at the end of the week,
that sort of thing. So you guys have kinda captured this and and are rolling
out a a new feature, to allow for this different
engagement in in sort of time You wanna expand a bit
on this this feature? Yeah. Definitely. And and I'll I'll I
think I'll start by taking it up a level before, digging
into the the feature, which is we tend to think of things on,
if you think about the classic, like, t or
or cross, diagram where you
have complexity and urgency, as the 2,
the 2 parts of that, the 2 by 2 matrix. Yep.
Exactly. The the 2, vertices or axes.
And so for things that are high urgency but low
complexity, I think that's where chat shines, both from an
incident and a request standpoint where it's high complexity
and and high urgency that for us feels like it should be a a phone
call, right, where it can be escalated to the right person right away.
And then there's the the spots between the 2 where it's like, you
know, low urgency, low complexity. Again, probably a great place for for
chat to shine. And so it's really all about being
intentional and having a point of view on, training your
users on when to use the the best of each each
scenario, each modality based on those factors.
You you can distill it down into there's work that needs to be done now
versus not now, and we've really optimized an
index on the the now side of things. Historically, what
we're launching now is, is a it's a product or a feature
called Planner, which introduces the concept of
scheduling into the platform whereby we can now field
or triage stuff now and then book it out, schedule it
for for stuff that falls into the not now category
without having to go back into the PSA to schedule
it. Right. And what you shared before, is,
this will satisfy all the Kanban nerds that wanna schedule
cards for for your tickets. This, satisfies that itch as well, so
I'm sure a ton of people will appreciate that. That's right. That's right. It's
a it's a kanban. Like, everything's drag drag and droppable
and sortable and, reorderable and
filterable. So it's a it's a very smooth dynamic,
view that we're really excited to to launch. Yeah. And people
that love it do absolutely love it. So that'll be great to see. Alright.
I'm curiously the other piece around, sort of chat as a as
a modality, you know, Teams is prolific
in because it comes well, it used to, come with
Office 365. And, for those that don't know, they they were
forced to sort of like, make it a side cart option,
because of, I guess, an FTC regulation.
So, but generally, most in most offices
have teams, but most, I would say, don't actually
leverage it. And I think, a, this is a serve an open,
green space for MSPs to leverage this as an opportunity
to drive Teams as a communication, option
in their client base. But for those that don't have
that, some may say, well, you know, this sounds great, but,
you know, my my clients don't use Teams and therefore they
wouldn't communicate with me in chat. And so, like,
is that wrong? How would you sort of push back on that
as a sort of a well, this doesn't qualify for me because my clients don't
use Teams? Yeah. I think, you know,
in the future, we we aim to be much more,
omnichannel. And what I mean by that is we believe in in
a world where all channels have a place and a time
and and a a use that's best fit for that
channel. And, really, it's about orchestrating an experience across all
of those channels, right person, right place, right
time, right communication style.
So, you know, taking it back from the the grand vision,
what that means for today is, you know, we do have a a desktop,
application in the system tray that they can launch much like,
a screen connect or, like, a lab tech, type
experience, except it'll be branded for your MSP, and it'll feel
exactly like the modality for your your customers who are in
Teams or or Slack. We can also stand up a
plug in on your website or their Internet. Really, it's about
it's about meeting them where they work and, making sure that it's
a smooth and frictionless experience, wherever that might be.
Okay. One of the really important pieces for for that type
of, like, agent based, communication, option,
is a presence indicator. It was always one of my favorite things. Like, going back,
know, back in the day, I built one of the largest linked link,
practices. So the predecessor actually for Teams, was the
the, MS Microsoft voice communication software.
And one of the selling features that was so what's that? Was
it Microsoft Office Communicator? Is that, my data? Yeah.
Yeah. And Lync was was the product. Yeah. That I guess it eventually
became. Yeah. I think it was communicator then link and then now, sort of MS
Teams Voice. Yep. And, one of the the
biggest selling features for that product is was the jelly bean indicator
of software indication of whether or not someone's actually available. You know, to
this day, this is sort of under leveraged, right, as people don't
necessarily kinda capitalize this on communicating someone's availability.
But, where I also found this really, really useful was, again, kinda
using chat in the past was, having a presence indicator as to whether or
not the person was at their desk to be able to reach out to them.
And one of the things that we hate in the MSP ecosystem is
telephone tag. It wastes Mhmm. So much time. Right? And you have
this this support ticket and the sales guy says I need this
fixed right away and every time you call him he's on a call with somebody
else and he can't like, oh, I got I'm busy. I can't do this right
now. Or the executive that is never
seems to be at their desk because they're traveling and don't don't have time to
help you with this. And there's some tools out there that will help you with
the scheduling of this, but I really like the fact that these
chat tools, you can sort of like scan through your tickets and see that,
oh, this person is actually on their computer. I can push a message to them
and say, hey. I see you're available. Can I support you with this right now?
Boom. Like, cuts through all that noise. I have to assume this is well, I
hope this is something that you guys are are gonna be able to leverage in
as a an engagement model for those clients. Yeah.
Yeah. So we don't have a presence indicator today, but it is very much,
on the road map. And it's something that I I totally agree with
conceptually in that, you know, the beauty of having
a footprint wherever the user is is that the
the need for phone tag or or email tag, right, goes
away. You stay connected. You have access to them when you need them.
It's not just them finding a an email address or a phone
number or having to remember to go to a a customer portal to ask
for an update on something. They can get it right in their
workflow, and they can get back to you, you know, when it's convenient for
them or, you know, same goes for for for the MSP,
when it's convenient for for you all. You can get in touch when you know
that they're available. Yeah. Right on. Okay. I'll I'll look
forward to to to those that feature for sure.
The, I guess the other piece to to consider here is rollout. Right?
So, for organizations that don't have a current
chat, support model, there is some
consideration around, you know, how does this change support? Right? Like right
now, we have to have people manning the phones. We either have those people
or other people managing the triage of inbound email,
and then we add chat to this. And, you know, I think the sort of
the tricky part to this in people's heads is that it is live support in
the same way that that phones is. Right? Like you can't just sort of get
to it an hour or 2 later, not that you should in triaging and inbound.
But, if someone opens up a chat request and have
to sit there for it open for 30 to 45 minutes, I don't think you're
gonna get a lot of love for that as a support feature. So it does
require this sort of immediacy, that in my mind
is really beneficial because these are the types of people that you wanna pull off
of phone calls. Right? Because I've always suggested, like, you can have a triage person
support kinda 2, 3, sometimes even 4 chats at a
time without losing their their marbles. But, you know, you can you can
literally only have one phone call at a time. So it automatically kind
of doubles or potentially even triples the inbound workflow that you can manage
it one one time. But, again, it does require that immediate
sort of staffing and recognition of there are chats coming in. We have
to have someone to be able to to sort of pick this up. So what
do you suggest to people that are like, well, what do I do here? Like,
how would I change my model? Do I have to, like, put additional
staff just for chat? What does that look like in your mind?
Yeah. And I think it it depends on I'm not
going to end with it depends. Don't worry. But, as we well know, there there
are few a consultative. Yeah. Exactly. There are a few models.
Right? You you have more of your pod based, quick fix technician.
You know, if I can fix it in 15 minutes, I do. If not, I
pass it up the chain type approach. Or if you have more of a
centralized dispatcher triage model where they're picking up the phone,
they're triaging it, they're getting into the right queue, In
both scenarios, I think it translates really well in that you
dedicate a quick fix technician, to man the chat
desk, so to speak, until you get a a sense of
what that volume will look like, in terms of inbound,
service requests via chat as you scale the the deployment, as you
scale the footprint into your customer base. So that's
a really good way to understand what the capacity
requirements would or could be, into the near
future and then build a model around that understanding
of capacity. So that that's one way. The other,
again, I think, as we think
through the the shift from phones to
chat, that's a very natural progression and one that we
recommend because, yes, phone calls are incredibly expensive, not only
for just the provider but also for,
the company, you know, your customer and the user on the other side.
You're you're both tied up for the duration of the call when you could or
maybe you should be working on on something else that's more production
oriented. And so, generally, we'd recommend
having whomever would be manning the phones that shift or one of the
resources manning the phones that shift, again, repointed to the
inbox and fielding emails and chats out of
there. So something else to consider here is,
you know, AI, is exploding
and, you know, it's showing up in pretty much every corner of the
technology. And and, basically, anything that
touches technology is is being impacted by AI.
Chat seems like a very natural
have to assume this is something you guys are considering. What do you think is
sort of the future of chat with sort of the explosion of AI in the
industry? Yeah. I I think the future, and
it it might be closer than than many think, is that certainly
with first party integrations where, say, you're connected to
the Microsoft, environment and stack, you'll start to see
end to end remediations whereby if you can capture
the intent of the request, like, say, I I need to stand up
a new, a a new group or a new team within my
tenant, and I'd like for it to have this email address,
and I'd like to add these members to that team, like low hanging
but high volume, requests. You'll start
to see the cost structure around that go from, you know, it
doesn't take very long, but I still need a human to intervene and do the
work, to I can handle it on a very
automated AI driven fashion in the not so distant
future. That's that's definitely a concept that we're working on,
and we believe we'll have in place before the end of this year.
And I'm I'm sure we're not unique in in that sense. But in the
in the intervening time, there's, you know, things that that
we and others are doing already, which is understanding the,
typification, the categorization of their quest as it comes in. And then
based on that, understanding the urgency and the priority of
it and handling all of that, information gathering
in an automated fashion so that by the time it gets to a technician,
the baseline information is elevated, and they have a really good
sense of what needs to be done before it it gets to a human.
Yeah. So this is, I think, like, I I had said kinda 2
years ago that, my my AI sort of prediction timeline
that so far is sort of proving to be true. I got a ton of
pushback when I originally released this 2 years ago about sort of, like,
thinking I was I was thinking too slowly, and I would say 2 years
later, I'm kind of right on track. So I'll give you kind of my quick
extrapolation of this. As 2 years ago, I said the first one to 2 years
will be just, like, pure experimentation. There'll be a lot of things that
are labeled AI, and it's just, like, people taking a stab at stuff
and some of it'll look interesting but, you know, ultimately it won't really show
up as a material change for a lot of people, a lot of experimentation.
Then sort of that 3 to 5 year period is where things start to show
up that are actually sort of like our true use cases where it
starts to show up as side carts like tools inside of tools,
where there's actually legitimate uses for it. And I think we're right at that
stage where those things are starting to show up. And then, said
kind of that 5 to 10 year period is where AI will,
dramatically change the technology support landscape and ultimately
decimate help desks. I think, like, over that 5 to 10 year period, it's
messy as to sort of when that happens, But I can 100%
see in the future where, you know, like, you don't need a
full staff of help desk people because most of the things, like, like, if
we extrapolate on what you're talking about of, you know, the there's an intent
understood by the request and it just goes out and automates a bunch of stuff
based on scripts and APIs. That definitely felt like a
pipe dream for the longest time. Like like I'm an old school IT
nerd where like in like 1998 and stuff like that
there was stuff being sold by Compaq
that labeled itself as self healing. Right? And then
IBM got big into this in in the early 2000. And it's never
really been true, but in the future, it will be.
Right? So, I'm I'm curious sort of your thought on on sort of
my mental modeling of that and what the implications of that are
to sort of the MSP ecosystem of, you know, do you need
a support support desk staff of 30 people
or, you know, 10? Will that be sufficient? Because most of
sort of that that, high volume, low complexity work is just
being managed by bots. Is that sort of something that you envision in the
future? Yeah. So I think your your timeline
is is very astute first off, so kudos to you.
You know, I think a lot of times people get excited about, leaps
and advances in technology, and, we saw it ourselves. Right?
We we brought the early v one of our time entry automation
functionality using, OpenAI's,
GPT 3 at time, I believe it was. And,
you know, the light bulb wouldn't really go off. We'd show people and we'd be
like, this is so exciting. Look, we're we're writing the time entries for your
team. And, you know, we would we would get very muted
response back. But then when ChatCPT became
publicly available and there was the big kind of groundswell of
excitement around, around AI and use cases of
AI. Then all of a sudden, we're getting, you know, prospects on demos saying, well,
why doesn't it do this? Why doesn't it do this? Why doesn't it do this?
And so, you know, definitely embrace the creative the creativity
of of MSPs and folks in the channel. It's something that we love
about working with, about, with MSPs is is the
knowledge sharing and the creativity and solutioning.
But, but yeah. So back to the original point.
I think your timeline is just about right on, and I think
we'll start to see, we'll start to see design
patterns where you have multi, what what first, you'll have
agents which are designed to handle a very specific
function or subset of functions, repeatedly. And then
we'll start to see, design patterns where you have multi
agent workflows and experiences. You might have, an
agent that's a specialist in desktops and an agent that's a specialist
in, networks, collaborating together
ultimately to to to, solve a problem,
with no or low human involvement. And I think what
that looks like and means implication wise for for the channel
over the long term is that you'll start to see very
well scaled operations whereby a team of
10, 15, 20, can do the work and have the reach
of what used to be what used to take a 40, 50,
60 person shop, if not more. So it's exciting,
but it does change the the nature of the work,
in in a sense. And so those who can navigate that
evolution and stay ahead of the curve, I think, are are going
to be really well positioned. Yeah. I think, like,
I don't mean to sound sort of like, Chicken Little about this of, like,
everyone's out of a job because, you know, AI is coming for your help desk
roles. I think there will be some of that.
I think a lot of it just forces an evolutionary change of the industry.
And the the way that I sort of like like explain this backwards is
similarly like when we were building, these, MS
communicator and link practices, This was when
BPOS, the, like, business productivity office suite, the predecessor
of of Office 365 and now, M365 was
rolling out. And I would have chat with chats with industry executives
that are like, you don't understand. Microsoft is stealing all of my money.
Do you realize how much money I make on exchange upgrades and maintenance and
hosting? It's like, well, okay. You can go throw yourself on those gears and and
try to maintain a hosting business with Exchange and doing project upgrades.
Similarly, you know, why does anyone wanna fight to maintain the
help desk if they don't need to? We're talking about really long time cycles here.
I'm not saying these people are gonna be out of job in 2 years. Like,
this is an this is again an evolutionary change to the industry where, like,
there'll be lots of other jobs opened up. And I a lot of ways, I
see this as sort of a return to the mean or a circle about what
we're doing is a lot of what we do goes back to consulting. Right? Like
your human skill set and your consultative skill set will be
far more valuable than than your general technical skill set
because that stuff just won't be as sort of necessary or unique
as it is right now. Because a lot of it will be filled by agents.
But, you know, who can go out and have consultative
conversations about all these wild technology changes that are happening
with humans that don't know anything and don't care to know anything about
technology. That's where the business will sort of evolve to. Right?
Yeah. And and I think it ultimately just it changes
the nature of the value that you're delivering to to your customers and to your
partners. I think you're spot on. It's it's how then do I,
take the knowledge that I've gained in orienting
that, technology to give give leverage within my,
my MSP, my consultancy? How do I then,
orient that towards my customers and help them gain leverage
within their operation? And I think that totally changes
the the calculus, so to speak, and and the value proposition
that we're we're we're able to offer to, to businesses everywhere.
Yep. So I mean, it's a cool space. Right? Like, I always joke, like, you
know, if if you like things to stay the same, technology industry is probably not
for you. But if you like an industry that's so dynamic, everything has a 6
month shelf life, this is a great spot for you. Right? And that's that's the
nature of being in an IT service industry is is the
only, the only the stability you have is that things
will change. Right? Like, it's it's, it's fun. Like, all
of these things that will shift the industry and have to adapt. If it
were easy, it'd be boring, and everyone would be doing it. So this is where
the margin gets made, basically. Right? Yeah. It's great for my
ADHD. Yeah. That's right. Along with everybody else in this
industry, for sure. It's like, like, maybe that's part of the reason that there there's
a bit of a, a bit of a bias as those people showing up in
this industry is it's just tuned exactly for you. Right?
Exactly. Yeah. Getting, yep, getting engaged in
change. Oh, it's a good thing. That's right. Cool. So, we'll throw in
some links and everything to to yourself, Matt, and to Thread.
Any sort of parting words of wisdom, that or,
requests to the audience that you would suggest they check out?
Yeah. I mean, I would just say get stay engaged with the technology.
We we've learned so much by standing up proofs of
concept and and speaking with our partners and and in some cases,
their customers to understand how are you thinking about it. It
is this design pattern feasible and realistic for how
you foresee the use of this technology within your business in the future.
And I think the more you have those conversations and, you
know, you you you find the areas in which you want to invest
and believe that, the the better,
outcomes that that you'll have, going forward. So that would
just be the recommendation is is stay engaged, stay in touch, keep tinkering,
and you'll end up, with a good answer. Awesome. Appreciate
your time, Matt. Likewise. Thanks, Todd.