DEV Community: Michael Palermo

Do you provide feedback?

Michael Palermo — Mon, 07 Nov 2022 02:20:27 +0000

When I get shipment notifications from Amazon, I am prompted to provide feedback on my delivery with two simple choices - a thumb up or down. Selecting either will pull up a web page with more options. On a recent occasion, I decided to time how long it took to complete the process.

It took a total of 8 seconds to provide feedback.

I timed the process because I realized I often provide feedback in this context, but skip the process with others. I feel like I subliminally know I can provide instant feedback with Amazon, but must question my investment of time with others who prompt.

This raises questions I would love to hear from others on:

Do you provide feedback when prompted?
Do you provide feedback only when there is an issue?
Have you seen quality feedback systems that you wish other companies would implement?
Have you implemented a feedback system and have any stories to tell on engagement?

I realize I am asking for feedback on feedback - so I hope this will be a fun discussion!

Reasons NOT to...

Michael Palermo — Thu, 29 Sep 2022 04:12:30 +0000

Developer Relations (DevRel) is commonly tasked to drive growth and success of developers using their company's product. Of course, coming up with reasons why developers should adopt their product is necessary to deliver an effective message. But wouldn't it also be healthy to put attention on why they may NOT adopt?

I am just brainstorming here, but the following list captures reasons I believe developers may not adopt a product.

Unaware

It is not possible for a developer to adopt or use a service if they have never even heard of the company or product.

Uninformed

Different from being unaware, this means the developer has only a vague or misinformed idea of company or product.

Unneeded

The developer does not perceive the relevance of company or product.

Untrusting

The developer's perception is that there is too much risk to engage with company or product. This could be due to not trusting the overall industry the company represents, or company/product too new in market.

Unhappy

The developer had (or heard of) a bad experience with product or company.

Uneasy

The developer may had initial interest, but the process to adopt or get engaged was too complex or confusing.

Uneconomical

The developer has interest but considers cost of product or investment in time/resources a barrier to continue. Competitors appear (or are) less expensive.

Underwhelmed

Despite possibly being the right fit for a developer, how the developer learns about the company or product did not impress enough to invoke active interest.

Unable

While the developer may personally like the company or product, the perception (or reality) is that no adoption could take place due to constraints/policies of organization developer works for.

I do not claim the above is an exhaustive list, but is it a good starting point for discussion? Imagine if each DevRel carefully considered each reason not to, and came up with a plan to turn things around?

If you have other reasons why developers may not adopt, please share!

Photo by Anna Shvets: https://www.pexels.com/photo/woman-with-hands-on-her-face-in-front-of-a-laptop-4226215/

DevRel != DevRel

Michael Palermo — Wed, 28 Sep 2022 01:36:37 +0000

I can not count the number of times I have had to explain what "Developer Relations" is. At an abstract level, DevRel is a service of a company/product that engages with developers in a manner that yields mutual benefits. Examples of activities/deliverables that are usually associated with DevRel include blogs, videos, meetups, presentations, hackathons, and so forth. So are all DevRels basically the same? No.

What makes one DevRel different than another if both seem to be producing the same kind of activities/deliverables? I invite you to consider the following points that are distinguishing factors:

Scope of Work

The potential of what DevRel could do is so much! While some companies reserve DevRel for evangelism/advocacy activities only, note many of the initiatives that could be brought into scope:

Product feedback
Community building
Ambassador/Champion program
Forum support
Presales support
Social media engagement
Documentation
Self-Serve (developer experience)
Tooling (utilities, IDE extensions)
Integrations (platforms, marketplaces, directories)
Developer Marketing
Events (conferences, meetups, hackathons)
Technical artifacts (code demo, apps, configs)
Content (blogs, tutorials, decks, videos)
Live Streaming

And I am sure I forgot something. Needless to say, so much could be done. Oftentimes, some of the items listed above are directly handled by other teams in a company. Examples include presales support, developer marketing, tooling.

How would DevRel know which items to take on, which to prioritize? This leads to our next points.

Available Resources

Available resources include people and budget. How big is the team? Is it possible to create cross-functional teams with others in the company? Could contractors be utilized? Is there budget for travel, events, merchandise? Is there budget for tooling/equipment, software if needed? DevRel can only scale to the extent it has available resources.

Measurement

Perhaps one of the greatest differentiators between one DevRel to another is how they determine how to measure success. I have observed some in DevRel that measure activities (# blogs, # views, # presentations, # likes, # comments, etc.) of which might be valuable metrics, but should never be the goal. I have also seen (and have been part of) DevRel that puts a revenue number on the group. Depending on the scenario there may be benefit, but I feel that should not be the goal either.

What should be the goal, the "north star" of DevRel? There is no single answer, but if it speaks to growth of users or activities, it is likely on track. Here are some examples:

Number of new users who joined over a period of time
Increase of overall product activity or downloads
New logos (companies)
Increase of monthly active users

I have seen many variations, but the idea is that DevRel promotes engagement with product.

Domain

The kind of company/product also separates one DevRel from another. The strategy to gain blockchain developers will likely vary greatly from a strategy to gain enterprise DevOps. Some products have wide appeal to the masses, others are very niche.

In conclusion, I posit that not all DevRels are the same. Factors that contribute to a DevRel's identity include scope, available resources, how it is measured, and the domain it is targeting. Trying to compare one DevRel to another could be like comparing apples to oranges.