No matter how much technology we have, everything is about people. Even the best tools and automation can fail if the people operating them are not good at IT. Often we buy tools to fix problems, only to find that the tool is not the solution. The problem is not with the tool: more often, there is a problem with the people who operate the tool. Many times, there is also a problem with the people who manage the people who operate the tools.
What does it look like when you are good at IT? There is time for proactive fault prevention. The causes of problems are addressed so that faults do not come back. There is a lot of consistency, both in the technology and in the people. We know what to expect from both the infrastructure and our team. Technical debt is acknowledged and paid down over time. Communication is open and direct; there are plans, and projects deliver on time(ish). We know why we sometimes must do the “wrong” thing. Most days, we leave the office on time and don’t need to worry. There are still crises and after-hours work. But the crises don’t happen every day or every week.
What about if we are not good at IT? Everything is reactive; faults drive the whole team. Faults reoccur, happening again and again. Every part of the infrastructure is unique. Changes produce unpredictable results. There are islands of knowledge; maybe only one team member knows how to start up the finance server. Projects are poorly planned and never quite complete, or they are rushed into production before they are ready. We have no idea how much technical debt there is or how to reduce it. Communication is unclear and inconsistent. Every day seems to bring a fresh crisis, and we are never sure when we will get home from a day at the office.
What difference do tools make? If you are good at IT, then you can use a variety of tools to make it easier to be good at IT. If your IT game is poor, then you can be a poor user of those same tools. As an example, we could consider a configuration management tool like Puppet, Chef, or Ansible. These tools allow you to define standards of configuration and apply those standards to groups of computers. They are enablers for consistent and repeatable configurations. With the addition of a version control system for their configuration files, they allow simple change processes. Even better, they allow easy rollback if a change has unexpected consequences. A good IT team will collaborate on the same set of configuration files. There will be a small number of configuration files, usually with a layered approach to maximize the reuse of existing configurations. A less effective IT team may have far more configuration files: perhaps several configuration files for each server. The less effective team may not have a version control system, complicating rollback of changes. They may not even share a single source of these configuration files, leading to consistency problems in server configurations when out-of-date Ansible playbooks are run. The poor IT team may have no consistent approach to using configuration management. The result is that a good IT team will be more effective with configuration management. A poor team may be less effective with the same configuration management tool.
What mindset will help a person get better at IT? A friend of mine is learning to fly. He described a training flight in which he was reacting to everything that the aircraft was doing. His reactions were great, and he got back to the airfield just fine. It would be easy to think that this stressful situation was what normal flying was like. The pilot instructor talked with him about being ahead of the aircraft: thinking about what was going to happen and being prepared; less reaction and more anticipation; knowing what is going to happen and avoiding potentially difficult situations. This is the mindset of a professional pilot, and I think it fits very well with being good at IT. Anticipate potential problems, and have plans for how you will avoid or manage problems as they come up.
I also see some parallels between the way DevOps is defined and how being good at IT works. Both are about a mindset and a way of working. Both benefit from a good set of tools, but neither happen simply because you have those tools. Both are very much about culture and leadership. I have seen an IT manager who prioritized rapid response to the most trivial request above all else. I later helped the same IT manager with a Severity 1 system failure. The failure was caused by delaying an improvement project to ensure that every printer had its toner changed. No matter how many tools we get, IT is still practiced by people.