Skip to main content

5 posts tagged with "developer-relations"

View All Tags

· 5 min read
Tim Post

The point of an early design partnership period is to match everything your product is capable of doing with what the current market needs it to do in order to achive fit. Right now, early software startups really seem to need turn-key documentation sites that someone else hosts and updates for them, so that's precisely what we're putting into the first product that we've actually developed in conjunction with early clients.

We can now deliver a fully-responsive developer documentation & community site with the following features:

  • Automatically updated by us! We manage content updates, release notes, screen shots, feature spotlights and feeds. You schedule releases on a shared calendar and push a button to make it live when you're ready. We handle updating your documentation and writing the release notes automatically!

  • We can pull tickets that you tag for us in your existing issue tracking software to help us build narratives around releases. Just tag them for-echoreply along with major item or minor item respectively and we'll use them as building blocks in the story. We don't require many face-to-face calls.

  • Built on Docusaurus to bring the flexibility of MDX and fully-responsive / accessible design that is easy to customize to match your brand. We'll handle the initial theme setup to blend with your site. Anyone that knows Markdown can edit content; advanced users can use MDX and react components.

  • We store your video content on IPFS through Filebase. No more cluttering git repositories with mp4 files, or uploading videos to YouTube (unless you want to!). Additionally, Filebase provides true distributed storage via IPFS; while it provides an Amazon compatability layer in the form of an S3 compatable API, your files are actually hosted around the globe and pinned on the real IPFS.

  • Static content is built and Hosted on Netlify with serverless functions enabled for richer content experiences, metrics, live support and others. We're actively developing more Docusaurus plugins that take advantage of serverless functions, which is outside of the realm of the goals of the project itself.

  • Organized so that all of your content is stored separately from code, in plain text files. Anyone with knowledge of Markdown can create, edit and translate content or send pull requests to improve it, but your functions, components, configuration, etc is stored in a private repository. We accomplish this through Git submodule orchestration.

  • We submit PRs in advance of release dates and collaborate around it just like you currently do code, so you always know in advance what's going to be published.

Pricing for this depends on your release cycle, and the complexity of your software. To make sure the product works well for everyone, the base price includes having us involved in all of your releases, even minor ones, so that we remain involved in the release narrative. We'll make a bigger production out of the ones where there's more to get excited about.

If you're interested in this, please reach out to us so we can assess your product and see if we'd be a good fit at this stage. We can support monthly or longer release cycles with very little lead-in time and be up and running smoothly within 45 days.

Does it have to be (Docusaurus / Filebase / Netlify / etc)?

For now, in most cases, yes. Gatsby is another option if Docusaurus won't fit the bill.

This arrangement lets us automate (for the most part) both the incoming end and delivery end of the work. However, it's feasible that we could do things a little differently - reach out to us if you have something else in mind and we'll see how it might fit in our workflow.

Can you migrate our existing documentation site?

In many cases, yes. It would depend on the volume of content, the amount of content with proprietary markup, internationalization strategy and design. We'll apply your logo and brand theme colors when we get started.

How do you coordinate everything?

We use a shared calendar (Google) as well as a shared Slack or Discord channel; for the most part we'll feel like a part time remote employee.

Who writes the content?

The person with the most experience in your domain (who also naturally knows what to look for) will put together the foundation for the content. For consistency, only one or two editors (max) at a time work on the final product that we commit, so that voice and tone stay the same and writing standards remain above objectively met.

How much is it?

The base price is $2500.00 Monthly and includes two feature screencast videos and up to 10 pages of documentation professionally written or updated each month.

A 45 Minute Introductory Call Is Free - Take Advantage Of It With No Obligation! →

The initial evaluation is free and there's no pesky sales follow up calls. If we don't get excited about working togther on the call, we won't pester you.

· 3 min read
Tim Post

I don't think it's much of a stretch for those currently working in some capacity providing or in orbit around DevRel right now to see how I'm suggesting this connection. Our product, the thing they pay us for, is the production - we certainly guide the products as part of that, but at the end of the day, we're all actors.

Advocates utilize empathy in the opposition of their gols in order to understand how to make other voices heard. That, my friends, is getting in character, and then we somehow magically transform into another face entirely, training that keen sense of empathy outwardly, in order to help negotiate what you know to be the best possible compromise. That, dear friends, is also called getting into character, and it's a wonder we don't have more disgruntled theater majors in our ranks (I seriously only know of one, and don't keep tabs on their disgruntledness).

In order to be in a position to discover our career as actors, we probably started as community managers social workers, then went on to customer success or sales engineering, or marketing, and finally jumped into DevRel. And before any of that, we were software developers or something. But that's actually not really even subjectively true any longer, and that's what makes me excited. People are seeing that you don't need to really have 15 projects under your belt in order to understand programming enough to strongly empathize with pain and friction, and even be able to identify it.

This means that DevRel isn't just an essential role in a product-led industry, it's another conduit into the industry altogether. And I think companies that are struggling to hire for this role could very easily set their sights on people already set up to create amazing content and experiences who could very eaisly understand and creatively narrate your product.

I hope to strongly encourage this push and to be as welcoming to newcomers who feel like they might not have enough developer 'street cred' to be part of this amazing role that helps shape how tech gets built (and more importantly, influence what doesn't get built). Please know that for everyone who feels like their coding skills are lacking, there's 10 developers who would rather rewrite VB.NET than go anywhere near a camera.

And if you need a friend in the industry, I'm @tinkertim all over the place.

A 45 Minute Introductory Call Is Free - Take Advantage Of It With No Obligation! →

The initial evaluation is free and there's no pesky sales follow up calls. If we don't get excited about working togther on the call, we won't pester you.

· 5 min read
Tim Post

The sun has just about set on another Saturday evening and I've spent a lot of time thinking about personalities. Some thinking has been about my own and who I need to be for Echoreply to be successful, as well as who Echoreply needs to be as it starts taking off from the soul shard or two that I put in it.

We as marketers are charged with personifying organizations in an effort to make them more relateable, and if you follow frozen beef sheets on Twitter, you're looking at a new professional art form. We as marketers do this extremely well and that .. worries me sometimes in the world of software that we live in.

I've arrived at corporate personification being harmful and I need no other evidence beyond how much effort we believe is required for human beings to relate to other human beings on behalf of a brand. Why do we insist that organizations, comprised mostly of human beings, are less human and fallable than the sum of the humans they consist of? Why don't we just be ourselves and humans the 99.5% of the time that just being ourselves would be perfectly sufficient? I've come to call this "The Cult Of Tech Company Personalities" after also observing that most PR disasters I've ever directly been involved with or caused could have been averted had I just let people be themselves. This cult-like behavior really can grab ahold of you.

This phenomenon constantly tasks me because we try our best to help our clients NOT be like this; why we "Vulcanize" all of a sudden when speaking on behalf of our brand is something that keeps me up late at night and in the shower until the water runs tepid.

My approach, thus far, has been to integrate myself as much as possible in our client's product workflow and essentially bring out the character traits that the organization already has, in the form of writing guidelines and media standards that are needed for everyone to happily human together consistently when pointed outwardly.

There's always a point where people begin to wonder if the voice is too genuine; despite strict observance of all expected formailities, norms and other things, and zero evidence that changing anything would be a good idea. But, despite admitting it's irrational, our own comfort often makes us sound less like people when we communicate while working in general, magnified by 10 if we're outward-facing.

As humans we know "too nice" when we see it, often because our reaction to it is sufficiently viscereal that we can't really anticipate it. Echoreply is one of the few companies nuts enough to put serious engineering muscle into brand voice KPIs, so it leaves us with a bit of our own personality helix to decode. And that, folks, is fun stuff to work on.

We currently do a pretty good job of tracking the impact of even miniscule changes to any part of our funnels, even completely unintentional ones that we weren't specifically monitoring for -- this is thanks to really great observability and testing platforms that integrate effortlessly. However, social sentiment as well as plotting likely emotional influences in and between data sets is almost always left up to anecdotal observations distilled down by senior leaders - in other words, it goes 'out back' to die.

We need to help bridge the "I can see this anecdotally" -> "I can Show You Where This Has Been Hiding" gap. Put another way, you notice when those you trust have even tiny changes to their personalities, which can sometimes make friendships with people who are still finding their authentic selves rather diffifcult at times. Unfortunately, we far too often overcorrect for this presumption when we think about it in the sense of our business and all too often deliver ourselves like pretentious, bland and strikingly overpriced theme park food.

Echoreply's process (currently in development) flips this on its head, asserts that humans are perfectly capable of relating to one another with their own personliaties, and implements only a minimal amount of structure on communications. That's usually a very bad idea, unless you can monitor it in real time and chart corrections organization-wide in how you relate to people.

That's what gets me out of bed every day. I'm sick and tired of all the product super hero stories revolving around someone in CS or DevRel or somewhere else having to break ranks and just be human instead. Why don't we just, y'know, do that by default? I can't wait to bring that to reality with all the guard rails it needs to work.

And thanks for helping me think out loud as the sun warms the front face of our house. This and more highly-specialized KPIs will soon be available to design partners in their client area, and also available via version-0 of our REST API which is coming out a month from tomorrow.

A 45 Minute Introductory Call Is Free - Take Advantage Of It With No Obligation! →

The initial evaluation is free and there's no pesky sales follow up calls. If we don't get excited about working togther on the call, we won't pester you.

· 4 min read
Tim Post

I'm often asked, "Should the person handling Developer Relations report to Product or Engineering?"

Sometimes, the answer is "yes", but most often, the answer is "neither" and what comes next might just surprise you - we've seen the best success when DevRel reported into Marketing. The reasons for this are also interesting:

  1. It prevents power dynamics from short-circuiting the advocacy function that the Developer Relations role critically supports. You can't be annoying, even professionally annoying, if you're worried about how it's going to affect your comp or performance review. That may NEVER be a problem where you are and if it's not, then fantastic. But you need to think about it hard.

  2. It tightly couples messaging that's given across a variety of contexts to fill a variety of needs. The reason you have a DevRel is to communicate outwardly beyond what the marketing for top-down adoption strategies is communicating. If you're reporting into the marketing wing, you're constantly perfecting this with them, and it's subsequently stronger.

  3. It lets you set DevRel as a goal for anyone junior on your marketing squad. Don't just wait for engineers to realize they take a shine to the marketing stuff, let marketers also feel like they can take a shine to the engineering stuff. What matters is real voices come out.

DevRel really is about the show which is why we really feel like it belongs in the creator space as much as it does anywhere. We're storytellers with a knack for simplifying complicated concepts; having been an engineer is one way of acquiring that, but certainly not the only one.

What About Reporting To Sales Engineering Or Support Engineering?

Those would also be fantastic choices for DevRel to report to. In fact, it might actually be preferable if there is an unusually high "touch" count for onboarding to your product, because it's certain to ensure the DevRel stays very focused on friction points as they work with the product folks, and saves lots of time back and forth.

Similarly, if you're at a point where your value proposition still requires a complicated demonstration, it might make sense for the DevRel to report into the sales wing as sort of a bastion against breakage for client workflows.

Whatever makes sense, but again, keep in mind that advocates need to, well, advocate - make sure there's no conflict of interest with self-advancement from just doing their jobs.

This Doesn't Change The Universal Hat Stand Function Of DevRel.

Often called the glue that binds multiple teams together, we also have to ensure that if just one role is super-optimized with whatever is needed to operate with great autonomy between teams, it's this one. So before you go changing who reports where, it takes a special kind of manager to help developer advocates succeeed.

One day you're learning about pain points in a language you've never used before; the next day you're recording a feature demo, and then you need to put some time into thinking about how you can get your users the best deal in a controversial feature update - my point is, you don't produce consistent artifacts just by working consistent hours every week. Managers need a great deal of trust and emotional grown-upness to grow people in this role.

You Can Also Just Hire Us And Think About More Important Things Right Now.

We can take care of most early needs until you're getting close to realizing launch and making some hires, and it's extremely affordable.

A 45 Minute Introductory Call Is Free - Take Advantage Of It With No Obligation! →

The initial evaluation is free and there's no pesky sales follow up calls. If we don't get excited about working togther on the call, we won't pester you.

· 2 min read
Tim Post

Developer Relations and Developer Marketing On Demand is a service by Echoreply that lets you access professional narration of and evangelism for products made for software developers without hiring a full time person to do this.

Our service is unique in that we strictly deal with developer marketing and we have strong engineering backgrounds; we're the hybrids that can both spot and appreciate the wow points in developer tooling. The reason that typical marketing companies don't make material as authentic as what you can do in house is it takes many kinds of specialization to see the entire picture.

Now, it's more affordable and accessible than ever. During our design partnersnip phase, we're distilling a vast mix of Marketing / Public / Developer Relations core competencies into services that can be augmented or based on software that we create which provides immediate value to early-stage companies, starting at the consultation.

Look for more soon, in the meantime, welcome to our MVP launch and thank you for your interest!

A 45 Minute Introductory Call Is Free - Take Advantage Of It With No Obligation! →

The initial evaluation is free and there's no pesky sales follow up calls. If we don't get excited about working togther on the call, we won't pester you.