I have been working on the Technology Days/Akamai Meetups for over a year now. From somebody in a technical role this is something somehow strange. The first thing I realize is that organizing recurring event is not as easy as it seems. When I first started working on this initiative the goal seemed to be a small easy one: create a technical forum where customers, prospects, field experts, and Akamai gurus could interact freely and discuss the future of the web. I am glad it became a large enterprise, but I had my tense moment down the line. Here are some considerations if you are planning on organize events:
Have clear goals
Why do you want to do this and what is the benefit you are bringing to whom? It is a large and vague question but if you do not have an answer to it, then your event will mutate uncontrollably and you won’t be able to evolve it. Consider this requirement gathering. When your client call and say they want the moon swimming under water, you need to understand why.
What is in it for Attendees?
Don’t trust the myth that “if you build it, he will come”. Your audience will not come if you do explain them what they will get out of it. If you do not know the answer, how can they know?
What is in it for Stakeholders?
Your presenters, promoters, budget owners, managers, etc. will have to buy into it. Different stakeholders will have different goals. Be aware of them and incorporate them into your plan. If your stakeholder goal does not align with your initiative, have a good reason on why not and an argument on why the stakeholder should still support you.
This was my first and most painful error. The events started happening and I did not have a good way to prove its value other than saying “people showed up”. In order to be successful you need to know how success looks like. Consider this your value confirmation or test cases. On my technical role I normally take the position that if you cannot test it then it is not a technical requirement. In events, if you cannot prove they are creating "value" then they will not happen again.
For example, "people will be happier when visiting the site after implementing Akamai" is not a technical requirement. You need to dig into what happier means. It could be that page load below 3 seconds makes people happier, and that is something you can test.
NOTE: surveys are your friend
Another great learning from working at the Tech Day: share your wins. It is not good enough to keep your success in a spreadsheet and share it with those who ask you. You need to create your own marketing campaign and gain interest from people who do not know about your initiative. BTW – this also apply to that cool code you have been using and no one knows about it…
You cannot do it Alone
Repeat: you cannot do it alone. Think on coding a new capability of function: everything looks good in your sandbox, but if you did no plan the code and architect it as an scalable solution, then you start overextending when you expand the code for release and needs to be supported.
Architect the event as if it were a new software/solution. Think on the expansion plan from the beginning and identify the resources you will need later. Convert those resources into stakeholders and include their goals into your plans.
Things are going to break
You know from working on technical projects that something will always break, so do not assume that planning an event is going to be any different.
I hope this tips helps you. In summary, you can do whatever you feel passionate about. Try to convert the language into something you understand and export the libraries that are useful for the new project.