DEV Community: Leon Adato

HOW TO DEVREL: The Most Un-Natural Act

Leon Adato — Mon, 17 Aug 2026 04:00:00 +0000

DISCLAIMER: No, I don’t believe I’m the universe’s gift to DevRel. I don’t have all the answers, all the skills, or even all the Pokemon. What I have is my experiences, collected over the 11 years I’ve been doing this work. That – my experiences and observations – are what I’m sharing in this series.

Before this blog gets de-listed for potentially purile content, let me explain up-front what “un-natural act” I’m referring to:

Getting conference attendees to try your software during the conference

Yeah, THAT un-natural act. Like… you’re at a conference, enjoying the talks, meeting new people, and having a great time. You decide to take a swing through the vendor space, mostly to see what combination of socks, t-shirts, pens, and charging cables you can snag for free.

Stopping at a booth, you’re chatted up by one of the staff, and they say… something clearly compelling. It might even border on mind-control. Your response is to pull out your laptop, head to the vendor’s website, start a free trial, and play around with their software.

This, my friends, is an absolute fever dream. I’m sorry, but I’m not giving up my time (to say nothing of my anonymity) for “a chance to win this Lego Millennium Falcon”. Anyone who thinks this would work has not hung around humans – and specifically humans working in the tech sector – enough. Short of something like “and you’ll immediately get a Lamborghini” (or 1 million dollars, or a lifetime supply of delicious chocolate cake), there’s nothing I can imagine a vendor saying to me that would get anyone to ACTUALLY do the deed.

Opening scroll

Or can you? It turns out, I’ve found a way to do just that. In fact, this technique – tested over 3 years at ~20 different events – consistently delivered a sign-up rate of 10% of the overall attendees. So if the event has 300 people, this technique got me ~30 sign-ups. But at a 3,000 person event, we saw 300 sign ups. Because you probably work in tech and love data, I will admit that there’s an upper-bound at around 5,000 people. Going to re:Invent (about 60,000 people) did NOT garner 6,000 sign ups. However I attribute that to the fact that all 60,000 people didn’t swing by the booth.

But the point stands – this technique gets a non-zero number of folks to take a moment, RIGHT NOW, and sign up. If you’ve been working the booth at conferences for any amount of time, you know that’s worth a lot of $5-a-pair branded aviator glasses.

Level 1: Make it a game

The first thing I did was take my company’s software (remember, I work in monitoring and observability) and incorporated into a game. I found a existing 90’s style side-scroller

and instrumented it with additional monitoring that collected everything from CPU, RAM, and network stats to the number of gems collected, the top level achieved, the speed of movement, etc.

Level 2: Make the back-end visible

Then I took all those stats and built a dashboard around it.

Level 3: Let attendees play AND see!

I built a portable display that allowed someone to play the game AND ALSO see the dashboard in my company’s portal that showed all the monitoring statistics.

CUT SCENE – in-booth discussions

Once this is up and running in the conference booth, people will naturally gravitated to it. A game display is just too enticing NOT to stop and check out. It allowed me to not only invite people to play (and even compete against each other) but I also used the game as a springboard for conversations – describing HOW each of the game elements was instrumented, collected, and displayed, which naturally led to discussing real-world use cases that were closer to home for the attendee.

The best part was that, because the example I used was a game, folks didn’t get hung up on “that’s not like my business” but also it got past the “what are you trying to sell me” resistance that everyone (myself included) feels when passing by a vendor booth at a conference.

But it gets much better than that.

Level 4: Pack it up

Packaging everything up to use in the booth is one thing. But what if you made it so the users THEMSELVES could download the game, pre-instrumented, and load up the dashboard in your portal?

That’s exactly what I did. First I made everything as simple as possible – bundling the game AND monitoring agent into a single downloadable bundle.

Level 4: Provide a walk-through

Next, I wrote up step-by-step instructions that talked folks through:

creating a free account in my company’s portal
downloading the game-and-monitoring bundle
making any configuration changes to connect the game bundle to the free account

The goal wasn’t to make any of this a guessing game or a quiz. If sample configs were needed, I gave them. If there were special add-ons needed for a specific operating system, I provided links. I wanted players to have the easiest, smoothest, fastest set-up experience possible.

Level 5: Offer the Quest.

After seeing the game in the booth, I would offer attendees the opportunity to download it for themselves and set up the exact same dashboard. That way they could enjoy the game AND see the real software (mine) in action.

But this, in fact, is the heart of the blog. THIS is the “most un-natural act”. Why on earth would they DO that??

Level 6: Collect Those Gems!

If you’ve played any game ever, you know that hard work needs to be rewarded. I offered a prize to anyone who came back to the booth and showed me the installed game with the dashboard up and running. The prize was significant. Not “here’s a PS5” significant, but compelling. Over the years, I’ve handed out everything from Ember mugs to Raspberry Pis to light-up LED D&D dice.

What I found is that the thing that compelled attendees to download and try the software wasn’t the expensiveness of the give-away, but the “cool” factor along with the guarantee that they’d get it. Nobody’s going to jump through hoops at a busy tech conference for a raffle ticket.

And that’s where the “10% of attendees” part fits in. That’s how many people, on average, were willing to take time (usually doing it while they were listening to one of the conference talks) and download the game bundle, set up the free account, and do the (minor, easy) configuration to connect the two things.

Bonus Level: Beat the BFG

We also had a big give away (yes, sometimes if actually was a PS5 or XBox), but I’m not a big fan of raffles. So we made it part of the entire engagement strategy.

IF the attendee downloaded the game bundle and set up the dashboard…

AND IF they showed us the dashboard (and got the cool prize).

AND IF if they actually played the game during the event, and had the highest score at the end,

THEN They’d win the prize.

How would we know? Their score in the dashboard, of course.

Hidden Level: The Kobiashi Maru

What I discovered the very first time I did this activity was that I needed TWO big prizes.

One for the person who played by the rules, who got the high score fair and square.

And one for the inevitable group of folks who found a way to tweak and change something to create an impossibly high score. Maybe they adjusted the math on the dashboard display. Maybe they added a multiplier in the data collection process. Maybe both.

Why? Why would I reward a cheater?

Let me reframe that for you:

What would you have to give someone at a conference to download a program, set up your software and a dashboard, and then EDIT AND MODIFY that setup to do something different? What’s the likelihood that ANYONE you asked for that kind of investment of time would do anything except walk away (possibly after laughing in your face)?

But here, someone did all of that without you even asking. In marketing and sales terms, this makes them the most qualified of leads.

The End Credits

The core of this idea is that I made a relatively boring, work-intensive piece of software more fun and engaging by associating it with something that was already fun and engaging, and then structuring the handouts and give-aways in such a way that rewarded the behaviors that helped me.

It’s not exactly an epic action that can only be done when you’ve collected 1,000 mana points. But, based on the fact that I’ve seen precious few other vendors do anything like this, it’s still one of those little known power moves that anyone could capitalize on without being seen as derivative.

Punchline, or Gut-Punch?

Leon Adato — Mon, 10 Aug 2026 14:00:00 +0000

I was excited and also humbled to be given the chance to deliver the closing keynote talk at PyOhio this year. You can see the video of that talk here. But a conversation afterward offered me a chance to reconsider and – hopefully – improve both myself and that talk for the future.

I set up a particular joke early in the talk: After establishing that “there really aren’t any poor technical choices”, I go on to qualify that statement with examples of demonstrably bad technical choices – things like not having backups, testing in production, etc. In that list I include the punchline:

Using Oracle for literally anything, ever.

Near the end of the talk I offer another list, this time technical decisions that sometimes leave us paralyzed with indecision. Near the end I ironically include the same line – “using Oracle for literally anything, ever”.

Both lines never fail to get a laugh from the audience. First, because any sufficiently large, complex, storied, and difficult to manage technology would fit the bill. I could have chosen from a range of programming languages, platforms, or solutions and gotten almost the same type of laugh. But second, because Oracle – the company, and certainly it’s CEO – have made itself an easy target.

And look, it’s a good joke, ok?

What I failed to consider is that plenty of thoughtful, dedicated, committed IT folks work with Oracle every day. Some might have had taken jobs that covered a wide range of solutions, Oracle included. And some might have seen where the money was – that internally the big projects and big funding was going to an Oracle-based project – and decided to go in that direction because of the potential for promotion, bonuses, and stability.

And in that moment, anyone in the audience who’d made that choice found themselves in an unintentional spotlight. Because, without my meaning to, I’d made them and their work the butt of a joke. At best, they now had to deal with folks winking at them and saying “using Oracle for literally anything, amirite?!?”. At worst, they had to explain why they had made a “poor technical choice”.

Moreover, unlike any of the other technologies I mention in that talk, I hadn’t offered an “out”. Every other poor technical choice is presented in a “That’s bad! No that’s good!” type of framing.

I wasn’t aware of any of this, although I’d given the talk several times, until someone at PyOhio stepped forward. Through the Code of Conduct grievance process (and massive props to the PyOhio team for having this process, and taking it seriously), they registered their discomfort, both in the moment and afterward. They related that, having built a career around their expertise with Oracle, they found themselves uncomfortable and conflicted about how to react during my talk. And after the talk was over they were uncertain about how (or whether) to mention their work to other attendees.

They asked the organizers to ask me to consider my talk in from their perspective, and reconsider how willing I was to put other people in the same situation, all for the sake of a momentary laugh.

It’s easy – too easy – to write off this one person as being overly sensitive, unable to take a joke, too self-absorbed or self-important to laugh at themselves. Upon even a moment’s reflection, it should be obvious that this would be both defensive and condescending. Who are we to normalize cruelty just or judge someone else’s response? “Nobody can take a joke any more.” Is (and, let’s be honest, always has been) the response of those who don’t want to bear responsibility for their words.

The truth is the person who filed the complaint is the epitome of bravery. It takes strength of character and conviction to stand up and tell someone that what they’re doing is wrong. I applaud anyone who takes that kind of risk. I’m deeply grateful to the person who did so in this case, even though I’ll never know their name.

SO… where does that leave me and my punchline? To be honest, I’m still not 100% sure. On the one hand, I could just modify the line to say “Oracle corporation”, separating the solution from the Law-firm-with-a-small-software-division that is the Oracle business. I could go searching from a different target that’s so old nobody would be offended – like Perl or XML. Or something that’s likely to be universally reviled – like Windows 8. Or I could cut the punchline out entirely. A conference talk doesn’t need to be a thinly veiled standup routine.

So I’m not sure of HOW it will change, but I’m absolutely certain that it WILL change. I was given feedback that was specific, personal, and urgent. To ignore it would be more than just a poor technical choice. It would be a poor choice as a human being.

HOW TO DEVREL: The 10x DevRel

Leon Adato — Mon, 03 Aug 2026 14:00:00 +0000

If you’ve been anywhere near the coding side of tech within the last 8 or so years (and that includes just sitting with a programmer in the lunch room) you have probably heard of the “10x Engineer”.

While the phrase is well known, the meaning remains somewhat murky. Does it mean an engineer who can develop 10x the volume of code? Develop an equal amount of code 10x faster? Create code that’s 10x higher quality? Or does 10x the number of functions?

The IMPLICATION is that this is a person who can provide 10x the “value” (however you personally define it) compared to a regular run of the mill software engineer. It builds on an earlier version of the same trope – the Rock Star Engineer. An equally impossible bar which itself builds on a more realistic observation: we’ve all worked with certain folks who just seem to have it all together. Who know what they’re doing, make fewer mistakes, and knock out the work.

The problem is that nobody is like that all the time. The people we remember as being brilliant made their fair share of mistakes – even on the days we thought they were knocking it out of the park. Rock stars hit bad notes sometimes. Sports legends miss the ball sometimes. 10x engineers get stuck.

More than sometimes, all of those folks have the same experiences we do. A lot.

So if they’re just regular mortals like us, what’s behind the myth?

On one hand, I think it has something to do with what those folks do NEXT. Having made the mistake, found their code to be buggy, realized they have no idea how to proceed, etc… they keep going. They ask for help. They recognize (and even embrace) the opportunity to learn. Hell, the best engineers I know revel in the opportunity to learn something new, or even learn a new way to do an old thing.

But there’s ONE aspect of the truly amazing folks that does qualify them as “10x”.

My friend Yechiel Kalmenson put it best in a blog post back in 2019

“A real 10x Engineer is an engineer who can boost the productivity of their team 10x. An engineer who mentors, uplifts, shares their knowledge, and ultimately brings ten other engineers up to their level.”

The only realistic way to get 10x more out of someone is to give them the space to replicate what they do in others. To allow their spark to ignite the same passion and drive in the people around them.

And so I finally come to the topic in the tile of this blog: the 10x DevRel.

Having read this far, it’s self-evident that even the most experienced, gifted, driven Developer Relations Advocate can’t write 10x more posts, record 10x more videos, engage 10x more audiences, build 10x more communities, run 10x more hackathons, and so on.

BUT… unlike the software engineers I described at the beginning of this post, DevRel folks are not usually surrounded by teams of other DevRel folks. There aren’t multiple teams of DevRels working in (and on) various aspects of the company’s offerings. In many cases, the DevRel you meet is the only one at their company. They are the proverbial “army of one”.

So how could it be possible for that lone voice in the wilderness to level up their game?

It starts by recognizing that everyone is the star of their own movie, everyone has a story to tell, and many of those folks would love a chance to tell that story but they don’t know how to get past the barriers in their way.

Those barriers might be workload, or language, or confidence, or technical skills, or simply not having a platform.

And our job as Advocates is to do internally what we already do for our customers: to listen to their stories. To encourage and uplift them. To help them recognize that their story is, in fact, worth telling.

And then to help fill in the gaps for them so that they can tell their story in a way, in a place, and at a time that enables them to shine.

Too much work? The Advocate can (and should) go to leadership and help explain how that story would attract new business. Is language an issue? The Advocate should encourage their colleage to tell their story in their words. The world is a multi-lingual place. The person doesn’t feel confident in their abilities? It’s the Advocates place to provide whatever support they need – co-authoring, co-speaking, editing, coaching, brainstorming, or simply offering an honest reflection of the work, but also promising not to stop helping until the story is ready to be told.

A 10x DevRel is the person who sees the stories in the people around them, and then creates avenues for those new storytellers to speak their truth.

A 10x DevRel is someone who takes the privileges they have – the credibility, the opportunity, the experience, the access – and uses it to open doors, not for themselves, but to then stand back and let those new voices step through and into the light.

So my question to you (if you’re a DevRel) isn’t “Are you a 10x DevRel”. My question is: “Why AREN’T you a 10x DevRel?”

All Bait and No Fish

Leon Adato — Mon, 03 Aug 2026 04:00:00 +0000

I’ve been helping a friend out with their job search for a couple of weeks, and got an email back from them the other day:

I applied for a few more with no response still. At this point it feels like throwing out a fishing line with no bait.

I wanted to share some of my responses to them, in case you are feeling the same way. A lot of it echos things I’ve posted in the past, and I will link back to those earlier blogs when appropriate.

First, to re-state what I said yesterday: Job hunting (especially these days) is a process that takes months, and your first response could take weeks, not days. I don’t like it, you don’t have to like it, but that’s the state of things irrespective of our feelings about it. The only way I’ve found to get past this is to just keep applying. The more things I shove into my end of the pipe, the more likely something comes out the end.

SECOND – and again this is one of those “especially these days” things – the effort you put into a job application can be (not “is”, it’s not guaranteed, but it definitely helps and certainly doesn’t hurt) directly proportional to the value of the result.

At one of the spectrum is LinkedIn’s “easy apply” button. It takes almost no effort at all, just a single click. And that’s just about the value you’ll get out of it: not much. You’re certainly not likely to get a callback, and even more likely the entire thing is just a process to feed the AI machines involved.

At the OTHER end of the spectrum is maximum effort: You find a job posting and you first research the company to see what they’re all about. Then you look through LinkedIn to see if you know someone who is there. Let’s say you don’t. You then dig deeper to see if you can find people at the company who have professional interests that match up with yours. You reach out to them and ask, not for a job, but for a conversation. You just want to hear what the company is about. The culture. The strengths and weaknesses. (assuming they agree) You use that conversation to get that person to know you – not as a resume, but as a person. After 1 or 2 conversations about the company, the work, etc you mention the job posting and see if that person is willing to make an internal referral. If they are, you have a solid leg up on the process. It’s STILL not a sure-thing, but it’s better than just sending in your resume and hoping for the best.

Now that (the second option) is A LOT of work. You can’t do that for every application. So how do you choose? You do some work. You look at the company (and the role) and see if it’s a place where you not only feel like you can do the work, but that you would WANT to be part of that organization. You believe in what they make, what they do, their mission in the world. And if those things are true, you make the extra effort and do everything you can to ensure your application has the best possible chance.

SO TO SUMMARIZE

You probably won’t hear responses from any job application for 2-3 weeks (and sometimes 5-6 weeks).
Having an inside contact at the company is a massive boost in the likelihood you’ll move to the next step
This is a volume game – you have to throw 100 resumes into the pipe to hear back from 1 or 2.
NONE of this is fun, nice, or enjoyable. It also isn’t the way tech has always worked. It’s also probably not the way it will always be

But it is the way it is now, and we have to work with what we’ve got.

Knowing What’s Under the Hood Helps

Leon Adato — Mon, 27 Jul 2026 14:00:00 +0000

I’m not a car guy. I can drive them, but I don’t know the first thing about fixing them, and not much about maintaining them. My son, on the other hand – who’s getting a degree in mechanical engineering – is most definitely a car guy. He’s learning a lot about cars, and he’s teaching me a lot about what I’ve been doing wrong, even with simple things like maintenance.

I was thinking a lot about that as chapter 2 of my O’Reilly book, titled “Wrangling Telemetry” was being written. What book, you ask?

A long, long time ago (it was April 21) in a blog post far, far away (you can find it here) I wrote about the O’Reilly book that Avi Freedman and I are writing about Network Observability.

The book title is “Practical Guide to Modern Networking Telemetry”. The raw, “lightly edited”, somewhat unexpurgated version of chapter 2 is available today.

You can find it here: https://www.kentik.com/go/ebook/oreilly-guide-to-modern-networking-telemetry/.

I will briefly point out that it’s REALLY worth your time to download this copy because the final version will be about 120-150 pages (those O’Reilly editors don’t work for free!), but the raw version clocks in at 82 pages, and that’s just up to the end of chapter 2. So you really are getting a whole lot of extra content right now – content that will be lost to what looks to be a machete-and-chainsaw editing process later this year.

But if those 80+ pages aren’t enough for you – if you want a little more behind-the-scenes extra content to close our your week – I wanted to expand on just one idea that I throw out there in the first couple of pages of chapter 2.

On page 42 I wrote:

“Yes, it’s true that vendor solutions do a lot of heavy lifting behind the scenes. But this book is about exposing and elaborating on what that behind-the-scenes activity is. Part of the reason is so you can be a more informed customer. Knowing what happens inside the black box of observability solutions, HOW you get from “data comes in the left side” to “pretty charts come out the right side” allows you to make educated decisions about everything from OpenTelemetry methodology to aggregation options to pipeline management.

No matter how well the amazing folks at O’Reilly edit down chapter 2, the question remains: “Why should I read an entire chapter about how the observability sausage is made? Why do I care about enrichment, normalization, pipelines, data storage, and the rest. Like Avi and Leon SAY, RIGHT THERE IN THE BOOK, the vendor handles that shi…tuff.”

Let’s go back to my car analogy. It seems I’ve been spending a lot – too much – on oil changes. I thought that natural oil was better than synthetic. It was also significantly cheaper. With his experience on two different teams that compete in Baja SAE he’s learned a lot. And – without getting into the nitty gritty (because I still don’t understand all of it, and this is a blog about observability not oil) the synthetic oil is better for the cars we have, and will last longer, and overall work better.

That’s information I didn’t have because I didn’t choose to think about how my car operated on more than a surface level. I was content to let the vendor (the quicky-oil-change place) make my choice for me, and to make decisions based on price rather than effectiveness.

I find – especially when it comes to monitoring and observability – that IT practitioners can fall into the same trap. We already have too much on our plate. We already carry a huge cognitive load. Learning about the internal process of a tool that – let’s be brutally honest for a moment – is often seen as little more than something we do to satisfy an audit doesn’t seem like a good use of our time.

But – like that oil change analogy – it can have massive long-term impact. Understanding how your monitoring tools “wrangle” the data can

help you avoid cost overruns
understand why data doesn’t always match (what you expect or what other tools are telling you)
use your tools both effectively and for the right use cases
avoid wasting money replacing tools “that suck” when in fact they don’t suck, you’ve just been using them incorrectly.
and more.

With all of that said, I don’t believe that knowing how to wrangle your telemetry is as useless as some people think. With the rise of Open Telemetry, those pipelines – and all the techniques to normalize, filter, sample, and transport data that they perform – is becoming more important than ever to understand.

So consider this chapter – in it’s full, lightly edited, unredacted form – to be Avi and my gift to you to become a better user of your monitoring tools.

Once again, you can find the book – all 80+ pages at this link: https://www.kentik.com/go/ebook/oreilly-guide-to-modern-networking-telemetry/.

HOW TO DEVREL: The Bechdel Test for Community

Leon Adato — Mon, 20 Jul 2026 14:00:00 +0000

For those unfamiliar with it, the “Bechdel test” is named for the American cartoonist Alison Bechdel. In one strip from her series “Dykes to Watch Out For“, a character described their 3 basic requirements to go see a movie. The movie had to have:

At least two women, who…
…talk to each other…
…about something other than a guy…

The point is that an embarrassingly small number of movies (not to mention TV shows, books, comics, etc) can clear that fairly low bar.

Equally embarrassing are the number of so-called “community forums” that fail to pass what I have termed my “Bechdel test for community”. In order to qualify as a real community, it would need to have:

at least two (non-employee) accounts with fully filled out profiles…
…talking with each other in a public area of the community forum…
…about something other than the company (or it’s products).

Meaning: A true community is a space where two people with common interests or goals talk to each other about things that matter to them. It might include the company who owns and runs the site, but it might not.

And a true community is one that not only permits, but encourages and facilitates those interactions.

Like the real Bechdel test, that bar seems low until you start surveying community sites. Most will have some form of a #random channel. Many will have other variations of #off-topic discussions. But those examples point to the flaw: often the things that permit a community to pass my test are the same things that are labeled “random” and “off-topic”, betraying the bias against having a true community.

If this hits uncomfortably close to home, don’t let that discourage you. Because improvement is within anyone’s ability.

Put Baby Product in a Corner

One of the things I find vendors fail to recognize (or know, but then quickly forget) is that their name, logo, and product are ALL. OVER. THE. PLACE. There’s need to put the brand front-and-center, nor to make the products the focus. This is because both of those things are intuitive to anyone arriving at “TechBrand.Community.com.”

Moving product-centric forums and their discussions – whether those are announcements or support discussions – into a corner effectively does the opposite of the #random channel I mentioned earlier. It makes a clear statement that “this space is for you, not for us.”

Make It a Sales-Free Zone

Closely related is a rule that I consider to be inviolable, both as a member of an online community and as someone closely involved with running them: A community space has to be completely free from sales activities.

Never in the history of ever has someone in a community forum lamented, “If only I could find a sales person to take my money!”

Like the point I made about product information, you have to recognize that community members will have no problem engaging with sales if they want it. There’s absolutely no need for sales to “check in” or “touch base” if they think a conversation is veering into sales-related territory.

I promise you that if there’s even a hit that sales folks are lurking on those channels, waiting to swoop in (either in the comments or out-of-band via email, phone calls, or whatever) your membership will shrink to zero faster than your platform’s software will be able to track.

Solicit Input, Not Free Labor

If you’re like most tech practitioners, you probably have enough work to keep you and 3 clones busy basically forever. The people in your online community are no different. If you want to demonstrate your respect for their time, not to mention your appreciation for being part of the community the last thing you should do is ask them for free labor.

That includes bug bounties, offering beta version (aka “free QA testing”), or community tech support. Even if they get points or swag.

Instead, the emphasis should be on encourating the community to share opinions, ideas, and experiences in ways that don’t look or feel like free labor.

That starts with problem-forward questions and discussions. Rather than asking how the audience uses a particular module or feature, center the conversation on “how many of you have experienced X?” (where x is a situation, issue, or problem). Or “How do you all deal with X?”

By focusing on the experience (hopefully something that happens to IT practitioners with regularity) you are making it clear your not trolling for customer reference stories.

Other conversation starters that might help:

What are some things nobody told you when you started working with (a certain technology); or in (a particular field)?
What’s a cool hack for solving X?
What issues slow you down every day that you wish you could make disappear?

…and so on.

From a company standpoint, let your community be a place where you open the door for members to participate in UX/UI sessions. These are designed to show early ideas about a new technique or technology, but in a way that allows community folks to offer input that can directly impact (and even change) the product. It’s a win-win that is still surprisingly rare in the tech world. Very few companies allow their community to get involved in a way that allows them to say “You see that option? That’s included because I told them how important it was!”

Reward Participation

That attitude – of valuing real engagement and contributions that benefit both the membership and you – should extend beyond your product to every aspect of the community. You should recognize and reward individuals any time they share their knowledge.

The place to start is recognizing and rewarding when some ASKS a question, not just when they answer them. Asking good questions is actually the hardest and most valuable element of building a vibrant and engaged community. A good question is the thing that starts a conversation, or keeps it going, or makes the answer matter in the first place.

Yes, you should also reward members who share snippets of code, scripts, dashboards, reports, and any other portable (meaning import/export-able) assets. And of course you should reward people for answering questions. But that shouldn’t be the primary focus or else you will once again fall into the trap of making the community space biased toward free labor.

Feature Request System, as a Feature

From a vendor standpoint, the most important question you can ask is “What do YOU need the product to do?”

And, as I’ve mentioned earlier when talking about UX sessions, it has to be asked in a way and at a time when the feedback you receive actually makes a difference.

For this reason, I strongly suggest making a public feature request page part of your community. This is a place where ANYONE (well, any verified community member, at least) can request a new capability.

But not only that. It should be a place where people can comment on the request to add nuance or challenge assumptions. ask clarifying questions. It’s also a place where folks can up (or down) vote those feature request.

This voting capability is more than just a popularity contest. Remember, these are requests from the public who uses your software. They are taking their time to tell you what they need (and why). When an FR gets a significant number of up-votes, it should be seriously considered by your developers. More than that, the developer staff should have to justify why those FR’s are NOT on the list, each and every development cycle.

One piece of criticism I’ve heard about this idea is “what if they say, ‘make the product free’ or ‘buy me a pony’ ?” To clarify: I’m not saying you must slavishly execute on every FR. Of course there will be folks who put in requests as a lark or just to be funny. But the vast majority will be serious.

Some – while serious – will not be possible. And that’s OK. But it’s valuable insight to know that a majority of your user base wants (for example) dark mode. If that’s something your dev team you can’t deliver, then it’s at least something your marketing team should address.

Shall We Play a Game?

Underlying all of this is a truth about online communities: the best ones make engagement and participation fun. Part of that is the content and conversations, but another part is endorphin-boosting rewards. Having a “gamified” online system that assigns points to users who answer (and ask!) questions; who upload resources; who particpate in quizes and missions; who engage in scavenger hunts and other activities… having a system that automatically tracks and tally’s reward points for those types of behaviors is important.

Equally important is having something to DO with all those points. An online shop or other system that lets community members trade in points for swag may sound foolish, but it’s the sweet icing on the cake of community interactions for many of us. It helps give us a reason to hit YOUR site rather than one of the 3 dozen other options in front of us as we sit at our screens.

Communities Are Worth It

A vibrant, engaged, participatory community is more than just a gift of goodwill to the tech space at large (although it definitely is that). It’s also an engine for change, self-awareness, and profit for the sponsoring company. It is a valuable source of customer insight – from superfans to potential employees to canaries who give advance notice when something about your product has become toxic. In one company where I worked, over $1million of revenue per year could be directly attributed to community activities.

But they require work. That includes moderation, content curation, and a careful hand when it comes to participation by the platform owner (that’s you and your colleagues) but not domination.

Hybrid Cloud – the Worst Possible Option

Leon Adato — Mon, 13 Jul 2026 14:00:00 +0000

I’m excited to share that I’m in the process of writing a book for O’Reilly Media! You can check out the Introduction and first chapter of “A Practical Guide to Modern Networking Telemetry” now. That link leads to an early release version, which means it’s been “lightly edited”. If you have comments, corrections, questions, or even kudos, let our editor know: [email protected].

I’m co-authoring it with Avi Freedman, CEO of Kentik, and it’s a labor of love for both of us. As we wrote in the “About the Authors” section, the idea to write this arose first and foremost to get down on paper all of those samples, examples, stories, and lessons we usually share in at conferences, or in talks, or when helping customers; but also to provide a resource to the readers themselves: who might need to articulate those same lessons to colleagues, managers, or the odd (very odd) person at a dinner party.

There’s one comment from the introduction that I wanted to unwind a little bit in this blog. In the section titled, “What IS the Network, Exactly”, I wrote:

Back in 2023, in his book “The Ultimate Guide to Network Observability“, Avi wrote,

“People often refer to “the network” in their organizations, but in most cases the network isn’t one entity. It’s a complex, diverse, fragmented, and loosely interconnected set of physical and virtual links and equipment, and it’s housed in a variety of places, including data centers, corporate wide area networks (WANs), private and public clouds, the internet, container environments, and even inside hosts. Organizations own and control some of those resources but simply pay to use others.”

Since that time, things remain largely the same. Sure, the cloud has gotten more cloudy (meaning opaque to users) even as it has become more ubiquitous within organizations large and small. And at the same time corporate LAN and WAN environments have not, by and large, become less complex (or sprawling, or expensive). In fact, the opposite has been true. Even as company’s investment in cloud has increased, so too has their investment in on-premises networking gone up.

Why is that? Because the more we – businesses and IT professionals alike – use the cloud, the better we understand what the cloud should be used for; and conversely, where cloud should absolutely not be used, whether due to considerations of cost, complexity, or security. And in those cases, we have brought systems, applications, data, and solutions back into our data centers, and found new and creative ways to connect and combine it with the cloud infrastructure.

And that – the cursed franken-network of modern IT: infrastructure that spans both cloud and on-prem environments, offering all the complexity, cost, and issues of both, while offering very little of the benefits.

The sheer horrific nature of hybrid networking might not be intuitively obvious to folks reading this because we live and breathe in a technical context every day. So let me draw a parallel that might make it clearer: hybrid cars.

Blending a traditional gas-powered combustion engine with a modern fully-electric motor sounds like a great idea on paper, but in practice it’s a nightmare. The design burdens the user with all the quirks and complexities of both systems; it also creates a completely new set of quirks and complexities on top of those; and offers only modest benefits – which are usually completely outweighed by the negative aspects of smushing the two technologies into one form factor.

And that’s what hybrid networks are: the combined costs and complexities of on-premises and cloud networks, with a whole new layer of the same incurred by trying to make them play nicely together.

The big difference between hybrid cloud and hybrid cars is, of course, that we IT practitioners don’t have much of a choice. As much as we wish – hell, as much as we TRIED over the last decade to push environments to fully-cloud or fully-on prem, hybrid is the reality we’re going to live in for the foreseeable future.

And that means we – IT practitioners in general and folks who care about (and are responsible for) monitoring and observability in particular – have to improve the ways we ensure performance and reliability of those environments.

And here, approximately 700 words into this blog, I’ve finally gotten to the problem I hope “The Practical Guide” will help fix:

the folks who are often responsible for building the cloud-based side of those environments often know very little about networking
and meanwhile, the teams who are often responsible for building the on-prem side of those environments often know very little about modern observability.

The book offers a clear and complete explanation of everything from the types of devices that comprise a “network”; to the types of telemetry those devices emit; and continues from there to explain how to collect, transform, transmit, and use that telemetry.As I mentioned at the start of this blog, chapter 1 is available in its early release version now. Go ahead and give it a look, and let me know what you think – either in the comments below, or by emailing my editor Gary at [email protected].

Time Data Series: Written In Our Stars

Leon Adato — Wed, 08 Jul 2026 13:49:37 +0000

Once upon a time (i.e. way back in October 2024) I wrapped up a blog in this series with:

Believe it or not, there’s still more to cover. In the coming weeks whenever I get to it, I’d like to cover ways to leverage the built-in astronomy functions for time calculations. Believe it or not, it can really matter in terms of having truly accurate times for things like the start and end of Shabbat and holidays, along with other observances.

And here we are in 2025, when it’s finally time for me to fulfill that promise, and talk about how the KosherJava library (and by extension, the PHP Zmanim port I’ll be using in this blog) can help you calculate and display what amount to straight astronomy in your application or web page.

Once again I need to begin by expressing my deep gratitude to Zachary Weixelbaum and Eliyahu Hershfeld, who both continue to answer so many of my persistent (and often basic) questions with patience, care, and good humor.

The House of the Rising Sun

The core aspect of what I’m showing is fairly simple: For a specific location (latitude/longitude, plus timezone) and date, find the time of day that the sun will be at a given elevation point.

Or to be even more specific: At what time will the sun be at 20 degrees above the horizon on June 10, 2025 in Cleveland? So let’s break down the key elements of PHP Zmanim we’ll be focusing on today.

These two lines load the parts of the PHP library we’ll be using.

use PhpZmanim\Geo\GeoLocation;
use PhpZmanim\Calendar\ComplexZmanimCalendar;

Next, we set up a location object (using variables for location name, latitude, longitude, elevation, and time zone); and a calendar object (using the location object we just instantiated along with the year, month, and day):

$location = new GeoLocation($locname, $lat, $long, $elev, $tz);
$zmanim = new ComplexZmanimCalendar($location, $getyear, $getmonth, $getday);

Finally, the code that calculates and displays the results:

$sunrise = $zmanim->getsunrise();
$twenty = $zmanim->getSunriseOffsetByDegrees(70);
print("sunrise: $sunrise\n20 degrees: $twenty\n");

If playing along at home, I should explain that I grabbed both the regular sunrise simply as a reference to the time at which the sun is 20 degrees up in the sky.

I also need to explain that yes, I know that 70 is not 20, so how does THAT work out? The getSunriseOffsetByDegrees function “thinks” of the sun as being at 0 degrees when it’s at its zenith, and 90 degrees at the horizon line. So for the purposes of this function going up (higher in the sky) causes the degree value to go down.

The full code looks like this:

use PhpZmanim\Zmanim;
use Carbon\Carbon;
use PhpZmanim\Calendar\ComplexZmanimCalendar;
use PhpZmanim\Geo\GeoLocation;

# Set variables:
#41.4939407, -81.516709;
$locname = "Beit Knesset Chochmat Shlomo, Beachwood, OH";
$lat = 41.4939407;
$long = -81.516709;
$elev = 0;
$tz = 'America/New_York';
$getyear = "2025";
$getmonth = "06";
$getday = "10";

$location = new GeoLocation($locname, $lat, $long, $elev, $tz);
$zmanim = new ComplexZmanimCalendar($location, $getyear, $getmonth, $getday);
$sunrise = $zmanim->getsunrise();
$twenty = $zmanim->getSunriseOffsetByDegrees(70);
print("sunrise: $sunrise\n20 degrees: $twenty\n");
?>

When the Night Has Come, and the Land is Dark…

I’m sure there are useful reasons to know the time when the sun is at a certain point in the sky during the day, but from a religious perspective, there are far more reasons to want to know when the sun is below the horizon line. I say “religious” because I can think of at least two that care about the time of the sun’s position before sunrise: Judaism and Islam.

Both have a concept of dawn that indicates the very first visible lightening of the sky in the east. This time is known as fajr in Islam and alot hashachar in Judaism.

Because we’re talking about a matter of perception, it can be ferociously difficult to nail down, a matter not made any easier by the constant shifting of the sun over the year, and the differences due to latitude.

However – and bypassing a huge swath of religious debate – let’s accept the opinion that the first light is visible by perceptive humans on a clear day when the sun is 18

degrees below the horizon. How can we calculate that?

Honestly, it’s not hard now that you know the basic structure. In fact, we just have to change one thing:

$dawn = $zmanim->getSunriseOffsetByDegrees(90+18);

Yes, I could have just typed 108 but I wanted to make it explicit that we’re calculating 18 degrees before sunrise (90 degrees from the zenith).

Get Me to the Church Synagogue on Time…

To offer a more involved – not to mention specific – example of how this can be used, I’d like to explain one method of finding the time for “Tzeit haKochavim” (“nightfall”, which is more poetically described as the time when it’s dark enough to see 3 large stars in the sky). For this particular method, the following series of calculations are used:

Select the date of the equinox (spring or fall)
Get the time for sunset
Get the time when the sun is 3.86 degrees below the horizon (after sunset)
Get the difference in minutes between those 2 times
Select the current date
Calculate “seasonal minutes” – an even division of daylight 6.1) Subtract sunset from sunrise to get the total amount of daylight 6.2) Divide that time into 12 even “seasonal hours” 6.3) Divide 1 seasonal hour into 60 even “seasonal minutes”
multiply the clock minutes you got from the equinox day calculations and multiply them by seasonal minutes.
And finally, add THAT number of minutes to sunset, to get the time of “nightfall” / “Tzeit haKochavim”

Confused? Yep, me too. It took me a while to wrap my head around this. But here’s what it looks like in code:

First, let’s set our location and today’s date:

$locname = "Beit Knesset Chochmat Shlomo, Beachwood, OH";
$lat = 41.4939407;
$long = -81.516709;
$elev = 0;
$tz = 'America/New_York';
$getdate = date('Y-m-d');
$getyear = date('Y', strtotime($getdate));
$getmonth = date('m', strtotime($getdate));
$getday = date('d', strtotime($getdate));

Next, we’re going to create a location object, and use that location object to create a calendar object set to an equinox day (in this case March 20).

$location = new GeoLocation($locname, $lat, $long, $elev, $tz); 
$eqzmanim = new ComplexZmanimCalendar($location, $getyear, '3', '20');

Get sunset for that day, along with the time the sun is 3.86 degrees below the horizon

$eqsunset = $eqzmanim->getsunset();
$eqtzeit = $eqzmanim->getSunsetOffsetByDegrees(90+3.86);

Get the number of minutes between sunset and 3.86 degrees after sunset.

$tzeitmin = number_format((float)((strtotime($eqtzeit)-strtotime($eqsunset))), 2, '.', '')/60;

OK, now it’s time to get some calculations for TODAY’S date. We’ll create a new calendar object and grab sunrise and sunset:

$todayzmanim = new ComplexZmanimCalendar($location, $getyear, $getmonth, $getday);
$sunrise = $todayzmanim->getsunrise();
$sunset = $todayzmanim->getsunset();

Now we’ll divide the time between sunrise and sunset into 12 equal parts (a “sha’ah” in Hebrew), and then divide one sha’ah into 60 even parts. That will effectively give us the ratio of seasonal minutes to clock minutes

$stdshaamin = number_format((float)((strtotime($sunset)-strtotime($sunrise))/12)/60, 2, '.', '');
$stdzmaniot = $stdshaamin/60;

Now we multiply the number of minutes from our equinox day times the seasonal minute ratio.

$tzeitadjustment = $tzeitmin * $stdzmaniot;

And finally, we add that adjustment to today’s sundown (also note we have to multiply the adjustment * 60 to make the clock math work out).

$todaytzeit = date('Y-m-d G:i:s', strtotime($sunset) + $tzeitadjustment*60);

And let’s output it to see what we get:

print("sundown: $sunset\ntzeit: $todaytzeit\nadjustment: $tzeitadjustment\n");

For June 10, 2025, the output would look like this:

sundown: 2025-06-10 20:59:34
tzeit: 2025-06-10 21:19:59
adjustment: 20.4228

Good Night, My Someone

Believe it or not, we’re reached the end of my “Time Data Series”. I will, of course, keep adding things as I learn them myself. But – unless you have something specific you’d like to see (which, by all means, please tell me about in the comments), I’m going to turn out the lights, take a moment to admire the stars both for their beauty and the breathtaking wonder at the complexity of their movements, and head to bed.

Thank you for coming along on this ride with me.

HOW TO DEVREL: Fuel for Your Creativity

Leon Adato — Fri, 04 Jul 2025 01:54:58 +0000

In my last post I talked about re-factoring your content from one form into another (blog to video, video to conference talk, conference talk to podcast, etc.). Which is good as far as that idea goes, but there is so much more you can do.

In fact, let’s do a thought exercise:

The Idea Engine Challenge

Challenge #1: Put 1 minute on the timer, take your hands off your keyboard / phone (meaning: NO INTERNET!) and then:

name 10 (or more) sports teams

How many did you get? How many more could you have come up with if you had more time? How many could you have gotten if you could have used the internet?

Challenge #2: Put 3 minutes on the timer, take your hands off the internet, and then:

List 25 (or more) songs with the word “love” in the title

Good work! Once again, take a moment to reflect: How many more could you have done with more time, with the internet, or if you could have worked with a partner.

Challenge #3: Put 5 minutes on the timer, once again no internet, and then:

List 50 (or more) recipes – just the name/title, not the ingredients

And for the last time, take time to think about how many more you could have done with help (internet, friends, more time).

The Real Challenge

Now give yourself a luxurious 10 minutes on the clock. You’re allowed to use the internet, or phone a friend, or whatever else you want. And see if you can:

List 100 content ideas

OK, stop (whether it’s been 10 minutes, or 1 minute, or no minutes at all). If you’re like most folks, that challenge felt distinctly different, and not in a good way. If so, the first thing to understand is that it’s totally normal. Coming up with content ideas isn’t the same as coming up with city names or sports teams or song titles.

The second thing to consider: Why? What was so different about coming up with content ideas versus songs or recipes? Likely, one of the primary reasons is that, whether consciously or not, you had a system in place for the first 3. You probably started listing:

Sports teams from places where I’ve lived
Pop songs from high school (or some other significant period of your life)
Recipes I know how to make
…etc…

BUT… your brain, if it’s anything like mine, gave no such immediate framing when it came to the challenge for content. Again, if you’re like me, reading that question felt like opening a door onto a vast barren, featureless wasteland where there was very little to latch onto, to connect the dots with, to even build a series of ideas around.

Framework is the Key

That is the brilliant observation behind Melanie Deziel’s book, “The Content Fuel Framework“. In the book, she outlines a few central issues with content creation, and then offers a single conceptual solution which is simple, repeatable, and effective.

I’m going to stop here and ask you to at least click the link and consider buying the book. I believe it’s that good. In fact, if you plan to buy the ebook or audiobook version, then your time will be better spent reading THAT instead of THIS. But if you’re still on the fence, by all means keep reading so that I hopefully convince you by the end of this post.

Format Follows Focus

“I NEED AN 800-WORD BLOG POST ON ______!”

These words, uttered by far too many of my managers over the years, are as frustratingly vague as they are common. I’ve taken to muttering (usually under my breath and after ensuring my zoom call is on mute) “Would you like fries with that?” When I’m feeling slightly less snarky I try to get some details. “OK, so you want 800 words on Kubernetes and IOT. Anything specific ABOUT kubernetes and IOT?”

“Nope!” Chirps this (only slightly fictionalized) manager, “The SEO is trending on those two terms, so I just need you to, you know…” (and then they waggle their fingers at the computer screen as if casting a spell.)

Ignoring the whole “SEO-term-driven content management strategy of doom” for a moment, a deeper issue is the belief that CONTENT == BLOG. Content can, obviously, take many forms. But equally problematic is when we are asked to “make me a video on ______”, or “Can you whip up a podcast episode about _______”.

The issue, Ms. Deziel points out, isn’t the fact that they are asking for content, it’s that they (and we) are starting with the format, and working backward to a topic. Worst of all is that a distinct framing, or point of view, isn’t even part of the consideration.

First and foremost, “The Content Fuel Framework” advises, we need to start with the FOCUS of the content piece.

What do I (and more importantly, Ms. Deziel) mean by “focus”? It’s not the topic. Your topic can be kubernetes, or IOT, or mainframes, or kubernetes mainframes running on IOT, or whatever.

Your Focus is “…the approach we take to sharing [our message].” If you feel like that description is unhelpfully abstract, let me offer some examples. Your focus might be:

Basics
Details
People
History
Opinion

The first two are the easiest types of focus to understand. For “Basics”, just think of a content piece titled “Getting started with _____”. Meanwhile “Details” is the grown-up cousin of Basics. Imagine a title like “Everything you need to know about _____” or “A S]Step by Step Guide to _____.”

But the other focus examples above are less obvious. “People” might include a title like “What led John Smith to invent the mainframe?” or “A profile of the top 3 movers and shakers in the world of kubernetes today”.

In her book, the author shares 10 focus areas, with detailed descriptions of how they work. My goal today is to give you a sense of how a “focus” works, but not to outline them all.

Once a focus is chosen, then (and, I’d argue, ONLY then) can you consider the format. Some of the formats are obvious – writing, audio, and video. Some might not have leapt to your mind but make sense once you see them – Infographic, timeline, Quiz. Others require explanation to fully understand, like “Tool” and “Map”.

Again, my goal here isn’t to list or describe them all, but to indicate that as content creators, our habit of always reaching for the same old formats doesn’t serve us well. Expanding our range of options allows us to find new angles to tell familiar stories; and to find formats that better suit those stories rather than shoehorning everything into a blog or a stare-at-the-camera-and-talk style video.

Greater Than The Sum of It’s Parts

“The Content Fuel Framework” offers 10 focuses (focii?), and 10 formats. These are somewhat interchangeable, meaning you could start with a “People” focus and create a blog, AND a video, AND a podcast, AND an image gallery, AND…

I’m no Alfred Einstein when it comes to math, but I’m pretty sure that 10 x 10 gives us, theoretically, a single topic (Kubernetes and IOT) with 100 content pieces.

Realistically, you’re not going to do that. Some focuses simply lend themselves to certain formats better than others. More importantly some core topics will more readily lend themselves to certain focuses than others.

But having explained The Content Fuel Framework, I’d now ask you to scroll back and consider the challenge I set before you at the start of this blog: 100 content ideas in 10 minutes. As you think about how far you could get before the buzzer sounds, it’s my sincere hope that you feel better, if not equal to the challenge.

Through Structure, Freedom

It turns out that having a framework – a set of rules, guidelines, even limitations – can create clarity by eliminating ambiguity.

I’m not implying that this is the only way, or even the One True Way to create content. “The Content Fuel Framework” is just one way to break out of a rut and find a new way to approach what is, for most of us, a significant part of the day to day work of DevRel. There are, of course, many others ways (feel free to share them in the comments).

More importantly, your newfound confidence (however you got it) in generating ideas, angles, and implementations for content will translate to an improved ability to collaborate with the teams at work: First, you hopefully now have a structure you can use to teach them that there’s more to DevRel than writing a blog; and from there you have ways to help them tell the best possible stories. Stories that reach, help, and resonate with the greatest number of people.

HOW TO DEVREL: What I Learned From "Spider-Man, The Musical"

Leon Adato — Fri, 04 Jul 2025 01:53:33 +0000

You wrote a blog. You’re happy with it. Proud of it, even. You like the way you captured your voice and style in the written form. You also like what the blog says – what it teaches the reader. It’s a good little blog. In your imagination, you give it an affectionate little pat on the head. You click “Post” and make sure it shows up on the public-facing site. Maybe you even give it one more little read-through.

OR… you deliver a conference talk. The slides keep people’s attention, your delivery and timing is spot-on. You get laughs at just the right moments, and there are plenty of questions for you at the end. As the applause ends and people head for the next session, you take a deep breath, unplug your equipment, and close the slide deck.

OR… you created a video. Again, you’re happy with it – maybe even a little proud – for all the same reasons as I mentioned previously. You give it one more watch, then click “Publish”.

Time to move on, right?

Then you get a message. It might be from someone in the company, it might be a contact on social medial. Heck, it might even be your Mom. But the message says “You should turn this into a blog/video/conference talk!” Meaning, take it from the form it’s in now, and turn it into one of the other forms (or any one of a few different options that I’ll get to shortly).

Should you though? I mean, you just SAID everything you have to say. Why say it again? Why water down the power, effectiveness, and presence of the initial form by creating a derivative work?

An Intertwining Web of Tales

This is the dilemma we (creative folks in general, and technical content creators in particular) face when we consider the idea of “re-use”. And I’ll tell you why you should do it. Or at least strongly consider doing it: Because “Spider-Man, The Musical” exists.

Here’s tl;dr of what I mean: the story of “Spider-Man” exists in many many forms. But each format works in it’s own unique way that is complimentary to, but separate from, the others.

Spider-Man, of course, began his life on the printed page. But even there, a single comic book series wasn’t enough. Since it’s inception in 1962 there have been more than 60 different serialized Spider-Man story-lines, with multiple series running simultaneously for much of that time.

Then came the Saturday morning cartoon. It wasn’t better OR worse than the comic. It was DIFFERENT. It was able to do things the pulp fiction version couldn’t. And of course, there were things the paper version could do that could never make the translation to animation. Likewise the 1977 live-action tv series was able to present things that were missing in both the printed and animated stories.

And so it goes – from print to animated tv to live tv to live movies to animated moves and around and around, like a spider spinning it’s web – each form able to highlight and even elevate some aspects, but unable to depict others.

I would continue this entire analogy to the musical, but in reality “Spider-Man: Turn Off the Dark” struggled in just about every way. So I’m going to pivot to a different story to continue my point

The Circle of Creative Content

The Lion King was an award winning movie, a magical experience for those who were a certain age in 1994 when it came out. When the musical was announced in 1997, I was skeptical. How could a live action portrayal of Simba’s journey ever capture the sweeping majesty and raw power of the movie? And of course, my skepticism was utterly unfounded. The musical took such a different, and equally majestic form that it captured imaginations in a way the movie could not.

Pivoting further away from wall-crawling web-heads, there are plenty of other cases where an original creative work was transformed – either in it’s entirety or in it’s essence – to a different form that could arguably be said was as strong as, if not stronger, than the original. Just one such example is when Eric Clapton transformed the wailing rock song “Laylla” into a jazzy and almost haunting acoustic version for MTV’s “Unplugged”.

Revisiting the Question

Coming back to the initial dilemma: Should you take your original content and transform it to a different format? My answer should be obvious: of course. Taking a video and blog-ifying; taking a video and blogging it; taking a conference talk and recording it; each of these modulations from one format to another will allow you to elevate, highlight, and showcase aspects of the core narrative in ways that the original delivery could not.

Moreover, the work of transforming it will force you to consider things from an entirely different point of view, and this might shine a light on elements or ideas that you completely overlooked during your first pass – either because the original format couldn’t support it or because the very act of translation requires re-evaluation.

Far from being watered down, you may discover that your story – whatever form it’s in – becomes stronger, more cohesive, more well-defined as a result.

HOW TO DEVREL: The Texas Sharpshooter

Leon Adato — Thu, 03 Jul 2025 19:49:22 +0000

DISCLAIMER: I do not believe that I’m the universe’s gift to DevRel. I don’t have all the answers, all the experiences, all the skills, or even all the Pokemon. What I do have is my experiences, collected over 11 years of doing this work. That’s what I’m sharing in this series.

Work at a software vendor (or really any group that creates features for a set of consumers – whether those consumers are internal users or external customers) for any length of time and inevitably you experience a moment when a new feature, module, or capability is released to the public, and the response is the human equivalent of this:

It becomes clear that the intended audience has no idea what the new feature is, why it’s there, or – most critically – what problem or use-case it addresses.

This is not (or at least not always) because the feature is badly designed, ill conceived, or poorly executed. Sometimes, the response from users is because the problem hasn’t been socialized well enough. Nobody understands the nature of the disease, and therefore they can’t understand the importance of the cure.

As a DevRel, almost as important as our work helping folks understand HOW (to install, to use, to extend) is explaining WHY: Why this capability is necessary? Why we decided to create this instead of 6 other things on our backlog? Why this feature provides an optimal way to solve a particular problem.

But I’ll be honest: Explaining HOW is relatively easy. Explaining WHY can be a lot of work.

One of the techniques I use that makes explaining WHY easier is a variation of the Texas Sharpshooter story. While this is normally categorized as a logical fallacy (and, when used in data analysis or debate, it is), for Developer Relations Advocates it is actually a fairly useful technique.

The Man, the Myth, the Legend

I’ll start with the colorful story behind the evocative name:

Once there was a prince who was also an accomplished marksman, who was traveling through the land. Along the road he stopped at a village to rest his mount. He sat down under a tree—and right there in front of him was the side of a big barn. He couldn’t believe his eyes. That whole side of the barn was covered with little circles, drawn with chalk, and in the center of each circle was a bullet hole! He jumped up in amazement. Who is this sharpshooter around here who never misses? Maybe they could have a little contest while he was here.

So he knocked on the door of the farmhouse and asked if they knew who the marksman was. Yes, they did. They brought him a barefoot boy of about twelve. ‘Here he is, Your Excellency, our son the sharpshooter!’ Of course, the prince was surprised. He asked the boy, ‘Tell me, young fellow, how do you manage to hit the bullseye all the time? Here, look at all these medals. I’ve just finished five years of training and even I couldn’t hit the target every single time.’

‘Oh,’ said the boy, ‘there’s nothing to it. I just like to shoot. So I shoot at the side of the barn and then I take a piece of chalk and draw a circle around the hole.’

Context Matters

Shooting the bullet and then drawing the target later makes for a bad-faith argument, but it turns out it’s perfect for content-planning.

When you work “inside”, meaning you are working with the developers of a product, you are actually existing weeks or even months in the future. What I mean is, your day to day thoughts and internal discussions are about a future version: how it will work, the problems it solves, etc. Whereas the users of the product only know about the features and capabilities they have today.

It’s often a challenge to remember that your context – the problem you’ve been working on for weeks, the one that will be solved with this next release – is completely unknown and unexpected by the majority of users. They haven’t been pondering the complexities of the use case. THEY haven’t been investigating ways to remove friction, toil, or error.

Your v-dot-now is their v-dot-next.

The mistake many organizations (and the DevRel’s right along with them) make is releasing the new version with the expectation that everything – the problems, use cases, and purpose of the new version – will be intuitively obvious because, duh, we’ve been talking about it FOREVER, right?

That’s how you get the German shepherd look when you do the big reveal.

YOU know what the feature is going to do, what problems it will solve, what improvements it will bring. BUT… you also know it won’t be ready for a little while. Talking about it now, when features could slip, deadlines might be missed, priorities re-arranged… heck, when entire teams could be re-assigned… promoting the solution now would be asking for problems when things don’t go as planned.

But you also can’t talk about nothing. And that’s where the Texas Sharpshooter technique comes in.

The new feature is the metaphorical bullet. It’s already been shot, in the sense that development work is already happening. You know where it hit, so to speak. Despite the fact that nobody but your internal team can see it, the landing point is there, on the wall. You’re job right now is to draw a circle around that spot by socializing the problem. You draw attention to the problem, the point where the bullet WILL appear, by drawing a big old bull’s eye on that spot.

In blogs, opinion pieces, panel conversations, videos, or whatever, your job as a DevRel is to talk up the challenge, cost, and toil of the issue – what it is, why it’s a problem, how much damage it does, and the current (imperfect, complex, kludge-y) solutions that exist.

Period. That’s it. No parting of heavenly clouds, no angelic choir. Just you and the audience bonding over your shared experiences. You give a knowing look that says “Life in tech, amirite?”

By doing this, you establish the context for the eventual unveiling.

TAMO (then a miracle occurred)

The best part of this technique is that you can have multiple threads like this going at the same time. Because let’s face it, we’re in tech and we looooove to complain. And show off. And complain about showing off. And show of how we compla…. never mind. You get it.

My point is that the companies where we typical work as DevRel Advocates usually have multiple new features, modules, and improvements in the pipeline at any given time. Maybe only a couple will hit GA soon, but we can get ahead of the curve by socializing those problems and fostering the online discussions, debates, counterpoints, etc long before the release date.

More than just being a clever marketing ploy, the sharpshooter concept also allows the business to understand how customers and the community will ultimately react to the new release. By gauging the audience’s overall understanding of the technologies and techniques, the organization can have improved documentation documentation or educational resources ready to go. By listening to the specifics of the dialogue about the problem itself, adjustments (or even UX/UI sessions) can be added to the timeline.

When used thoughtfully, this technique allows for a better overall product as well as a better overall release.

HOW TO DEVREL: It Might Not Be New, but It's Yours

Leon Adato — Thu, 03 Jul 2025 19:47:08 +0000

Lately, I’ve had several conversations about “how to DevRel”. Some of that is absolutely related to my current job search. But it’s also been a topic that comes regularly even when I’m settled into a company: When meeting folks at a conference who want to understand what my title (which has fluctuated between “DevRel Advocate”, “Technical Evangelist”, and even “Head Geek”) means; Or discussing specific techniques with other DevRels on our super secret slack channel; Or justifying my existence internally because, even though the role has existed since 1980 half the company still doesn’t know what the frak it is, nor what it involves.

Although that last part is more due to the fact that “Developer Relations” is one of those five-jobs-in-a-trench-coat types of roles, so it’s understandable.

In any case, I’ve been mulling over not just what DevRel IS, but also the ways I approach the work of DevRel, from writing to video to community to speaking to demos and onward. And I thought I’d blog about it for a bit.

DISCLAIMER: I do not believe, for a moment, that I am the universe’s gift to DevRel. I don’t have all the answers, all the experiences, all the skills, or even all the Pokemon. What I do have is MY experiences, and while they aren’t the last word in DevRel, they are uniquely MY word about DevRel, collected over 11 years of doing this work. That’s what I plan to share.

We’ll call this my “How To DevRel” series, and see where it takes us. Today I want to address a common concern among content creators of all stripes, which is the fear that the thing you’re creating has already been created in some form by someone else, and who am I to take another swing at that topic now?

Nothing New Under the Sun

I’ll start by selectively cut-quoting Marianne Williamson (you can read the full quote here)

We ask ourselves, ‘Who am I to be brilliant, gorgeous, talented, fabulous?’ Actually, who are you not to be? […] Your playing small does not serve the world. There is nothing enlightened about shrinking so that other people won’t feel insecure around you. We are all meant to shine, as children do.

You’re afraid you’ll say something that has been said before? That you’ll demonstrate a tool or technique that’s been covered a dozen (or a hundred, or a thousand) times by the original inventor, and by someone from the inventor’s company, and by 6 different IT luminaries, (and so on, all the way down to the inventor’s dog)?

Let me put that worry into a different context to see if it still holds water:

Do you remember when you heard the song “White Christmas” that one time, and of course you never had to listen to it again, because you heard it already? How about the fact that Bing Crosby sang it just once, because he didn’t want to “be derivative”? And of course, nobody has ever sung “White Christmas” ever since, because of course Bing sang it and so it’s been sung and that’s all there is to it.

Of course not. The premise that we experience art once, that the first rendition is the only authentic one, is ridiculous.

Not only do we listen to the same recording over and over, many folks go out of their way to see the same performer sing the exact same song (or set of songs) multiple times. We go to hear cover bands play the exact same set but of course, with their own personal twist on things. We go to multiple renditions of a play or musical when they show up in our town.

In short, a story (whether it’s written or spoken or sung or danced or painted) becomes more powerful, not less, when we hear it through the lens of a different person’s experience and style.

Imitation is…

Yeah yeah, we all know that quote. And also the one Picasso said about stealing.

But here’s something important to understand: Imitation is when you do something that someone else has already done in the same way they did, without adding anything of your own, with the expressed intent of doing it that way BECAUSE the other person did it that way.

For creative folks, pure imitation is actually really REALLY difficult. It’s nearly impossible NOT to add our own spin on something. Even comedians who do impressions of other people understand that the real humor lies in “doing” the other person with just enough of a twist that it’s not just different for the sake of being different, it’s different in a small, subtle, and unexpected way. That’s what makes it funny.

On the other hand, even creations that were themselves inspired by other creations bring something new. “It Ain’t Me Babe” by Bob Dylan was inspired by The Beatles “She Loves You“. Sheryl Crow’s “All I Wanna Do” was inspired by Wyn Cooper’s poem “Fun“. Claude Monet’s “Déjeuner sur L’Herbe” was inspired by Edouard Manet’s painting of the same name. To go a little further afield, the Broadway musical “Sunday in the Park with George” was, of course, inspired by the Seurat painting “Un dimanche après-midi à l’Île de la Grande Jatte” (A Sunday Afternoon on the Island of La Grande Jatte) .

It’s OK to find inspiration and insight in the work of others, to build your story out of something you saw, read, or heard. Of course give credit where it’s due, but also trust that your creation is going to have it’s own new elements that make it fresh, valuable, and uniquely yours.

Saying it With Your Voice Adds Power

When you write (or make a video, or talk at a conference) about a new technique, technology, or experience – one that’s not NEW-new, but rather new-to-you – you open the door not only to folks who, like you, haven’t known about it but also you allow people who were already familiar with it the chance to see it through your eyes. Your excitement, curiosity, and enthusiasm cast the well-known into a new light. You also create the opportunity to review and re-think that topic, to reconsider it’s value or application today.

I believe in this idea so strongly, I took one of my conference talks – “Looking Back at a Lifetime of Poor Technical Choices“, and made it open source. I realized that even using the exact same format and structure, everyone’s journey and choices would come out so differently, and resonate so powerfully, that you could do 5 of the same talk in the row and they would all be interesting, compelling, entertaining, and informative. You can find it (and download it, and make it your own) here on my github repo.

So… If you find yourself asking, “Who am I to give this demo? To write about this topic? To host this podcast? To be on this panel?” then, to paraphrase Ms. Williamson, “…Who are you NOT to?”

She continues, powerfully,

“As we let our own light shine, we unconsciously give other people permission to do the same. As we are liberated from our own fear, our presence automatically liberates others.”