Should Developers be Interacting with Customers? – Some of the Development teams I’ve worked with have learned a great deal by listening in on user research sessions. But have you experienced an environment where developers are encouraged to work and support customers directly? In this piece by Jun Wu, here are some of the lessons she learned as she transitioned into a tech support role.
Should Developers be Interacting with Customers?
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.