Work with your own company
As a developer evangelist you will find that a large part of your work is dealing with internal developers and unpredictable changes to your company.
This can actually be a much harder job than dealing with outside developers. The reason is that people on the inside do not only see the outcome of the products and disagree with that but are also part of the journey towards these - and that journey can be painful, frustrating and sometimes just plain confusing.
Your job as a developer evangelist is to listen to developers, understand their problems and communicate with management to try to sort the issues out. You also need to ensure that you remind people of facts instead of chiming in with bad rumours - what the outside world says about the company and products might not necessarily be the real picture.
Example: It is pretty scary just how big a business company rumours is. Sites like Valleywag, Alley insider and lately sadly enough more and more TechCrunch are always on the lookout for a juicy story that rivals the celebrity rag mags. Proper investigation and separation of rumours and facts is not high on the list - what stirs emotions is what a successful news post is about.
There are a lot of things you have to be aware of when you are a developer evangelist. One of them is the enemy within the company.
Prepare for prejudice
You have a very unique and new role which spans various traditional roles. Especially for developers moving away from the day to day grind can easily be seen as betraying the cause. Prejudiced developers are amazingly proud of being the delivering part of the company and consider anyone who does not code superfluous. I am sure you met these people and heard statements like “I don't know why we need designers, I know how to use Photoshop, too!”. It is somewhat ironic that the people whose standing in the company you try to improve are the ones that are likely to be opposed to your role.
In the end, this is something you will have to live with. You will burn a few bridges and you will have to suffer a lot of internal and external abuse and nagging but it is important to keep your eyes on the goal. If working for 12 years as a web developer has taught me one thing then it is that delivering awesome work pleases first and foremost yourself. In order to have an impact in the company and to get things changed you have to take your hands off the keyboard and start talking and persuading.
Don't get discouraged by people seemingly stabbing you in the back - in reality this is exactly the miscommunication and lack of people skills that you try to help out with. See it as a challenge and not as a show-stopper. Once you can show successes of improving the standing of developers in the company you can go back and call a comparison match. Most of the time this is not necessary any longer though as the terribly grumpy people either left the company or others start telling them to stop.
Deal with company changes
As the IT market is constantly changing so do the companies in it. This can be a great thing but in most of the cases it will mean that you have to deal with happenings that are beyond of your control. Mergers, acquisitions, new products, products being discontinued, rounds of layoffs, redundancies - all of these things happen, so be prepared.
Fact: The sad fact is that none of them ever have anything to do with the quality of your work. The concept of shareholders buying into a company because they believe in it has been dead for years - it is all about trading stocks and moving them to make money in the process. This means that any publicly listed company has 3 months time to make any new product a massive success as this is the time in between shareholder meetings. If there is no immediate success then the product gets canned and the people on it with it. This is a terrible state of affairs and it leads to mediocre and short-win driven products instead of great, lasting experiences. And the latter is what good developers are all about.
The thing about you being a developer evangelist is that you are in the spotlight of the world and the company so you'll be the first to be asked about an opinion when there is a big change in your company. This can have disastrous effects - either you violate a company policy and tread very hard indeed on the toes of your legal, HR, marketing and PR team or you sound like a company drone to the geeks in the company. Here are a few things to be aware of:
- Every change in the company has a legal process - while you are not an official press channel to the outside world your statement can be misquoted (oh and it will) and get you into legal trouble with your own company - liaise with PR and legal as soon as possible when there is a change. Then tell the developers in your company the legal implications.
- There is no “off the record” - neither internally and especially not when you are talking to the press/bloggers/outbound channels.
- Switch to listening mode - during the first few hours after a dramatic change listen to everybody and keep your eyes and ears open to what people say. This helps you to stop people from completely destroying their professional standing in the company and the market and to learn about what is really happening. Don't be part of the noise that drowns the facts.
- Don't act emotional and make assumptions - almost any change in the company will annoy people. In the heat of the moment this can lead to very dangerous comments, assumptions and truisms which will come back to bite people in the butt a week later. Be aware of this and don't fall into the same trap. Instead be ready to bail these guys out later on. Get the facts and before you say anything have a backup that can verify what you are saying.
- Make your knowledge level clear - if people ask you what is going on don't say “no comment” as that implies you know something but are not allowed to say it. Simply state that you are not in a position to know yet but that you are investigating.
Tip: This last point is very important. As your job is to communicate with everybody in the company people already assume that you have a much more in-depth knowledge than they have. As developers get very paranoid about changes in the company this can mean that people think you know all about what annoys them but hold back as you are siding with “the company” or “the management”. Don't lose your contact with and the trust of the developers in the company over something you have no control over.
Example: One very interesting example of a change was when in one round of redundancies a broadly liked and respected very outgoing and extremely talented developer got made redundant. The developer was also part of a team that built one of the most important products at the time. The mailing lists where flaming, people were twittering about the unfairness of it all and in general everything pointed towards the company having completely lost its marbles. Speaking to HR I got to learn that the reason he was picked was that in a previous round of redundancies he had filed for voluntary redundancy and naturally these were the employees who were picked first. In addition to that talking to the developer himself I found out that he was totally OK with the decision and looked forward to having more time to look after his pet freetime projects and turning them into businesses. All the emails and comments going out failed to either address the developer himself or HR for a statement and this resulted in an avalanche of misinformation and bad blood.
Be there for internal developers
You traveling the world and seemingly spending your work time aimlessly surfing the web and twittering can give a wrong impression of you losing interest in being a developer. Work around that by not losing the connection with the people in your company that build things and listen to what they do.
Tip: Don't get bogged down in detailed problems of other developers though. You should be a voice of reason, understanding and pragmatic solutions and you can only be that if you see the work being done from a vantage point.
More importantly listen very hard when developers feel hindered in delivering their job. Then talk to their management about these problems. Keep these talks anonymous and show the impact these problems have on delivery, employee retention and quality of the products your company builds.
Any change for the better you can cause and any improvement in the areas people are concerned about that can be attributed back to you allow you to not be part of the delivery without losing geek points. You achieve this by talking in the right language at the right time to the right people. Developers are always asked to deliver yesterday what is defined in a week's time and never feel the chance to voice their concerns. Make them aware that you can be their spokesperson and that you are there to demand time for discussing problems with their managers.
Example: I was very touched when one of my former colleagues asked me to have a few late night phone calls (over Skype) to talk about his future in the company and an offer he had from another company. I was also very annoyed about how frustrated he was about not feeling any joy or empowerment in his job. The reason was that he didn't dare talking to his manager. My main question in these calls was how he feels about going to the office every day and he said that he dreads it. The decision was clear: if you do not like going to work and you don't feel you have a chance to cause any change - leave. He is now in a new role in a different company, feels very excited about the challenges there and left the company not in anger but with a feeling of accomplishment and knowledge that there are caring people in his old company and not only the ones that made him leave.
Work with PR and marketing
As stated in detail beforehand your role as a developer evangelist means that you are in between classic outreach departments like PR and marketing and developers. The danger there is that these departments could see you as competition.
Therefore it is immensely important that you keep on good terms and in constant communication with these departments. The reasons should be obvious:
- You don't want to give mixed messages - different views, yes, but you should both at least promote the same products to different audiences.
- PR and marketing know legal implications you don't - so make sure you chat with them before prematurely releasing information or promoting products that are about to change drastically.
- These departments have already established communication channels which can give you a good way in to speak at conferences and work with the press.
- You can learn from their experience - most probably these departments will have people that are on the job longer than you have been and can predict patterns.
- You can feed back state-of-the-art developer information - validating the impression PR has of a new product with realities makes sure that over-ambitious advertising doesn't promise developers functionality that you'd have to explain is not available yet.
- Sharing contacts can open doors - you might have a way into companies and publication channels that PR always wanted to have but couldn't find.
Only by liaising with the other outreach channels of the company you can make sure that you give the same message. You don't want to be seen as a threat.
Be known as an outward channel
As a lot of people talk about the company to the world on different levels it is a good plan to tell the company about your outward communication channels. This ensures that you are not approaching the same people in parallel and possibly give mixed messages effectively undermining your and your company's credibility. It also shows the company that you are a person that reaches where they can't. List all the places where you publish:
- Magazines (print and online)
- Mailing lists
- Professional groups and bodies
- Social networks
- Social apps
Also make sure to tell people that you have invite codes and accounts for products (if you have them of course). This works a treat and stops people from having to sign up themselves if they just want to have a look.
Train other evangelists and developers
Just like clever developers share as much of their knowledge with other developers you should plan for training people in the company to do what you do. The reason is the same in both cases: you can share the workload and you can be sick or take a holiday. Another thing you can do is target new ideas and spend time on other plans what to do with your (professional) life.
Training evangelists is a tricky thing - by definition evangelists should be found and empowered and cannot really be “made”.
Just like you use your powers of communication and persuasion to bring products to developers you can use them to bring potential evangelists out of the woodwork:
- Make the company aware of the communication channels to the outside world. Say that the blog you have is successful and that you are very happy to publish in-depth blog posts about current work and best practices used in the company. Then offer help with writing those.
- Tell the company about events - both the ones you organise and ones that happen in the area. This is especially necessary when you can't attend them. Offer to support a developer who wants to go with free goodies to give out (stickers, shirts…) - if they go and bring back photos and information how it went to write a blog post together.
- Offer specialised internal training and talks - as the prospect of evangelism might still be alien and even scary to people cut the training offer down to things that can be applied in any professional role: writing for the web, public speaking tips, finding great web content (well, basically the different chapters here).
- Share great responses from the outside world - send out for example a newsletter of “happy geek quotes” with tweets and blog posts about how a certain event or product launch was received in the developer world.
- Ask people to challenge your products - run some internal competitions to change or collect ideas about how people in the company would like your products to change. In my company we have hack days for that and more and more companies start doing the same.
Tip: A lot of this will tie in nicely with communication channels that PR and marketing already use. Ask them for help instead of doing your own thing and creating confusion and trespass on their territory.
Share useful technology
As a developer evangelist, you will have the hand on the pulse of technology. Not everybody has the time to keep up the same way - actually hardly anybody has. That's why a very interesting part of your job is to communicate great technology finds with your company.
So if you find great tools that make everybody's life easier, share them with the company. This can include things like screenshot tools to stop people from sending you Word documents with embedded resized bitmaps, translation tools, communication tools and basically anything that you use to save time every day.
Example: One thing you will find is that if you are an early adopter of technology the main market will get to know some of them a few months later. Twitter and Oprah using it is one example. Another is blogging. In my current job I had great success by using both and then helping marketing to set up blogs and HR to use Twitter. This creates an amazing amount of goodwill with these departments and it is an easy step for you as you are already excited and knowledgeable about these technologies.
Balance your personal and official channels
One issue you will face sooner or later as a developer evangelist is where to put your information. The big mistake there is to use your own, personal channels (blog, Twitter account, Facebook page and so on) for everything. This is tempting to do, for several reasons:
- You control the timing and style of the publication – it is your blog/twitter account/google+ profile…
- It aids your personal brand – people come to you to find out cool, up to date technical info
- It is lucrative – you can make some extra money by showing ads or getting other sponsorships
This is how a lot of personal blogs work, and well at that. The issue, however, is that once you publish for a certain company you are not just "you" any longer. You are a translator and a voice of a certain company or product and – more importantly – the people working in or on it. That's why it is a very bad move to use your own channels as the source for company or product specific information. For various reasons:
- You limit yourself – by posting about a certain company or technology you become the person to cover that technology. You have to answer comments you can not answer but the people working on the technology can. You set yourself up for an endless game of Chinese Whispers. What happens when you leave the company or move on to another product?
- It will cause discontent – whilst it is good that you use your fame to promote the work of your colleagues, you also get benefits (tangible in the form of advertising money and lesser tangible in the form of fame) by writing about the work of other people. You didn't do the hard work, you didn't attend the meetings, you didn't work extra hours to meet deadlines but you become the face of the project. This can be seen as ripping people off.
- You cause a disconnect – your channels are not where the product is built and maintained. What happens when the technology changes? Keeping the information close to the subject matter and maintained by the people who work on the product ensures that things stay up-to-date without your intervention.
- You miss out on internal promotion – an official blog or repository of your company is promoted by the marketing department and everyone in the company. People know it as a channel and are excited to see new and up-to-date, well produced information there. Your own blog might not be known to people in the company and is not seen as a trustworthy channel as it is not in control of the company. You could go rogue any time, or your blog could be hacked. Official channels will shy away from promoting your work with you.
- You cause a massive maintenance overhead – it is up to you to keep the posts on the subject up-to-date when changes to the product happen. You might not be with the company any longer when changes happen and you don't want to have to deal with questions by people years later when "your product" out of a sudden changes.
All in all, the balance between publishing on your own channels and company official channels is simple: publish detailed information tied to the product where the product is maintained – a company wiki, an official blog maintained by the company, the GitHub repository and similar places. That way you can move on to another company without leaving confusion and a mess behind. It also ensures that web searches in the future find a maintained resource, and that social media updates don't end up in a missing page – a company has a stake in keeping an official resource available. As an evangelist, your job is to raise the profile of the company creating the product you promote and the product itself. Thus the official pages with the up-to-date information should show up higher in search results than your own blog. Otherwise you failed at doing your job. You are a pointer, a transmitter – not a replacement.
What you publish on your own channels should whet the appetite of your readers to go to the official place and learn more. This could include translations, a quick screencast, screenshots, a nice demo using the technology (instead of being it). Think of your company's product as a movie and you are the one who cuts and releases the trailers in various places to get people excited about it.
There is a very fine line between promoting your company's work and taking credit for it. Don't cross it and you'll help the company and keep being a trustworthy resource and communication channel.