Welcome back to How to Handshake, Optigo Networks’ podcast series on OT networking, building automation, and the conversations that actually move the industry forward.
Subscribe to the podcast on Apple Podcasts, Spotify, Deezer, and YouTube!
What actually happens when IT and OT have to work together?
In episode four, we’re joined by Jim Meacham from Altura Associates and Doug Plumley from Dartmouth College to talk about what actually happens when IT and OT teams are told they have to work together. Where do they misunderstand each other from day one? When IT security and OT security both want different things, how do you write a policy both sides can live with? And what does a working IT/OT relationship even look like once the kickoff meeting is over?
We get into why “it’s all IT” might be the more useful framing, the day-one vocabulary gotchas that derail projects (yes, including “I have eighteen routers”), Doug’s “pain index” rule for routing 11 p.m. alarms, Ping’s million-dollar broadcast-storm war story, and what owners can actually do at the construction-spec level to stop the bleeding.
In this episode, we’re tackling:
- What “IT/OT convergence” actually means: Why Jim and Doug argue it’s all IT anyway — and where that framing helps and where the “OT” label still gets in the way.
- The day-one vocabulary gotchas: Why “I have eighteen routers” and “I still need this Windows XP machine” derail kickoff meetings, and how a translator in the room saves the project.
- The million-dollar broadcast storm: Ping’s case study of an IT-led OT network rebuild that made the BAS worse — because the highway got bigger but the exit didn’t.
- Standards as the stop-the-bleeding moment: Why most of the friction lives in the construction phase, and how owners can use submittal reviews to reject controllers (and unmanaged switches hiding inside switchgear) that fail security review.
- Where to actually start: Doug’s argument for pizza and hackathons, Jim’s argument for leadership and curiosity, and Ping’s argument for calling your neighbor.
Watch the full episode and subscribe here: https://howtohandshaketheotnetworkingseries.riverside.com/
What topics, debates, or technical deep-dives do you think this show needs to cover? Send us a message on LinkedIn, Reddit, or Bluesky, or email us at marketing[at]optigo.net.
Related links:
Transcript:
Ryan LaFlamme: On this week’s show, Jim Meacham from Altura Associates and Doug Plumley from Dartmouth College are here to talk about what actually happens when IT and OT teams are told they have to work together. Where do they misunderstand each other from day one? And when IT security and OT security both want different things, how do you write a policy that both sides can actually live with? I’m Ryan LaFlamme, and this is How to Handshake, Episode Four.
Ryan LaFlamme: Thank you, Jim, and thank you, Doug, for joining us today. We’re talking OT and IT convergence here. I’d like to start by going around the room. Let us know who you are and what you do. Jim, we’ll start with you.
Jim Meacham: Great to be here. Thanks, Ryan. Jim Meacham — I’m one of the founding principals of Altura. My background is in building automation and controls. I started in industrial automation many years ago, but I’ve been in the building space for about 23 years now, doing a lot of energy efficiency and commissioning work, which got us deep into the building automation space. So I’ve spent a lot of time thinking about these things. Excited to be part of the conversation.
Ryan LaFlamme: And Doug, nice to see you again.
Doug Plumley: Nice to see you. Doug Plumley from Dartmouth College. I’m a software architect on the Campus Services Technology Services team. It’s quite a mouthful. We’re an embedded IT team in our Campus Services division. Campus Services is comprised of dining, facilities like a ski way — really runs the gamut, including daycare and childcare. We run between seventy and eighty different applications for those various groups. A large part of that is our integrated automation program: building automation, utilities, plants, and so on. We typically run the IT infrastructure for that, the application layer, and increasingly we’ve gotten more into the networking side of it with things like BACnet, really helping architect that to scale on an enterprise network like ours.
Ryan LaFlamme: And Ping, once again.
Ping Yao: Hello, everyone. Pleasure to be here. This topic is near and dear to me — it’s basically how I started with Optigo Networks.
Ryan LaFlamme: Let’s dive in. For listeners who have seen terms like “IT/OT convergence” in headlines but haven’t had the time to dig into what that actually means — you two are great representatives — what is it? What are people actually describing in a day-to-day building?
Jim Meacham: I’ll jump in. It’s been a fun ride over the last twenty years to think about this. My personal opinion is that it’s all IT. “OT” sometimes is a term that can get in the way of the coordination that needs to happen. It really is about getting information across your networks. In the classical sense, OT is operations technology — your control systems, anything related to the operation of the facility. But there’s a lot of gray area: what is OT, and who owns it? This conversation is meaningful in that regard — how do we get these groups to talk better and interface in a way that actually accomplishes the outcome. At the end of the day, it’s all IT, because it’s all going to end up on that network. We don’t want stranded networks that aren’t managed with a high degree of cybersecurity. That’s the old-school stranded facility OT network — managed by operating engineers, with all kinds of cyber risk they owned. Let’s get that to the people who can actually manage it.
Doug Plumley: I’d echo that and say yes — the key piece is, it’s technology. We’ve often talked about OT and IT like they’re different things, but to Jim’s point, they’ve been computers for a very long time. Pneumatics have been on their way out for a while. When we say DDC, a lot of these things are commodity microprocessors and microcontrollers. Now they actually have CPUs the layman like us can recognize: ARM, Intel, AMD. So they’ve ceased to be purely OT — they’ve been computers for a very long time, and the reality check is they run code just like any other computer. The difference is really the means in which that code is implemented on them. The convergence we’re talking about is also predominantly the network technologies being used. IP won. IP won quite a while ago. This industry is now catching up to that fact. And the big challenge with treating things like OT, like they’re something special, isn’t that you get magical uptime — in a lot of ways you’re actually getting more downtime. IT, with roles like SRE — site reliability engineer — has been measuring things to five nines of uptime for years. We need to take that mentality and that engineering skill set and apply it to this industry.
Ping Yao: To add to everything Jim and Doug just said: if I can borrow from the cybersecurity world, we think of cybersecurity as three things — the technology (the product you can buy and install), the process that governs it, and the people. I’d wrap a fourth layer around that: the business and its objectives. One of the biggest differences happening now for IT/OT convergence is that not long ago, OT and IT people were very different. There was a department for OT, with its own process, procedures, documents, and budget. Now we’re seeing a lot of gray area. We’re seeing people like Doug, who straddle both. We’re seeing building services people who have a background in IT now straddling into the building technology side. We’re seeing budget pulled from traditional IT to supplement OT contracts. Not long ago, when you installed a BAS, IT had nothing to do with it — it pulled its own wire, its own conduit, had its own people. Now we say: you need a port, you need a process for upgrades, you need cybersecurity firewalls. The real question is, are we going to get to full convergence the way telephony did in the nineties? There’s no more “department of telephony” — it’s just part of IT. We still today have building automation as a separate group with some budget. Will we see, in the next ten, twenty, fifty years, that it just becomes part of one global technology group?
Jim Meacham: Interesting question. The services IT provides to support any function of a business will be the same for operations. There’s still going to be an operations group that manages its specific applications, like other business units that manage applications specific to what they do — but they have long-standing relationships with IT for cloud services, physical network services, laptops, everything else. Those relationships are decades old in most places. They’re relatively new for building automation, which is behind on a lot of things — that’s a whole separate podcast. But we’re catching up. So I believe we’ll always have building automation folks who are owners of those applications, but we’re going to have the services provided by IT that monitor and keep everything up, do backups, and do the things you’d expect from any business unit.
Ryan LaFlamme: For all the convergence going on, I think for most organizations we still have OT under our facilities people and IT as its own monolith. So IT and OT teams sit down at first project meetings — what are the misunderstandings that come up most often? Doug, I want to look at you on this one, because of the work you’ve done at Dartmouth and what I’d call a pretty novel approach to addressing those misunderstandings. Walk us through the solution you’ve come up with and the lessons learned.
Doug Plumley: I think it helps to have at least one representative in that first meeting who can bridge the gap. More often than not, people want to do a good job — they mean well. There are things lost in translation, issues they know of with certain network architectures that they see as a bug that another group might see as a feature. It’s hard to get them together and talk about it without really showing each other how the magic works on either side.
One of the first gotchas is definitely the network side. A typical network engineer is going to find protocols like BACnet, topologies like MS/TP, or daisy chains generally to be very foreign. BBMDs broadcasting across broadcast domains — that’s a no-no. They teach you that in setting up subnets in the first place. So when you reframe it — “Hey, network engineer, BACnet isn’t just a protocol for transporting data, it’s actually an application layer in itself. We have products built around this protocol that enable different vendors to pull in each other’s information. To enable that, we have to enable broadcast across these domains so we can discover each other’s things. This is very similar to how mDNS works” — suddenly the network engineer goes, “Oh, okay, I see what you’re trying to do. It’s a weird way of doing it, but let’s figure out how to make it work.”
Ping Yao: A good example, Doug — to add to that. A big gotcha is when a building automation guy or lady walks in and says, “Oh, I have eighteen routers.” Your IT engineer is going to put a big kibosh on that very quickly, not realizing that in the world of BACnet, a router is not an IP router. It’s a nomenclature thing — a big no-no. Having someone who can bridge the gap and say, “Whoa, hold on. This conversation about routers — it’s really a gateway. It’s a translation device” — that’s huge.
Doug Plumley: The other gotcha I’ve seen a lot is when having a Windows XP machine is a feature — it’s a tool. “I have to have this in order to service this really old thing.” And the IT professional is like, “Oh gosh, this is a security nightmare, we can’t let it on the network.” My approach is: okay, well, don’t use the Windows XP machine as your personal machine. Use it as a tool. It doesn’t need to be on the network anymore. Problem solved. But it really comes down to getting people to genuinely sit down. That’s the first step. If you’re doing that, you’re already doing more than some teams are. We hear a lot of stories where people just don’t talk to each other, and that’s the worst thing you can do. Get in the same room, talk it out, whiteboard it, create visuals so people can extract meaning from the words instead of just talking past each other. That’s been Dartmouth’s approach: get smart people in a room, mash up ideas, talk it out. Campus Services has really focused on the culture we’re building. Through that process, we’ve been able to build an integrated automation program and team — a working group, a steering committee, getting all those people in one room working through our problems. That’s how you really solve these tricky situations, and that’s how you scale.
Ryan LaFlamme: Jim, I see you nodding.
Jim Meacham: Yes. I believe it’s mostly a vernacular problem. People don’t know how to speak each other’s vernacular to actually communicate the situation. There’s really not much resistance anymore. Maybe five, six, seven years ago there was still some resistance from both sides of the coin even to engaging. Now it’s taken as, “Yeah, we’ve got to do it. Maybe I don’t understand it, but I understand we have to.” So let’s start from that perspective.
Ryan LaFlamme: I think we probably all agree that that’s the first principle at this point — we have to. This convergence isn’t something we can stave off for another ten or twenty years just because we don’t feel like doing it.
Ping Yao: I’ll add to this. In building automation, in OT, it’s very rare that you don’t have baggage. That Windows XP comment Doug just made — that’s the reality. In the majority of cases, we’re working with buildings and systems that have been around forty or fifty years. We have to maintain these systems for a long time. These chiller plants, these power plants, were built way before anyone moved into the buildings — there were probably eighteen tenants before you. There’s baggage we have to deal with. You can’t walk in and say, “What’s this serial connection? Rip it out, we don’t want it. What do you mean you have a daisy chain? What do you mean you need a Windows XP?” We need that level of understanding that this industry has been around for a long time and is going to continue to be here for a long time.
Jim Meacham: The few cases I’m still seeing friction today are when one group is worried about the perception they’re creating. We’ve got to be honest about what we want. Whereas those issues — “my Windows XP machine, my isolated network” — used to be something OT professionals protected, I’m now seeing that shift. They’re saying, “I don’t want to hold the risk of this. I want IT professionals who understand to come help me address it. And by the way, maybe I can get funding to do things that reduce risk for the organization that I haven’t been able to advocate for.” Used to be everybody would say, “I don’t care about that Windows XP machine on some isolated network.” But if you get IT involved, I guarantee they’re going to be like, “In here. How do we get rid of that? How do we elevate this as a critical security risk? Because we just did our audit, and we’re getting those out of there.” We have a lot of clients now where the upgrade work everyone knew they wanted to happen from the facilities side is being driven by cyber and IT, because they’re saying, “We’re no longer going to tolerate this isolated risk.”
Ryan LaFlamme: Let’s talk about roles. Say a controller drops off the network at 11 p.m. on a Saturday night. In this converged environment, who’s getting the first call? Is it the IT team? PagerDuty kicking off? A controls contractor? A facilities person on call? How do we draw those boundary lines so it doesn’t turn into a bunch of finger-pointing?
Jim Meacham: I’ve got a perspective on this. For OT, I don’t believe you should ever have a network dependency. If a controller goes offline for an air handler or a VAV, or something feeding information into the system even across a network, it’s got to be able to still operate without that dependency. There are a whole bunch of reasons for that — but that’s the nature of controls. Good controls design will always make sure of that. So the question really becomes: does anybody need to know at 11 p.m., or is it okay? There’s a difference between “the controller itself stopped working” — okay, we might actually have a physical problem — versus “I can’t see the information from that controller because of a network issue.” It’s the facilities folks who are going to notice first. It should be that everything is still operating, and what they’re noticing is a low-priority alarm that a device is offline, but I’m certain it’s still working because that’s been tested. Now, it’s interesting when you look at things like clinical operations: what happens when my MRI goes offline? That’s two different business units. You’re going to handle those things differently in an IT convergence.
Ryan LaFlamme: These situations do arise. So there should be a plan in place?
Doug Plumley: Yeah. A general statement, but how I like to approach this is with a phrase: the pain index. If you’re not familiar with it, the idea is that those who are most responsible for fixing the problem should be closest to the pain. Let’s say a controller is periodically going offline and coming back online, but you’re kicking the notification out to the IT team, who can’t actually deal with it — it’s some physical-layer issue with the piece of hardware itself. Now you’re in this uncomfortable position where the IT people are getting annoyed, and maybe the OT people haven’t responded in a timely fashion according to the IT people. You want to put the people who can solve the problem closest to the alarms that are notifying them.
Ryan LaFlamme: Without naming names, walk us through an integration where things didn’t work — where the teams weren’t talking, weren’t agreeing, or it was a vocabulary issue. What was the root cause, and what was the eventual solution?
Doug Plumley: I have a lot of battle scars from failed integrations. When I first started getting involved on the OT side with BACnet — Ping was actually really helpful in this, by the way; I think he taught me a lot of what I know about BACnet — we had a major controls vendor having trouble integrating with our lighting system. Pretty common: Wi-Fi hub, gateway-style lighting system. I really got my feet wet on BACnet troubleshooting. I’ve done PCAP captures, I’ve used Wireshark — what’s the problem? I’ll figure it out. We did eventually figure it out, and it came down to Wireshark captures. This integration is one of the reasons I’ve really pushed internally — and have been vocal in the industry — about running OT networks the way we do IT networks. I am kind of the anti-daisy-chain, anti-ring person, unless you have a really good reason. The reason I was able to troubleshoot that effectively is because I had the ability to run simultaneous network traffic captures on both nodes that were impacted. At the end of the day, what I like to do is point the finger in the right direction. Not this, not this — it’s your fault, here’s why, and you’re going to fix it. That’s what it means to get down to a level of specificity where there’s no BS. We know what the problem is. We’re willing to help you figure it out. Let’s just get it done.
Ping Yao: I have a good story too — won’t name names. Very large organization, fairly deep pockets. Their building automation system wasn’t performing — graphics were very slow to load — and it had gotten to a pain threshold. They run fairly critical services. I’m not sure how the decision was made, but IT got brought in. They dropped the hammer. They spent close to a million dollars to rip out the entire — they had an isolated OT network. It was still operated by IT, but it was an OT network, and in their case they really needed that separation. They ripped everything out, put in new cable, new switches — beautiful, top-of-the-line stuff. Powered the whole thing up, and the BAS system got worse. Why? Because basically they made the highway bigger but didn’t make the exit any bigger. It just flooded into the BACnet routers, which actually choked more than before. The intention was right, but the understanding wasn’t there. The pain threshold was just so high — “let’s just do it.” That’s when we got brought in and found what was causing it. The broadcast storm was so bad that, in the old network, the broadcasting was dampened by a slower network. By making the network faster, they actually made it worse.
Jim Meacham: One I’ll bring in is from a new construction project. We do a lot of new construction work, and that takes a lot of planning, because you’re about to bring on a lot of devices — lots of opportunity to get it right. In this particular project, there was a lot of good planning, good coordination, collaboration between design and the facility-related systems and OT folks. Security reviews of hardware and software — all best practices for bringing devices onto a converged network. Then one of the pieces of hardware — a large piece of switchgear — showed up to the site. It was going to have a network drop. What was discovered: it had its own little unmanaged switch inside of it. That’s a major no-no on a HIPAA-compliant network. They ended up having to roll back and do a serial connection to that device, because that was the only way to keep the network sanitized. The lesson learned: when you’re doing submittal reviews of all this equipment showing up during construction projects, IT has to do really deep reviews of what’s actually going to be installed for anything with a network port on it. We’ve since put together a much better process. This could be hundreds or thousands of pieces of equipment, so it’s a lot of work, but it has to happen. We’ve caught a lot of things — metering cabinets where it’s like, “Oh yeah, we always put a little switch in here.” No switch. We’ll handle it. We’re going to home-run everything. We don’t want your switch — you can talk across our switch.
Ryan LaFlamme: Security policy seems to be one of the biggest head-butt points between IT and OT. The classic IT priority order is confidentiality, integrity, availability — keeping data from leaking is usually most important. In OT, we’re looking at almost the opposite, with availability being the most important. We need those systems to keep running, especially when we’re talking about occupancy sensors or elevator banks. How do teams actually write one policy that both sides can live with when the priority orders are seemingly conflicting?
Ping Yao: Loaded question. And I’ll call myself a non-expert here. I know enough to be dangerous, but in our community there are some amazing resources — over the last fifteen, twenty years there have been quite a few cybersecurity experts dedicating their time to our industry. They’d be the ones to chime in. But the number one thing is to define the business priorities — just like you highlighted. Writing a policy without understanding what you’re trying to achieve, locking everything down so you can’t use it — that might not be an option. Saying every controller needs to use 802.1X might not be available, because now you’ve locked yourself down to a vendor you may or may not want to work with. So business priorities first. Then writing those policies — and the difficult thing is enforcing the policies, doing the tabletop exercises to make sure they’re actually followed. But it also needs a really careful mitigation plan, because you can’t get to where you want to get immediately. It may take multiple years. These OT systems have a significantly longer lifecycle than IT systems. Go in understanding the business priorities, understanding it’s going to take time, and take it one step at a time. You should probably never get to the end — just continuously improve.
Ryan LaFlamme: We could do a whole session on this — and we probably will. Let me expand and bring in the next question, which is closely related: patching, remote access, change management. These are all areas where there’s going to be a lot of clashing. Where are the compromises? How do we come to a place where everybody can at least live with it?
Doug Plumley: I think we do have some growing up to do on the protocol side. BACnet/SC has been slow to be adopted by the OEMs, to be totally frank. I sometimes wonder if it’s too little, too late, because you see some vendors going in different directions with their own proprietary protocol running over TLS. Let’s be honest — TLS encryption in transit has been around a very long time. It’s a solved problem, and it is one of the biggest challenges I see with protocols like BACnet/IP and Modbus. That needs to be solved quickly at an industry level. We need to make sure we have interoperability with BACnet/SC — that’s step number one. We really need to nail authentication and authorization problems as well, which I believe is coming in future revisions of BACnet/SC. This industry has missed a lot of opportunities. If you look at what’s being done with containerization and templatization in IT — Ansible, Terraform — IT infrastructure has become commoditized to the point where I can write it once and redeploy it many times very quickly. In the OT world, controllers, configurations, the servers we set up are very precious to us. If something goes wrong, it might take days or weeks to stand them back up. From a cybersecurity perspective, that puts us in a really bad position, because when something goes wrong we don’t have an opportunity to just rebuild it from scratch and see if that fixes the problem. We need to adopt more patterns and practices from the IT side to solve some of that.
Jim Meacham: That speaks to collaboration and communication. If the IT and facilities teams — I try not to use the word OT — are working together to address the needs, define availability, define requirements and expectations and escalations, then it will be known, and you’ll be able to work through problems. We’ve got lots of examples where growing pains have to happen to get there. We have centrally managed supervisory servers across national portfolios that are getting automatically patched and accidentally pushed applications they’re not supposed to get — a certain application that conflicts with the supervisory application. Those challenges have been had by other systems for years. You always have a non-production environment, and you test these things. That workflow exists; it’s just new to building automation. So we run into a lot of problems where we didn’t have good coordination. It really just comes down to sitting down, writing down expectations, who’s doing what, and working it out.
Ryan LaFlamme: Perfect segue. Something Ping wrote about for Optigo is the concept of collaborative training — putting the people responsible for OT, your systems integrators, and the IT team in the same room to learn those tools and workflows together, rather than training the siloed groups separately. Jim and Doug, have you seen something like that where you work? And for listeners, what would be one concrete move that an IT leader or a facilities/OT manager could make right now to start closing those gaps?
Jim Meacham: The answer to the first part: no, I don’t think I have really seen that. It tends to be that IT folks and OT folks are training each other, but they’re not being trained together. There’s a nuance there, and it can be important. What’s been interesting to watch for my team — they’re system integrators — the skill set needed to succeed has evolved. They all have to be good network engineers now. They have to really understand what’s happening on the networks, or they can’t be successful. They can’t wait and not understand the flows of information, how protocols and everything interact — it’s a prerequisite now from a systems integration perspective. That’s probably slower to be adopted on the user side, with the folks who are operators expected to have a deeper knowledge of networks. In terms of what folks can do now: just make sure there’s clear commitment to the future state. The future state is, we expect this outcome of how devices are going to be on our network, and everyone is responsible for working together to achieve it. Having a very clear architectural mandate — everybody has to be aware of it, and that becomes the basis by which people can collaborate, train, and coordinate.
Ping Yao: I love your passion and optimism. But one of the key difficulties in our industry is that so many of our systems are governed by the construction phase of a site and the business incentive of those delivering them. Many don’t have a long-term incentive on the quality of the system. It’s very much a bid-spec, lowest-bidder-wins, get to the finish line as quickly as you can, hand off the keys, and get out. If the owner has a mandate and standards and specifications, that gets driven into the construction project. A lot of the work we do — you’ve got to do the validation, review the design, review the submittal, make sure that’s what’s installed in the field and that’s how it all comes together. Commissioning has been around a long time, from a mechanical and lighting-control-system perspective. We have to commission the network components of everything across the entire network, including OT. You can dictate that during construction. And you better dictate that.
Jim Meacham: We’ve had controllers get rejected. “We can’t use this controller — it went up for security review, and unless they address these issues, we’re not letting it on our network. Find a new controller.” That has happened. And that’s great — it’s a win.
Ping Yao: From my perspective, like — pain in the ass. Sorry, guys.
Jim Meacham: It’s a kick in the butt to the building automation industry: we’re not going to let you get away with this crap anymore. It starts with the owner saying, “We own it. We’re not going to let our vendors drive it anymore.”
Ryan LaFlamme: I’d be remiss if I didn’t shout out Episode Two, where we discussed life after commissioning, and Episode Three, where we did a deep dive with Nate Benes about BACnet/SC. It’s great that all these topics are coming up — they’re very connected.
Doug Plumley: If you started with the hard things — the capital projects, the designs, the standards — in some ways that is harder, because there’s real money involved. Things can go sideways quickly with a lot of stakeholders, and a lot of people you have to convince without a lot of evidence. One thing I’ve liked is really focusing on the operations of existing building stock. How do we take the problem the OT team is seeing, or the IT team is seeing, sit down, and solve it from the perspective of building trust? You break things down into small everyday problems, things people see as very painful, and solve them. For example, certificates. This industry is very scared of certificates. But if you grab an IT person, they’ve probably dealt with certificates at some point, and they’d be delighted to tell you how PKI works — they’d probably talk your ear off. So maybe you take a problem the OT person is seeing — they need a cert for a specific Fox setup — sit down with them, help them. Now you’ve solved the problem for that person. You’ve built a little bit of trust. And now you can say, “All right, we see this problem X, Y, Z, and we could prevent it from happening again by putting this into our design guidelines.” That feedback loop is really powerful. It builds trust on your team, and you can still get that feedback back into your construction guidelines, depending on what it is.
Jim Meacham: I’ll echo that. You’ve got to get the stuff into the standards, because that’s the stop-the-bleeding moment. If you don’t do that, you’re going to keep having operational issues to solve.
Ryan LaFlamme: Last question, and I feel like we’ve touched on a lot of this — this is really bringing it all back together. If you two were advising a facilities director or an IT director on where to start working together on a new relationship, what would you tell them about how to structure it? Are we talking a full merger, a joint working group with clear boundaries — or two groups fully separate, coordinating through liaisons?
Doug Plumley: All right, so I’m the omnipresent IT director with unlimited budget, dealing with bad culture issues and teams that are fighting with each other. Never happens, right? In all seriousness, I’m really food-motivated. If you sat me down in a room with another person and said, “Hey, here’s lunch. Here’s an interesting problem Mark over here was telling me about that I feel like you’ve run into before — why don’t you guys eat pizza and talk about it,” I genuinely feel like you’d have some decent outcomes. The pre-meeting I’d have before that is, if you have some personalities that need to be managed, sometimes people do need a little bit of training on how to talk to each other. I feel like I’ve learned over my IT career how to talk to people. I was a really hot-headed, “I’m always right, we should do it my way” type of person. I’ve learned to change how I’m communicating — not to go for the immediate win of the battle, but to think long-term, what’s the war I’m trying to fight, what’s the objective. That’s really changed how I talk to people. Teaching people how to talk to each other is really helpful. Putting them in a room, doing hackathons — we really like doing that. Take a hard problem, put people in a room, do smart things, it’s fun. When you take the pressure off — don’t come into the meeting with a problem to solve, let the individuals or the group organically come up with it — now it’s a shared idea, a shared problem to solve. They get together, have some fun, and they build a relationship.
Jim Meacham: What I’ll say is probably similar. It takes leadership and clear vision — that’s where it starts, and that can lead to the how, based on teams and personalities. You have to have leadership and you have to have curiosity. The curiosity is, how are things working for you? How can we learn from each other? What’s working and not working in your world? And then the safety bit — you’ve got to be able to air out the laundry. Everybody’s got things from years of whatever happened in the past. It’s nobody’s fault that there’s that Windows server, that there are network vulnerabilities on the OT side. It’s not any one person’s fault. Maybe it’s a vendor’s fault — fine, we can throw them under the bus. If you really want to get to what structure should look like — should we merge? — I don’t think you start there. The structure needed to support all this is going to come later, after you have some engagement to say what’s really needed. The size of your OT system matters. I’ve seen very successful groups that are still separate. I’ve also seen really good solutions where there are dedicated IT professionals within those organizations leading those efforts, because of the scale of the system and the speeds and things needed. It depends on the organization, the goals, and the complexity of the systems you’re dealing with.
Ryan LaFlamme: So the core here is to start with the right mindset and the acceptance that this is going to happen. The headspace of “we have to work together, we’re going to work together, and I want this to work.” Your structures can almost grow organically, as long as you maintain that willingness.
Ping Yao: I want to add one thing in terms of first step. My big recommendation — sometimes when I meet people just starting this journey — get out there. Go to conferences. We unfortunately don’t have a lot of conferences in our community where you can connect with people like Doug and Jim, but there are some. Those who are getting out are already hungry and curious to talk about how IT and OT, IT and facilities, work together. Call your neighbor. If you’re a facility manager, call your neighbor — whoever it is. If you’re a university, call the university next door. If you’re a building owner, call another building owner. Ask them what they’re doing. You might find they’re not doing any more than you. If they are, learn from them. Get out there. Talk to people. You’re going to come back energized — you’ll have ideas, some good, some not. That’s how I’d say first step. If you want a list of people to reach out to, get on LinkedIn, connect with us, connect with Doug or Jim. We all want to help each other grow. It’s going to make us better. This community is a little too inward — we look to ourselves within our organization and not outward enough.
Ryan LaFlamme: On that note, Jim, where can people find you?
Jim Meacham: You can reach out to me on LinkedIn for sure. I’m not an avid social media person — just my personality. You can also go to our website, AlturaAssociates.com. We’re helping a lot of large organizations figure out how to navigate these questions and standards. Enterprise thinking is a big part of what we’re bringing to this from an OT perspective: how do I stop treating this as a project-by-project solution and create a truly enterprise standard that allows me to treat it as — and get the value of — an enterprise system. I’d love to keep chatting about that.
Ryan LaFlamme: And Doug, how can people find you?
Doug Plumley: I try to put myself out there, but same on the social media side — I’m only on LinkedIn, and happy to chat with people there. If you put yourself out there — industry trade shows, online discussions, listserv group lists — I’m often on them and willing to exchange ideas. I also try to put some of my ideas out as little code; I share what I’ve learned in places like GitHub as well.
Ryan LaFlamme: Buy pizza for Doug.
Doug Plumley: Yes.
Ryan LaFlamme: I will join you gentlemen any time for pizza — fully down with that. With that, thank you so much for joining us. We barely scratched the surface, but I love that we ended on the people side. So much of this is people-driven, and it’s about having the right attitudes to start with. Have a great one, everybody.
Jim Meacham: Thank you.
Doug Plumley: Thanks, Ryan. See you next week.
