Weekly Byte: Keeping priorities straight and scaling support
As a small software company trying to make waves in the medical industry, we at pMD have to do things differently than most folks. One of those is how we interact with our charge capture, secure messaging, and HIE customers. In a previous post, I wrote about a developer's responsibility to their customers. Philosophically, I think a developer must communicate directly with their users on a regular basis. Not doing so leads them down a slippery slope of wrong priorities.
Customer support is perhaps the most raw form of this crucial feedback. When speaking to other software developers about their projects, I can pretty quickly tell if they've ever had any substantive experience communicating with users (or if they've ever had any). Doing support changes you as a developer, quickly kills any bikeshedding, plants your feet firmly on the ground, and tells you what needs to be done. Pleasant or unpleasant, the work is real, but so is the satisfaction, knowing effort is not being wasted. When your team and customer size is small, little to no organization is needed to provide excellent support and still maintain efficiency. As the team grows however, it's every organization's challenge to maintain and nurture the communication link with their customers.
Some companies hire consultants, which then recommend and implement a far away call center, shielding the developers and the company from direct contact with their customers. Sometimes this may make sense, I'm not sure, but it's probably not before your company has achieved its mission statement. Balancing efficiency and the benefits of egalitarian support by the whole company is no easy task but something I've been tasked to scale as pMD has grown. Today, the team is still relatively small but spread across four time zones, and our customer base has grown by several orders of magnitude since I joined. In my next post, I'll discuss some things we've been trying, and new experiments on doing effective support. There are always difficulties when trying new things, figuring out what works and what doesn't, but it's necessary as we try to reinforce our link to our customers, and try to make waves.
Customer support is perhaps the most raw form of this crucial feedback. When speaking to other software developers about their projects, I can pretty quickly tell if they've ever had any substantive experience communicating with users (or if they've ever had any). Doing support changes you as a developer, quickly kills any bikeshedding, plants your feet firmly on the ground, and tells you what needs to be done. Pleasant or unpleasant, the work is real, but so is the satisfaction, knowing effort is not being wasted. When your team and customer size is small, little to no organization is needed to provide excellent support and still maintain efficiency. As the team grows however, it's every organization's challenge to maintain and nurture the communication link with their customers.
Some companies hire consultants, which then recommend and implement a far away call center, shielding the developers and the company from direct contact with their customers. Sometimes this may make sense, I'm not sure, but it's probably not before your company has achieved its mission statement. Balancing efficiency and the benefits of egalitarian support by the whole company is no easy task but something I've been tasked to scale as pMD has grown. Today, the team is still relatively small but spread across four time zones, and our customer base has grown by several orders of magnitude since I joined. In my next post, I'll discuss some things we've been trying, and new experiments on doing effective support. There are always difficulties when trying new things, figuring out what works and what doesn't, but it's necessary as we try to reinforce our link to our customers, and try to make waves.
