Hey Abhinav, DX is such a critical component to a successful API, and historically "developer" has meant "human." As agents become important consumers of APIs, what are your thoughts on how DX evolves? Is "agent experience" or "machine experience" different than developer experience?
Hello... I work on the Flows product at Postman. Love this question.
I believe wholly that the definition of a developer is rapidly changing (arguably has already changed). It's clear that it won't mean people who are "classically" trained in software development. I particularly like the view point that we're evolving from developers to conductors (SpecStory did a nice write up on this [1]) where we are more focused on orchestrating Agents.
I also think that APIs will either need to be ready for AI (trusted, solve for authentication, have clear specification, lots of examples) or will be AI dependent to fix them up and put a new layer on top. Discovering the right API to solve the problem is central to the dynamic logic agents introduce to workflows.
I've been building agents for both personal use and for automating internal processes within my team/across the company, and the DX has not felt all the foreign from typical development... an idea, a quick prototype, a tight inner loop for rapid feedback, then a graduation to a deployed asset. While not foreign, doesn't mean there isn't plenty of room for innovation. The DX is where we're really focused today, particularly with Flows.
If anyone else is wondering, TIL the spelling “Hallowe’en” on a number of these postcards is a contraction of “All Hallows’ Even," and that "even" was a common term for "evening" in Old and Middle English.
Thanks for mentioning this. Truth is I don't exactly remember. I'd say the first 10–20 were friends and former colleagues. Definitely people we directly reached out to and invited to the Slack.
There was also early interest around a framework we created called the Orbit Model[1], which at that point existed primarily in blogpost form.
Before starting Orbit, we did consulting[3] in the developer relations/developer marketing space for about a year, and had met a lot folks who were thinking about the challenges we sought to address, so that group of clients and prospects definitely provided the seeds for the early community.
But yeah, to your point: content can be a great way to attract like-minded folks to an early community. We certainly saw that with the combination of our blog + the Orbit Model.
> I think this could and should be generalized into "Avoid surprises"
Great way of putting it. When we were considering moving our community from Slack to Discord[1], we actually did a Request for Comment[2] laying-out our rationale, and asked for comments on the doc. I think this went a long way towards building trust and buy-in around big community decisions.
I run a tech community on discord and I'm having a really hard time keeping it alive and well. We've been active for about 5 years and it's hard to keep a tight group of regulars around. Most people seem to come and go, a lot of them only interested in getting their issue solved. People who are interested in being part of a community, chatting with other people etc, don't seem to find what they're looking for and end up leaving.
I have about a full renewal of the regulars every year or so where the old regulars become inactive and new people emerge but I can't seem to build a cohesive core of people and build a community culture around them beside the moderators. Have you managed this? How do you deal with retention and culture?
First day? Maybe 5 people we harangued into joining?
As for the first three months, it depends on when we start counting (I'd say May represented the first month we actually started working on community deliberately), but had 59 by end of July.
Thanks! We definitely could've started with events sooner, IMO. The simple practice of getting folks together to meet and talk shop contributed to the sense of momentum overall and the interpersonal connections in particular.
I should note that all the events we've done to date have been small, and focused on our existing community. I think such focus made sense for us in year one, since we were building the community and the product at the same time. In other words, we didn't have the capacity to produce a broadly-focused event.
That said, the intimate vibe in the early days goes a long way toward engendering a sense of ownership and belonging among community members. I honestly think it's more meaningful to do smaller insider events more frequently in the early days, versus casting a brand net and potentially diluting the group’s nascent identity and culture norms.
Now that we're scaling up, I anticipate increasing the reach of our events as well. But that’s okay, as we have the team to support it on one hand, and on the other, the culture of the community is already well-defined.
> "We used the word "love" a lot at DigitalOcean as one of the key/core values for how we thought about customers and community. "
Right on! We think the language we choose for our frameworks has many downstream effects, and we specifically use "Love" (versus something like “engagement”) in the Orbit Model: https://github.com/orbit-love/orbit-model
> "how do you think of blogs and content marketing w.r.t this? Is that a "big marketing effort" or does it fit into community?"
There’s definitely lots of overlap between content and community, and generally we don’t try to draw hard lines, as context matters so much.
For the purposes of this question, though, we can think in terms of a spectrum. On one end, all content would be community-generated, and on the other, all content would be produce and distributed by the company.
In most cases, you’ll have a mix of both.
In the case of NRG, the formula discussed in the article, the question is “how fast are we growing before layering on incremental investments in sales and marketing.”
For the purposes of this metric, I think the spirit of the law would say that company-generated content would fall outside of scope, but stuff that folks in the community were organically creating could reasonably be included.
Author of the post here. We compared each platform across ~25 factors, looking specifically at their utility for communities of different shapes and sizes.
I've found the book "New Kingmakers: How Developers Conquered the World" really instructive on this point.
It focuses on the "rise of the developer," if you will, as an influential decision-making and budget-holding role within a company. It also includes lots of perspective on appealing to developers and avoiding marketing and business jargon.
As a nontechnical founder myself, it's been really helpful.
For one we thought they'd care about TAM — most did, but the way the cared differed. In other words, some immediately required a firm answer to "How can this become a billion-dollar business," while others asked questions that seemed to pressure test our hypotheses and assumptions, but were more interested in quality of thought rather than our ability to see the future.
We thought they’d care about product mockups, but most didn’t. My assumption is that they knew it would all change drastically (they were right).
They did care a lot about how prior experiences would confer advantages, so we ended up leaning into that heavily the more we pitched.
reply