Why Your Developers Should Support Customers
Lessons learned supporting customers and appreciating a different perspective of development
Tech support is probably one of the most unloved jobs in technology. Developers frequently look down on tech support as people who can’t program. The tech support team is often thought of as a team of people who “raise the issues” with development teams. They’re the people who are the communicators of “problems.”
This is why developers and software engineers will walk away even when they’re directly confronted by a member of the tech support team. The reply tech support always gets is: “I’m busy on another project. If it’s a big issue, please talk to my manager.”
When I transitioned into a tech support role for Front Office trading and risk systems after being a senior developer for Middle Office reporting applications in the investment bank I worked at, people thought I was nuts. My need to see the “big picture” drove my decision at the time. I also thought the business knowledge I gained at the job might lead to a developer job for one of the Front Office trading and risk systems. But, instead, I rose through the ranks of my tech support team, became a leader, and eventually found myself appreciating development from a different perspective.
From my years dealing with customers, development team managers, developers, and members of my support team, I can now offer some insights into why I think every developer, at some point in their coding career, should sit in that tech support chair to support customers. Even for a short time, such as two weeks, the experience can change the mindset of a developer, change the way a developer codes, and increase the skill set of a developer.
See the “Big Picture”
As a developer, it’s easy to focus on just one part of the software or system. Often, it’s comfortable for both the team and the developer to routinely work in the developer’s area of expertise. This makes “seeing the big picture” that much more important. As tech support, the developer can appreciate the inter-relationships inside the system. The developer can also appreciate all the other systems that depend on this system.
For instance, when we started a developer rotation in our support team, the developer frequently commented, “I didn’t know that XYZ system depends on data from our system. Why are we receiving data from the ABC system for pricing this instrument?”
Boost to Morale
Seeing the product of a developer’s work being used by clients is a huge boost to morale. It’s also motivation to do “better.” When the developer sees that their work sits in the center of an important piece of software or an important system, that developer will be that much more motivated to perform at their best.
For instance, when we were rolling out an important version of our software to a new group of internal users, one of the “star” developers rotated on our team for two weeks. That developer was able to solve the client’s issues “on the spot” because he wrote most of the new features. By the end of the two weeks, this developer was grinning from ear-to-ear because he was the one who ensured a successful release and ultimately the success of a project that took six months to complete.
Learn the Nuances of Usage
Even with the best requirement gathering, there are nuances on how clients use the software or the system. Different types of clients will also introduce new nuances of usage. Often, that nuance is not captured “exactly” by the testing team or the project management team.
For instance, we frequently had instances where one client was responsible for introducing bugs into our system simply because the client was not using the system or the software as intended. This new client did not introduce the bugs. But those 10 steps that the client took inside the software or the system in its exact sequence highlighted a bug that was already there.
Sharpen Debugging Skills
Debugging is a critical skill of any developer, and there’s no better place to learn about debugging than in a support team. Developers usually focus on debugging software in one language, or one part of the system. But, members of the support team often debug entire systems. This means they trace issues from one end through many components to see what results come out of the other end. All the intermediary results have to be worked out to keep track of what will happen at the end.
For instance, when our risk systems outputted “wrong” numbers for our clients, the answers were rarely simple. Members of our support team often had to trace through the log files of many components to finding all of the intermediary outputs. Then, they had to retrieve all the prices that may be involved in our calculations. Finally, we had to put all of those numbers together on a spreadsheet to manually calculate them and verify the output. Debugging from error messages coming out of the compiler is straight forward compared to debugging from data-generated errors that span many system components.
Learn the Importance of Architecture and Design
Performance and reliability are easily two of the most critical issues that developers will encounter when doing tech support. Each time, when these issues creep up, the developer’s patience is tested. A developer might not understand why clients complain about a 10-second delay. But, when they see the impact a 10-second delay can cause in real-time, that developer can appreciate good architecture and design that makes the system fast and resilient.
For instance, one of our developers couldn’t understand why we “recycled” the cache every afternoon before one of our large overnight batch jobs started. When that developer did his rotation on our support team, he learned that the “recycling” allowed for 10x the performance for clients who were using our systems heavily in the afternoons.
The developer then went back to his team to suggest changes in the architecture and the design to alleviate the performance issues. On top of that, in the next release of the system, critical backup and contingency plans were worked in to allow for more resilience in the entire system.
Learn to Appreciate the Simple and the Complex
Developers have a knack for solving complex problems. Tech support has a knack for translating complex problems into simple bite-sized pieces. Combining these two perspectives can be extremely beneficial when dealing with complex system problems.
For instance, when one of the developers rotated with our team for two weeks, he was surprised to see how quickly our clients were clicking through the components of the software. “Wait, did you know that all these clicks add up to the activation of many parts of the system. Please slow down the clicks.”
The trouble is that the client can’t slow down the clicks. The client has to perform his work very fast. In the next release of the system, the developer suggested simplifying the design of a particular part of of the system to cater to this specific type of usage. This allowed those clicks to continue, and the clicks generated a much higher response rate from the system. The client was happy with the performance. The developer was also happy with the simplification that allowed for a more scalable system.
Learn About Data and the Challenges It Introduces
Developers often only work with test data until the testing stage. Test data often does not represent real data adequately. The saying goes, “No matter how much you test with QA data, someone somewhere will ultimately break the system with some kind of live data that was not accounted for.” In tech support, the experience of working with live data by fixing clients’ issues will allow developers to think about data and the problems it introduces more thoroughly.
For instance, one of our systems had data coming in from many pricing engines that upstream, such as Bloomberg, Markit, etc. These pricing feeds introduced a significant variable into our risk systems. Having spent two weeks with us watching the members of our team painstakingly manually calculate trades by retrieving data from these pricing feeds for the clients to verify their numbers, a developer announced, “Data is no joke.”
That developer went on to appreciate the critical work that our support team did to bridge the gap between the development team and the support team. The developer also realized the importance of data integrity within the system. The next release of the system contained many mechanisms to ensure this data integrity.
Learn a Different Set of Soft Skills
Communicating complex problems and solutions is difficult for anyone. But, communicating these problems and solutions under a time-constraint is even more difficult. Often, on-the-spot prioritization is important in time-critical communication. This means that tech support members learn when to say what to the customers, how to explain certain problems, and what information to present for optimal transparency. When a developer who is used to speaking slowly, explaining in detail, and drawing diagrams suddenly has to adapt their communication style to this type of environment, it often takes both time and energy.
For instance, one of the junior developers who frequently rotated on our team made a point to stop by Starbucks every day on his way to work simply because the caffeine allowed him to speak faster. He often told us that spending time on our team is like doing code competitions — it takes a sharp mind and quick tongue to be able to succeed.
Learn the Importance of Test-Driven Development
Many developers do not like test-driven development. Developers who are concerned about architecture will argue that designing the entire system from scratch is extremely important. However, on minor releases of the software or the system, test-driven development to fix critical issues are not only important but also necessary.
For instance, we often had problems in our issue tracking system that had long lists of steps to duplicate a bug. Developers joked about how our tech support team is teaming up with the clients to “break” the system. But, when the same developers rotated with our team and saw those convoluted steps performed in real-time, those developers created real test cases in their testing plan and developed new features to allow for these types of use cases to integrate more seamlessly into our system.
Learn the Importance of “Timeliness”
Business changes in real-time. Developers are creatures of habit. This is good. We want software and systems that will stand the test of time. At the same time, agility and flexibility are also important. When business changes, clients have to adapt quickly. Whether or not the clients can continue to use the software and the system depends on how quickly the software and the system can adapt to the situation.
For instance, the ability to work with Excel data is extremely important for any financial system. At the same time, data integrity is a huge issue when working with Excel. Developers who rotated on our team were able to experience in real-time how a set of requirements for new features kept changing as the business changed for the client. Eventually, they recommended the development of an entirely different part of the system to give these types of clients the flexibility and agility they were looking for.
For developers to be successful, appreciating a different perspective on their work is important. This is why having some experience supporting the customers is vital to the developer’s success. In the process, the developer can learn to think differently about the various parts of the software or system, such as design, testing, data, and requirements.
The developer will also appreciate the user experience that much more. This will allow them to adjust their thinking to be more client-centric. Ultimately, the experience will allow the developer to be more successful at developing systems and software that the clients will appreciate.
About the Author
Jun Wu is a Content Writer for Technology, AI, Data Science, Psychology, and Parenting. She has a background in programming and statistics. On her spare time, she writes poetry and blogs on her website.