The Value of Technical Advocates
Developers partnering with a clients as a long-term technical advocate has many benefits. These relationships can improve client satisfaction and increase sales activity.
Being a technical advocate also helps the developer expand their perspective and understanding of the client’s business problems. Better developer knowledge about the client can lead to improved products and company business results.
Make sure that your manager understands the effort that you put into being a technical advocate and the benefits your company receives as a result. Being a technical advocate should be personally rewarding, but your organization should also recognize it as an element in your personal career growth.
The relationship between a technical advocate and the client is just like any other relationship: it takes time and effort to build and to maintain. This blog will provide some best practices that may help you be a more effective technical advocate.
Becoming a Technical Advocate
Many developers find themselves thrust into the role of technical advocate because the client is having a critical problem. The technical advocate might be assigned because they are a subject matter expert in the technology related to the problem, or they may be assigned simply to make the customer feel that their complaint is being handled with the highest urgency.
While the circumstances of this “shotgun wedding” relationship may be unpleasant, it can result in very effective relationships. One of the hardest parts of establishing a technical advocate relationship is building credibility with the client and developing an understanding of the client’s environment—both of which can be byproducts of solving a critical problem.
Many companies have formal technical advocacy programs or use technical advocates as part of the process of introducing new products. Establishing an effective relationship in these situations can be more difficult because there is less opportunity for the advocate to build credibility with the client and the client sales team.
Goals of a Technical Advocate
The overall goal of a technical advocate is to help the client and the client sales team to be successful. One of the best measures of success is a client’s expanding use of your company’s technology and their increased satisfaction.
A technical advocate needs to establish a good relationship with the client sales team. The sales team “owns” the relationship with the client and should have extensive knowledge of the client’s business needs, organization and technology—knowledge that you will need to be an effective advocate. The client sales team will expect you to leverage your deep knowledge of the technology to help keep the client happy and to achieve their sales goals.
Of course, you will also need to establish a good relationship with the client. An understanding of the client environment is the foundation of this relationship including their organizational structure, current information technology topology, key applications and their strategic goals. As you become more familiar with the client, you should be able to use this knowledge to suggest actions that will make the client successful. Do not be afraid to suggest actions that may appear to be obvious. Sometimes it takes a push from an outside “expert” to help the client take action.
A technical advocate can provide value to the client in many ways depending on their knowledge and personality, including providing insight to the client on future directions for your product, advising the client on best practices for using your technology or providing assistance to help the client resolve a problem. What is important is that the client perceives a positive benefit from the advocate relationship.
How Can I be an Effective Technical Advocate?
You can be an effective technical advocate by behavior that I call the three “C”s:
- Communicate
- Collaborate
- Control
Communicate
Communication is the foundation of an effective technical advocacy and covers many individual activities. It is important to engage in regular communications with the client and with the client sales team.
I would strongly recommend that you start a new technical advocate relationship with a face-to-face meeting with the client and client sales team. Although you can maintain a relationship by email or telephone calls, it is much harder to establish a new relationship without direct contact.
Once you have established the relationship, you should maintain it by interacting with the client at least quarterly. If you do not have regular communications, your knowledge of what is going on with the client will get outdated. That will make it much harder for you to be effective when you do engage with the client. Regular communications also reinforces the perceived value you provide by being visible to the client and to the client sales team.
Communication also includes being prepared when you engage with your client. Keeping notes is a good way to maintain context, particularly when you have advocate relationships with multiple clients. Simple things like dressing appropriately for client meetings and understanding the purpose of the meetings before you arrive can make your interactions with the client smoother and more effective. You should work with the client sales team to reinforce their messages. Being responsive to the client and to the client sales team’s requests is one key way to build credibility and to strengthen the relationship.
You should also bring the knowledge you gain by working with clients back to development. The perspective you gain by working with the client provides important insights that can help your company develop technology to address your client’s needs. The insights are particularly useful when planning future enhancements, when evaluating designs, or when deciding which problems to tackle first. The more clients your development team has advocate relationships with, the broader your knowledge base and the better the results.
Collaborate
Even though you are a subject matter expert, you will need to contribute in areas outside your expertise. An important value that you provide to your client is the ability to leverage other resources in your company to help solve your client’s problems. The reality is that no single person is going to be able to deal with every potential situation that might come up, so you will have to collaborate with other developers, with service organizations, and with other resources in your company.
So how do you find these other resources? To start, you should leverage your development colleagues. Either they can directly address the issue or they can direct you to other people who can.
This is one of the hidden benefits of being a technical advocate: the exposure to issues outside of your area of expertise and the development of your own personal network.
Control
Control is perhaps the most difficult problem for technical advocates—controlling your natural tendencies to attempt to do everything for your client. Being a technical advocate should be an adjunct to existing support and development processes, not a replacement. Control is important to avoid advocate “burn out” and future client disappointment. To illustrate this point let us look at a few common scenarios:
Problem Management
Sometimes technical advocates are asked to resolve a problem for the client outside of the normal support process. This can occur when the technical advocate establishes their credibility with a client by helping to resolve a problem. The client or the client sales team assumes that the technical advocate will resolve all their problems.
This can be a bad situation because you probably have many other responsibilities that do not leave you time to be a “help desk” for your client. In addition, your client will run into problems that will be difficult for you to resolve because they are outside of your area of expertise. If you become your client’s problem resolution manager, you will eventually disappoint them and damage the relationship. Your support people are not going to be too thrilled with you circumventing their processes, either. J
Your client should always use the standard support process. You can assist with the problem resolution by working in the background to help the support team, providing your insight and knowledge of the client’s environment. The key is to help the client be successful in using the existing process instead of circumventing it.
One final note around problem management: the technical advocate should never criticize another area of your company in front of the client. It only hurts your company’s credibility and it does not help to resolve the client’s problem. You are a representative of your company; act like it.
Requirements Management
Another common challenge for technical advocates is dealing with client requirements. The client and client sales team often assume that as a developer, you have tremendous influence on future technology enhancements.
This can be very difficult and risky for the technical advocate. Your business has a formal process to control which new functions will be included in future releases of your technology. Because development resources are always limited, this process involves prioritization between strategic and client requirements. Some requirements will be unfulfilled.
Client sales teams often complicate this issue by introducing you as “the guy from development who can implement all of your requirements”. This kind of introduction (which is even worse if you introduce yourself that way!) is very dangerous because it sets the stage for client disappointment. You should not solicit requirements.
You are probably going to get enhancement requests from your client anyway. So how should you handle them?
Make sure that you understand what the client is really asking for—not just the function they ask for, but what business problem they are trying to solve. Clients sometimes ask for new functionality to solve business problems that existing functionality can already solve.
However, let us assume that there is a genuine requirement for new functionality. You should continue to document the requirement by clearly recording the required functionality, the expected business benefit to the client, the urgency of the request, and the client contact information.
You should be very careful to set the client’s expectations appropriately. Help the client to understand that, just like in the client’s business, your company must prioritize many requirements and it is not possible to satisfy them all.
After you have documented the client’s requirement and set the client’s expectations, you should use your team’s process to track and evaluate requirements. It is perfectly acceptable to act as an internal advocate for the client throughout your requirements process, but you should keep that advocacy out of the client’s view to avoid unreasonable expectations.
By the way, you should be cautious even when discussing planned functionality. Product plans are subject to change as new tactical or strategic requirements appear. You want to be careful to “under promise” and “over deliver”.
What happens when the client sales team says “If you promise to add function x to the product I can close a $20 million sale?” Well, the first thing you should do is to confirm the opportunity—that is, validate that the client sales team actually has a $20 million opportunity “booked” in the sales system. People sometimes exaggerate, so it is best to understand the amount and probability of the revenue opportunity. Any commitment for new function in a specific period should come from an executive. Development plans change and it is important that any commitments to clients come from the executive who has ultimate control over the content.
Summary
As you can see, being an effective technical advocate is not rocket science, but it does require a certain amount of organization coupled with a commitment to communication. Technical advocate relationships, like any human relationship, require time and effort to build and maintain. It takes work, but the benefits to you, to the client and to your company make it worth the effort.
Companion charts are available on Slideshare at http://www.slideshare.net/chromeaix/technical-advocate-bestpracticeskruemcke
The secret product manager 