The Call for Participation for Grace Hopper Celebration just closed last week, and I saw a flurry of proposal submissions on Twitter. I am very excited to see so many people stepping up to speak, but I have some bad news:
Your proposal will probably be rejected
GHC attracts a lot of proposals. A lot. Women from all walks of computing submit their talk ideas. In the past years I have heard a lot of excellent proposals being rejected. Bottom line, it is a very competitive process.
Don't waste your proposal
Now that you have written your proposal, you should submit it to other conferences. There are always conferences looking for speakers. Some resources:
Write/Speak/Code is the first conference I tried sketchnoting, and people loved it. I was really surprised because I still consider myself someone who cannot draw, but somehow I am good at sketchnoting. How come?
Constraint satisfaction problem
Naturally, I will explain my approach with a sketchnote:
When I took Alexis' sketchnotes class three years ago, I was really hung up on the idea that I needed to draw. The repertoire of shapes and objects that I can draw is really small, so I never actually tried sketchnoting after the class.
What changed? I flipped the problem around. I phrased it as a constraint satisfaction problem. I am using a small toolbox to express ideas I heard. And as an engineer, I am extremely good at that.
In the sketchnote above, I wanted to convey the idea that illustrations do not need to be realistic. At first I wanted to draw two trees, one realistic, one not. But alas, I cannot draw a realistic tree. Instead of giving up, I worked around by drawing a box with a dotted line to represent the realistic tree that I am unable to draw. Problem solved.
I am not kidding when I say my toolbox is small. You can see it in the sketchnote. The plain old notes vs sketchnotes part. That is literally my toolbox.
The most important thing I picked up from the book is to use pen instead of pencil. This forces me to always make progress instead of erasing and re-drawing and second-guessing myself. It also makes me more forgiving of my mistakes, and come up with creative ways to fix them.
In the toolbox about bullet lists, I made two bullets with stars, because a single bullet doesn't make a list. And then I realized that I have nothing to more to say. What to do? The second star was already drawn. With ink.
I ended up writing "There is no second point" next to the second star. And you know what? It now emphasizes the fact that it doesn't take much to make sketchnotes.
A lot of serendipity came from using a pen and being forced to make things work.
Find your style
I really enjoyed the The Sketchnote Handbook because it includes examples from many sketchnoters. I pick and choose techniques that works for me:
Some sketchnotes are very free form, popping images left and right seemingly randomly. That terrifies me. But many examples use a grid style. I came up with my own layout algorithm: top to bottom, and if an item took too little horizontal space, put something next to it. This is very similar to traditional note taking, just using a bit more horizontal space. I can do that.
Some sketchnotes fill the whole page, and the pressure to do so paralyzes me. But many examples have whitespace between the items, and that is totally okay.
The book recommended using a vertical layout for panels, drawing the face of one panelist on each column. There is no way I can draw portraits. So I skipped that part. But it also showed a few simple ways to draw people. Now Starfish Man is a regular cast member in my sketchnotes.
Share
This is the most potent motivator: Twitter. You know how some people take a screenshot of a block of text to get around the 140 character limit? That looks stupid. But I can totally post a sketchnote to stuff more content into a tweet. And it looks awesome. So awesome that I get lots and lots of retweets, which gave me the confidence to do more sketchnotes, which gets more retweets.
The third day of Write/Speak/Code is dedicated to contributing to open source.
Speaker buddies offsite
I have known my fellow writing panelist Corey Latislaw for a while, and we have always been speaking buddies, pushing and supporting each other. Rather than attending code day, we decided to have an offsite to catch up.
Yes, we played hooky for a leisurely brunch at Feast and a lovely walk on High Line. And we talked about our next steps as public speakers, brainstormed talk ideas, and plotted the steps to make it happen. This is the hallway track taken to the next level :)
The art of being awesome
We headed back to the conference just in time for Jen Myers's talk.
The awesome machine
"Awesomeness begets more awesomeness"- this perfectly sums up #WSC2015conf. Big congrats to the team! Looking forward to what comes next :D
Write/Speak/Code is a great combination of practical advice and dedicated time to write, to speak, and to contribute to open source. It is also a congregation of amazingly awesome women, pushing and supporting each other. Everybody is super charged with energy, ready to take their endeavors to the next level. Or as Buzz Lightyear puts it, to infinity and beyond!
This is a part of the Write/Speak/Code series. Read more:
Intro,
Write,
Speak.
The second day of Write/Speak/Code is dedicated to speaking: writing a talk proposal, and giving a lightning talk.
Work in pairs
We started the day with a few exercise to brainstorm talk ideas and find a partner with similar interests. Each pair worked together throughout the day to write the talk proposal and prepare the lightning talk. Thisbuddy system is a brilliant idea, not only to bound off ideas during the day but also to hold each other accountable after the conference ended. I hope everyone will keep in touch with her partner and push each other to propose to conferences, help each other refine the talks, and cheer for each other as we all step on the stage!
To help us write better proposals, Write/Speak/Code put together a panel of conference organizers, sharing their experience on the other side of the table.
After the panel, we split into small groups, and speaker mentors gave feedback to the talk proposals written earlier.
Speaking Effectively About Your Work
Next lecture is from Melissa Collom on how to create engaging presentations.
Lightning talks
Just like Write day ended with writing, Speak day ended speaking: give a lightning talk! Each talk was recorded, so everyone received feedback on the spot and can also go back to watch and review their talk.
This is a part of the Write/Speak/Code series. Read more:
Intro,
Write,
Code.
I really like how Write/Speak/Code alternates between hands-on activities and lectures/panel. Next up is the writing panel, and I got to share my experience alongside Pam Selle, Debra Williams-Cauley, Julie Steele, and Corey Latislaw.
We concluded Write day by writing a blog post. I just stepped off the writing panel, and realized that I forget to share my blogging formulas, so I ended up writing a blog post on how I write conference reports. Oh so very meta!
This is a part of the Write/Speak/Code series. Read more:
Intro,
Speak,
Code.
When I heard about Write/Speak/Code, I know I want to be a part of it. My career has benefited tremendously from writing blog posts, speaking at conferences and sharing my code as open source, and I want to empower other women developers to do the same.
Make it happen
Once I decided that I want to help out at Write/Speak/Code, I need to figure out how to make it happen. I met Vanessa Hurst while we were both speaking at OSCON 2013, and she co-founded Write/Speak/Code, so I reached out to her. She put me in touch with the organizing committee, and while I was waiting for results from mentor nomination and selection, I decided to write a blog post in the spirit Write/Speak/Code and send that to the organizing committee. A few weeks later, they invited me to be on the writing panel and also be a speaker mentor. Yay!
I normally don't share stories like this, but I feel this is appropriate for Write/Speak/Code. If you want to speak at a conference, there are many ways to get in the door. Answering to an open CFP (Call For Proposals) is one way, but you can also reach out to the organizers directly. If you don't know them, get an introduction. Make it happen.
Write/Speak/Code
Write/Speak/Code is a 3-day conference, each day dedicated to Write, Speak and Code:
I wrote about my formula for writing technical articles. I also have one for trip reports, to talk about conferences I attended. Having a fixed structure means I can plug in the content from the conference and publish the blog post a day or two after the conferences ended, while it is still fresh on people's minds.
When Cate and I was touring Copenhagen, we talked about how we got into public speaking. One thing led to another, and we decided to publish a newsletter together. We had a little bit of time on Monday before Øredev, so we put together our first issue in the hotel lobby!
2. Highlights
I point out things that I enjoyed. This is pretty easy because I tweet during the conference, so I just embed the tweets in my blog. I also search for the conference hashtag and include other people's tweets.
I also include photos from the events. Photos are great because they take so much space that you post looks rich even if you did not write many words. Same goes for embedded tweets.
If I was speaking, I mention my talks, embedding or linking to slides and videos if available. Usually I keep this pretty short, assuming people can check out the slides or videos if they are interested.
To celebrate International Women's Day, Google Developer Groups all over the world are hosting Women Techmakers events. I organize the local chapter, GDG Boulder, and I thought this is a great opportunity to showcase the wonderful women techmakers in our community. Inspired by the popularity of Ignite Boulder, I decided to host a night of lightning talks.
Since I was new to the Boulder area, I don't know too many people. As a result I pretty much asked every single female developers I know if they would like to give a lightning talk. Some of them are from GDG Boulder, others are DevChix members I met over lunch. To my surprise, almost everyone said yes. I was expecting resistance because usually when I broadcast speaker request over mailing list, nobody replies. I have two theories:
Boulder people care about the community, ready to step up and contribute when asked.
Asynchronous broadcast aka email blast is a bad way of asking. Synchronous 1-to-1 is the trick.
When I asked someone in person or over instant messaging, they have to tell me yes or no on the spot. My suspicion is that it is difficult to say no, so I ended up getting quite a lot more yeses than I expected. On the other hand there is no cost to say no in an email broadcast. You just do nothing.
Spread the word
After I found speakers, picked a date and secured the venue, it was time to spread the word. I added the event to our Meetup page, and posted on social media as well. But what brought most of the attendees was cross posting to other local groups. Rylee Keys was especially helpful, inviting members of Women Who Code and Girl Geek Dinner to join us at the lightning talks.
Talk preparation
A few of my speakers said they have nothing to say, which such is a normal response when people get asked to give a talk that I actually gave a talk about it. I offered brainstorming help, and helped half of the speakers come up with their topics. I was ready to give feedback on the slides as well, but they procrastinated so much that there was no time to do it.
Master deck
I know everybody is busy, so I set out deadlines for the title and slides for the talks in advance, hoping that it would help some of them set aside time to prepare. And some of them did. But I needed to nag the rest during the last week, and it was quite stressful. Normally speakers can work on their slides until the last minute if they present from their own computers, but since each talk was only 5 minutes long, swapping machines constantly would be very disruptive. To avoid that I took cue from Ignite Boulder to have a master deck that combines decks from all the speakers. This means I needed the slides ahead of time, hence the nagging. I got the last deck an hour and a half before the event, and breathed a sigh of relief.
Clicker run-through
I have spoken at Ignite twice, both hosted by Brady Forrest. He runs a really smooth show, and one trick is to sit the speakers in the front row, in order of presentation. I totally stole that.
Unlike Ignite, I am not advancing slides automatically, so I brought a clicker for the speakers. I had the speakers come before the door opened to the public, lined them up in order of presentation in front of their seats, and did a clicker run-through. I started clicking through the intro slides, passed the clicker to the first speaker, had her review her slides while trying out the clicker, and passed it to the next speaker.
Show time
Door opened at 7pm, and slowly the room filled up. We had more than 100 attendees, which was really exciting. Here is the slide I projected when people were mingling before the event started:
See the hashtag? I wanted people to talk about the event on social media, and they took the cue:
I kicked off the event at 7:30pm, explained GDG Boulder and Women Techmakers, and turned the stage over to the first speaker. One after another, our speakers regaled us with fun and inspiring stories, ranging from freelancing to hackathons to refactoring to wearables.
Time flies when you're having a good time, and before we knew it the talks were over. I went back on stage and asked if everyone enjoyed the show. After an enthusiastic yes, I encouraged people to get in touch to give a talk as well, so we can have more events like this. A few people took up on my offer, and I am super excited to hear their stories!
Lightning talks is a great way to celebrate your community. Step up and make it happen! Here are some lessons I learned:
Invite speakers individually
Ask local groups to spread the word
Project the offical hashtag before the event starts to encourage social media engagement
Prepare a master deck for smooth speaker transitions
Sit the speakers in the front row, in order of presentation
Keep it going by encouraging attendees to speak. Add a question to your RSVP to ask if they want to give a talk. Make an announcement at the end of the event.
P.S. In the spirit of asking, the GDG Boulder Youtube channel needs 500 subscribers to get a custom URL. Will you be so kind to subscribe?
But to be honest, when Kelly invited me to be on the panel, I wasn't sure what I got myself into.
You see, I have seen many bad panels. The panelists showed up without any preparations, so instead of an insightful discussion, it was just a bunch of people spewing unorganized thoughts on stage.
Fortunately the panel last night was not like that. Far from it. The panel was very well put together, educational and entertaining all at once.
So, what makes a good panel? Contrary to popular belief, it's the moderator, not the panelists. True, the panelists are the ones talking most of the time, but the preparation before the event makes all the difference, and the moderator is in charge of that.
Kelly was a fantastic moderator. Here is what she did:
Invite panelists with various backgrounds
Send questions to the panelists ahead of time
Highlight the unique experience of a panelist by asking a question specific to one person
Contrast the different perspectives of all the panelists by having all the panelist answer the same question
There were 5 of us on the panel. Some are hackathon participants, others are judges. Some are developers, others are subject matter experts. We all received questions a week before the event, and were invited to add more. I was asked to define the different types of hackathons since I did that in my Ignite talk on hackathons at Google I/O, but everyone got to answer questions like "Why do you attend hackathons?"
A good moderator curates the content by assembling panelists with complementary skills, let them know what will be discussed ahead of time, and directs the flow of the conversation. The hackathon panel hits all these points, and it was a real pleasure to share my experience and learn from the other panelists at the same time.
