Happy Developers
Best Practices

Tips On How To Run Great Workshops

I have worked on large scale evangelism and ecosystem projects in both the hardware and software markets at global scale for many years now. I got my start in ecosystem management and technical evangelism at Mashery, which was subsequently acquired by Intel prior to being spun off to TIBCO. At the time, Mashery had a network of 50+ customer APIs being hosted on it’s developer API portal.

At Mashery, it was my job to work with a team of global technical evangelists to train lots and lots of developers in how to make use of our customer’s APIs. It was a master class in technical evangelism: During this time, I personally supported more than 60 workshops and hackathons and trained tens of thousands of developers on how to use Mashery APIs. 

Here are a few things that I learned along the way about running great workshops, I hope you find this useful! If you are planning or interested in running workshops at scale for your own platform or technology, feel free to reach out to say hello.

Tips On How To Run Great Workshops 

Running Workshops

The goal of running a workshop: Generally speaking, my goal whenever I ran a workshop was to get developers to walk through a setup process and familiarize themselves with the technical platform I was hoping to convince them to adopt. An advanced goal would be to design a workshop which has “take home” value that continues engaging developers after the event. One of the key elements in running a workshop for me was always aiming to get developers to an “Aha!” moment. There should be some sort of personal feeling of reward for completing a workshop where the developer feels that they have learned to do something neat that they couldn’t do before.

If you have a great product or platform – by definition you are helping developers do something faster and more easily than they could before. Another great goal is to get direct developer experience feedback on your product allowing you to fix potholes in your designs, documentation, sample code and user interface. 

Have a printed packet: Technical skills tend to be distributed on a Normal Curve with 10% of your audience being “super capable” and another 10% being early beginners. Some developers can shoot through every step of your getting started process in a couple minutes and are immediately bored. If you make the high achievers wait while you complete a 75 minute slide show about “how to do the basics of my platform” talk, these overachievers are going to be bored out of their minds. Providing people with a printed packet which includes “advanced” topics allows this group to work ahead on their own and feel challenged. Let developers self guide if they want, provide difficulty tiers so people in the room can customize their challenge level.

Don’t hand out hardware until you are done talking: One thing I learned while evangelizing hardware is that if developers sit down with a device in front of them, their attention span is gone. You can get on stage, shout, bang a drum, show slides and they are going to ignore most of what you say. If you do have hardware devices for developers to play with, you might want to hold them back until you finish your prologue (which should be very short). It can be really time consuming to have to answer the same questions 50 times because everyone in the room ignored your “How to get started” slide show because they immediately started tinkering when they sat down. You can avoid this problem by handing out devices AFTER you talk.

Your workshop should have “Take Home” value: One of the big problems with doing workshops in general is that developers may use your platform, take your hardware home, enjoy it once and never work on it ever again. The ultimate objective is to drive long-term engagement with your platform. For this reason, you might want to consider designing your workshop so that developers walk out of the event with something that is useful at home or in their normal lives. A great example of this are the AI badges that Adafruit sells. Developers can build these badges, take them home and then bring them to other events or continue experimenting with them. That is a good workshop. 

Running Workshops

Closing Thought: Developers have extremely limited attention spans

This is a problem I have seen more at larger companies: Developer evangelists get on stage and show a massive slide deck going through every nook and cranny and sub-product line that their parent company produces. Slight problem? Nobody cares. Want to know what developers care about? “How do I build a neat thing right now.” It isn’t a bad assumption to imagine that every word you say is not remembered or understood. This is why printed packets are so helpful – Developers can check and recheck on their own to look back at what they may have missed. 

Workshops are not the place to advertise your company or your products, at least not for very long.