PLC and Automation Q&A: Engineer Burnout, IT/OT Skill Gaps, and the 2026 Hiring Reality

How's it going, everyone? Welcome to the next episode in which we're going to be answering some of your top questions in the industrial and manufacturing space. If you have any feedback on the current format, if you have other mediums where maybe interesting questions have been asked, don't hesitate to reach out.

It's easy to leave me a comment on YouTube and/or reach me on LinkedIn, which should also be in the description for however you're consuming this video and/or audio format. Without any further delay, let's get into the first question that we have for you today, and that's going to be from the user RangerNoob5346.

And he says that, "One thing that surprised me about modern automation projects, I used to think most automation complexity came from PLC logic itself. But after reading more about larger industrial systems, it honestly seems like the bigger challenge now is managing communication between everything around PLCs, HMIs, edge devices, databases, remote access, analytics, etc.

At some point, it almost starts looking closer to software infrastructure than traditional isolated control systems. Not saying that's good or bad, just interesting to see how much the field seems to have been evolving." So I have a couple of thoughts on the side. So I have been in the industry for over a decade now.

I have done everything from PLC and very traditional controls to HMI, SCADA development, MES, larger data projects that touched ERP systems. So I understand what he's describing extremely well. That being said, it really depends on the company as well as the role that they are hiring for. But I would tend to agree that the industry is shifting a little bit, and more and more I would say traditional IT or software-based responsibility is now falling on control systems engineers.

So number one, first of all, it depends on how well the plant is running, but also how many different projects there are at the plant of pure control systems nature. So in larger facilities, you often have dedicated control systems engineers. All they do is, number one, they deploy new projects, they troubleshoot existing systems, and they make sure that production is running.

They simply do not have the time to start learning communication and protocols outside of traditional operational technology or OT, so they never touch switches, they never necessarily touch hardware that is above that layer, and they will never necessarily make changes to anything outside of, let's say, a FactoryTalk View SE, maybe a Win- CC on the Siemens side or perhaps Ignition on the SCADA side.

They will not necessarily work with data and software. So again, it depends on the size of the facility. Generally speaking, right now, we're in this, I would say, transitional period where everyone's trying to figure out how can we leverage AI, right? And obviously, I talk to people of, I would say, different opinions on AI.

Some of them will say that AI will revolutionize the world, and some of them discredit or dismiss AI completely. The reality is probably the answer lies somewhere in the middle where exactly is very difficult for anyone to say. But what I'm trying to say with that statement is that on the control system side, more and more work needs to or is or has to do with the data that's coming out of the plant floor that someone wants to analyze with AI, that someone wants to leverage to deploy more infrastructure.

So to that point, yes, absolutely. Control systems engineers are being pulled into conversations that previously were not happening because there was not as much emphasis on getting that data into higher level systems so that they could provide the ROI for the business.

The second question I actually read this morning while drinking my coffee. It is very interesting and very, I would say, revealing of our industry if you're an outsider. So the question comes from a username called DesperatePlenty5752. He says, "Honestly, are people generally miserable in this field? I'm on my second job working for a major foodstuff company, and I'm looking to leave or pivot at this point.

Zero mentorship, very little documentation. My coworkers are constantly complaining about management, and I'm starting to spend most days just working on HMIs or reading manuals. My motivation is starting to run thin because my office is starting to become hostile towards me because of mistakes I'm making, and plant operators are complaining about the engineers and want to get us punished because we keep changing the program.

I'm not learning much, and the environment smells like rotten milk constantly. My first job was at an OEM with an insane manager who'd get into yelling matches with my coworkers, but at least there was some friendliness among us. I'm really thinking of just leaving the field entirely. I've lost all interest in the work.

I'm tired of self-starting for what exactly? Same pay, no recognition, leverage for other jobs where, yes, the pay will, will be more, but I'll have longer hours, more fingers pointed at me and impossible demands for production or clients. I don't think I've met a single happy controls guy in my two point five years working.

Is there a silver lining?" And this is the unfortunate reality that a lot of younger engineers are being put into, and then they switch careers entirely. They go somewhere else for, again, better pay, better recognition, whatever it is that they're looking for, better projects, better teams. And so I honestly resonate with some of these comments.

I have not seen it to the point where I was dissatisfied per se with the team. My experience has been a little bit different, right? So I can elaborate on that just a little bit. So when I first joined the first end user for whom I've been working for multiple years since, and again, you can see my profile.

This is open information. I joined Procter & Gamble back in two thousand and fourteen. I very quickly learned that enthusiasm is extremely important for our job. It is very easy to get discouraged by the environment, the fact that, electrical systems, you need to be coming in on sometimes the weekends, during the holidays.

I spent multiple Christmas times and New Years because that's simply when shutdown happens, right? And you need to perform electrical work and some upgrades for the facility. And if you start working with people who are miserable, who are considerably dissatisfied with the work that they're doing, who don't-- who have lost the passion, right?

And it's not to blame necessarily the people, but it becomes extremely draining on you as well. So you're already discouraged by maybe the challenges of the field, maybe by the facility, right? So it's not usually the nicest environment. So let's be honest. If you work for a pure software company and you're working remotely, or you're working in a very nice office with a fully paid cafeteria, with fully paid gym memberships, and then you're comparing this to a plant environment, which again, some are better than others, but ultimately it is different.

The work is, I would say, different. And so there is something to be said about our environments not always being as good as in the software industry. And so if you're already comparing yourself on that front, and then you come in and you have coworkers that are constantly complaining, you want to push the company forward, you want to work on interesting projects, but every time it's being shut down by management, this is what results in high turnover for multiple sites.

And what is the managerial solution to this? Obviously, to some extent, you need to be getting rid of the bad apples. You need to let people retire. You need to let people go somewhere else if they are, as this person points out, making the workplace impossible, right? And I've seen these plants where you show up and you ask them the question, "What happened to the previous person that was in the seat?"

They left after eight months because they were overwhelmed by the project. There's zero training. The team is super toxic. What happened to the person before them? They spent a year in the role. They understood what it took. They were called in the evenings, in night shifts to troubleshoot every single time.

They had zero support. They got the finger pointed at them, and they also quit. And so you start to recognize a pattern that is not with the person, but rather with the company. So when you're evaluating I believe that this is the best advice I can give this person is when you're evaluating your next role, make sure to ask those questions.

Why did the previous person leave? Why are you hiring for this role? What kind of training programs and support are you going to provide to help me get up to speed? The role of the manager or the director that's supervising this person is also to an extent to shield them from quote unquote blaming, finger pointing, and whatever else might come at this point, at least early in their career, from the clients and or operations.

So this is, I wouldn't say that this is a normal situation. I would agree that many have lived through this situation. So there's definitely jobs out there that will put you in front of a very miserable team. So make sure that when you do make the switch into a new company, because having made two switches in two and a half years is still relatively short.

I believe that the sweet spot to making the switch is after three years, maybe five years, because that's when you've actually learned the business, you've provided the value, and ultimately you are ready to either be promoted, go somewhere else, maybe gain some different experience. But if you've made the switch after one year, it won't look that good on your resume.

Hi, my name is Vladimir Romanov. I am the founder of Joltech as well as Solis PLC. With a background in electrical engineering and an MBA, and over a decade of experience leading projects in manufacturing and industrial automation, I help engineers, managers, and manufacturers make smarter technical and business decisions, modernize their operations, and build stronger careers.

If you're serious about manufacturing, automation, and staying ahead in the industry, subscribe and join the community

The next question we're tackling is a bit of a technical one. So let's pull up the screen, and we're going to do our best to figure out what's going on. So this is posted by the username lostcheek6610. Why bitwise and? And he says-- So we have a screenshot of RSLogix or Studio 5000. "Hi, guys. What is the purpose of using this bitwise and?

I have read the manual and don't get it. Thank you." Edit: Thanks for the replies, guys. I understand this instruction now. Can anyone explain why they are using an array and even need to isolate bits from the array tags?" So I have countless tutorials on bitwise operations on different instructions inside of RSLogix and Studio 5000, including many countless ones inside of Solace PLC Training.

So I do invite you to check those out. What I can immediately say is they're applying a mask to the inputs, right? So we have the local to input data ten, and we have the local to input data eleven. Again, without being able to cross-reference, it is impossible to understand what kind of data this actually is.

This is obviously an analog signal, and it says that it's an input and output collision left, collision right. So to me, at very first glance, this seems to be a double integer, meaning that it has thirty-two bits of information that is being masked on the left and right side. So we're basically converting these double integers into integers, right?

And the reason for that is gonna be based on the documentation of these devices. In certain cases, the data is only contained in the first sixteen bits of an instrument. The rest sixteen bits are either out of bounds or out of range, or they're going to be used for some other information. So to truncate them with this fashion would actually extract the data that you don't have or you're not able to manipulate if you're going to take the entire double integer.

The second question that he's asking is: Can anyone explain why they are using an array and even need to isolate bits from the array tags? So the arrays that I'm assuming he's referring to is this local to input data ten and local to input data eleven. This is standard practice for your analog cards.

So we're simply looking at the register ten or input ten, again, depending on how it has been mapped, and we're looking at input eleven, which has been- aliased to this IO tunnel X collision right and IO tunnel X collision left. So we are basically aliasing the analog card input into a PLC-based tag of a different name, but it is by default going to be the specified array tag based on when you add this analog card into your IO tree.

So that's the reason why it is an array. And why do we need to isolate bits from the array tags? Again, I would assume this is some kind of an analog card, but I do not have the data sheet of the device that's tied to it. I am assuming that's the reason why we are performing this operation. Let's see what people are saying.

Bitwise unlike that will be used to mask only the data you want to keep. So 65535 will mask the first 16 bits only from the source. So exactly. So the data must be contained in the first 16 bits of the analog card. Everything else needs to be discarded. And again, there could be many reasons as to why and what is contained on the other side.

We've got an interesting post that is not necessarily a question, but it was highly upvoted inside of the community. So let's switch over, and it's posted by the name of Future Gohan Aviva Hurt Me. And we see a very interesting PLC wall in front of us. Retired development modules, networking going to the left for stuff that can handle Ethernet.

Was looking at building DIN rail mounted test units, but going to just make an I/O board to get the right side with terminals. I can wire from individual PLCs too. And as many of I have an entire wall of PLCs. It is sitting to my left-hand side in the office that I do connect to very frequently.

A lot of the PLCs have also gone into training kits. That being said, let's take a closer look. So again, I'm just going to zoom in for a moment, and we have a slick 500 chassis. We have a ControlLogix PLC. It looks like an L71 series. Again, we can zoom in as much as possible. We have an EN2BT card. EN2TR card, sorry, with the two Ethernet ports.

We have a DeviceNet card, which probably will never get used. We have a Mitsubishi PLC here, and we've got... What else do we have here? So some of these PLCs I don't even recognize. We have a GE Fanuc PLC. We have a CompactLogix. We have a Micro800 series PLC. Again, I don't know off the top of my head which form factor this is, as they do have about five or six different models.

We have an ABB PLC. We have a few MicroLogix PLCs, so I have the MicroLogix 1000, 1100 series. I believe this is 1200 and then 1400. We have a point I/O rack with all sorts of different modules, including digital inputs and outputs, some analog cards, some safety modules. So just an overall really great rack of hardware to practice on.

What I have realized with time is, number one, you do need to make the investment into some hardware in our industry. If you would like to learn to further your career. It is very difficult. Again, in most instances, you will have access to PLCs, of course, in the work environment, but it is hard to make changes.

It is hard to experiment and not because it is impossible, but simply it is too risky to make some of those changes without losing production. So what I typically prefer is if you have some capital to invest, if you're looking to, like I said, build your career, is purchase a PLC that is no longer utilized on the plant floor, usually for pennies on the dollar if you go on eBay, set up a small test environment in which you can then practice different operations, maybe go into RSLogix 500 or RSLogix and Studio 5000, create some different routines, experiment, and do your best to understand some of the nuances that might be a little bit difficult to grasp by just looking at the logic.

We've touched on this topic a little bit in the past, but this question keeps being brought up, so I'm going to switch over, and this comes from the user called ApejackEffect7965, and he's asking: Anyone weak in IT/OT? I'm fifteen years out of college and programmed many PLCs and HMI platforms. Field service for years and many commissionings across several industries.

One thing I've always felt behind on is the IT/OT side. I'm familiar with virtualized HMI server VMs on servers with client stations, PLC development software on a VM, set up OPC communications. One time I configured some kind of Eagle router thing where the PLC had a different IP range than the engineering station.

I've come across some people who seem to inherently navigate admin settings, domain controllers, firewall rules. They seem to just know what to click and configure. That's never been the case for me. Whenever I've looked into these subjects, I'm bored and don't retain much. Anyone else skating by this in field while kinda faking they know how all the networking is set up?

It also doesn't help I've never really been the one responsible for the networks outside of the plant floor control network. And this is a-- again, this is a common sentiment that f- is felt by some controls engineers, right? So as I've mentioned a little bit earlier as well as many other times, because we're in this age of uncertainty a little bit with AI, a little bit with data, everyone is looking to figure out how to tie plant floor metrics into the IT side.

And when I say everyone, I'm generalizing as well, right? There's going to be companies that, of course, are purely focused on making product. They don't want anything to do with AI on the plant floor today. I would say that the larger entities are definitely experimenting with c- what can be done. And of course, it's not just for AI purposes.

It could also be for SCADA purposes, MES. So what you'll typically find is outside of just deploying production lines, everything now needs to be tied into a network. Everything needs to be talking to either a common SCADA or MES system or otherwise. Therefore, there is this, I would say, expectation for the control systems engineers to understand a portion at least of the IT side.

However, it is not the usual case for every facility out there. I think there's still a lot of work and a lot of tasks to be done on purely the OT side. How do you learn the IT side? As he mentions, you need to have the interest or you need someone to put you in front of those projects.

If both of those are untrue, obviously there's very little incentive for you to spend a ton of time understanding servers, understanding IT infrastructure, understanding containerization, right? So again, the first steps are if you're interested to understand, you will find the information. I would argue that it is easier than ever if you wanted to go online, not only talking about LLMs and the chat GPTs, copilots, or anthropics.

If you simply go on YouTube and you search for these topics, it is very easy to find this information. Some engineers that I've talked to decided to push all the way through and make it part of their skill set and got certified perhaps on the Cisco side. So if you have listened to me in the past, I've talked very positively about the CCNA certifications that will teach you a lot of the networking side and foundation you need to know on the IT side.

I have also released countless modules on how to work with different IT topics from setting IP addresses to configuring VLANs on the Stratix side. So there's definitely an opportunity to learn and it is not for the lack of the information. Of course, if you're busy for 60 hours every single week configuring PLCs, configuring control systems level logic, then it is going to be very difficult to put any focus or emphasis on the IT side.

Does anyone else feel that networking is difficult to grasp? I believe that it's like anything else. If you put the time and the effort, you can master it. And that's pretty much all I have to say. If you have any questions on that side, don't hesitate to reach out.

The last question that we have is around the PLC job market. And so I'm going to read the question first. So this comes from the username called minutestranger8335. " I'm exploring the PLC/automation field in Germany and wanted to understand the current market situation for entry-level roles. From what I have seen on LinkedIn, many PLC and automation engineer jobs in Germany seem to have surprisingly few applicants compared to software and IT jobs.

I'm curious why that is. Is there actually a shortage of PLC and automation engineers in Germany? Is there a field considered difficult specialized so fewer people apply? What skills are most important for getting an entry-level PLC role in Germany? How is the market currently for fresh graduates or people with little experience?

What do experienced engineers think a beginner should focus on to become employable quickly? I'd really appreciate insights from people already working in industrial automation PLC in Germany. Thank you." So for some context, I have not worked in Germany. I do work on a variety of consulting projects across Europe with quite a few German entities as well.

So I am very familiar with the state of affairs as well as the manufacturing landscape specifically in Germany. So there will be a couple of factors to discuss. I've obviously not applied for entry-level PLC programming jobs in Germany, so keep all of that in mind. So the first question is: Is there actually a shortage of PLC and automation engineers in Germany?

So the short answer is yes, there is a shortage of PLC and automation engineers in Germany. However, as we've seen a lot of layoffs in the software industry, which will be an answer to one of his subsequent questions, it is not as easy to make the transi-transition from software into automation as people have been made to believe.

So there's definitely a lot of open roles. The oth-other side is, that I want to mention is a lot of factories have been closing down. So Germany has been in a quote-unquote recession, again, depending on your definition of a recession, but the market has not been great. I know that there has been a lot of pressure from the Chinese vehicle manufacturers, for example, on the automotive industry.

We've seen a lot of new robotics coming in from those markets as well. So the jobs have been challenging as well because of those closures. A lot of engineers are moving to other positions. Is there a shortage of engineers? Yes, but there's also a lot of them on the market. Is this field considered difficult specialized so fewer people apply?

Of course, the industrial automation space Once again, requires knowledge from very different disciplines. You need to understand the business. You need to understand the general state of the industry. You typically need to understand robotics. You need to understand PLCs. You now need to understand networking.

You need to have some idea of the IT side. So there's a lot of different disciplines that come into play when it comes to automation, so it is not as easy as developing websites, for example. What skills are most important for getting an entry-level PLC role in Germany? So Germany is, first of all, is going to have, as he mentions, Siemens, TIA Portal, WinCC commissioning.

Very important, right? So again, Siemens is, I would say, the dominant vendor of that space. Of course, there's going to be other OEMs that are also very strong that have a strong presence in Germany. Phoenix Contact, for example. Beckhoff has a lot of presence in Germany as well. So it depends on which role you're applying for, but also what is the end user going to be utilizing or what is their preferred platform of choice.

Similarly, visualization-wise, it could be WinCC. It could be screens built on top of Beckhoff. It could be screens built on top of Ignition at this point. German language, yes. Internships, sure. Electrical basics, yes. That's-- So a lot of those are just fundamentals. I would say if you're looking to get into automation, it's going to be your PLC programming, your HMI development.

I would argue some robotics or at least a general understanding of robotics, but ultimately fundamentals of manufacturing and electrical best practices, right? So understand the basics of drawings, panel design, understand some robotics. Again, if you're looking at entry-level jobs, you don't need to be an expert.

You just need to be able to confidently explain some of those concepts in an interview. How is the market currently for fresh graduates or people with little experience? I would argue that we are in a very difficult market based on my knowledge of what's going out in Germany simply because of, like I've mentioned, there's layoffs from other industries.

There's closures of various facilities because of the general Pressures from other areas. Germany is not doing very well financially as a country, and it's going to be hard for graduates without any experience to land jobs in the current market. What do experienced engineers think a beginner should focus on to become employable quickly?

So this is a very good question, right? Your main goal as a new graduate when you're going into interviews is to understand what they need help with. And what I mean by that is different companies are going to have different needs. Some are going to be expanding and running projects quite aggressively.

Some are going to be troubleshooting and doubling down on their current infrastructure. Others will try to optimize production lines. So ultimately, if I'm in the shoes of a senior engineer, systems architect, maybe even consultant to that extent, what am I looking for? Number one, I'm looking for someone who's going to be safe while conducting work.

So when I've interviewed engineers with little experience, I wanted to make sure that if they are, for whatever reasons, left alone on the factory plant floor, they can be trusted with the safety best practices. You never want to be in a position where you get a call where a junior guy has done something that was deemed unsafe.

Again, I'll spare you the details on the legal side. Ultimately, as someone who is trying to go home to their family safely needs to make sure that the guys who are hired are not going to be putting myself at risk and of course others. Number two is decent knowledge or the ability to figure out and stand on your two feet on your own.

And what I mean by that is, again, the expectation is not that you have all the answers, but the expectation is that you are going to put in some effort to find the answer and to then come back to the senior level engineer or architect when you need further clarification. It is not okay to be given a task and not to have done any legwork, start asking immediately for support.

If we have had a conversation and where the scope is generally understood, I expect for you to be able to find some documentation online, read through some, per-for example, code that exists in the current plant. If you are struggling to connect to certain components or retrieve certain documentation, don't hesitate to ask, but at least put in some effort to start the process as opposed to be answering or asking those questions immediately.

And this is something that I-- you would look for in an interview. What kind of projects have you done? How did the projects go? How was the teamwork What was the outcome, et cetera, et cetera. I'd really appreciate insights from people already working. So anyways, that's all I had to say. I think that there's definitely opportunities, but I would argue again, based on my external understanding, is that Germany is not doing extremely well.

So it might be difficult to find entry-level jobs in our field at this time.