The app I’m using for my to do list

(drum roll) It’s the native Apple Notes app. I know, perhaps it sounds boring but let me explain.

Like many people out there I have tried many different to do apps. This is just a short list. I tried, TickTock, Google Keep, Trello, WorkFlowy, Notion, Taskade, Todoist and probably a dozen others.

I always wanted a simple to do app where I can keep a list of tasks I need complete. Once a task is done I wanted to mark it done (or cross it out). I didn’t need any complicated project management features or collaboration features. On a number of occasions I wanted to just switch to using pen and paper. I imagined I’d write my list of tasks and cross them out when completed. One drawback with a pen and paper is that you need to carry it with you.

As I continued to try more apps and read what other folks are using (there are thousands articles on various to do apps and approaches out there). I decided to give a very simple app a try. I thought this approach would bring me the closest to a pen and paper but I’d still be using an app.

That app is the native Apple Notes app on iOS, ipadOS and macOS.

Apple Notes
Continue reading “The app I’m using for my to do list”

What is no-code?

In this blog post you will learn about the no-code space, its history as well as some of its advantages and disadvantages.

What is no-code?

Okey, so what is no-code? No-code is using any tools that allow you to build software applications without coding, usually using visual and drag-and-drop tools. The following definition form Wikipedia describes this space nicely:

No-code development platform (NCDPs) allows programmers and non-programmers to create application software through graphical user interfaces and configuration instead of traditional computer programming.


Instead of writing code you can use graphical user interfaces, configuration and wizards to build software applications. For example, an integration no-code tool Parabola allows to build app logic using a graphical flow instead of traditional programming. You wire and connect various components such as API calls, mappings into a flow which is then executed.

Sample Parabola flow

I personally like the term “visual development” a little bit more than “no-code”.

Continue reading “What is no-code?”

Why developers have influence today?

When people ask me what I do, I tell them I’m in Developer Advocacy/Relations space. Most people look at me confused and say: what? Even folks who are in a software space usually don’t know what this role is.

To help better understand what we do I tell them that we work with developers where our mission is to provide developer education, help developers be successful, help developers solve their problems, and make developers super heroes. Most folks wonder why we have to do that. I tell them that developers today have a lot of influence and some are even making purchasing decisions.

Evans Data Developer Relations Conference: Over 95% of developers have some role in purchasing
Continue reading “Why developers have influence today?”

A year of blogging every week

Last January I set a goal for myself to publish a blog post every week that offer some value, even if small (I actually started in February 2019). I couldn’t miss even a single week, no excuses. I had to publish something. Now, not every blog post was a long-form, in fact most blog posts were short and cover something very small/specific. Nevertheless, the goal was not to miss a single week. For me it was important to get into the habit and stay consistent and once the habit was established it became easier to come up with content ideas and write every week. If this also works for you — that’s great. You should come up with your own approach to keep going.

If you think it will be hard to come up new ideas every week that go beyond the standard tutorial, article or how-to, I shared a blog post on interesting content ideas you can try. The blog post covers the following ideas:

  • Notes or summary from a conference, meetup
  • Event in 10 pictures
  • Links to series of articles
  • Links to previous month video recordings

Since I published that blog post, here are some additional ideas to help you.

Continue reading “A year of blogging every week”

How many developers did we help?

Measuring success in Developer Relations is always one of the most interesting questions or challenges. Every organization does it differently – from measuring how many stickers were handed out, how many Twitter followers one has, to how many people attended a conference talk, to how many API calls were made. There are many more things you can measure. Every approach has its pros and cons and every organization will use an approach that helps reach their business goal(s).

I listened to a great Under the hood of Developer Marketing podcast with Jesse Davis:

where Jesse shared that a metric we should care about is how to help the developer next.

Continue reading “How many developers did we help?”

Make developers awesome

Last September I was in a meeting with Burr Sutter. Burr runs Global Developer Advocacy at Red Hat. We were talking about Developer Advocacy and I remember Burr saying something along these lines:

Our job is to make developers awesome

I right away thought about this image:


I think the first time I saw this image was at Share Knowledge Not Features. The original graphic is from Features vs. Features.

I think it’s easy to focus on features but that’s not what Developer Advocacy is about (at least in most cases).

Developer Advocacy is about showing what developers can do with your product/service, what problems developers can solve and what solutions developers can build. I covered this topic earlier in this blog post: Share outcomes and results, not features.

Our job is to help, show and educate what rad things developers can build.

Developer Advocacy is how to make developers awesome 🙌


When I shared this blog post with Burr, he told me he uses another phrase:

Our job is to give developers super powers

So here you go, two really great phrases to describe Developer Advocacy from Burr Sutter:

Our job is to make developers awesome
Our job is to give developers super powers

Developers don’t hate marketing

A few weeks ago I attended Evans Data Developer Marketing Summit. During a panel one person said:

“Developers hate marketing”

I don’t agree with that.

I think developers don’t like bad marketing.

People in general don’t like bad marketing so I don’t think developers are any special here.

When someone says “developers hate marketing”, I always associate this with an old car salesperson:


No one would disagree that this is bad marketing (or sales), most of us probably experienced that. These folks usually use shady tactics and push features, not solutions.

Most will agree that (most) organizations today don’t do this.

At Evans Data Developer Relations Conference in March 2019, Willie Tejada, IBM Chief Developer Advocate said this:

On marketing to developers:

It’s not true that developers don’t want to be marketed to, they are simply very very educated “consumers”.

Here is an example of buying an espresso machine (such as Nespresso)
People will spend a disproportional amount of time learning about the machine and how it works. When they go to the store to buy it, if the sales person knows less than the buyer the buyer will be frustrated. We don’t like when we go to buy something and we know more about the product than the person selling it to us.

There are many great books on marketing out there. A great book I recently read is This is Marketing by Seth Godin. Here is how the book defines marketing:

Marketing is the generous act of helping someone solve a problem. Their problem.

and this one:

Marketers offer solutions, opportunities for humans to solve their problems and move forward.

There is nothing inherently bad about marketing to developers. Companies simply need to be helping solve developer’s problems. If we do this, then we won’t need to say that developers hate marketing (hopefully).

Our goal should always be to share outcomes and results, not features. My all time favorite resource is Adam DuVander’s Share Knowledge, Not Features.

I think here is one good example of that (there are thousands more of course):


Webflow is a No Code platform to build websites. Above is their home page. Webflow is not telling people that they have a visual HTML editor – that’s a feature. They are telling people what problems they can solve, what is the outcome – build a better website, faster, without coding.

Whether you call it developer marketing or something else – let’s help developers solve their problems, show them solutions, outcomes and share knowledge 🙌

“The Making of a Manager”, a book I highly recommend and some of my favorite parts

There are thousands of books on how to be a manager and I’m sure many of them are very good. I just finished reading The Making of a Manager by Julie Zhou. I loved the book and highly recommend to new managers, not so new managers and people who might want to be managers one day.


Many management books out there give you a lot of theoretical advice on how to be a manager or just advice that’s not applicable to real world. What I loved about Julie’s book is that it’s full of very practical advice and tips. You can take it and use today. I liked that Julie wasn’t afraid to share that she was scared many times, that she wasn’t sure if she made the right decision and that’s it’s OK (and actually beneficial as that’s how we grow) to make mistakes because we are all humans. Reading the book I said many times “oh yes, that’s how I felt” and “oh, and I was in exact the same situation”. This kind of connection makes this an excellent book that I highly encourage to read. Seeing how the Julie dealt with various challenges and grew to be VP of Design at Facebook, is a great learning experience.

Continue reading ““The Making of a Manager”, a book I highly recommend and some of my favorite parts”

Applying the Fogg Behavior Model to Developer Relations

I found about the Fogg Behavior Model from #saashacker newsletter. I found this model super interesting and right away thought if it can be applied to Developer Relations.

Fogg Behavior Model Graphic 2019

First, what is the Fogg Behavior Model? You can find a detailed explanation on The model has three main components: Motivation, Ability and Prompts.

The model says that to influence someone to do something, you have just two levers:

  • Motivation – how much someone wants to do something
  • Ability – how easy it is to do the thing

The third component

  • Prompts – is a call to action, trigger or cue for a behavior to happen

So, could this model be applied to developers? Let’s look at each component and see how it can be applied to Developer Relations.


So what can motivate developers? Here is a list of motivations:

  • Solving a (challenging) problem (at work or a personal project)
  • Giving back to community. For example, contributing to an open source project
  • Career growth, personal growth, learning


Ability is how easy it is to do something. I think ability has a strong connection to Developer Relations. We (Developer Advocates) always strive to make things easier for developers. A big part of this is making our documentation, tutorials, videos, guides and everything else easy to follow and complete.

In June at DevRelCon in San Francisco, Steve Pousty gave an excellent talk called The Kick Ass Curve for developer relations. I recommend you watch the talk, one of the themes from Steve’s talk was that we need to make things easier for developers so they can become successful, and fast.


A prompt is a call to action, trigger or cue for a behavior to happen. In the context of Developer Relations, a call to action can be a hands-on workshop that a developer can attend, or an online event. It could also be a friend recommending the technology. It can also be an interesting and easy to follow step by step tutorial that you saw in an email newsletter, an interesting blog post, article or an interesting tweet. All these prompts can lead to: “hey, I want to try this”.


Looking at the Fogg Behavior Model, we want to stay above the green Action line. Staying above the line means a developer is motivated, and it is easy for her to complete something and the prompted has worked. I believe most developers are very motivated. Where we can make a bigger difference is in the Ability.  To make developers successful, we need to strive to make things easier such as produce high quality documentation.

There are probably other ways to apply this to Developer Relations (or I might be complete off, hey, who knows). Would love to know what you think, please leave any feedback in comments.

If you want to learn more about the Fogg Behavior Model, you can pre-order BJ’s forthcoming book, Tiny Habits: The Small Changes that Change Everything. For the first time ever, BJ explains the Behavior Model in depth for a global audience.

Share outcomes and results, not features

I recently subscribed to #saashackers daily newsletter. Every morning you get a short SaaS growth case study in your inbox. It’s a quick 3-4 minute read that I recommend you try.

Today’s email talked about Mailchimp and how they got to $400 million in revenue from just 550 employees.

What caught my eye was this image and the text that followed:

Source: #saashacker newsletter

text after the picture:

They are selling an outcome, not features.

They are selling the thing people actually want, not their software.

Whether you are a direct to consumer brand with 50,000 customers or a mommy blogger with 1,000 subscribers, you want:

  • To build relationships with your customers
  • To increase sign up (by 250%)

You don’t (necessarily) want:

  • Email templates
  • CMS integrations


And this has a very close connection to Developer Relations (or Developer Marketing).

We should be sharing outcomes and results, not features. We should be showing people how to solve problems, not our software.

I’m sure most of you know this but I think it’s worth mentioning. I personally tend to forget about this (sometimes) and also it’s much easier to talk about features than benefits.

Most of you probably also said: “wait.. this is not new at all” 🤦‍♀️🤦‍♂️

You are absolutely correct 🤩

Adam DuVander has created and shared this wonderful page: Share Knowledge, Not Features: The Secret of Marketing to Developers is to Not Use Marketing. It’s Developer Relations classic and my favorite Developer Relations resource. I highly recommend you read and bookmark this page. Adam explains that we should be sharing knowledge, not features.

So, let’s try to share outcomes, results, problem solving and knowledge, not features✌️