Developer Relations

Developer Advocate Handbook (2): Learn to Collaborate with Your Own Company


Author: Christian Heilmann
Compiled by: Zhuang Qi

As a developer advocate, you’ll find that most of your work content is inseparable from company colleagues and company changes.

In practice, this is far more difficult than dealing with the outside world, because company colleagues will be more familiar with and understand the products you advocate. This also means that when the outside world gets excited about products launched by the company, company colleagues may not feel proud. It’s like getting praised without doing good work, making you feel your efforts aren’t recognized.

The product launch process can be painful, frustrating, and even confusing. For example, successful launches need financial support, and you may encounter many setbacks in this process because not every product in the company can get the same resources.

As a developer advocate, your job is to listen to colleagues’ opinions, understand their problems, and communicate with management to try to solve these problems. You also need to help colleagues understand the facts and resolve their concerns, avoiding unnecessary misunderstandings. Because external voices’ evaluation of the company and its products may not be true.

When frustrated, people are likely to say negative things about the company on social media or elsewhere. This not only affects the product but may also leave a stain on your career. Usually, you’re not just a sounding board for colleagues when they’re frustrated, but also a mentor, helping them not do things they’ll regret in public. For this, you need to build credibility, which is very important and can help them vent their emotions without affecting their work. This is also an important step in verifying the value of developer advocates to developers. After all, you’re their spokesperson.

Note: For most online media, watching a tech company fail is worth celebrating because it can generate buzz and bring lots of clicks. Even now, tech companies are still labeled as “smarter than ordinary people” or “inherently evil and arrogant.” Because people can easily find out where you work online, any unwise words from you or colleagues might be embellished as “an employee from company X said…” to better attack the company. You need to ensure you or your colleagues don’t fall into traps due to frustration. At this time, you need to highlight your value and help colleagues get out of frustration.

When working in developer relations, you need to pay attention to many things, one of which is internal resistance from the company.

| Preventing Bias

Developer advocates are a unique role, spanning various traditional roles. For developers, being away from development work for a long time is a betrayal. For those biased developers, delivering what they develop has a sense of pride, and they think people who don’t write code are redundant. I believe you’ve encountered this situation and heard things like “I don’t know why we need designers, we use frameworks!” This is a very interesting problem—while you’re trying to help developers improve their status in the company, they may be opposing your role.

Finally, you need to learn to accept these. Learn to step out of your comfort zone, accept constant complaints and suggestions from inside and outside, and persist in being results-oriented. My 12 years of development experience taught me one thing: you can only do better work when you’re happy. If you also want to change the company’s status quo, then you must leave your monitor and go offline to communicate and understand.

Actually, this is you helping developers improve their communication and interpersonal skills. Please don’t treat it as an obstacle; you can view it as a challenge. After you successfully improve developers’ status in the company, go back and ask them what they think of you. Of course, you don’t need to care too much about others’ opinions because you can’t please everyone.

| Embracing Company Changes

With the booming development of the IT industry, companies in the industry are also embracing changes. But it also means that in some cases you need to handle problems beyond your ability. For example, mergers, acquisitions, launches, discontinuations, round after round of layoffs—these can all happen, so you need to be prepared.

Reality is always sad. In most cases, company changes have nothing to do with your personal work performance. They’re closely related to shareholders’ trading arbitrage in the stock market. This also means many companies need new products to succeed in a very short time. If expectations aren’t met, new products will be abandoned by shareholders. This is unhealthy development; it creates many short-term profit-driven products rather than those with good experiences. This choice is closely related to our developers.

As a developer advocate, you’ll always be in the spotlight, so when changes occur, you may be the first one colleagues ask. This can bring very bad effects, such as violating company regulations, having disputes with legal, PR, and marketing departments, so you need to pay attention to several things.

✅ Every major company change has corresponding legal procedures. So when changes occur, you should contact PR and legal departments as soon as possible and inform developers of the corresponding impact. Because although employees aren’t official information channels, external statements may be misquoted, getting them involved in internal company legal disputes.
✅ There’s no “off the record.” Whether in the company or on your social accounts, blog, and other external channels.
✅ Switch yourself to listening mode. When the company starts changing, it’s recommended to listen to everyone’s voice rather than adding noise. This also helps you maintain colleague relationships while understanding the true situation of events.
✅ Don’t be emotional and make assumptions. After changes occur, people can easily become irritable and may say some seriously untrue comments and assumptions. You need to remember this and not fall into this trap because you still need to protect colleagues.
✅ Indicate the timeframe you know about. If someone asks you what happened, please don’t answer “no comment” because this means you know but can’t say. You just need to indicate you’re still learning about it.

Note: The last point is very important. Because your job is to communicate with developers, when they’re confused, they’ll think you’re on the “company” or “management” side and must know more than them. Don’t lose developers’ connection and trust because of things you can’t control.

Example: In a round of layoffs, a beloved core developer was laid off. Then people started complaining about the unfairness on the company intranet, email lists, or social media like Twitter, pointing out the company’s unwise decision. But after I communicated with HR and the developer personally, I learned that this developer had applied for voluntary layoff in the previous round of layoffs, and this was confirmed by the developer personally. But in all emails and comments, no one mentioned the real situation, leading to a lot of misinformation and bad feelings.

| Serving Internal Developers

At work, you often need to travel around the world or seemingly aimlessly post online. This can easily give an illusion that you’ve lost interest in development. The solution to this problem is to ensure you don’t disconnect from development teams and developers.

Note: Don’t be annoyed by others’ doubts. You should be a rational, understanding, and pragmatic person. Only by looking at your work from an objective perspective can you become such a person.

More importantly, when developers encounter difficulties at work, you need to listen seriously and talk to their managers about these issues. Of course, you need to ensure the anonymity of the conversation and demonstrate the impact on product delivery, employee retention, and product quality.

Developers’ work is relatively saturated, and they don’t have opportunities to express their concerns. You can achieve this by communicating with the right people at the right time in the right language. Let them realize you can be their spokesperson and fight for opportunities to communicate with managers. Getting changes through your efforts will also get you support.

Example: Before, I had several late-night calls with a former colleague, discussing his future development at the company and an invitation from another company. This made me annoyed because he wasn’t experiencing the joy of work. The reason was he didn’t dare communicate with his manager. In the conversation, I mainly asked him about his daily feelings at the company, and he said he was scared. If you don’t like going to work and feel you have no chance to make any changes, the result is obvious: leave. He now has a new role at another company and is excited about new challenges. When he left the company, he wasn’t angry but had a sense of achievement because there were still people who cared about him at the previous company.

| Working with PR and Marketing Teams

As mentioned above, being a developer advocate means you’ll be between traditional promotion departments like PR and marketing and developers. This triggers these departments to view you as a competitor.

Therefore, maintaining good relationships and continuous communication with other departments is very important. The reasons are also obvious.

✅ You don’t want to give users ambiguous information. Although perspectives differ, you’re all promoting the same products to different audiences.
✅ PR and marketing departments know legal implications you don’t know. So before releasing information in advance or when products are about to have major revisions, make sure to communicate with them in advance.
✅ PR and marketing departments have established existing channels that can provide you with opportunities for speaking and cooperating with media.
✅ Be good at learning from their department’s experience. There will be seniors with longer tenure in these departments who can provide you with useful experience.
✅ You can feedback developers’ real situation. Ensure ads aren’t over-promoted, and verify PR’s impact on new products with actual situations.
✅ Learn to share resources. You may have resources other departments don’t have, such as other companies, promotion channels, etc.

Learn to connect with the outside through the company, which can ensure consistent external information. It’s also conducive to promoting colleague relationships.

| Being Known as External Channels

Different people evaluate a company from different angles, so informing the company about your external channels is a good method. This can also successfully avoid overlapping with users your colleagues reach. It fills the gaps in existing information channels and effectively maintains the company’s reputation. Here please list the channels where you publish information:

✅ Blog
✅ Print magazines and electronic magazines
✅ Mailing lists
✅ Forums
✅ Conferences
✅ Professional groups and organizations
✅ Social networks
✅ Podcasts
✅ Email newsletters
✅ Live streaming channels

Also inform users that you have product invitation codes and test accounts (if available), which is very effective and can help users who just want to experience it, saving them the registration process.

| Training Other Advocates and Developers

Just as visionary developers share their knowledge with other developers, you should discover and cultivate colleagues in the company who want to do or are suitable for developer relations work. There are two reasons: one is to share your workload when you’re sick or on vacation. The second is you can find your new goals, spend time doing other things, and be responsible for your career.

There’s another benefit: you can communicate with different people and let your experience play out on different channels. If you’re a mid-career developer advocate, some new channels may feel strange to you, but some younger colleagues in the department may already be using those hot new channels, and with a little guidance, they can do better than you.

Training advocates is actually a tricky thing. By definition, advocates should be discovered and empowered, not “created.”

Just as you use communication skills to recommend products to developers, you can also use this to discover potential colleagues.

✅ Make the company realize the necessity of external channels. Assuming your blog is successful and you’re willing to publish blogs about the company’s current work content and best engineering practices. And provide help with writing technical articles. Prove that personal social media channels are more human and get more user attention than those commercial brand publishing channels.
✅ Collect activities related to company business. Including activities you organize and other local activities. When you don’t have time to attend these activities, you should prepare things that need to be distributed (stickers, shirts, etc.), then encourage developers who want to attend activities. If they bring back photos and other information after attending, you can complete a blog together.
✅ Provide dedicated internal training and lectures. Because the career prospect of developer advocates is still unfamiliar to everyone, and for most people, public speaking is terrifying. Therefore, streamline training content to be applicable to any profession, such as online writing skills, public speaking skills, quickly searching online content, etc.
✅ Share hot events from outside. For example, sending a “happy social quotes” email newsletter, including hot tweets and blogs about a certain event or product launch in the developer world.
✅ Set up challenges for products. Conduct some internal competitions to collect ideas from internal personnel on product optimization. In the companies I’ve worked for, we all set up “hack days” to achieve this purpose. Now more and more companies are starting to do this.

Note: Many of these need to be completed together with PR and marketing teams, not just doing your own thing.

| Sharing Practical Technologies

As a developer advocate, you’ll have your finger on the pulse of technology. Not everyone has time to chase technology and communicate about technology implementation—this is also the fun of developer advocate work.

If you discover any cool and useful tools, please be good at sharing with others. This includes screenshot software, translation software, social software, automation process tools, etc.—anything that saves you a lot of time every day.

Example: If you’re an early adopter of new technology, you’ll find that new technology will slowly become popular in the following months. In my career, I’ve helped marketing and HR departments establish emerging channels like blogs and Twitter, achieving huge success for these departments. This is easy for you because you’re already very familiar with and understand these technologies.

| Balancing Personal and Official Social Channels

As a developer advocate, sooner or later you’ll face the question of where to put content. The biggest mistake is using your own personal channels (blog, Twitter, YouTube, Facebook, etc.) to publish all information. Balancing personal and official social channels has many benefits, for the following reasons:

✅ You can decide the time and style of publishing yourself, your own territory, your own rules.
✅ Helps build your personal brand, fans follow you to learn the latest technical information.
✅ This is profitable; you can earn extra commissions through ads or other sponsorships.

This is also how many KOLs operate, and they’re all very successful. This is also where the problem lies—once you only publish information for a certain company, you’re no longer “you,” you’ll be a spokesperson for a certain company or product. This is why using your own channels as a source of information for the company or product is a bad move. Reasons are as follows:

✅ This limits yourself. Constantly publishing information about the company or technology, you become someone who specifically reports on that company or technology, and you must also answer questions you can’t answer. Putting yourself in an infinite dead loop, but when you leave this company, what will happen?
✅ This causes dissatisfaction. Although using your fame to promote work is a good thing, you’ll also earn extra income through ads (tangible is ad fees, intangible is fame). In people’s eyes, you don’t need to do hard work, don’t need to attend work meetings, and don’t have final deadlines, but you’ve become the spokesperson for this project. This may be seen as stealing others’ labor results.
✅ This creates information disconnect. Because your channels aren’t where products are built and maintained and can’t be updated in real time, it’s recommended to let dedicated staff maintain official channels. This way, even when technology trends change, information won’t become outdated.
✅ You’ll miss official promotion. Company colleagues are all used to promoting the company’s official blog and Github repository. Because everyone knows they’ll get the latest and most authoritative information from these places. In comparison, your own blog seems less official, and given your risk of job-hopping, official channels will have concerns when promoting.
✅ You need to pay huge maintenance costs. After product upgrades, you need to personally keep yours up to date. And you probably don’t want to update this content after you leave.

In short, you need to balance the relationship between your own channels and official channels. Publish product-related information where products are officially maintained, such as official Wiki, blog, Github, etc. This way, even if you change jobs, you won’t leave a mess. This can also ensure that when users search, they find official resources that are always maintained, and from experience, official channels have higher weight in search engines than your blog. As a developer advocate, your job is to improve the image of the company and product itself. You need to be a compass, a propeller, not a substitute.

The content you publish on your own channels should激发 readers’ interest to go to the official website to learn more details. This may include translations, screen recordings, screenshots, and demos using that technology (rather than becoming it). Think of your company’s product as a movie, and you’re the one who generates interest by publishing clips and trailers on different platforms.

In product promotion, you need to balance the relationship between the company and yourself, don’t cross the chasm, you’re still the trusted external communication channel for the company.

| Removing Brand Thinking

A key element of a successful developer advocate is removing the brand from your thinking.

The company you work for creates many products, some may be cool, some may be bad. But as a developer advocate, your goal isn’t to make people interested in the brand and its company, but to make developers like talking about your products and promote them on their own. This is why you need to separate yourself from your company’s brand. Although this is hard, the more famous the company you work for, the more likely you’ll be portrayed as “the person from company X.” I’ll discuss this issue in later chapters of this book, but you need to prepare yourself.

Only when you’re excited about a product, separate yourself from the brand and move toward the product. If the department creating the product can’t make you interested in the product, don’t talk about it. Instead, work with the department to find the product’s value. Before advocating any product, you need to answer a question: What help does the product provide to developers?

The products you advocate need to make you interested. You need to clearly understand the product’s development direction and who to contact for product information. If this product doesn’t have a corresponding person in charge, you may need to give up.

People working around the product aren’t suitable for advocating the product. Because they’re too close to the product to discover those obvious defects in documentation. And they may have gotten used to those overly complex operations. They may even have unique product language; these terms have special meanings in the team’s daily communication, but would be strange in blogs.

Your job is to provide developers with simpler and clearer documentation and examples and help them do their work better. Because only when everyone works together can we build a beautiful product world.

The real power of removing the brand is that you can better collaborate with competitors.

Original address of this handbook:
https://developer-advocacy.com/

Reposted from: Developer Relations »


Similar Posts

Content icon
Content