Personal Support at Internet Scale

How Pipedream does Developer Relations

When I was 17, I worked the Guest Services desk at Target: the place you take returns or deal with anything that goes wrong.

I was lucky to get the job. For a kid, it was a lot of responsibility. I treasured it, and learned everything I could about how to work with customers.

Target did support right:

1. We listened and empathized deeply with customers to form a personal connection and understand their needs. I learned that listening patiently and saying, "I hear you completely" goes a long way.
2. We solved the problem quickly.
3. We tried to solve 100% of problems. If a customer was looking for an item we didn't have in stock, we'd call other stores. If the customer tried to return something that broke after our 90-day return window, we'd help them call the manufacturer to see if a warranty covered the product.
4. We had the training, tools and autonomy to solve most problems ourselves. Escalating to a manager wastes customers' time. If we could solve the problem in the moment (even if it meant an exception to our policy), we'd do it.

16 years later, I'm a co-founder at Pipedream, an integration platform for developers.

I run a team of Developer Relations Engineers (DevRelEng). We're customer-facing software engineers that support a community of 200,000+ developers. And we're hiring!

Since our customers are developers, every customer interaction = developer relations. This includes marketing, sales, support, solutions architecture, and more. DevRelEng is involved in it all.

When I work with our customers, I use the same principles I learned at Target. But now, we're supporting users over the Internet. It's tougher to fully empathize because we can't read their body language. Communication is asynchronous, so it takes longer to address issues. And since anyone with a computer can use Pipedream, we receive a higher volume of requests.

How do we maintain highly-personal support at Internet scale? And how do we specifically tackle this for a developer tool like Pipedream? This is how DevRelEng was born.

Three principles govern our work:

1. Our customers are developers. Developers can empathize best with other developers, so they should interact with customers.
2. DevRelEng is equipped with the skills and autonomy needed to solve nearly every customer issue. We frequently ship code to production to fix a bug or address small feature requests. Issues are solved fast, and our customers notice.
3. We approach developer relations like software engineers, building internal tools and automating everything we can to make us more efficient.

It works well for us, and I'm excited to tell you all about it.

What is Pipedream?

Pipedream runs an integration platform for developers. What does that mean?

Developers use Pipedream to connect different apps and APIs together using a visual programming environment. If you need to send a message to Slack or write a record to your database each time someone opens a new issue in your GitHub repo, you can develop a "workflow" without writing code.

But you can run custom Node.js code anywhere you need it, extending any of the built-in actions or adding your own. This is where Pipedream shines. You can quickly transition from a no-code workflow to a Node.js serverless function as you need more complex logic.

You can use Pipedream to automate almost anything, and it's free. Watch the video below, or read our docs to learn more.

What does DevRelEng do at Pipedream?

You can break down DevRelEng into two core functions:

1. Supporting our customers
2. Building software / tools to better support our customers

Supporting our customers

It's worth reiterating our core mantra:

Since our customers are developers, every customer interaction = developer relations.

So when we say "support" in DevRelEng, we're talking about the whole customer lifecycle, from marketing to sales to technical support.

Pipedream is free for low-volume workflows. Most users chat with us in our Discourse, Slack, and GitHub communities. Many of these users are evaluating Pipedream for use on their team, and later upgrade to one of our paid plans. We aim to answer 100% of our community questions because:

1. It builds a public database of answers to common questions. If we answer a question once, it's indexed by Google and we can refer future users to these answers. We acquire a lot of new users from search keywords for specific APIs, so each new page we add (e.g. "How do I connect Stripe and Discord?") contributes to that acquisition strategy.
2. When someone gets a workflow working, they're hooked. They end up building more, and we convert a percentage of those users to a paid plan. We're doing Sales without explicitly selling anything. We just helped them use the product.

Larger teams have access to dedicated, priority support. DevRelEng handles that, too. Most of these customers use Slack, so we setup dedicated Slack Connect channels where they can reach us quickly (from the customer's perspective, nothing is better than chat support). These teams are composed of highly-technical power users. With them, we're often wearing our Solutions Architect hat, answering workflow design questions or helping them build custom sources and actions.

Like with our free customers, we try to answer questions in public. If a Teams customer asks a general product question in a private channel, we'll write a doc or a Discourse post and share it with them so that all users benefit.

We also hear a lot of product feedback as we talk to customers. Here, we act as Product Manager, asking a lot of clarifying questions to get at the core of what the user's asking for. Every new request is assigned a GitHub issue, and we ask future users to +1 those issues so we can track the most popular asks. We've developed a Pipedream workflow that collects this reaction data so we can analyze it:

This is a great example of how we're thinking like engineers when we solve support problems. It's a perfect segue to talk about the engineering side of DevRelEng.

DevRelEng software and tools

We use standard tools to manage our community (GitHub, Slack, Discourse) and infrastructure (AWS, Vercel, Snowflake, etc.). I'll tell you how we leverage these services, and how we automate everything we can using Pipedream (DevRelEng alone runs 40+ Pipedream workflows internally).

GitHub

import axios from "axios"

export default {  
  key: "http-get-request",
  name: "GET Request",
  description: "Make an HTTP `GET` request to example.com",
  type: "action",
  version: "0.0.1",
  async run() {
    return await axios({
      method: "GET",
      url: "https://example.com",
    })
  },
}

Our GitHub repo is the center of our developer community. All Pipedream components (triggers and actions you can use in workflows) live on GitHub. Any user can contribute new components for any app, and we manage component development on this project board. Our docs are public, as is our roadmap.

We run 10+ Pipedream workflows on different events from GitHub. For example, we kick off a workflow when specific labels are added to issues. When a user requests a new integration, the app label is assigned, and it sends the app request to our integrations team. When a user requests an event source, we add the source-docs label, which sends a message to the user asking them if they'd like to develop the source themselves:

This is a good example of how we automate highly-personal support. We write a kind, helpful note once, and we develop an automation to send it to any customer with the same request.

Discourse

Discourse provides an open-source community forum. All Discourse posts are indexed by Google, which helps existing users find answers to common questions, and attracts new users through search. We self-host our Discourse forum at https://pipedream.com/community as a Docker container using the discourse-docker project.

Slack

We also operate a public Slack, where people can ask questions about Pipedream, chat component development, or share workflows and tips.

Some people prefer to chat on Slack, others live in Discourse. We maintain both to let users communicate over their preferred channel. The main drawbacks are:

1. We split our community between Slack and Discourse (something I believe we can solve)
2. Slack isn't indexed by Google.

To solve #2, we built Discourse Bot: a Slack bot, powered by a workflow, that converts Slack threads to public Discourse topics.

Any time an issue is solved in Slack or a good discussion wraps up, we chat @Discourse Bot with the desired title of the Discourse topic:

That kicks off the workflow, converts Slack's message format to Markdown, uploads images, and creates a Discourse topic with posts for each message in the Slack thread:

Docs

https://pipedream.com/docs is managed with VuePress and deployed to Vercel. Docs are mostly written as Markdown, but VuePress lets us write custom Vue components when we need it. Anyone can edit our docs on GitHub.

We try to write comprehensive docs. Any time a user has a question, we ask, "is it documented?" If not, we'll either write a doc for it and share it with the user, or make a note to add a doc later. For this, we developed a Slack Bot called Docs Bot. We chat the Docs Bot in Slack:

That triggers this workflow, which creates a GitHub issue with the docs label:

Every couple of weeks, we search for all open docs requests and write a batch of them.

AWS

We run Pipedream on AWS, and the DevRelEng team is no different. A few example apps:

• We operate a Squid proxy paid customers can use to route HTTP traffic through a fixed IP.
• We run an anomaly detection app powered by Facebook's Prophet forecasting library. It tells us if metrics dip or rise in unexpected ways ("Did signups drop? Is something broken with that flow?"). We built the service because customers kept reaching out to tell us some feature broke before we noticed. Normally these issues show up in product data, so the app looks for these anomalies and tells us when they happen.
• We've also setup "dead man's switches" that tell us when core integrations break. For example, we run a Pipedream workflow that sends a message to Discord. A different workflow runs on new Discord messages in the same channel. If both workflows run successfully, we were able to send and receive messages from Discord, so the integration works. We ping AWS CloudWatch to notify them that message was processed end-to-end. But if this process breaks, the dead man's switch triggers since it hasn't received data, and we raise an alarm in Slack:

Segment, Snowflake, Looker

Product data is critical for our team. When we're troubleshooting a bug, we need to understand how many users might be impacted. Or we might want to look at the number of users who use a specific integration to assess the priority of developing new actions.

For analytics, we use the SSL stack:

• Segment: Usage data is recorded via Segment track calls. Segment syncs these events to Snowflake, managing the schema for us.
• Snowflake: Snowflake is fast, and works well as a product analytics database.
• Looker: Looker is essentially a pivot table for your database. We create a model of our Snowflake schema that maps SQL to metrics and dimensions. When you use Looker's UI, you write no SQL. You just pull in metrics and dimensions (e.g., I want to see the count of users who signed up for Pipedream week over week), and Looker runs SQL behind the scenes. Looker is critical for answering complex questions quickly.

Challenges ahead

Pipedream is three years old. The product itself and the nature of how we interact with our developers will change drastically over the coming years. As we grow the business, DevRelEng is thinking about a few core things:

• Content / SEO: Search traffic is critical for our user acquisition. If a developer asks Google how to integrate two apps, we want them to land on Pipedream. The whole company thinks about this problem, and DevRelEng tackles it from a community perspective. How do we develop more useful content for Pipedream and the integrations ecosystem at large? How do we encourage the community to generate content?
• Maintaining high-quality support: How do we continue to respond to 100% of requests in a personal, timely manner as we scale? This will involve a thoughtful mix of automation, technical writing, and cooperation with our community. We support 500+ apps, but we're not experts in them all. How do we leverage our community of experts, or the app providers themselves, to assist with bespoke integration questions?
• Scaling contributions: Building event sources and actions requires expertise in the target API. We are experts at building integrations, but again, we lack deep expertise in any one specific API. Our team is focused on improving the core Pipedream component API and reducing the barrier to contributions so that it's easy for the experts (app providers, community developers) to create components.
• Automating everything: We have a backlog of 30+ workflows we'd like to develop to solve things we do frequently (and manually) today.

Join the team

We're a small team with a lot of experience growing companies, but we need help solving these problems. We're looking for software engineers who like DevRel, DevRel who like writing code, teachers, solutions architects, and more. If you know how to write code and you've supported people in a technical role, you'll be a great fit. Apply here.

We're also hiring a UI Engineer and a Devops / Site Reliability Engineer.

If you have any questions about DevRelEng, Pipedream, or just want to say hi, I'm:

• Dylan Sather (Pipedream) on our public Slack
• dylburger on Discourse
• dylan at pipedream dot com