Evangelism

This morning news.com.au ran a segment about new job titles based on an interview with me a few weeks ago. In the interview about developer evangelism I answered a few questions and – more importantly – covered the difference between sales and developer relations. Here are my full answers to their questions:

In layman’s terms, how would you describe your job?

A developer evangelist (or developer advocate which is a term many prefer now) is an expert who helps developers use the products of a company and technical people in the company to get the time and support to write excellent products. The job is a communicator role between the technical experts of a company, the outside world, but also different departments of a company. Working in tech is a taxing job although it doesn’t look that way. A lot of people have demands but are not interested in understanding what you do – they just want the work done. The job of the developer evangelist is to bridge that gap. By creating learning materials, presentations and help with communication in between departments. Developers are excellent at solving technical problems and building great software. But many have neither the time nor the drive to communicate their efforts well to others. This is what we do.

Would it be fair to say you work as a sort of salesman for companies to encourage other people to purchase things from the company? Or purchase apps for example?

No, not at all. This is the job of a sales department and their main goal is to artificially create demand for a product. As a developer evangelist you help the product on a technical level. You create example projects using the product. You collect and collate outside feedback, triage it and then bring it to the busy technical team. You help people with technical issues. You create demand in the technical community by talking about the product and showing how it makes the life of developers easier.
If you do a classic sales pitch in the form of “you don’t need to understand this, our product magically fixes all your problems” you’re dead as a developer relations person. You need to have the technical knowledge and properly understand how the product works, not simply sell it. Of course, we’re all creating demand and interest, so in a way we are sales people. But what we sell is knowledge about the inner workings of the product to the outside. You sell your company as a place using cool tech to other developers. We sell outside interest back to the company helping it to priotitise product roadmaps. Good DevRel work doesn’t necessarily result in more product sales. Instead it helps with hiring new talent and ensure people in the company are happy. A company with a fixed product does not need a developer evangelist. When your product offers more granular access to its features using for example an Application Programming Interface (API) then you should consider bringing this role up.

As a comparison, consider a car company. The sales people are there to sell cars – customers don’t need to know the internals. A devrel person would be the one explaining mechanics how to maintain the engine. The person should present at conferences why your cars have great technology and are good for the environment. And explain that your company is much more than just a maker of cars. We create interest and explain how things work so people from the outside can contribute. We don’t sell products.

On your Linkedin you say, ‘I like to take complex technical things and translate them to various audiences in an understandable format’. Is that for people working for companies like Microsoft? Or the general public?

That depends on the event or publication I am asked to reach out to. I’ve explained tech and products of my former and current companies internally to our own people of other departments. I explained them to outside developers working for other, similar companies. I worked withthe open source community as a whole, designers, product managers, project managers and at one time also to people working in the unemployment office. That’s the “various audiences” bit in there.

The general public is less interested in the inner workings of products. It makes more sense to give this communication channel to marketing. However, a good developer evangelist works very closely with sales and marketing to make sure that your company advertisements and press releases don’t overpromise or make it impossible for your developers to deliver in time.

The job of a developer evangelist is to make technical issues easier to understand. This also means to help your company to communicate to the general public without dazzling them with buzzwords.

You don’t only to explain the how but also the why. And the why differs from audience to audience and needs different explanation materials. This could be a very well documented and explained piece of code, an exciting use case and demo app or a presentation. It boils down to being a good communicator and feel empathy with the audience. Far too many technical documentation assumes a perfect audience and thus fails to spark interest. Other information materials show a shiny best scenario but never explain what to do when things go wrong. As a devrel person you need to find a good middle ground.

How does one go about becoming a developer evangelist?

The perfect scenario is to move an interested developer of the product into the role. You need to know the products and technologies inside and out to be a good developer evangelist. People in technology have had their fair share of overpromise and slick sales people telling us things work that do – in fact – not. So you need to have the right “street credibility” or you’re just a sales person that tries to reach a very hostile audience. Personally I was in a lead developer role in a company when I transitioned. I didn’t see any more ways to get promoted on a technical level without moving into management. So I proposed the role of developer evangelist to help the company to improve our internal and external communication. I was lucky to find a sympathetic ear as this is a big issue for a lot of companies.

To start, you need to know what you want to talk about. You can’t only be a good presenter or writer, you also need to know the technical details and know what the market as a whole is doing. For developers or technical project managers who consider a role in DevRel it is a great idea to do a competitive analysis and find out what gets developers excited and how it relates to your company. Then you can start selling the idea of this role to your company. One thing to remember is that only your own excitement sells. If you don’t care about the technology you are supposed to promote or you don’t understand it, you will fail.

Do you developer evangelists work in every tech company? For example, is there a developer evangelist attempting to sell Candy Crush to developers or people looking for the next app to play?

I am pretty shocked how far this has grown. When I wrote the developer evangelism handbook there were only a few companies that had devrel departments. Now almost every technical startup has them.

However, the example of Candy Crush or next app to play is nothing a developer evangelist should do – at all.

King, the company behind Candy Crush most likely has developer evangelists. Instead of telling people about their new games they talk to game developers how to use their analytics, scoring mechanism and other internal features of games. Developer Relations (DevRel) is a hot topic now and a lot of people try to jump on the bandwagon. It kind of washes out the idea of what it is meant to do – improve communication between technical and non-technical people. Developers are a sought after community. They are early adopters and often they are ahead of the next wave of change in our markets. It is tough to hire talent, and it is even harder to retain them. A functioning DevRel department is there to make the technical people in your company be understood and proud of what they are doing. It is not about going to events and giving out T-Shirts.

Do you believe developer evangelists are just one of the many jobs people need to embrace/learn to do in the 21st century. If so, how should people start learning?

It is for sure one of the newer jobs and one that still needs proper definition. However, I would disagree that people should start as developer evangelists. It is a role technical people should transition into once they know your company’s products and goals. That doesn’t mean though that the skillset needed for it isn’t a thing everybody should be learning. We’re at a stage where technology evolves faster than humans. In the very near future it will not be about who can program, but who can use intelligent products that work for us in a sensible manner. Knowing what is happening at the bleeding edge of technology and finding simple ways to explain it is a skill that will become more and more important. It is especially important to make a conscious decision to avoid the drama and hype about technology. Right now, the tech world is getting a bad reputation of being horrible people who only look out for themselves and don’t care about what our products do to people. It is a good time to disprove this impression.

The beauty of our time is that the internet is a great place to learn all kind of things. You can use online courses to try out ideas and technologies for yourself and play with them. There is no certificate for developer evangelism. We’re still at a very early stage. You can use that as an opportunity.

These are the notes of my talk at DevRelCon in San Francisco. “Turning a community into evangelism helpers” covered how you can scale your evangelism/advocacy efforts. The trick is to give up some of the control and sharing your materials with the community. Instead of being the one who brings the knowledge, you’re the one who shares it and coaches people how to use it.

Why include the community?

First of all, we have to ask ourselves why we should include the community in our evangelism efforts. Being the sole source of information about your products can be beneficial. It is much easier to control the message and create materials that way. But, it limits you to where you can physically be at one time. Furthermore, your online materials only reach people who already follow you.

Sharing your materials and evangelism efforts with a community reaps a lot of benefits:

You cut down on travel – whilst it is glamorous to rack up the air miles and live the high life of lounges and hotels it also burns you out. Instead of you traveling everywhere, you can nurture local talent to present for you. A lot of conferences will want the US or UK presenter to come to attract more attendees. You can use this power to introduce local colleagues and open doors for them.

You reach audiences that are beyond your reach – often it is much more beneficial to speak in the language and the cultural background of a certain place. You can do your homework and get translations. But, there is nothing better than a local person delivering in the right format.

You avoid being a parachute presenter – instead of dropping out of the sky, giving your talk and then vanishing without being able to keep up with the workload of answering requests, you introduce a local counterpart. That way people get answers to their requests after you left in a language and format they understand. It is frustrating when you have no time to answer people or you just don’t understand what they want.

Share, inspire, explain

Starts by making yourself available beyond the “unreachable evangelist”. You’re not a rockstar, don’t act like one. Share your materials and the community will take them on. That way you can share your workload. Break down the barrier between you and your community by sharing everything you do. Break down fears of your community by listening and amplifying things that impress you.

Make yourself available and show you listen

Have a repository of slide decks in an editable format – besides telling your community where you will be and sharing the videos of your talks also share your slides. That way the community can re-use and translate them – either in part or as a whole.

Share out interesting talks and point out why they are great – that way you show that there is more out there than your company materials. And you advertise other presenters and influencers for your community to follow. Give a lot of details here to show why a talk is great. In Mozilla I did this as a minute-by-minute transcript.

Create explanations for your company products, including demo code and share it out with the community – the shorter and cleaner you can keep these, the better. Nobody wants to talk over a 20 minute screencast.

Share and comment on great examples from community members – this is the big one. It encourages people to do more. It shows that you don’t only throw content over the wall, but that you expect people to make it their own.

Record and teach recording

Keeping a record of everything you do is important. It helps you to get used to your own voice and writing style and see how you can improve over time. It also means that when people ask you later about something you have a record of it. Ask for audio and video recordings of your community presenting to prepare for your one on one meetings with them. It also allows you to share these with your company to show how your community improves. You can show them to conference organisers to promote your community members as prospective speakers.

Recordings are great

They show how you deliver some of the content you talked about

They give you an idea of how much coaching a community member needs to become a presenter

They allow people to get used to seeing themselves as they appear to others

You create reusable content (screencasts, tutorials), that people can localise and talk over in presentations

Often you will find that a part of your presentation can inspire people. It makes them aware of how to deliver a complex concept in an understandable manner. And it isn’t hard to do – get Camtasia or Screenflow or even use Quicktime. YouTube is great for hosting.

Avoid the magical powerpoint

One thing both your company and your community will expect you to create is a “reusable power point presentation”. One that people can deliver over and over again. This is a mistake we’ve been doing for years. Of course, there are benefits to having one of those:

You have a clear message – a Powerpoint reviewed by HR, PR and branding and makes sure there are no communication issues.

You have a consistent look and feel – and no surprises of copyrighted material showing up in your talks

People don’t have to think about coming up with a talk – the talking points are there, the soundbites hidden, the tweetable bits available.

All these are good things, but they also make your presentations boring as toast. They don’t challenge the presenter to own the talk and perform. They become readers of slides and notes. If you want to inspire, you need to avoid that at all cost.

You can have the cake of good messaging and eat it, too. Instead of having a full powerpoint to present, offer your community a collection of talking points. Add demos and screencasts to remix into their own presentations.

There is merit in offering presentation templates though. It can be daunting to look at a blank screen and having to choose fonts, sizes and colours. Offering a simple, but beautiful template to use avoids that nuisance.

What I did in the past was offering an HTML slide deck on GitHub that had introductory slides for different topics. Followed by annotated content slides how to show parts of that topic. Putting it up on GitHub helped the community adding to it, translating it and fork their own presentations. In other words, I helped them on the way but expected them to find their own story arc and to make it relevant for the audience and their style of presenting.

Delegate and introduce

Delegation is the big win whenever you want to scale your work. You can’t reap the rewards of the community helping you without trusting them. So, stop doing everything yourself and instead delegate tasks. What is annoying and boring to you might be a great new adventure for someone else. And you can see them taking your materials into places you hadn’t thought of.

Delegate tasks early and often

Here are some things you can easily delegate:

Translation / localisation – you don’t speak all the languages. You may not be aware that your illustration or your use of colour is offensive in some countries.

Captioning and transcription of demo videos – this takes time and effort. It is annoying for you to describe your own work, but it is a great way for future presenters to memorise it.

Demo code cleanup / demo creation – you learn by doing, it is that simple.

Testing and recording across different platforms/conditions – your community has different setups from what you have. This is a good opportunity to test and fix your demos with their hardware.

Maintenance of resources – in the long run, you don’t want to be responsible for maintaining everything. The earlier you get people involved, the smoother the transition will be.

Introduce local community members

Sharing your content is one thing. The next level is to also share your fame. You can use your schedule and bookings to help your community:

Mention them in your talks and as a resource to contact – you avoid disappointing people by never coming back to them. And it shows your company cares about the place you speak at.

Co-present with them at events – nothing better to give some kudos than to share the stage

Introduce local companies/influencers to your local counterpart – the next step in the introduction cycle. This way you have something tangible to show to your company. It may be the first step for that community member to get hired.

Once trained up, tell other company departments about them. – this is the final step to turn volunteers into colleagues.

Set guidelines and give access

You give up a lot of control and you show a lot of trust when you start scaling by converting your community. In order not to cheapen that, make sure you also define guidelines. Being part of this should not be a medal for showing up – it should become something to aim for.

Define a conference playbook – if someone speaks on behalf of your company using your materials, they should also have deliveries. Failing to deliver them means they get less or no support in the future.

Offer 1:1 training in various levels as a reward – instead of burning yourself out by training everyone, have self-training materials that people can use to get themselves to the next level

Have a defined code of conduct – your reputation is also at stake when one of your community members steps out of line

Define benefits for participation – giving x number of talks gets you y, writing x amount of demos y amount of people use give you the same, and so on.

Official channels > Personal Blogs

Often people you train want to promote their own personal channels in their work. That is great for them. But it is dangerous to mix their content with content created on work time by someone else. This needs good explanation. Make sure to point out to your community members that their own brand will grow with the amount of work they delivered and the kudos they got for it. Also explain that by separating their work from your company’s, they have a chance to separate themselves from bad things that happen on a company level.

Giving your community members access to the official company channels and making sure their content goes there has a lot of benefits:

You separate personal views from company content

You control the platform (security, future plans…)

You enjoy the reach and give kudos to the community member.

You don’t want to be in the position to explain a hacked blog or outrageous political beliefs of a community member mixed with your official content. Believe me, it isn’t fun.

Communicate sideways and up

This is the end game. To make this sustainable, you need full support from your company.

For sustainability, get company support

The danger of programs like this is that they cost a lot of time and effort and don’t yield immediate results. This is why you have to be diligent in keeping your company up-to-date on what’s happening.

Communicate out successes company-wide – find the right people to tell about successful outreach into markets you couldn’t reach but the people you trained could. Tell all about it – from engineering to marketing to PR. Any of them can be your ally in the future.

Get different company departments to maintain and give input to the community materials – once you got community members to talk about products, try to get a contact in these departments to maintain the materials the community uses. That way they will be always up to date. And you don’t run into issues with outdated materials annoying the company department.

Flag up great community members for hiring as full-time devrel people

The perfect outcome of this is to convert community members into employees. This is important to the company as people getting through the door is expensive. Already trained up employees are more effective to hit the ground running. It also shows that using your volunteer time on evangelism pays off in the long run. It can also be a great career move for you. People hired through this outreach are likely to become your reports.

I just had a journalist ask me to answer a few questions about developer evangelism and I did so on the train ride. Here are the un-edited answers for your perusal.

In your context, what’s a developer evangelist?

As defined quite some time ago in my handbook (http://developer-evangelism.com/):

“A developer evangelist is a spokesperson, mediator and translator between a company and both its technical staff and outside developers.”

This means first and foremost that you are a technical person who is focused on making your products understandable and maintainable.

This includes writing easy to understand code examples, document and help the engineering staff in your company find its voice and get out of the mindset of building things mostly for themselves.
It also means communicating technical needs and requirements to the non-technical staff and in many cases prevent marketing from over-promising or being too focused on your own products.
As a developer evangelist your job is to have the finger on the pulse of the market. This means you need to know about the competition and general trends as much as what your company can offer. Meshing the two is where you shine.

How did you get to become one?

I ran into the classic wall we have in IT: I’ve been a developer for a long time and advanced in my career to lead developer, department lead and architect. In order to advance further, the only path would have been management and discarding development. This is a big issue we have in our market: we seemingly value technical talent above all but we have no career goals to advance to beyond a certain level. Sooner or later you’d have to become something else. In my case, I used to be a radio journalist before being a developer, so I put the skillsets together and proposed the role of developer evangelist to my company. And that’s how it happened.

What are some of your typical day-to-day duties?

Helping product teams write and document good code examples

Find, filter, collate and re-distribute relevant news

Answer pull requests, triage issues and find new code to re-use and analyse

Help phrasing technical responses to problems with our products

Keep in contact with influencers and ensure that their requests get answered

Coach and mentor colleagues to become better communicators

Prepare articles, presentations and demos

Conference and travel planning

How often do you code?

As often as I can. Developer Evangelism is a mixture of development and communication. If you don’t build the things you talk about it is very obvious to your audience. You need to be trusted by your technical colleagues to be a good communicator on their behalf, and you can’t be that when all you do is powerpoints and attend meetings. At the same time, you also need to know when not to code and let others shine, giving them your communication skills to get people who don’t understand the technical value of their work to appreciate them more.

The main benefit is developer retention and acquisition. Especially in the enterprise it is hard to attract new talent in today’s competitive environment. By showing that you care about your products and that you are committed to giving your technical staff a voice you give prospective hires a future goal that not many companies have for them. Traditional marketing tends to not work well with technical audiences. We have been promised too much too often. People are trusting the voice of people they can relate to. And in the case of a technical audience that is a developer evangelist or advocate (as other companies tend to favour to call it). A secondary benefit is that people start talking about your product on your behalf if they heard about it from someone they trust.

What significant challenges have you met in the course of your developer evangelism?

There is still quite some misunderstanding of the role. Developers keep asking you how much you code, assuming you betrayed the cause and run the danger of becoming yet another marketing shill. Non-technical colleages and management have a hard time measuring your value and expect things to happen very fast. Marketing departments have been very good over the years showing impressive numbers. For a developer evangelist this is tougher as developers hate being measured and don’t want to fill out surveys. The impact of your work is sometimes only obvious weeks or months later. That is an investment that is hard to explain at times. The other big challenge is that companies tend to think of developer evangelism as a new way of marketing and people who used to do that can easily transition into that role by opening a GitHub account. They can’t. It is a technical role and your “street cred” in the developer world is something you need to have earned before you can transition. The same way you keep getting compared to developers and measured by comparing how much code you’ve written. A large part of your job after a while is collecting feedback and measuring the success of your evangelism in terms of technical outcome. You need to show numbers and it is tough to get them as there are only 24 hours in a day.
Another massive issue is that companies expect you to be a massive fan of whatever they do when you are an evangelist there. This is one part, but it is also very important that you are the biggest constructive critic. Your job isn’t to promote a product right or wrong, your job is to challenge your company to build things people want and you can get people excited about without dazzling them.

What significant rewards have you achieved in the course of your developer evangelism?

The biggest win for me is the connections you form and to see people around you grow because you promote them and help them communicate better. One very tangible reward is that you meet exciting people you want to work with and then get a chance to get them hired (which also means a hiring bonus for you).
One main difference I found when transitioning was that when you get the outside excited your own company tends to listen to your input more. As developers we think our code speaks for itself, but seeing that we always get asked to build things we don’t want to should show us that by becoming better communicators we could lead happier lives with more interesting things to create.

What personality traits do you see as being important to being a successful developer evangelist?

You need to be a good communicator. You need to not be arrogant and sure that you and only you can build great things but instead know how to inspire people to work with you and let them take the credit. You need to have a lot of patience and a thick skin. You will get a lot of attacks and you will have to work with misunderstandings and prejudices a lot of times. And you need to be flexible. Things will not always go the way you want to, and you simply can not be publicly grumpy about this. Above all, it is important to be honest and kind. You can’t get away with lies and whilst bad-mouthing the competition will get you immediate results it will tarnish your reputation quickly and burn bridges.

What advice would you give to people who would like to become a developer evangelist?

Start by documenting your work and writing about it. Then get up to speed on your presenting skills. You do that by repetition and by not being afraid of failure. We all hate public speaking, and it is important to get past that fear. Mingle, go to meetups and events and analyse talks and articles of others and see what works for you and is easy for you to repeat and reflect upon. Excitement is the most important part of the job. If you’re not interested, you can’t inspire others.

How do you see the position evolving in the future?

Sooner or later we’ll have to make this an official job term across the market and define the skillset and deliveries better than we do now. Right now there is a boom and far too many people jump on the train and call themselves Developer “Somethings” without being technically savvy in that part of the market at all. There will be a lot of evangelism departments closing down in the nearer future as the honeymoon boom of mobile and apps is over right now. From this we can emerge more focused and cleaner.
A natural way to find evangelists in your company is to support your technical staff to transition into the role. Far too many companies right now try to hire from the outside and get frustrated when the new person is not a runaway success. They can’t be. It is all about trust, not about numbers and advertising.

Having analysed a lot of conference talks lately, I found a few things that don’t work when it comes to keeping to the time you have as a speakers. I then analysed what the issues were and what you can do to avoid them and put together a new chapter for the Developer Evangelism Handbook called “Keeping time in presentations“.

All this information is applicable to conference talks. As this is a handbook, all of it is YMMV, too. But following these guidelines, I always managed to keep on time and feel OK watching some of my old videos without thinking I should have done a less rushed job.

This one gives advice why it is not a great plan to publish company specific information on your personal blog or social media channels but instead on the official, company sanctioned ones. That way you don’t cause internal controversy and leave yourself open to moving on without burdening yourself with maintenance of information you don’t control.

In short: your company’s products are not there to promote you or your blog. You are there to promote the products and bring people to where the up-to-date, officially maintained information is. That is what being a developer evangelist is about.

Meet 10 already existing or new Evangelism Reps and deliver a great training to get them started.

I easily achieved that mission but I was a bit disappointed when I saw that we only had an hour of training rather than the originally planned 2 hours. I partnered with the man who got me excited about Mozilla in the first place, Tristan Nitot, to introduce the attendees of our training to the Mozilla mission and get them excited about presenting and producing posts, screencasts and code examples.

When I plan trainings, I have something for every minute of it and the main trick is to make the attendees do the work. This is not because I am lazy, but as humans we tend to retain information we found out by ourselves much better than things we just listened to. The plan for this session was:

00.00 – 05.00 – Introduction and aim of the course
“By the end of this training you know where to find information to promote Mozilla in person and on the Internet”

The idea is to have four groups and make them each for 4 minutes collect information on the topic and then shift around, so in the end each group has their own findings and those of others to use in their presentations.

So much for the theory – 10 people had signed up for our session which is a good size. When our session started though, about 45 showed up and we had neither the whiteboards in place or enough chairs, so we had to get them from other rooms.

The beauty of the 4 group training is that it scales so in the end we had groups of 12 people which made for longer discussions and appointing speakers but it worked out. Incredibly well, actually – I am always amazed how you can make a group of people work very concentrated together when you set a simple goal and a fixed time frame.

As there was a lot more interest in evangelism training Shezmeen Prasad and me thought it a good idea to offer another, after-mozcamp session in the hotel. We set it on Sunday at 8 – 10pm after two days of a packed schedule and again wondered if anyone would show up. They did, 35 of them this time.

As the room layout did not really lend itself to a training in the style of the other we spent the two hours with open Q&A about speaker tips and tricks and watching a few talks analysing how the speakers made them great – again in a group information gathering and presenting session.

As a follow-up (and as this was a common request) I cleaned up the HTML5 slide deck we have for evangelism reps and created two screencasts on how to get the slide deck and present in it and how to write your own slides.

I find, however, that there is still a lot of confusion as to what developer evangelists do, and I also find lately that a lot of very obvious marketing and PR messages get sold as developer evangelism.

What we do as developer evangelists

Developer evangelism for me started out of the necessity to have an unbiased, sane voice for developers out there. We don’t sell products, we explain them and let developers make their own decisions about using them. Our main goal is word of mouth and people using the materials we provide. This means first and foremost one thing: being honest and real about what a product does and how it is useful for developers.

We also need to be the spokespeople for developers in our companies. We should know what people use out there and what they want, what excites them and how our products match those needs.

And this is where a skill comes in that can rub people with traditional marketing and PR tasks and skills the wrong way which I call pre-emptive writing.

What is pre-emptive writing?

What I mean by pre-emptive writing is that when you for example blog about a product you do not only praise its usefulness and show what it does for people but you also slip out of your role as a salesperson. Instead think of how you as a developer would read this were you a fan of a competing technology or other products.

Then you include and answer the arguments that you would write as comments to your own post playing that devil’s advocate. Instead of taking the traditional route of not mentioning flaws that might go undetected or obvious similarities to other products you mention them with the arguments that make them interesting for you. For example:

If your product has a flaw that needs ironing out you mention what can happen and how to recover or fix the issue. You also list the obvious feedback channels people can use should that problem happen to them. As developers we know that stuff breaks – it is ridiculous to claim otherwise and let people find out the hard way

If your product is very close to a competitor’s you explain that this is the case as the other product is a very useful thing and it wouldn’t make sense to reinvent the wheel if it runs smoothly. You point out the differences and benefits your product has – for example that it ties into a larger set of products or that it is available open source or performs better in a head-to-head comparison. People make these comparisons in any case – if you anticipate and do them in their stead they see that you are one of them and that you are not blinded by your own advertising. If the similarities are very obvious it would make you look like a very uninformed person or not very skilful liar not mentioning them

Why is this important?

Three words: de-trolling your feedback. Right now our jobs can be incredibly frustrating as the feedback we get (and marketing and PR also looks at) is largely polarised. You either have fans praising what you do over the moon or fans of your competitors pointing out that they already did the same and you are catching up.

Of course you also have comments full of vitriol by people who just hate what your company does and want to repeatedly tell you that, but that is a thing you can happily ignore.

By pointing out the obvious pros and cons of your product to people you prevent a lot of obvious hateful or overly excited comments. Yes, this will cut down on the number of comments you will get but it will also start a more interesting conversation.

Another effect of pre-emptive writing is that you don’t have to prepare a counter-statement – you already did that. In a traditional marketing world this is what you do. You don’t say what’s wrong but you prepare a statement for the press when things go wrong. In most cases you prepare this statement after things went wrong with a lot of stress, phone calls and “we need to deal with this now, people are re-tweeting and re-posting the bad messages all over the place”. This is stress we can avoid.

Getting pre-emptive writing out can be tricky as it is against a lot of basic beliefs of sales and marketing. But you are a developer evangelist – this is your job. Pre-emptive writing and constantly questioning your own products makes you one of your audience and keeps you their spokesman – a developer evangelist.

As part of the Mozilla Evangelism Reps program, I am right now preparing a training on how to learn from other talks. As a demo I went through a few talks showing what makes them interesting and pointing out good tricks the speaker (in most cases subconsciously) used and how you could use that for your own talks.

I really enjoyed this talk as it shows that enthusiasm about a subject matter and just “having a go” can work out really well. It also shows that everything can go wrong when you present and that it isn’t the end of the world – you just need to move on swiftly.

Today the Developer Engagement Team has launched the Evangelism Reps program – a special interest group within ReMo. Each year, we get thousands of requests to send Mozilla speakers around the world to talk about HTML5, new web technologies, Mozilla’s mission, our projects, products and more. Now, we would love for you to join the effort and become a Mozilla speaker too!

This program is open to paid staff and Mozilla Reps of all skill levels and capabilities. If you are a new speaker and have always wanted to represent Mozilla at events, you can take advantage of our advanced speaker training where you can learn from people like Christian Heilmann and Robert Nyman on how to give effective presentations and get access to their best practices. People who are veteran speakers can also benefit by having the tools and resources available to host events, prepare stunning screen casts and be mentors to new Evangelism Reps.

We encourage all current Mozilla speakers to please join our Speaker Database even if you don’t join the Evangelism Reps program. This will help us know who you are and match you up with the speaking opportunities that fit you best.

One of the things we want participants in the The Evangelism Reps program to do is give us a quick introduction video of themselves to have a face to connect to a name. This should not be anything big, a simple, “hi, here I am” will suffice. So here is my introduction as an example.

All in all the production and publication time of this was an hour – and that included cycling a mile to find a shop that has Tofu sausages and Babybel cheese. Here’s what I used:

A MacBook Air (could be any laptop with a camera)

Photobooth (or any other tool that can record a camera – this could be on your mobile, too)

The first thing to remember when trying to do something like this is to simply for go for it. So I wrote myself a little script and just had it open next to the recording tool:

Technically, this is not good, but I wanted to do this quickly. You can see my eyes flicking to my script from time to time. I shouldn’t have to as I knew what I wanted to say but humans work that way. Give us a “Linus blanket” and we will always come back to it.

What’s Inside

As a member of the SchoolofWeb.org you will have access to:

* Web design, Web development and Web business resources including educational content, custom curriculum and training resources covering advanced techniques, and the most up-to-date best practices and methods
* Lesson plans for those that teach
* How-to guides to establish a Web professional program at your school or college
* Web professional directories
* Web professional job boards
* Web professional career guides

National Web Design Contest HTML and CSS Training Video

2018 Summer Class

WebProfessionals.org (aka the World Organization of Webmasters) has a 20+ year history of supporting practicing professionals and those that teach them. We also support aspiring web professionals. To that end, we are offering a summer class fro high school students and adult learners who would like to know more about creating web pages. This two week online course can be started any time from June 1, 2018, through late July, 2018. All assignments must be completed before August 10, 2018. Learners will have direct access to a teacher (who is available to answer questions and provide support and encouragement).