Ryan McCarty: And I think this is where infographic style communication becomes really helpful because you can do a one pager and you can include a lot of short steps in that one pager just to help someone through to give them that final mile of information that they'll need to familiarize themselves with. Make it easy, make it friendly.

Tom Arbuthnot: This week on the Teams Insider Podcast, we have another customer perspective. We have Ryan McCarthy, who's a Senior Unified Communication Engineer at a large legal firm. We talk about his journey with Microsoft Teams and specifically dive into the requirements in legal. Lots of talk around meeting Interop, complex AV requirements and business expectations around meetings and Teams.

Really hope you enjoy this one. Thanks very much to Ryan for taking the time. Also thanks to Landis who are the sponsor of this podcast. Really appreciate their support. If you're looking for a Teams certified contact center or attendant console, do check them out. On with the show. Hey everybody, welcome back to the podcast.

Got an exciting one. Another customer perspective, Ryan McCarthy, uh, who's at Freshfields and I've spoken to Ryan many times over, over the years. And so I finally twisted his arm to come on the podcast. I'm really excited about this conversation. So thanks for coming on Ryan, first of all. 

Ryan McCarty: Oh, you're welcome, Tom.

Tom Arbuthnot: So give us a little bit of a context and background about yourself and your role. 

Ryan McCarty: So, as it stands today, I'm a Senior Unified Communications Engineer at Freshfields. Um, I've been here now for around about seven years. I deal with, at this moment in time, a lot of UC and AV design work, particularly around property portfolio.

Um, how technology fits into requirements of the firm and a legal organization and how that meets legal mandates. You know, what, how we meet our clients, what platforms we meet our clients on and so on. 

Tom Arbuthnot: Awesome. And legal, quite a challenging environment. Lots of different platforms in play, lots of different clients, obviously lots of different requirements.

You actually come up through the kind of the Microsoft Exchange side into this space. Is that right? 

Ryan McCarty: Yeah. When I initially joined the organization, I was a Messaging Engineer. Um, I wouldn't say it was my greatest skill set. Um, and it's still not a favorite, to be honest. I find UC much more enjoyable. It's a, what I would say, a hybrid skill set.

So it draws on a few different areas, you know, networks, the platform knowledge and so on. Um, and of course, devices, if you get into the meeting space and IP phones and so on. But, uh, yeah, I've, uh, developed through a few roles in my time. And at this point, doing what is solution architecture in the AV space.

Um, and yeah, it's something that I do, do thoroughly enjoy. 

Tom Arbuthnot: So tell us a little bit about your kind of journey through Teams and Teams Rooms and your experience there. 

Ryan McCarty: Yeah, sure. So we start, we started looking quite some time ago at Teams Rooms back when it was SRS V2. So it was a modernization project.

We were looking at various different products on the market and we settled on SRS as it was back then, because it gave us that really modern user experience. Um, soon after that was upgraded to the first iteration of Teams Rooms. But as you can remember there, Tom, there was a lot of things missing back then.

And even, you know, as we've, as we've slowly progressed and there's more and more things been added, I think there's still some way to go before, um, it's a full, solution. Although people who I know at Microsoft might not be pleased with that statement.

Tom Arbuthnot: This is why we have people like you on Ryan ,because you've got an AV perspective as well. So it's good to hear where, where there are perceived gaps or real gaps, depending on the business use case. And it's different use cases for different customers Of course. 

Ryan McCarty: There's a lot of differences there. And you know, when you look at the ecosystem in MTR, as you, as you have in that right now, you've got the MTR app, You've got the Android app, and you may have a Surface app, although I believe that it's being slowly folded into Windows, so the 

Tom Arbuthnot: Yeah, yeah, Surface is going to become another MTR, really.

Ryan McCarty: Yeah, and when a user goes into those rooms, right now you have that burden of knowledge of knowing what room type they're in, what the functionality of that room is, and how it can interact with the outside world if you're not just having a Teams call. So a good example of that is, you know, MTR Windows.

At least up until recently, you could do Zoom and WebEx by direct guest join. On Android, you could only do Zoom. And I believe Android could not use Pexit. So again, once that matures and once you can do everything on every platform, you minimize that. But in the meantime, as technologists, you have to look at that ecosystem.

Okay, well, how do I educate my users so they don't have to worry when they walk into a room, what platform they're using, what hardware's in the room, and how do I do what I need to do? And one way of doing that is being able to standardize heavily. And that's something that I've spent a lot of time on.

But you do end up with a mixed ecosystem because. You do end up with complex spaces and MPR's, you know, multifunction spaces which will usually be Windows because they have to integrate with a DSP and so on. Or you'll end up with what I refer to as kind of standards based spaces where you might end up with a Rally ecosystem from Logitech or something similar from Poly which is Android OS.

But it's a contained ecosystem that you can put in at a lower price point and have a good enough solution. 

Tom Arbuthnot: Yeah. And you jumped straight on Interop there, which is interesting. It's always interesting to see what people come to first. And I guess that that's something you've had experience of, right? 

Ryan McCarty: It's a big thing in legal.

You don't get often to choose the platform. You can either be a trusted partner in a conversation that, you know, your customers, customer controls, or your client will dictate platforms. So, you know, that could be Zoom, it could be Webex, it could be Google. And you don't often get to say, Oh no, we're meeting on Teams and you need to meet us here.

Tom Arbuthnot: Yeah, you're not the one in control of that conversation. You're, you're subservient to the scenario. 

Ryan McCarty: Yeah. And as a technologist, then you have to choose a platform or make sure you're using a platform that can meet with them. So that's where Pexip becomes a nice, what I refer to as a glue in the middle.

I almost envisage Pexip much like the selling point of an SBC is that back to back, you know, negotiating protocols on either 

side. 

Yeah. So you end up with platforms like Pexip that can bring the SIP into the Teams ecosystem. Um, although, you know, other parts of that can be trying to use direct guest join.

Um, we've, or I should say, I've had limited success with that. I think it's okay to a point. Um, but I think supporting SIP across the whole ecosystem is the way to go. And I know with the August updates, we are nearly there. 

Tom Arbuthnot: Yeah, I guess you're pretty excited about Sofa to loop everybody in. Microsoft are now opening up the ability for Pexip and potentially other CVIs to allow click to join from any SIP address on an MTRW through Pexip and into that, so not just to a SIP standard endpoint, but potentially into WebEx or Zoom or Any of the other cloud platforms that support SIP, and most of them do, with a simple click to join, which is a big step forward for Interop.

Ryan McCarty: Yeah, definitely. I think the only thing that you could benefit from there as well is having code based join across all of those platforms as well, if that's not currently in development. It's not something I've seen any, you know, any announcements on as yet, but one thing you have to consider there is meeting invitations are great, Until the meeting start time passes and then other than fudging your way through the mailbox and accepting that meeting invitation.

There's no way to get the MTR to accept it. 

Tom Arbuthnot: Yeah. So if it's a run into the meeting scenario, then it's tough, isn't it? Cause like your typical user struggles with that forward the meeting to the room and the lag on that and everything. 

Ryan McCarty: And don't get me wrong. As I say, there is a fudge. If you're an IT admin, you can go into the mailbox and you can manually accept that invite.

So once that start time has passed. You can get it onto the panel, but quite often, particularly in legal, there's no time for that. The meeting started, you look a little bit silly, and the last thing you want to do is have a massive delay while you go and get IT to accept the invitation, maybe even later.

So code based join would be the ideal add on to that, and I know it's something that you have in, say, the Zoom platform, for example. You have both the SIP join capability via invitation and the code based join. So capture those eventualities where you're not quite on time. 

Tom Arbuthnot: Makes sense. What's your experience been of bringing in AV ecosystem into Teams Rooms as well?

Have you done anything around those, those bigger spaces and building in extra, extra audio capabilities or video capabilities? 

Ryan McCarty: Yeah, we. We have a fair few divisible spaces, flexible spaces where the tabling may be removed, the rooms may be reconfigured for various events and so on. So we've had a number of partners over the years in that space.

You know, I think, I think I'd be amiss to say there's probably a couple of big partners in the space that everyone knows of, and we've used each of those ecosystems to achieve this. Um. Right now, I think one of the most recent projects we did in the East Coast U. S. Um, we had a triple space with large format LED screens, reconfigurable tabling and everything else in there.

Awesome. And it does provide a really good experience. Um, there's not a great deal from a platform's perspective that you can do. You know, it's just a room until it plugs into that integration system but you can do a lot of clever things in there. I guess the limitation really becomes budgetary as opposed to what you can do with the technology, but you can have lighting and blinds control.

You can have controls in there to select input locations and so on, along with, you know, global mute and then, you know, Push to speak and so on. 

Tom Arbuthnot: Awesome. I'm interested in your perspective. You've kind of got, you've got the AV skill and you can talk IT. You're kind of living in those two worlds. Is that a fair comment?

Ryan McCarty: Somewhere in the middle, I would say. Um, But yes, it's something I've been doing for some time now, so yeah, you also have the construction side because a lot of what you get comes from building architects saying this is the proposal and this is our vision for the space. How can the technology fit into this?

And sometimes it is a little chalk and cheese because the building architect has a, An aesthetic vision for a space and then I want to put a microphone or a camera on the ceiling. 

Tom Arbuthnot: Loads of glass, nothing on the walls, a concrete floor, like it's all going to be super clean. And then you're like, yeah, this is like the worst scenario for our audio.

Ryan McCarty: It's funny, I saw an analogy on this some time back, which I think was quite accurate. I think building architects are designing the building to be the place to be. Whereas I think these days, post COVID, with flexible working, 85 percent of calls coming from remote participants, there really needs to be a bit of a change there to bring it around to the technology is the reason you go to the office, as opposed to the aesthetics of the space that you reside in.

Now, there is a conflict there in the sense that a lot of confidential meetings that you have in the legal world do require everyone, or a lot of people to be present in the room, but there needs to be that middle ground, in my opinion. 

Tom Arbuthnot: Yep. Yeah. And what are your thoughts if you could come into an organization and, you know, based on your experience, like say they're doing, uh, either they're doing a refurb or they're doing a Greenfield site.

How do you bring the architecture and kind of building and facilities, the IT and the AV together efficiently. 

Ryan McCarty: So this is something I've spent the last two years working on, and I think the key point or the key focus in that scenario is having a technology portfolio to a point where you have some.

Clear standards defined, and don't get me wrong, these don't have to be set in stone. They can be flexible standards. So when I talk to you about our integration provider, i. e. hardware provider, you have a set of standards on the technology and the hardware, but you don't necessarily have a standard on how it's implemented.

You have the flexibility to implement it to a floor plan, and that means that not every room is going to be identical in those. What you could term as premium spaces, but it does mean that the behavior, the programming, the interface should all be familiar whether you are in Paris or New York. 

Tom Arbuthnot: Right. So you're, you're normalizing the user experience as well.

Like I might be in Paris, I might be in London, but I can walk into a room. It's like, Oh, divisible rooms work like this. Small rooms work like this. 

Ryan McCarty: But also in the legal space, you tend to have a couple of different. Operational areas when, within a firm so you kind of have client spaces where you'll meet the clients and those rooms will tend to be higher high end rooms, but then you have practice spaces where you can make them just good enough because the tendency in those spaces would be that you meet on your firm's internal platform. So Teams or whatever the platform is. 

Tom Arbuthnot: Yeah. 

Ryan McCarty: That means you can then go for vendor solutions, vendor standard solutions that are at a lower price point, but can deliver the same quality user experience. So the likes of Yealinks, your Polys, your Logitech, keep it in that ecosystem. Um, what I would say is.

It will be prudent to standardize on one, because the more you introduce, the more management platforms you're going to have to have, the more monitoring you're going to have to have, and there's in the industry yet, to my knowledge, there isn't an all in one place where you can aggregate all of these signals from MTRP and all the other platforms.

Tom Arbuthnot: No No, it is a complex management, I was just saying. We were talking offline, the London News Group, that's one of the conversations is you've got the, you've got the pro portal, you've still got stuff intact for Android, you've got the OEM tooling as well, and there are things the OEM tooling that we, that we can't do natively.

So that's a really interesting point that you try and minimize the number of OEMs to, to smooth out the management capability. 

Ryan McCarty: I mean, I'm not going to say I'm going to put, uh, a, uh, copyright or, uh, an idea registration down for that one Tom, but, uh, if anyone's thinking of it, it's definitely needed.

Yeah. You know, something along the lines of ThousandEyes from Cisco that aggregates all signals from all of these platforms. Because. You know, someone said to me, What about if you could integrate it with ServiceNow? And that's great. But the problem is with integrating with any sort of ITSM system, if the data is not clean, you're engineering, reviewing those tickets, especially if there's hundreds of them a day coming out of these systems.

It will become less and less effective. People will start ignoring signals because they're just seeing spam. So this is where, you know, one central system that could both aggregate the signals and maybe use some sort of AI to go, Okay, there's a correlation here between this signal from one platform and this signal from another.

There must be an issue. Better red flag that. It would be really valuable. 

Tom Arbuthnot: And I think Microsoft have said with the Pro Management Portal that their kind of North Star is everything can be managed in there, we're just not there yet, but like it's a it's a tough one because the OEMs have clever things they want to do on their platforms as well.

So either one has to plug into the other somehow for that for that to come together. 

Ryan McCarty: It's an interesting point on everything can be done in that platform, because as I think through it, perhaps I think as I think of my experience of. The OEM portals, particularly the integrator portals, you're just not getting the volume of signals in there that you need, especially if you've got complex spaces, right?

Um, just things like, you know, devices being offline would not be picked up by MTRP's Pro Portal because it's a signal that MTRP is not going to be looking for that the MTR itself may not even be aware of. You know, it's just a HDMI over IP device offline over here. 

Tom Arbuthnot: Yeah, that's invisible to the MTR potentially, yeah, good point.

Ryan McCarty: I think the same thing would apply, let's use a Logitech example. If you're using a site on a table, MTRP probably wouldn't be aware of that device going offline. And again, it's those sort of edge cases that the OEMs are great at monitoring for themselves because it's their own product. But you need some way to bring that together, add some intelligence, correlate those signals, and then go, okay, that whole room's down.

So that could well be a network issue, nevermind individual vendor problems. 

Tom Arbuthnot: Sounds like you've got a startup, Ryan, I reckon. 

Ryan McCarty: Honestly, Tom, I don't have the will or the experience to develop anything like that. 

Tom Arbuthnot: But yes, it's really interesting to hear that because you're living it. And what's your, your wider thoughts on manageability?

Because again, I see this is interesting, because there's AV stuff to manage, and there's IT stuff to manage, like who owns the Teams policies, who owns the hardware? Well, thoughts on that? 

Ryan McCarty: It probably gets more convoluted once you consider this at a global scale because you have local IT teams in the mix there, so you've got your technology teams at third line who are a bit more briefed on the technology and have KBs to refer back to, you have your local teams who are dealing with people day to day who are trying to use the teams, so use the room should I say, and 

it's an interesting question and it's, I think it's one that a lot of organizations are going to wrangle with whether you outsource that expertise to another organization because you don't want to increase your own internal resource count or otherwise. Um, it's, it's a tough one. And I think it comes down to it, to each individual business, how they handle it.

You could upskill your guys. Absolutely. Um, outsourcing it, you know, It is an option if you want to minimize costs and just put that on to somebody else to look after it for you, particularly if the expertise lives within, you know, an AV integrator that you have a close relationship with. It may make sense that the people that implement for you also do the maintenance and monitoring and everything else.

Even day to day operations, I've seen that in some circumstances where you have some dedicated staff on site to make sure that these systems remain online. Um, I have seen, you know, that maintenance and daily checks are really important in these spaces. And, you know, while we do have a, at least in MTR and Nightly Reboot, sometimes if the system has extra components attached to it, not everything comes back gracefully.

And just having someone going in there day to day and checking the health of the system, particularly things like freezes don't get caught in monitoring platforms because, you know, from a signals perspective, it's online, right? When you walk in the room, if a touch panel is frozen, only the person in the room is going to catch that.

And, you know, when you've got high importance of meetings going on in your suite, what's the importance or what's the ramifications of failure? Is that going to cost you? Is it going to cause reputational damage if every time the client comes in they're going to see a meeting room that's not functional and therefore you can't meet and you've got to rush to another room and so on?

Tom Arbuthnot: Yeah, yeah, I see both cases. I've seen people fully, fully outsourced or fully in house or a bit of, bit of hybrid, um, but you're definitely not the first person to say that, that kind of. Daily checklist and daily check approach. If it really is that important, then having someone come in, do a meet now, check the check the AV is, uh, you can't get much better than that in terms of knowing everything's up.

Ryan McCarty: And of course, being an internal technologist, I'm always going to say having the knowledge internally also helps your organization, you know, in having those conversations in working with integrators and dare I say, and not being taken for a ride by anybody in that particular market. 

Tom Arbuthnot: Yeah. And how have you found the kind of pace of change with Teams rooms?

The, the patching, the, the feature changes? Like, like how do you deal with that

Ryan McCarty: Maximum deferment at the moment. . So in MCRP, my deferment inclination is to defer as long as possible. To avoid scenarios where you update too early and you catch a bad update. Um, maybe that's just how long I've worked in IT because, you know, I still have the end mentality of N-1, whereas these days with cloud based systems, we're encouraged to have the policies set to 30 days or so.

So it's, it's a challenge to say the least, especially in high importance spaces where you want to minimize downtime, having that maximum deferment set helps maintain that stability. Is it the right course of action or what's recommended? Not necessarily. And I guess I'm more risk averse. So I want to make sure I've got that breathing space.

Tom Arbuthnot: Yeah, well, when it's your neck on the line and nobody's chasing you for the next feature as well, they're just chasing you for like, make the call thing work consistently. I can see the logic of that. Have you tried mixing it up? Do you do like certain rooms first and then other rooms later? Or do you just try and defer across the board?

Ryan McCarty: I've got, I've got small defined pools of test kit. So, you know, we'll get the updates on the test kit early. One of the ones we got recently was the QR code update. And, you know, that's a visual change. And as soon as that pops up on one of the test rigs, someone's like, what's that? You know, it was something that I wasn't particularly monitoring and I wasn't waiting for.

So, you know, it pops up and it was a bit of a surprise, but, you know, that had been deferred for 60 days. In an ideal world, what you'd want to have is, you know, user adoption people alongside your team constantly picking up on UI, sorry, UI changes such as the QR codes to make sure that documentation is updated.

But I think, Realistically, we all know that that's not necessarily the case and I don't think any organization has the luxury of people sitting around waiting for UI changes to occur so they can be documented at the first convenience. 

Tom Arbuthnot: Do you have any thoughts on how you do user adoptions and comms change on that?

Do you proactively communicate it or do most of the users just pick up like new capabilities? 

Ryan McCarty: I think it needs some sort of hybrid approach, so I've been having similar conversations, and one thing that I've been encouraging is to use more infographic style, um, content, so it's, it's, you know, easy to digest at a glance.

Tom Arbuthnot: Okay, so kind of bite sized engaging stuff. 

Ryan McCarty: Being as long in IT as I have, and don't get me wrong, I've not been in IT as long as Some people, or a lot of people in that sense, but there was a tendency, and there still is to an extent, to document in Word documents that end up being 15 pages long, and you can grab bits and pieces, and even SharePoint documentation that I've produced ends up being quite a long and laborious document that you have to jump through. 

Tom Arbuthnot: Yeah, communicatingg like an engineer is different to communicating like a user adoption, isn't it?

Ryan McCarty: And I think this is where infographic style Communication becomes really helpful because you can do a one pager and you can include a lot of short steps in that one pager just to help someone through to give them that final mile of information that they'll need to familiarize themselves with, make it easy, make it friendly.

But I think also using internal platforms such as Yammer or Viva Engage as it is now to communicate that along with email, you know, and you make sure that you're doing. Long form content, micro content in those different methods of communicating with people. Viva in particular is really helpful because it puts a notification in Teams.

So you get a notification that someone's posted in Viva to the All IT group or the All Users group. This is our new equipment. And it prompts people to go in there, whereas email to an extent is discouraged these days. But I still think, um, particularly for those. Having worked as long as I have, it's still somewhat effective.

Uh, you know, I may open it. I may glance at it. 

Tom Arbuthnot: Yeah. Yeah. That's really useful. So, uh, Just want to say thanks so much for that. I'm just thinking through all the, all the tips there. It feels like I need to do like a mini blog post of all the tips, but it's great to get your perspective today particularly Legal, those, those very specific requirements in terms of use cases and reliability is so good to understand.

So thanks so much. Hopefully I'll see you at one of the upcoming events as well. 

Ryan McCarty: No problem, Tom. 

Thanks. Thanks for having me.