A first day in HVAC that begins on a snow-covered roof in New Jersey with a screwdriver, a voltmeter, and a dead machine tends to leave an impression. For Aaron Hastings, that moment was more than a rough introduction to the trade. It was the beginning of a mindset that still defines his work today: step into the problem, understand what the system is really doing, and do not back away just because the conditions are difficult. That mindset carries through his appearance on It’s a Controls Problem, where he joins Charles Johnson and Matthew Vanberg to discuss a subject that reaches far beyond control logic and commissioning checklists. At its core, the episode is about how the best Controls Technicians learn to operate on both sides of the table at once.
In building automation, it is easy to define success too narrowly. We can reduce the job to point mapping, graphics, sequences, startup, and troubleshooting. Those are all necessary parts of the work, but Aaron’s message is that they are not the whole picture. The strongest technicians do more than make equipment run. They help operators trust what they are seeing. They help owners understand what they are paying for. They help decision-makers see why a control issue matters operationally and financially. In other words, they translate between field reality, building performance, and business value.
That is what makes the phrase “champion both sides of the table” so powerful. On one side are the technicians, operators, and maintenance teams who live with the system every day. On the other side are owners, managers, and financial stakeholders who need to justify investments and understand outcomes. Too often, those groups speak past each other. The field may know exactly where the pain is, but not frame it in terms leadership can support. Leadership may hear about problems, but not understand the operational consequence behind them. Aaron’s point is that the best controls professionals learn to bridge that gap.
That lesson matters everywhere, but it is especially relevant in critical facilities and data centers. In those environments, a controls issue is rarely “just a controls issue.” A sequence that is vague, an alarm strategy that is noisy, or a system handoff that is poorly communicated can create consequences far beyond the original defect. Operator confidence drops. Response time suffers. Workarounds appear. Nuisance conditions become normalized. In a mission-critical environment, those are not minor inconveniences. They are operational liabilities.
One of the most valuable parts of the episode is the way Aaron describes the evolution of a technician’s thinking. Early in a controls career, success often looks simple: get the controller online, prove the point, start the fan, modulate the valve, close the interlock, finish the task. That phase matters. Every technician needs strong fundamentals. But over time, the work has to grow from basic function into something more mature. A system that merely runs is not necessarily a smart system. A better question is whether it runs clearly, efficiently, predictably, and in a way that supports the people responsible for it.
That is where Aaron’s view of smart buildings becomes especially useful. A mature controls professional does not stop at “it works.” The deeper questions begin after that. Is the sequence stable? Are we wasting energy? Are alarms actionable? Are operators forced to compensate for weak logic? Is the design maintainable over the life of the building? Can the issue be explained in a way that leadership will actually support? Those questions mark the shift from simple execution to real building performance.
Another reason Aaron’s perspective carries weight is that it comes from broad, practical experience. He did not grow only inside one brand, one platform, or one narrow lane of the industry. He moved from mechanical work into controls, then into multi-brand integration and consulting. That matters because the BAS world rarely stays neat. The field is full of legacy platforms, hybrid systems, partial retrofits, undocumented dependencies, and strange edge cases that do not fit neatly inside textbook examples. Technicians who grow in this environment learn that adaptability is not optional. It is part of the craft.
That is why Aaron places such a strong emphasis on documentation. In the episode, he explains that he keeps careful notes, screenshots, and videos when he works through unusual problems. That habit is not just about personal organization. It is about survival in a field where the same obscure issue may not return for years, and when it does, the people involved may have changed. Good documentation turns a hard lesson into a reusable asset. It protects the next technician, the next project phase, and often the next crisis.
For organizations trying to build stronger onboarding and knowledge-sharing practices, that point deserves attention. Too much technical knowledge still lives only in people’s heads. A good technician can solve a problem today, but a good team captures that knowledge so the solution becomes part of the organization’s capability. Screenshots, notes, logic summaries, sequence clarifications, and field observations may seem small in the moment, but over time they become the difference between repeatable competence and repeated confusion.
Aaron is equally sharp when discussing alarm strategy. Many facilities have quietly accepted alarm overload as normal. They have learned to live with high alarm counts, repeated nuisance conditions, and systems that cry wolf so often that operators stop reacting with urgency. Aaron rejects that mindset. Better programming, better sequence cleanup, and better operational thinking can reduce noise and make alarms meaningful again. That is not just a cosmetic improvement. It is a foundational piece of trust.
In critical environments, alarm trust is everything. A BAS that floods operators with weak alarms teaches them to ignore the system. Once that happens, even good alarms lose power. For Controls Technicians, this is a vital reminder: alarm strategy is not simply a programming task. It is part of reliability, response quality, and operator confidence. The goal is not to create more alarms. The goal is to create better alarms.
The same practical clarity appears in Aaron’s discussion of sequence design. He points out that many sequences look impressive on paper but fall apart when translated into control logic and field execution. Complexity alone is not intelligence. In one example, he describes reducing a sprawling 600-line chiller plant sequence into a one-page format that could actually be coded, reviewed, and understood. That is a highly valuable controls skill and one that is often overlooked. The job is not merely to preserve complicated language from a specification. The job is to translate intent into logic that is clear, testable, and maintainable.
This is where Controls Technicians can bring exceptional value to a project. We often stand closest to the moment when design intent meets operational reality. We are the ones who see when a sequence is too vague to test, too complicated to explain, or too disconnected from how equipment is actually installed and maintained. That position carries responsibility. It requires us to ask better questions, simplify where needed, and protect the long-term usability of the system rather than blindly preserving complexity.
Aaron’s comments on serviceability reinforce that same principle. A design can look efficient at bid time and still become a burden in operation. If access is poor, maintenance is labor-intensive, graphics are unclear, or failure modes are hard to isolate, the long-term cost can far outweigh the original savings. This is one of the most practical truths in BAS and HVAC work: first cost is not the same as lifecycle value. Controls professionals ignore that lesson at their own risk.
Perhaps the most memorable idea Aaron wanted emphasized is also the most revealing: every problem is a controls problem. On the surface, the line is clever. At a deeper level, it is a philosophy of growth. Aaron is not saying controls people should be blamed for everything. He is saying that difficult, messy, inconvenient problems are exactly where technicians sharpen their judgment and become more valuable. The weird integration, the unstable sequence, the legacy system no one wants to touch, the issue that crosses mechanical, electrical, and operational boundaries—those are the assignments that build real capability.
That is an important lesson for anyone entering the field. A technician who sees every hard system as punishment will eventually resent the work. A technician who sees difficult problems as opportunities to grow will continue expanding in value. That attitude changes everything. It turns frustration into development. It turns complexity into education. It turns uncertainty into professional leverage.
The episode also reflects Aaron’s broader commitment to education through Riding With the Senior Tech .Com, where he shares field-based lessons that help other technicians learn faster and avoid avoidable mistakes. That detail fits naturally with the larger message of the conversation. Good technicians solve problems. Great technicians also leave a trail that others can follow.
In the end, Aaron Hastings offers a model of what modern controls professionalism should look like. Build strong fundamentals. Respect the field. Listen to operators. Document what matters. Clean up alarm noise. Simplify sequences. Think beyond the point level. Understand how technical issues affect people, operations, and budgets. And when the hard problems come—and they always do—treat them as the work that will shape you. That is what it means to champion both sides of the table. Not just to make systems run, but to make them clearer, more useful, more reliable, and more valuable to everyone who depends on them.
