Ep. #4, Collaboration and Constraint with Nicolas Grenié of Typeform

Patrick Woods: Awesome. Thanks so much for coming on the show today, Nico. Could you tell us a little bit about who you are?

Nicolas Grenié: Yeah, thanks for having me.

I'm pretty excited about this podcast.

I'm Nicolas and I'm a developer advocate at TypeForm.

I've been there for two years, and I am also running the SF DevRel Meetup in San Francisco.

Patrick: Awesome. How did you get into the world of DevRel and community in the first place?

Nicolas: It's been about seven years, I will say, now.

The first time I got to be introduced to developer advocates, it was during my first internship in Silicon Valley where I discovered that I was a software engineer.

I was doing software during the day, I was hacking stuff, but I was spending most of my time in hackathons.

At that time the hackathons were new, and you will see all the companies that were starting, the Twilios, the Send Grids, the Firebase, they were all there.

They had those people that you will see every weekend and they were the developer advocates.

I don't think they were called developer advocates at that time, but that was my first introduction to it.

After a year in San Francisco going to a lot of hackathons I had to go back to France, and at that time a company called Mailjet, which was a European email provider, was launching.

They were looking for some people to help them go to the developer market in Europe, and this is basically how I get started doing some contracting for them and bringing the experience that I had from going to hackathons in San Francisco.

Patrick: Awesome. I love the San Francisco DevRel Meetup. I've been quite a few times.

I'm interested, what's the thing that keeps you going when you're organizing that thing month over month? I know it's got to be a lot of work.

Nicolas: The meetup, it's a really fun place and it's a good time to put a face on the user names that we see online.

We're all very connected through different social media that we use, is it through Twitter, is it through Slack, is it through GitHub.

Sometimes we don't get the opportunity to meet in person, so whenever everybody's around in the city it's great to meet in a meetup and build those relationships.

Because we're going to build some projects together, we are going to work on some things together for our different companies or just for fun, and it's also a good way to get people introduced to the space.

If they're just new and got a new job, just starting into the space, they get to meet other people that can eventually guide them or answer their first few questions they may have about being a developer advocate.

So, I really like this community aspect of "Let's build stuff together."

Patrick: Shifting gears a bit, what would you say is the secret to building things developers love?

Nicolas: There's no specific secret, but I think it has to be something that excites you first.

You're the first audience. You're a developer for most of the people in the space, we're all developers, and so you should be excited first.

For all the different reasons, is it because you are solving a problem that you've seen in one of your customers?

Is it a problem that you solved for someone that you've seen running a business? Or is it just to have fun?

This is where you get your excitement, and this is where you're building this.

This is something that's going to be shown in the way you render it.

Is it through the effort you put into the design?

Is it being the first to put into writing the blog post? People are going to feel this excitement.

If you try to fake it, and this is how I feel personally whenever I do something that I'm not 100% passionate, you can feel that it was not my first choice.

This is not the content that I want to deliver, but I was forced to do by sales, by marketing, by another force.

It ends up being an OK content that doesn't resonate as much with developers.

Patrick: What's your advice for companies that are trying to tap into that passion of their advocates or their community leaders, or whomever?

What's your advice for companies and getting their best, most passionate work?

Nicolas: I think everywhere, not specifically for developer advocates, but you've got to leave some space.

Creativity and passion can't really be ordered, and this is not something I can deliver every day eight hours a day, but if you give me the space and if you give us the time, if you give us the conditions to make it happen then it will happen naturally.

If you sometimes put too much processes, if you put some numbers like this week, this month, you have to create that much content, then the creativity aspect of it will disappear.

The impact that those people are going to have on the content will disappear.

Patrick: That's a great point.

It's interesting, because it may contrast a little bit with one of the hottest topics in our space right now, which is KPIs and measurement and improving ROI of DevRel and community activities.

How do you think you balance on one hand the creativity and having the space and not knowing when a project is going to be delivered because it just takes time, versus the business need to deliver results?

How do you rectify those two things?

Nicolas: It's a fine balance, for sure. It really depends on the size of the company, really depends on the different goals that the company have right now, as well as what they want to do with community.

But I think it's best where you have some actual number of goals and things that drive the global strategy, because we want to talk to JavaScript developers.

We're going to make all the efforts to have a proper JavaScript, SDK, etc.

Those things you can measure in terms of when they will be delivered, how they will be delivered, and the impact you will have on the business.

But then everything that comes around, how are we going to publicize this?

We should have a partnership we're going to build around this, which is the innovation and the creative aspect of it.

This is a bit harder to measure when you're doing the planning and a bit harder to measure after, but it doesn't mean that it's not valuable, and it doesn't mean that you should underestimate the time you should spend on those things.

This is probably more a long term goal, and a long term impact as well.

Patrick: Thinking about your own programs, how do you demonstrate that your efforts are paying off?

What are the things you track and demonstrate internally?

Nicolas: We can do better on tracking, but on the different things we track, mainly on this part around the content and the return we get from the community, we're using Glitch.

So one thing we track is the activity of a Glitch project in terms of views, so how many people are going to see that project in terms of remixes.

Which could be understood as a fork, so that shows us how many of the people really went and tried to activate that project.

It's a bit further than just starting a project and saying "I like it." This is more like, "OK. I want to try to implement it myself."

In our case, we use that measure to eventually push some product features, the API project that we have or usually leave on the side of the product for some of the projects, they are patches to features that don't exist in the product.

By measuring those things, we can see if there is some engagement, if that's something that people want and eventually that gets implemented.

Another way of doing this is by measuring the API calls and the OWASP traffic.

If we force everyone to go through OWASP, that gives us more data on how they onboard people and how many users are using their app.

By measuring those, we also see the trends of how many apps were created this month, how many made their first calls, and how many users it impacts on our site.

Patrick: That's really cool. In our community we all love tools, we love products. What's the one tool that you can't live without?

Nicolas: I will say, and I already mentioned that now, is Glitch.

That's my tool of choice, probably because it's easy to get started. I can create a Glitch project in two clicks, and certainly everything that I build is public so I don't have to worry too much.

It's going to be something that I can share at the end of the day, I can make a tweet about this.

I was like, "I spent the afternoon on this thing and now you can all use it."

Documentation on this project will be easier as well, it's going to be a markdown file and it's already there.

It's also a great tool for engaging people because for them it's easy to replicate and make it happen.

When I give examples on how to consume a web hook and do something with this web hook, I don't have to tell them about Angular.

I don't have to tell them about deploying into Heroku or other cloud services, everything comes built in.

It's like, "You just remix this to give the URL, and is this URL somewhere else? And you're already good to go."

It's easy to activate them and get them excited, so this is definitely for me, the tool of choice at the moment.

It helps me run workshops as well, everybody's on the same machine.

We don't have to think about libraries that you have to install first, we are all on the same environment so we really recommend people to invest in their team stage on Glitch

Patrick: Cool, right on. Thinking beyond tools, what's your favorite trick of the trade?

Nicolas: If I tell my secret sauce, it won't be secret. Is that what we said about magic?

For sure, there's probably shortcuts or things you can do that we can call low hanging fruit, mainly when it comes to content.

I think it's a good thing overall, usually.

If you want to give more impact and more visibility to your content, it's always great to do that with someone else and it's always great to bring someone else on board.

Yes, you want to demonstrate your product and you want to demonstrate your technology, but what if you added another API on it?

What if you added another project to it?

Then suddenly you're talking to two communities, three communities at a time, and that gives you a bit more reach.

The other thing that I really like as a trick is whenever you start something like this, is to try to put new constraints.

So, today I want to learn about React in something else with my product.

I want to make that constraint clear, and this is the things that I want to explore.

I don't know anything about GraphQL, today I'm going to make a GraphQL example.

Learning as a beginner, what it takes, and how you can add GraphQL with my tool or how you make simple things.

So, before starting, what are the rules of your project?

Put the boundaries of it, it makes the game a bit more fun because if you're into your muscle memory of "I already know all the tools or all the frameworks," then you lose the innocent aspect of discovering a new technology.

It's always good to get the perspective back.

I think that that comes from putting limits and boundaries on your stack and projects.

Patrick: Yeah, that's great. You mentioned two things in that answer, one is partnerships and the other is constraints.

I want to jump back to the partnerships aspect of that answer briefly, so what's your advice to other DevRel and community leaders in terms of attracting partners and collaborators?

What's your process for making that a successful experience for all parties involved?

Nicolas: I think we've done that very naturally.

Again, that's nothing that has to be forced.

This is usually-- This is where the meetups and the community is great, is "I have a good feeling with that person. I think it's something that will work naturally. Let's try to work together on one project."

And eventually that can become a theory and eventually that can become a bigger involvement, but I think for us as developer advocates, we could be part of the biz dev organization that specifically works on partnership.

When we do that, they really are driven by sales number or are they driven by adoption?

Be like, "OK. We should have an integration with those people because that's going to grow our business. This is how much money it's going to bring."

Whereas us, we're more like, "Let's be a bit more genuine and see how things connect. Let's do it the hackish way at the beginning, and eventually we can work on something bigger once we've proven that there is adoption or there is interest. Now we can make a full on integration and we'll pass that to a regular engineering team to make the whole work."

But that's something we discovered, we're in the jungle making the first pass in the jungle with a machete. This is a way to explore things.

Patrick: It sounds like speed is the most important thing at that early phase.

Nicolas: Yes. This is a luxury we have as a developer advocates of developer relations.

I think we have a bit more time on our plate compared to an engineering team where we have the flexibility of, "You want to explore partnership opportunity with that company? Let's instead talk DevRel to DevRel, work on a fun project together, show and demonstrate the value of the two products combined, and let's measure the adoption and the engagement on that and see if it's worth it."

Instead of jumping a whole team, as whole sprint and more sprints actually into building a full integration that won't hit what people were expecting, or that won't have a market.

We're saving time and resources and we go quicker through the momentum.

This is one of the strengths of DevRel for partnerships.

Patrick: That's great. You also mentioned self-imposed constraints helping to drive the creativity of your projects, how do you pick those constraints in the first place?

Nicolas: That's a great question. I'll tell you what is my thing, I don't know if that's a trait of character, but I may get bored very quickly.

I always want to try new things and the issue with tech is there is always a new thing on the block, there is always a new framework and a new technology.

But again, that's a strength and a fun part of the job where you have the luxury of time to go try those things and see how it could work for you.

I would like to get the time to discover a new tool, and usually just how I pick this constraint is "I haven't done anything w ith GraphQL yet. Let's spend two days to discover GraphQL and write something about my learning."

"I haven't done anything about Serverless, I want to discover Serverless. It's not as new, but let's discover Serverless and spend a whole lot of time to understand the different providers or understand how I can connect things together, automate things and just put some constraint."

You will do a similar project, but you choose different tools to force yourself discovering different things.

I'll tell you, my new thing right now is it's more on the personal side, but is using some of the TypeForm technology.

I decided that for this project I'm not going to code anything, I want to discover the no-code experience.

That's actually a topic we can talk about, but what it means for developer advocates to talk to the no-code community.

Because this is a new community that we see and for some of our products and tools it makes sense, they're part of a community and it might not be coders, but they don't use code.

But in the end they're the same hackers and they're the same builders that we're talking to regularly.

So my constraint for that project is I'm just going to use no-code tools and we'll see what I can achieve.

Patrick: Cool. So what are the no-code low-code tools you're excited about working on these days?

Nicolas: No-code tools are many.

The good thing about this space is right now it's growing and there are so many of them.

I will say I get excited by different things, I get excited by things like Glide or Bravo studio, which are two apps that link to build mobile apps using Air Table, Google Spreadsheets and for Bravo with a Figma design.

So certainly I know nothing about design, I know nothing about mobile development, but suddenly that becomes something that's available to me.

It seems easy to build native-like apps, the only thing I had to know is how to connect things together.

This is definitely one I like a lot, and I have a lot of questions as well around something called Parabola, which seems to be a bit more advanced than Zapier in doing a lot of more things for APIs and connecting to all kinds of APIs.

People are building crazy workflows around that.

Patrick: Cool. Shifting gears a bit, what do you believe about DevRel that no one else believes?

Nicolas: That means I have an original thought and I believe I'm the only one thinking of it, which probably is not the case.

I will say one thing I believe that's strongly true is it doesn't really matter where we end up in an organization, it's one of the questions that people have.

When they start into DevRel and the company, when they are in a company and they feel it is not the right place, they always ask others "Where does it belong?"

While I think it's a good question in terms of numbers, reporting, career and personal stuff, I think in matters in terms of the mission and what the day to day job is I think this is one thing I strongly believe.

It doesn't matter if you're in engineering, marketing, sales, partnership, the real mission is still the same.

You want to make your developer successful on your platform, and all the activities you're going to take are going to be pretty much similar no matter where you sit.

Patrick: Yeah, that's a question everyone seems to ask.

So, who inspires you? Any people or teams that are inspiring you in DevRel or community management right now?

Nicolas: There are a lot of people to do great things in developer advocacy, and many inspire me at different levels.

I get really excited by everyone that does streaming right now, so the people at Postman, they put up some good streaming content certainly in a couple of weeks, just reacting to things that were happening.

I'm realizing this shift and the reaction to it. I'm very excited by people that managed to ship a lot of content and engage a lot with their community.

I don't think she's technically DevRel anymore, but Cassidy Williams who was doing a lot of things around content, CSS, email hacking.

In a way, this is DevRel. In the community, this is also really inspiring.

But in general I'm inspired by all of us, everyone that's in the team, the community out there.

They're doing a lot of different things at a different level.

This is the drawback of having such a community, I want to do all the things as well.

When I see someone writing a great piece of blog posts or starting a series about documenting what they do in their own community, "This is so nice, I want to do the same. I want to get more into writing this type of content."

When I see people going and getting engaged with a specific community somewhere a bit more remote than when we talk about the original tech hubs, it's like "We want to do that. I want to do that."

It has a lot of meanings for us, and so there are a lot of people doing a lot of different things everywhere.

Patrick: Cool. What would you say has been your proudest moment as a dev advocate?

Nicolas: I don't know if I have a proudest moment, I guess pride is an interesting feeling personally, but I recently felt very connected to my company and my product and what we do as a community.

That's a story you probably have read maybe now, with this whole situation that is happening right now over the world a lot of businesses had to shut down, and they were struggling.

Comes a story of a family that are based in France, in the Alps near Chamonix.

They are selling fruits on the markets and the government shut down the farmer's market, so they can't sell fruits anymore.

This family has been doing that for dozens of years there, they are 60 years old people, they were close to retirement and now they lose their source of income.

Their son is based in Canada, has been telling them to go digital for many years.

They haven't done it because the only thing they knew was the farmer's markets.

Because of this whole situation, from Canada their son sets up quickly, a TypeForm connected to a bunch of different tools and makes their business digital.

Now it's been three or four weeks that they're running and they're considering dropping the farmer's market because that brings enough revenue for them, it makes their life easier.

They don't have to run-- Imagine they are 60 years old loading and unloading the truck every three days because they were doing markets every day, and now it's a bit more comfortable for them. They have the money in their bank account, everything goes digital through Stripe.

They do the deliveries at different pick up places in the valley.

So they bring business to other businesses, to a flower shop somewhere, it's a bakery shop somewhere else.

They're bringing economy back to the valley and connecting people, so this is a great story.

Like, "OK. I think the DevRel aspect of this is more on the community side and trying to find a solution with a specific customer."

Like, "OK. This is not in the product, but let's see how we can hack things together to make it happen for you."

As well as connecting the tools together so it is a part of the no-code thing, where you make a TypeForm and you connect it to Stripe to collect payments and you connect it later to a map that was doing Circlet.

It optimized the route so you can do the deliveries, and you are empowering a new business to sustain and help a family live.

That would be a recent highlight on the job.

Patrick: That's incredible.

Nicolas: This family, they got mentioned in the Stripe article regarding their last run of funding.

Like, "We raised a bunch of money." So the guy who published a tweet about, "Hi. This is what I do for my parents," whatever.

The next day, Stripe announced their own funding.

There is one link that says, "We do help all kinds of companies, including farmers in France."

So they found the time to include that into the press release, and it's great.

Patrick: For the non-French listeners to the program, explain to us Raclette.

Nicolas: Yes. As you may have heard already, I'm not native and I come from France.

So sometimes I speak with a bit of a French accent, and Raclette is a social tradition in France where you all invite your friends at home and you share some melted cheese, a Raclette cheese with potatoes and charcuterie.

If you're from Switzerland, you will claim that is from Swiss.

That it's a Swiss thing and not a French thing, but it's both.

That's something that's very common around winter, people get to invite you to their house.

They have Raclette party with the office and with the people from your soccer club.

You get Raclette parties all the time because the winter is cold and you need to gain some fat, and I realize that that's something that we didn't have in San Francisco.

I was missing the social aspect and this is how I decided to launch as a side project, a Raclette delivery business called SFCheeseParty.com.

I guess this is where you want it to go, where you can order online a cheese party and we'll bring you the cheese, the device to melt the cheese and everything you need to have fun and have a social time in a different way with your friends.

Patrick: That's an amazing side project.

Nicolas: It's a no-code project. It doesn't need anything.

Patrick: So, this podcast is called Developer Love.

We talk about developers, we talk about things we love.

I'm interested, what's one thing you're loving right now?

Nicolas: One thing I really love right now is that we have in mind, people have in mind to try to have in mind and remind other people that don't have this in mind to keep making developer content developer tutorials and projects accessible to the people that get started.

We all forget after years of coding, after years of being into the space, we all forget the paths that we followed when we got started.

I feel that what I love right now is there are still people trying to make this accessible and available to all, and through all kinds of tools this is definitely something true.

Is it through Glitch? Is it through the different boot camps? Is it through something like Twilio Quests?

There are different ways to get people into that and lower to the thing that can scare you.

It looks scary from the outside, and I love that there are many forces that are trying to make it more accessible.

Patrick: It sounds like empathy and a beginner's mindset are really important to your work.

Nicolas: Yes, empathy is important to understand what is the issue from the customer's point of view so you can help them the best.

And "Beginner" because we all are a beginner somewhere. It might be through code, it might be through a special tool.

I'm a beginner on everything. This is also why I do projects by constraints, I want to be a beginner in everything.

The reason why I choose developer advocate as a career path is instead of software engineering is that this is where I get my excitement, by learning new things and learning a bit of everything.

Not being a master at a specific in particular, and so I'm a beginner in almost everything that I've tried because then I get bored.

Having this beginner mindset, helping you bring more people on board and help them better.

Patrick: Great. Nico, thank you so much for coming on the show today. I've learned a lot. It's been a real pleasure.

Nicolas: Yeah, thanks for having me. I hope some of this ramble makes sense.

Patrick: If people want to learn more about what you're up to, where should we send folks to learn more?

Nicolas: You're going to make me pronounce my username, which is @Picsoung.

That has been my username for more than 15 years on the internet, but this is where you're going to find me on GitHub, Twitter and all the different places.

If you ask me, I can tell you where it comes from. Ask me in DMS.

Patrick: Can you spell it for us?

Nicolas: This is where I should have chosen another username. PICSOUNG.

Patrick: Awesome. We'll see you on the internet.

Nicolas: Thanks, see you there.