We’ve just finished organising a Demo Day for Intel ® Edison a new maker hardware platform which was great fun.
After years of running Arduino workshops, corporate training days and other hardware centric events at Tinker it seems there is renewed interest in this format. The amount of press around the internet of things means new people are interested in supporting the rapid making / hacking of hardware. Sometimes it’s to promote a new platform or hardware, other times it’s to see if new novel investable ideas are created. After a recent conversation with an intern organising his first hardware event for a well known incubator program, I thought I’d share how we do things here as it might benefit others. This was also prompted by Arial Waldman’s excellent post on organising Science Hack Days.
I’m making a number of assumptions moving forward on this post:
- You have budget for hardware
- You have budget for technical experts
- You are running a 2-3 day event
- There is a commercial drive behind the event (otherwise you wouldn’t have budget for 1. or 2.)
- Attendance is free (meaning you will get a mix of attendees, not hand-picked ones)
0. What are you doing?
Before you open an excel spreadsheet and plan your event’s budget and timing, you’ve got to ask yourself what success looks like. Is it that you want new ideas, new prototypes and feedback on a hardware platform or simply entertain people by getting them to make things? Depending on the answer, your event will be very different.
If you want new ideas, forget about the hardware as coming up with an idea, developing a business case around it, and pitching doesn’t require any prototyping. Prototyping will have a role when you want to test your product idea with potential users and validate some of your assumptions. It will take you more than 3 days to do this well and this format is best addressed by longer design workshops.
If you want new prototypes or feedback on a platform read on.
1. Introduce everyone
Before you plunge into a 20 minute introduction, before you make teams, before you even say hello, make sure people have tools to introduce themselves. A sticky badge with their first name will do (corporate badges are often too small to read and make everyone feel like a tradeshow attendee). Then make sure you go around the room and get everyone (team & attendees) to say their name and profession. It’s simple, stupid and so very effective at getting people to acknowledge each other and get the team to think about who might need more or less help.
2. Tools don’t make ideas.
Organisers often think that by putting people in a room with a 3D printer, a laser cutter and some electronics this will generate great ideas. This is rarely the case.
You should always take the time to actually teach people how to use the tools you’re supplying from scratch on the morning of the first day, levelling the playing field as much as possible and getting everyone to learn something new and talk to each other.
Arduino is still my favorite platform because there is so much documentation and example projects shared by the community.
If you’re a new hardware or software platform provider, really make sure that documentation is available for a total beginner. You never know who your attendees will be, so don’t assume they know either anything about electronics or anything about code. Of you have a bunch of experts in the mix, just make sure they are sat next to each other and they will plough on ahead while you do the introductory bits.
3. Have basic materials
Not everyone will want to build a whole end product, so always make sure you have paper, scissors, glues, knives, cutting mats, a soldering iron and all manners of craft materials to get people going quickly. Play-doh, lego and the usual post-its and pens are also useful. I’ve ended up with a suitcase full of this that I take to events that we are running. It might not be used, but you never want to assume what kinds of ideas people will have.
4. Provide technical support
Providing technical help to attendees is really crucial when you’ve provided new tools. We have always designed events with teams of 2-3 attendees max and one technical expert per 2 teams. It’s a high ratio but you wouldn’t believe how important those people are to your event. Just because an attendee is sat at a computer looking serious, doesn’t mean they know what they’re doing. The role of your technical expert is to ask “how’s it going” over and over again and know when to let people get on with it after they’ve pointed them in the right direction. There’s also nothing worse than a technical expert who tries to build the thing for the attendee. It’s about building a sense of confidence in attendees. They are new to this, but once the event is over, they should know how to keep going on their own and know what resources to tap into.
5. Provide documentation
Stop printing pieces of paper, just put all your documentation on github. Even if your attendees have never heard of it, they’ll learn how to use it. Github will be key in building up the documentation needed between the workshop leader and the technical experts. Giving them a chance to add to the documentation and experiment before will make them more ready for questions.
6. Encourage team work but don’t push people into it
Just because you are trying to get a good mix of people, doesn’t mean they want to work with each other or will sync up at all. Get people to share their ideas on an ideas wall or online before the event and let teams naturally happen, or not. You won’t get better ideas if you force interactions between attendees. They’ll feel bossed around like kids.
7. Champion & document ideas
After an event, all the ideas that people are working should be documented and listed on github. People should be able to upload a picture of what they were working on, what they tried to build and the code they used. This is a great way of championing all the attendees and their work.
8. Always close with a demo
Another way of championing people is to get them to present what they have done to the rest of the group. You are closing their experience and making sure they work to a deadline. This is really important in making attendees feel like they’ve achieved something during their time. If you don’t do a closing demo, someone could simply bury themselves in a deep dark problem that might take weeks. If there’s a demo, they know they can’t focus on the deep dark problem and should just get on with getting something to work. Always clap (as Russell says) after each presentation and never give them more than 5-10 minutes to present or you’ll be there all night.
With all this, and the basics (feed them well, give them daylight) you should have a great time and accomplish your aims. Enjoy your hackday!