Why support teams may be the most underutilized source of quality engineering and software talent.
I started my career in tech in the early 2000s at AppleCare. At the time, Apple was doing something unusual. Before anyone touched a phone, we went through a full month of in-class and hands-on training. The focus was not just technical knowledge, but empathy. We were trained to understand problems from the customer’s point of view, to think creatively, and to help people who were often encountering technology for the first time.
Those early years shaped how I think about software, systems, and teams more than any formal engineering education ever did.
Seeing Systems Through Customer Eyes
Back then, everyone started in consumer support. We supported the original iMac, which was bringing a completely new group of people online. Parents, grandparents, kids, and first-time computer owners who had never imagined themselves using technology.
We could not remote into machines. We could not see their screens. We had to rely on questions, imagination, and careful listening. We had to visualize the space someone was working in, the power strip they were using, the modem they described with unfamiliar language. We learned quickly that users do not think the way engineers do, and that was not a weakness. It was insight.
Customers often used technology in ways engineers never anticipated. They described problems using their own mental models, not ours. Many of their insights were dismissed simply because they did not share our vocabulary. Support forced me to confront the gap between how systems are designed and how they are actually used.
Support as a Crash Course in Reliability
Support teaches you one thing very clearly. Reliability builds trust. Flashy features do not.
If a system fails repeatedly, customers leave. Often you do not get a second chance. That reality has a way of sharpening your priorities. It pushes quality to the front of every decision.
Edge cases also stop being theoretical. The fastest way to discover how software breaks is to ignore the documentation and approach it as a complete novice. End users will always surprise you. They will combine features in unexpected ways, use systems outside their intended context, and surface failure modes no test plan ever covered.
To Apple’s credit, engineers would occasionally sit with us and listen to real customer calls. Those moments made it obvious that proximity to users creates understanding that no backlog grooming session can replicate.
From Support to Engineering
Later in my career, while working at Pearson supporting the PowerSchool student information system, my transition into software development came directly out of support. I had moved into support engineering and spent much of my time acting as a liaison between large customers and the development team.
By the time I moved into development, I understood the product holistically. I could train new engineers not just on how the system worked, but how it failed and how customers experienced those failures. That perspective carried forward with me.
Customer advocacy became a core instinct. Even when I was not the most senior developer in the room, product managers and QA consistently valued my input because it was grounded in real-world usage.
Quality Grows Near Failure
Constant exposure to bugs, outages, and frustrated users changes how you write software. Quality stops being abstract. It becomes personal.
I have long believed that quality engineering and support should live much closer together organizationally. If I were designing an org from scratch, I would strongly consider placing QE under the same umbrella as support, not as a subordinate function, but as a parallel track. The support experience creates a natural farm league for quality engineering, and in many cases, for software development as well.
Some of the best developers I have worked with came out of QE backgrounds. At the same time, QE deserves its own growth path. The goal is not to drain talent, but to create intentional pipelines where skills and empathy compound over time.
What Modern Organizations Miss
Most companies treat support as a cost center. It is undervalued, outsourced quickly, and often treated as disposable. In doing so, they miss a significant opportunity.
Support roles are often low barrier to entry. That makes them powerful on-ramps for early career talent. With intentional development paths, companies could grow future quality engineers and developers from within, retain institutional knowledge, improve morale, and support inclusion goals at the same time.
People generally want to stay at companies that invest in their growth. Pipelines like this reduce churn and strengthen culture.
Scaling Teams With Empathy
My time in support shaped how I later led teams as an engineering manager. It tuned my sense of empathy and gave me patience for people trying to grow into new roles.
Support also trains you to stay calm under pressure. Customers can be angry. Incidents can be chaotic. Effective response requires composure, structured troubleshooting, and an understanding of how systems interact. Those same skills are essential for incident management, prioritization, and managing technical debt.
A Missed Goldmine
When leaders view support purely as an expense, they overlook a goldmine of talent. Support engineers develop empathy, communication skills, system intuition, and resilience under pressure. These traits are hard to teach later and invaluable at scale.
If I could redesign one thing about how support and engineering interact, it would be more intentional overlap. More shared context. More open communication. More pathways between roles.
Support is not the end of a career. It can be the beginning of some of the strongest engineering leaders an organization will ever have.
At O’Side Systems, I help teams design systems and organizations that scale with quality and empathy, not just speed.
If you want to rethink how your support organization fits into your engineering strategy, contact us to see how we can help.