I attended the No Code Conf in San Francisco on November 13, 2019. This blog post is my conference recap. I also added some opinion and history of No Code space.
The main theme of the conference (in my opinion) was: the are millions of people who want to create and build solutions but they don’t know how to code. No Code will allow these folks to build applications without code. No Code allows to focus on customer experience and value, not on servers. No Code is going to democratize software development.
I know this is a lot so let’s unpack this.
Democratize software development
Today there about 24-25 millions developers in the world which means only about 0.3% of people today know how to create software, invent new things.
Scaling your Developer Relations program is a challenge faced by virtually all organizations. It doesn’t matter if you are a startup with 10 people or IBM – you still need to scale your efforts.
IBM probably has one of the biggest Developer Relations organizations in the world. Even with such size, Developer Advocates cannot be everywhere to host in-person workshops, meetups and attend conferences. You cannot scale with people.
Even if you could send a Developer Advocate to every meetup or conference, there are many more developers who don’t attend meetups or conferences. There are many reasons, maybe they leave in an area where there are no meetups or they don’t have conference travel budget. You need to reach these developers and also scale.
The way to scale a program is through content, online meetups (webinars), videos and online forums. I shared how to scale with online meetups and content before:
All these resources are available to anyone with an internet connection regardless of location and can be consumed any time of the day or night. In addition, all these digital resources can provide value for a long time, months or even years.
On September 24-25 I attended the Future Developer Summit in Menlo Park, CA. It’s an event where about 60+ leaders discuss the future of developer marketing and developer relations. Here are pictures from the event. I created collages so you will see more than 10 pictures 😉
On Friday, September 27 IBM Developer SF hosted a 1-day Containers Developer Summit. We started with a hands-on workshop on how to build your first container-based application followed by talks from Alibaba, Kong, Robin.io and IBM. Here are 10 pictures from the summit.
On July 29, 2019 I attended the SF DevRel meetup at MuleSoft. The meetup was held at the Salesforce Tower. Jordan Schuetz and Sabrina Marechal from MuleSoft gave an overview of MuleSoft’s Developer Relations program. The following are my notes and what I learned. Based on what I learned, MuleSoft has an excellent Developer Advocacy team and program 👏.
Sabrina is sharing how she built and mananges MuleSoft community
Nicolas is starting the meetup
Jordan is sharing contet strategy and metrics
Note: I highlighted (bold) their best approaches, in my opinion.
We also tried something new at this summit (our two other summits are AI/ML summit and Blockchain summit). We hosted a hands-on workshop before the main talks. We created three self-paced serverless tutorials that people can complete in under 10 minutes. As people would come in, they would take a printed tutorial handout (two or all three of them) and go and code them. It’s a great way to get some hands-on training. We of course had Developer Advocates to answer any questions.
Last week we hosted another 1-day developer education event: Blockchain Developer Summit (our previous event is here and here). The event was a huge success with over 140 technologists in attendance. Here are 10 pictures (or more) from the event.
Make users happy and successful with your product/service
Get users to be awesome in the least possible time
Different companies can have different curves
Background knowledge and experience of users (don’t control)
Quality of documentation and teaching material (control)
The actual design of the product/API (control)
The size and helpfulness of your community
We often disagree with Product Managers and Engineers because PMs and Engineers think they are at a different place on the curve. PM and Engineers are familiar with the service/product and usually don’t experience “learning” about the service/product like outside developers
PMs on the curve
Engineers on the curve
Think about the audience (who you are targeting and how to get the pas the suck zone ASAP)
If we can’t get people out o the suck zone before they give up – we will never get them to experience power
Remember, when “talking” to others, to think about where they are on the curve
Use the curve when it helps, ignore it when it is doesn’t