Practical Tips for Technical Advocates

The Value of Technical Advocates

partnership_advocate_businessman-shaking-hands1Developers 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

Advertisements

About Jay Kruemcke

Jay has had more than twenty years of experience in the information technology industry. Starting from a rather humble beginning at IBM, Jay became a mainframe systems support programmer. Eventually Jay joined the AIX operating systems development team early in that product's development. Jay leveraged technical skills that he built in systems management to establish himself as a member of the IBM Austin Executive Briefing Center. His expertise in systems management with the SAP ERP system enabled his first product management role, as the owner of the Tivoli management product for SAP. Over the next three years he established that product as a success with the help of a strong development team. Jay returned to AIX in a product management position initially focusing on managing new requirements for the AIX operating system. Jay established himself as a subject manager expert in AIX and Power Systems virtualization and became a frequent guest at conferences around the world. Jay succumbed to the dark side and spent four years in IBM marketing in which he introduced AIX version 6 and AIX version 7 and many product innovations including the first every open beta program for an AIX release and a significant restructuring of the AIX offering structure and prices. Jay was part of the cloud software development organization and and focused on managing development engagements for clients deploying clouds using Power Systems servers with PowerVC and related products. In March of 2016, Jay retired from IBM and started in a new role as a product manager for SUSE, the Open Software company. Jay new focus is on enterprise Linux for POWER and ARM processor based systems. The postings on this site solely reflect the personal views of the author and do not necessarily represent the views, positions, strategies or opinions of my employer. Follow me on twitter @mr_sles, @cloudrancher and @chromeaix.
This entry was posted in Product management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s