DEV Community: Mary Thengvall

Prioritizing Our DevRel Backlog with Form Builder, DMN, and a Process Model

Mary Thengvall — Mon, 22 May 2023 19:32:16 +0000

Developer Relations teams typically have a wide variety of skills to meet community members where they are and help them get where they need to be. These skills can range from programming, creating content, and giving technical presentations, to mentoring community members on the best ways to use the product, running community programs, and communicating feedback to internal teams on ways to improve the product experience. But when the backlog grows faster than tasks can be completed, how do we prioritize the work that’s in front of us, ensuring we’re working on the most impactful items?

I recently faced this predicament on my own team here at Camunda. I needed to not only help my team decide which projects to prioritize but also help our coworkers understand how (and why) we respond to new requests.

While I could have written and published an internal strategy doc that listed our reasoning, information overload sets in quickly, and I’d rather not ask Camunda employees (Camundi) to read yet another page in our internal wiki every time they have a request. Instead, I turned to DMN and Camunda Platform 8’s new features to build a process model with an integrated form. While it’s not yet perfect, it’s already benefiting my team! How did I get here?

Step 1: Identify the criteria for prioritization

I chose to start with a DMN table, which would be the foundation of the model. Before I could build this table, however, I had to identify the criteria we would use to prioritize the DevRel team’s work. Many DevRel teams prioritize tasks based on impact on the developer community, alignment with the company’s goals, or level of effort.

In our case, the assumption is that the work being submitted to this form is independent of the projects we’ve already taken on as a team for the quarter. This allowed me to keep our criteria simple: alignment with the team goals and the urgency of the task.

Step 2: Create a decision table

With this criteria defined, it’s time to create the DMN table. These tables map the input values (timing and goals) to the output value (priority) based on a set of rules. A nice perk of building the prioritization rules into this table is that as our criteria change over time, I can update the table and the new rules will take effect immediately. Because the table is versioned, I can revert to a previous iteration at any time if necessary.

The first thing I had to define was the input data which the decision table will use to process requests. In my case, I used the following:

Input: 2023 Goals
Expression: goals
Type: string
Predefined Values: “healthy C8 community” “successful C8 community” “C8 community onboarding” “other”

Note: While filling in predefined values is optional, I found it helpful when populating the decision rules.

I set the second input (Timing) with fairly general ranges: this week, month, or quarter, and next week, month, or quarter, as well as no specific timeframe.

I kept the output value very straightforward: yes or no, with a possible exception that could be raised to me if necessary. Lastly, I’ve used the hit policy “first” in order to evaluate the rules from top to bottom and stop when a match is found.

The end result is a decision matrix that allows us to easily filter company requests that meet these specific goals and aren’t urgent (e.g. can be completed this month, next month, or next quarter). For anything that falls into the “this week” or “next week” timing, it’s likely going to be a no, unless it’s a very high-priority task that also aligns with our goals; in this case, the request is flagged as a possible exception in need of review. The outcome is a fairly straightforward model that outlines when we can prioritize requests and when we’ll need to either reconsider them at a later time or simply say no.

Step 3: Create a form to populate the decision table

I repurposed a simple Google form we’ve used for years, using the Camunda Form Builder so I could integrate it with my decision table.

Once the form was created, I made sure the key for the questions around the goals and the timing matched up with the expression in my DMN table.

Step 4: Integrate the form and decision table into a process model

An idea is submitted & evaluated

The next step was to create a process model using Web Modeler. This model represents the process of prioritizing tasks, including collecting the criteria via the form, applying the decision table to determine the priority of the task, and communicating the decision to the appropriate Camundi. Let’s take a look at the current model:

The first section of the model includes the completion of the form, the DMN table which helps us prioritize the task, and an automated Slack message (using our Slack Connector) that notifies the DevRel team a new request has been submitted.

I connected the form to the model by copying the JSON from the code editor in the form builder and pasting it into the properties panel of the user task “Complete DevRel Request Form.”

I then added a Business Rule task and connected it to the DMN table I created by associating the following fields:

I copied the ID for the Decision from the Decision Requirements Diagram (DRD) view and pasted it in the Called Decision: Decision ID field for the Business Rule task.
In the Result Variable field, I pasted the output name from my DMN table (abilityToHelp).

It was important to me to minimize blockers (including myself) for these requests and better enable my team to take action, so I wanted to make sure the entire team would be alerted whenever someone filled out the form. Using the Slack Connector, I set up an alert to go directly to our team channel.

The next iteration will include a link to the specific request, in addition to the results of the DMN table so it will be easy to see at a glance whether additional insight is needed.

The decision is validated

The next step in our process is to validate the decisions.

There are two decision gateways here:

Do you need help making a decision? The DMN table will automatically determine this step, moving requests directly to Look at automated decision if the answer is a clear yes or no. If the answer from the DMN table is abilityToHelp = “possible exception,” it will be flagged and go the Escalate to Manager route.
Do you agree with the decision? When I was first designing this process, our Community Manager Maria Alcantara made the excellent observation that there may be times when users disagree with the automated decision. If this is the case, requests should be escalated to the manager.

Right now, looking at the automated decision as well as making the decision are user tasks that have to be managed within Tasklist. If users need to escalate to manager in either case, they can type in a variable agree = false for the first question and doThing = false for the second. In the next iteration of this model, I’d like to have a Slack integration that allows us to say yes or no to both of these questions in order to move forward seamlessly.

The end result of all these decisions is that we have a clear path forward: we’re either going to tackle this project or not.

The outcome is communicated

Feedback loops are important to us at Camunda, so I wanted to make sure no matter what the decision was, there was a follow-up with the person who requested help.

Rather than listing every Camundi in the Requester DMN table, I chose to include variants of our team members’ names: first name and first + last name, in lowercase as well as camelcase, since DMN tables are case sensitive. The output is groupCamundi with either the value of devrelTeam or_ colleague._

These final tasks are all user tasks, but again, there are opportunities to include automation here:

Create a Trello card in our task board based on the form.
Send a refusal message to the individual who submitted the request.
Notify the requester when the task is moved to the done column in our task board.

We could likely even turn the form into a Slack bot that then pings the appropriate team member. In short, there are all sorts of possible iterations here, which we’ll definitely explore as we roll this out company-wide.

Step 5: Be more productive

I have high hopes that this process model will continue to help us prioritize our work more effectively, ensuring we focus our efforts on the tasks that will have the greatest impact on our community members as well as Camunda company goals. Additionally, by streamlining the prioritization process, we are able to complete tasks more quickly and efficiently, improving our overall productivity.

While this prioritization of tasks might seem like a relatively small and perhaps insignificant issue compared to the other items on our plate, this DMN table, form, and process model will serve as the foundation for future team endeavors and resource-planning. Here’s to solving “mole hills” before they turn into mountains!

What have you created with Camunda lately? Let us know over in our forum. I’d love to hear how process models have made your day-to-day work easier!

The post Prioritizing Our DevRel Backlog with Form Builder, DMN, and a Process Model appeared first on Camunda.

Camunda Cloud: Podcast Edition

Mary Thengvall — Thu, 13 May 2021 10:00:00 +0000

title: Camunda Cloud: Podcast Edition

published: true
date: 2021-05-13 10:00:00 UTC
tags: CamundaCloud,CloudNative,Podcast,ProcessAutomation
canonical_url: https://camunda.com/blog/2021/05/camunda-cloud-podcast-edition/

The latest episode of the Camunda Nation podcast is live and we’ve recorded a Camunda Cloud special for you. Join Camunda’s CTO Daniel Meyer, Camunda Cloud Project Manager Felix Mueller and Sebastian Menski, Director of Camunda Cloud Engineering, as they talk all about Camunda Cloud going GA with the release of Camunda Cloud 1.0.

We discuss:

What is Camunda Cloud?
What’s new in Camunda Cloud 1.0?
How to choose between Camunda Platform and Camunda Cloud?
What’s coming next for Camunda Cloud?

The Camunda Nation podcast is the voice of the Camunda Community, from product managers and engineers, to innovative open source contributors and empowered customers. It’s freely available on a range of channels including Spotify, Google Podcasts, and Apple Podcasts.

Don’t forget to let us know what you think – you can reach us on Twitter, drop into the Forum or get in touch via our website.

The post Camunda Cloud: Podcast Edition appeared first on Camunda.

Introducing Camunda Cloud – Industry-First Process Automation as a Service

Mary Thengvall — Tue, 11 May 2021 13:00:00 +0000

title: Introducing Camunda Cloud – Industry-First Process Automation as a Service

published: true
date: 2021-05-11 13:00:00 UTC
tags: ProcessAutomation,WorkflowAutomation,camunda,cloudnative
canonical_url: https://camunda.com/blog/2021/05/relentless-innovation-introducing-camunda-cloud-10/

At Camunda, we have always pushed ourselves to innovate in the field of Process Automation. From our early days as a lightweight Java project, we’ve relentlessly innovated — engineering an end-to-end Process Automation tech stack that has helped organizations across the globe automate mission-critical processes.

But innovation never stops and organizations continue to look for new ways to increase the velocity of business transformation. To address this need, more and more organizations are turning to the cloud, which is increasingly becoming a business transformation accelerator.

That being said, as enterprise applications are being built entirely in the cloud, organizations are struggling with automating processes across multiple systems, people, and devices in an end-to-end manner. These processes often include modern components such as microservices and serverless architectures, as well as distributed and high-throughput applications. Development teams are finding it time-consuming and cumbersome to build and run their own Process Automation environments, adding significant cost and delays to their application development timelines.

In a world where organizations have come to expect the simplicity and efficiency of Cloud-based, fully managed services, Process Automation is no exception. We therefore want to provide an enterprise-scale Process Automation as a Service solution that is truly transformative and lives up to the expectations of our “cloud-first” customers and users. That’s why we’re excited to announce the General Availability of Camunda Cloud.

Camunda Cloud

Camunda Cloud is an enterprise SaaS solution for end-to-end Process Automation built from the ground up for the cloud. It is based on the ISO standard BPMN and includes a horizontally scalable workflow engine along with built-in components for collaborative modeling, operations, and analytics.

As a fully managed Process Automation as a Service, it provides push-button deployment and is ideal for enterprise development teams that need instant access to highly scalable process automation services for their mission-critical applications. Being built for the Cloud means a flexible, open architecture which easily fits into existing environments, while also running on Kubernetes with loosely coupled building blocks that can be deployed and scaled individually, making it effortless to scale for Cloud native applications.

Just like Camunda Platform, Camunda Cloud puts developers centerstage — it is built to improve developer productivity with built-in integrations for a broad range of programming languages and tools.

As I said in my recent keynote at Camunda Community Summit: We believe that Camunda Cloud will accelerate how organizations will be able to adopt process automation in a way that will be highly developer-friendly, but at the same time, will remove heavy operational burdens.

To enable organizations even more and help them to accelerate their Process Automation journey, we have engineered a Cloud native stack that covers the full automation lifecycle:

Collaborative process design for business & IT with human-readable graphical models based on the ISO-standard BPMN 2.0.
Horizontally scalable workflow orchestration powered by a new class of BPMN workflow engine that delivers true horizontal scalability and enables high-performance use cases that were once beyond the realm of workflow automation.
Process visibility & monitoring for mission-critical processes that span multiple systems and services. With tools designed for teams to manage, monitor, troubleshoot running workflow instances.
On demand and scalable with native Kubernetes integration to easily create and manage all workflow clusters. Deploy processes at the push of a button, scale to meet needs, monitor cluster health and control organizational settings.
Built in gRPC integration supports a broad range of programming languages including Java, C#, NodeJS, Ruby, Rust and Golang.
Support for a variety of process use cases including microservices orchestration, serverless function orchestration (e.g. AWS Lambda), human workflow management, and end-to-end Process Automation across people, systems, and devices.

Proven in Production

Camunda Cloud has been built with significant input from customers who have already deployed the solution in production environments during an extensive public beta period and an early access program. Camunda Cloud is being used globally for various use cases. athenahealth is using it to automate its messaging campaigns:

“We needed to orchestrate and automate the millions of messages that we send out on a daily basis. Camunda Cloud provides the advanced workflow and high throughput capabilities we need while making it easy for us to run millions of process instances at any given time.”

Kunal Shrestha, Director of Product Management, athenahealth.

Mineko is another example:

“Using BPMN improves maintainability of the orchestration. We can show all orchestration models to our colleagues and stakeholders without having problems explaining it.”

Felix Jordan, CTO, Mineko

If you’d like to see more of the amazing projects our early adopters have built, read how MINEKO is orchestrating AWS lambdas with Camunda Cloud.

Availability

We’re making Camunda Cloud available immediately, and on demand at camunda.com/cloud. It will be available in three distinct plans:

The Free trial plan which provides users the ability to easily get started modeling and deploying processes in Camunda Cloud. It includes the entire Camunda Cloud feature set along with Community support.
The Professional plan which is designed with self-service in mind, and provides a quick and easy entry point for a paid subscription that’s ideal for small teams to get started with Camunda Cloud. It comes at a base price of USD $990/month and is billed annually. This base price includes predefined Process Instances, Task Users, and a pre-configured set of cloud hardware resources. Please visit the Professional plan FAQfor more details. It also includes 8×5 support in your timezone. Additional Process Instances, Task Users and cloud resources are available based on consumption pricing.
The Enterprise plan, which is ideal for organizations looking to automate several of their business processes. It can scale effortlessly to support a large number of monthly process instances, includes enterprise SLAs and 24×7 support.

Camunda Cloud is immediately available on-demand at camunda.com/cloud.

You can read more about Camunda Cloud in our release blog and don’t forget to let us know what you think — your feedback shapes our products and we’re looking forward to hearing what you have to say and learning more about what you’re building with Camunda Cloud. You can easily reach us on the Camunda Forum or get in touch with us via our website.

The post Introducing Camunda Cloud – Industry-First Process Automation as a Service appeared first on Camunda.

A Can’t-Miss Opportunity for Camunda Developers

Mary Thengvall — Thu, 22 Apr 2021 13:00:00 +0000

title: A Can’t-Miss Opportunity for Camunda Developers

published: true
date: 2021-04-22 13:00:00 UTC
tags: processautomation, event, camunda
canonical_url: https://camunda.com/blog/2021/04/a-cant-miss-opportunity-for-camunda-developers/

It’s almost here! We’re counting down the days to the first-ever Camunda Community Summit, a two-day event curated especially by developers for developers. During the summit, our speakers will take deep dives into technical topics, provide live coding demonstrations, and show off the latest advances in product automation — all in a highly collaborative virtual format. Much more than a “Camunda 101” introduction to process automation, the summit is geared toward expert Camunda developers who want to get even more out of the platform.

The Camunda Community Summit offers participants the opportunity to learn, contribute, socialize, and grow. Specifically, you can expect:

An interactive opportunity to learn from experienced Camunda community members
A place to share your Camunda knowledge and experience
A chance to meet and build relationships with others in the Camunda community
A way to expand your knowledge and skills by getting real-world feedback on the work you do

Registration is now open, and there is no cost to attend. Want more details? Here’s the scoop:

Day 1 focuses on the topics that matter most to you during our Unconference. Our just-announced Day 1 agenda features sessions submitted by community members and upvoted by the community. From orchestrating microservices using the Camunda platform to proven strategies for creating a good process model, Day 1’s conversations with Camunda engineers and community experts will give you a unique opportunity to learn from and collaborate with each other.
Day 2 kicks off with a keynote presentation by Camunda CTO Daniel Meyer; he’ll share a perspective of Camunda’s developer-friendly approach to process automation, an overview of what’s new in Camunda Platform 7.15 and what’s around the corner in our next release, and a look at Process Automation as a Service with Camunda Cloud. We then will break into three distinct tracks focusing on up and coming technologies, intermediate/advanced Camunda topics, and inside insights from Camunda employees.

We are delighted to have some of the best and brightest minds in the industry sharing their expertise throughout the Camunda Community Summit. Our impressive speaker roster includes:

Adrianna Tan, director of product management for the City and County of San Francisco, talking about how to use automation to simplify and improve existing needs and address future problems.
Markus Stahl, automation engineer for Deutsche Post Adress, presenting his company’s open source contribution that provides a bridge between Camunda and Robot Framework, helping attendees understand why this combination outpaces common commercial RPA.
Krishna Kumar, principal software engineer of Walmart Labs, explaining how Camunda Platform helped the company grow its wireless business by combining customer-centric and process-centric approaches.

The Camunda Community Summit promises to be a valuable, insightful experience for developers and process automation pros — and there is no cost to participate. Register today for the summit, and we’ll look forward to virtually seeing you next week.

Photo by Pakata Goh on Unsplash

The post A Can’t-Miss Opportunity for Camunda Developers appeared first on Camunda.

The DevRel Path to Success: Awareness, Enablement, Engagement

Mary Thengvall — Wed, 10 Mar 2021 03:22:05 +0000

I’ve had dozens of conversations over the last year alone with people who are wondering how to split up the work within a Developer Relations team. Whether you’re trying to figure out what type of Developer Relations professional to hire (someone with a developer background? someone who has experience running a community forum? someone who thrives when faced with the creative challenge of how to make people aware of your new product?) or trying to decide which of your team members is responsible for which tasks (as I’m doing at Camunda right now!), having a clear framework with which to divide the responsibilities and focus our work is important.

In a previous blogpost, I mentioned that supporting your company's empowerment of the technical community is the cornerstone of what we do as Developer Relations professionals. This foundational understanding can then be divided into a few categories: awareness, enablement, and engagement.

Let’s start with definitions. What do I mean by “empowerment”?

To give someone confidence or strength to do something.

The Path to Empowerment

In order for a technical individual to succeed with your product, they need to be confident that they have the ability to use your product, or at least the confidence that they can find the resources which will make them successful.

In order for them to have this confidence, they first need to be aware that your product exists and is capable of meeting their needs.

Next, the resources that exist need to be capable of enabling them to use your product. This could be your documentation, best practices guides, tutorials, client libraries… the list goes on. But this experience of onboarding with your product, and understanding that they’re capable of easily using your product to solve their problems, is a huge step toward adoption.

Lastly, once a community member has adopted your product, it’s time for them to engage with your community.

At Camunda, the DevRel team’s mission is to “provide opportunities for developers to be more successful by making them aware of our solutions, enabling them through great experiences, and fostering a culture of collaboration.”

We empower developers and other technical professionals to be successful by making them aware of our products and projects, enabling them through the content and excellent experiences we produce, and inviting them to engage and collaborate with us as well as other Camunda community members.

3 Functions of Developer Relations

Our team has three distinct functions: Developer Advocacy, Developer Experience, and Community Management. These three segments loosely map to the path to success that we set up for our community members: Awareness, Enablement, and Engagement.

Note: This is a generalization based on the range that my team’s responsibilities fall. I understand some of these responsibilities can fall outside of these particular roles as well as within multiple functions within the Developer Relations team. There are also items that fall within the purview of all three functions (see the inner triangle). Think I’m missing something or that some of these items belong in a different place? Leave a comment below!

Special thanks to Danielle Andrist for designing this illustration!

Broadly speaking, our Developer Advocates are responsible for making sure our community is aware of the solutions we provide. They do this through producing content (blogposts, speaking engagements, livestreams, etc.), building sample applications and integrations, and building relationships in the broader tech industry. They also make our Product Managers, Engineering Leads, and other stakeholders throughout the company aware of relevant, actionable feedback from our community of users as well as the broader technical community. This product feedback coupled with information about the broader tech industry (what are the trends that they’re noticing? how are other open source communities handling certain issues? what’s the latest framework or extension that we should look into?) is incredibly valuable information and plays an important role in the enablement of our community members.

Our Developer Experience team is the team primarily responsible for this developer enablement. From the standardization, accessibility, and readability of our documentation to the initial experience a developer has when they first encounter our product to the contributor experience, this function is what puts the finishing touches on a fantastic talk from a Developer Advocate at a technical conference. The Developer Advocate makes people aware of the fact that our products exist. The Developer Experience team gives people the confidence to know that they can easily solve their problems by using our fantastic guides and resources. It also reassures them that if they do happen to find an area that they’d like to contribute to, we’re not only prepared for them but are willing and able to support and engage with them. This is where the bridge to engagement starts. As we focus on the experience of an engaged community member, we start asking questions about how we can engage with them further, keep them engaged, and move them further down the path to becoming a Camunda Champion.

Community Management is where the engagement function really starts to take shape. Our Community team works with our most engaged community members - those who run meetups, speak at events on our behalf, and continually give back to the broader community of potential Camunda users. From our Camunda Champions to our conference attendees and forum contributors, our goal is to build a strong community of people as well as connections -- connecting members of the community with different functions at Camunda, as well as feeding useful tools and information back into the community.

Don’t Forget About Your Internal Community

As you can see, Developer Relations isn’t only externally-facing. There are places where the concepts of awareness, enablement, and engagement apply internally as well. How much time should you spend focused on internal engagement versus external? That’s a topic for another blogpost, but in the meantime, I’ll leave you with a list of ways my team fulfills this “Awareness, Enablement, Engagement” trio, both internally at Camunda and externally with our communities.

Internally to our coworkers:

Awareness of our team’s existence
Awareness of the feedback that the community is willing to provide
Awareness of the processes we can facilitate (feedback loops, documentation standards, etc.)
Awareness of the way that the community members can serve the company (DevRel Qualified Leads)
Enabling our coworkers to better serve the community (Enterprise customers as well as Open Source contributors)
Enabling our coworkers to better communicate with our customers as we provide additional data about who those people are (e.g. patterns, general demographics, etc.)
Enabling our coworkers to write, speak, and code in a public fashion in front of our audience.
Engaging our coworkers with the community through DQLs, conferences, forums, social media, and more.

Externally to our community:

Awareness of the existence of our various products and projects
Awareness of our team & our mission
Awareness of the resources we provide
Awareness of our willingness to hear and transmit feedback internally
Awareness of the solutions we offer (open source as well as enterprise)
Enabling them to get up and running quickly and easily
Enabling them to be successful in their company / role
Enabling them to progress in their career through training opportunities, resume building skills, and more
Enabling them to try new things (guest blogposts, guests on the podcast, etc.) as well as for them to experience a larger reach due to our amplification of their work
Engaging them with each other as well as with our employees (cruise director analogy)
- Forum/Slack
- Social Media
- Conferences
- Meetups
Engaging them in small, specific groups for knowledge sharing & community building (e.g. meetup organizers)
Engaging folks to not only use our software, but contribute, collaborate, and give back (moving them up the pyramid of engagement)

A note for those of you who find yourselves pursuing all of these functions as a one- or two-person team, I recognize that we’re in an incredibly lucky position at Camunda to have a relatively large team and an executive team that understands the value we bring. If you’re responsible for awareness, enablement, and engagement and struggling to find the balance between them, I can empathize! I’d encourage you to read First, Understand the Company Goals to help you prioritize your goals and find a way to make the value of your work clear to your stakeholders.

Secondly, find allies throughout your company. You’ll likely find others interested in Awareness in the marketing department. Look for your Enablement friends in the product and engineering divisions. Lastly, make friends with the support and customer success teams to help out with engagement gaps. By being smart about how you prioritize your tasks and working across teams to accomplish goals, you’ll find yourself making progress in all three areas.

Interested in more information about how to reach across all three of these functions as a small team? Let me know in the comments below and I’ll work toward a blogpost about the topic in the future.

DevRel Qualified Leads: Repurposing a Common Business Metric to Prove Value

Mary Thengvall — Sat, 14 Dec 2019 15:51:34 +0000

Metrics -- and the stakeholders who continually ask “what’s the ROI on that?” -- have often been the bane of our existence. I know I can relate with this meme… I believe I’ve made that face myself more than once after a frustrating conversation with an executive who just doesn’t understand the value that my team provides on a daily basis.

But what if we shift the mentality -- not their mentality… but our mentality? What if we view metrics, not as the bane of our existence and as something that we constantly have to fight against, but as the way to prove our value?

One way for us to do this is to focus on metrics that reflect the talents that we have. Before we’re forced into metrics that don’t fit our skill set, before we’re given metrics that don’t line up with the work we’re doing, let’s set our own metrics that truly reflect the value of the work that we can uniquely do.

What metrics are these, you may ask?

I call these metrics “DevRel Qualified Leads.”

What are “DevRel Qualified Leads”?

But what exactly do I mean by DevRel Qualified Leads? And how exactly does this apply to metrics?

Let me put it this way: if you’ve ever attended a conference and had your badge scanned by a sponsor, or filled out a form on a company website to receive a special report, you’re now a Marketing Qualified Lead for a company out there.

In other words, you’re someone who the Marketing team has identified as a potential customer. They produced content that you were interested in, and as a result, got your information. They then vetted your information to make sure you met their standards or expectations, and then handed your information off to Sales for them to reach out to you down the road. Marketing has now done its job of filling the Sales pipeline, and their job is done. They aren’t responsible for making sure that person becomes a customer. That’s the Sales team’s responsibility.

This is a fairly well-understood business metric in most companies. It’s also typically accepted that sales is a multi-step process and Marketing has the top-of-funnel responsibilities.

Once Marketing’s job is done, they go back to finding new ways to create more “leads,” or people who have found the website, the company, or the product in some way, which they then “qualify,” or vet to make sure that they’re potential customers, and again, pass off to Sales.

Why Qualified Leads?

So some of you may be asking, why did I choose a term like “qualified leads,” particularly when the jump can so easily be made to sales?

For those of you who are familiar with my work, you know that I don’t believe DevRel or Community teams should ever (EVER!) have sales metrics to gauge their success. It muddies our work too much and changes what should be a genuine relationship into one that revolves around money, which isn’t sustainable.

1) It’s an accepted term in the business world.

However, most business people know what you mean when you say “qualified leads.” While they might initially only think of additional customers or sales metrics as the resulting success, you can add to their foundational knowledge rather than trying to introduce a completely new business concept and metric that people aren’t familiar with. Tweaking something slightly is always easier than completely rebranding, and in an industry where we struggle to be accepted for the value we provide, we need to start adopting some of the known business terms in order to gain the respect and understanding of our colleagues.

By asking people to adopt the new definition of “leads” to include “folks who can contribute value to the company in some way” rather than just potential customers, we can expand the meaning of the word and therefore insert ourselves into the business conversations in a way that’s not only understood, because we’re speaking the same language, but is also respected by stakeholders and executives throughout the industry.

I came up with this term after meeting with one of my clients, whose team had metrics that were traditionally given to another department, such as Sales (how many people signed up for an account this month?), Recruitment (how many applicants did we get this quarter?), or Marketing (how many leads did you get at that conference?). These are all things that DevRel and Community Professionals have zero control over. Who knows whether the person you met at the most recent conference will even apply for the job, let alone whether the hiring manager will hire them. Maybe their application won’t make it through the system because of the one quirky thing about their education, or perhaps they don’t click with the hiring manager.

Whatever the case may be, you can’t be held responsible for whether or not that individual got hired… you have no say as far as salary, compensation, or any number of other negotiating factors go, or whether they’ll be a good fit with all of the other team members once they are onboard.

But you are capable of passing along those connections to the right team in hopes that together, they will be able to accomplish a task that furthers the overarching company goals. What does this look like? Here are a few examples:

Marketing: Case Study or Guest Content

Maybe you’ve encountered someone who’s consistently answering questions on your forum and has obviously had a very good experience with your product. They might be a good contact to pass off to Marketing for a Case Study, or perhaps they’d be interested in turning some of their longer forum pieces into a blogpost.

Product: Feedback or Beta Testing

If you’re getting exceptional feedback from an individual, passing them directly to Product might be a good idea. The Product team will be able to have a longer-form conversation with that community member and parse the important pieces that they’ll implement in future features rather than you playing messenger. Or if you’re getting close to rolling out a new feature that a handful of community members have been asking for some time, perhaps you pull them in before it’s released to the public for beta testing.

Engineering: Hard-to-solve Bugs

At times, you’ll meet community members who have stumbled on a particularly hard-to-solve bug and is willing to help your engineering team get to the bottom of it. By making this introduction, you’re actively helping your community (the bug is fixed rather than ignored) as well as your company (they’re able to more quickly solve the bug and return to day-to-day work).

Business Development / Partnerships: Integrations

Maybe you’ve run into a community member at another company who’s willing to help build out an integration that will help customers use your products in tandem. Your Business Development or Partnerships team would likely be more than happy to handle that conversation going forward.

Recruiting: Potential New Hires

On occasion, we’ll come across community members who just “get it.” They click with everyone at the company. They understand the product. They’re passionate about the cause. If you have an open source product, perhaps they’re already contributing during their free time anyway, so when a position opens up, they’re a perfect person to pass off to Recruiting.

Sales: Potential Customers

And of course, if you run into someone who’s interested in purchasing your product, you can pass them (or their manager or team lead) off to Sales.

You get the idea… these connections are incredibly valuable and might not have ever happened were it not for the DevRel or Community team’s direct involvement in the community who now knows and trusts them.

DevRel Qualified Leads = Business Value

These DevRel Qualified Leads are incredibly important to keep track of for a number of reasons, the most obvious reason being, of course, that it’s a definitive way to attribute value to the activities that the DevRel team is involved in. Additionally, in aggregate, it’s a valuable way to see which activities overall are more effective than others in the long run as well as track themes throughout the industry.

For instance, if you run across three front-end developers who are really interested in your product, which is traditionally focused on the ops or security professionals, you’ll want to make a note of that. Or perhaps you start to see more interest from a non-technical group of folks. Keeping track of these outliers and reviewing your notes once per month, quarter, or year, will help you determine new patterns in your audience, which can help inform the personas that the marketing and products teams work on.

DevRel Qualified Leads = Community Value

These leads also contribute community value, because as you’re making these introductions between community members and your coworkers, you’re also making introductions between community members. And this leads us to my favorite analogy for Community Building, thanks to my good friend Amy Hermes: Community Management is a pseudonym for cruise director.

How many of you have been on a cruise? I haven’t, but my partner and I dressed up as over-the-top tourists a few years back. You know the person who makes sure that you have everything that you need… that you’re not feeling left out… that you have someone to talk to and relate to, so that you’re having the best possible experience? That’s the cruise director, and likewise, we’re the cruise directors of our communities.

Those people who all mentioned the new topic that they were pursuing? I, as the community cruise director, am responsible to introduce them, foster that relationship, and make sure that they’re not only pursuing that topic and reporting back to me with interesting tidbits, but that they’re enjoying doing so! Part of what we can do to ensure this is build a community around that topic, which, of course, requires other people. So I’ll introduce Marie to Bob, and the two of them can chat about the latest doodads and thingamabobs that they’re looking into while I fade into the background as the two of them get more and more excited about this fascinating topic. Later on, I can follow up to see how the conversation went and if there are any patterns or otherwise interesting information that I can parse from it.

2) It highlights our unique value

We as Community Managers have a unique talent. We usually don’t wind up in DevRel by accident -- we’re already doing all of these things in our personal lives, and many of us just seemed to stumble into this work by default. We have a talent of connecting people, bringing people together, and making people feeling comfortable and confident and empowered. This slightly expanded definition of Qualified Leads (folks who can contribute value to the company in some way) allows us to highlight this value rather than be forced to find a more traditional metric that encapsulates our unique abilities.

But so what? Who cares? Why, at the end of the day, do these connections truly matter? They matter because of the core definition and purpose of community building. At its foundation, the purpose of community building is to build relationships with, empower, and enable our various communities. And this empowerment is beneficial for both the community and the company.

I love this quote from Zan Markan’s blogpost “Developer Relations is Developer Enablement” and I think it applies to all communities, whether they’re technical or not:

“Enabled developers are productive, less likely to churn, and better suited to champion our products and services inside their teams, organisations, and wider networks.”

— Zan Markan, Developer Relations is Developer Enablement

Twilio’s Developer Evangelism team puts it this way:

“Our job is to inspire and equip developers to build the next generation of amazing applications. This means understanding what they are trying to do, pointing them to tools and training, and generally helping them be successful.”

— Twilio's Developer Evangelism Team Mission

Is this an inexpensive endeavor? No! But is it worthwhile? Signs point to yes! Twilio has invested a significant amount of money into something they were told would never make them successful, simply because they understood the true value of community building: if you can prove to your community unequivocally that you not only want, but will listen to and implement their feedback, you will gain their loyalty.

Part of inspiring, equipping, enabling, and empowering our communities is connecting them with each other as well as with our coworkers. We’re already making these connections instinctively! We build relationships, make introductions, and connect people in ways that make them more successful. Now it’s time to take that thing that we already do without thinking about it -- dare I say, one of the things that we are uniquely qualified to do -- and turn it into a metric that can not only benefit the company, but the community as well, and at the same time, give us a tangible way to prove our value.

3) We need a single metric that can be used across the industry.

And this leads me to my final point. We need a single metric of success that can be used across the industry. Far too often, our answer to the question “what are your metrics of success?” is “well… it depends!” and let me be clear -- that’s not a bad or wrong answer. What success metrics you use really does depend on the company! I tell my clients, “Your goals for the community need to be aligned with goals for the company,” which means, realistically speaking, that the DevRel initiative is not going to look exactly the same in every company.

But having a single metric across the industry that everyone can point to and understand is an important part of moving our industry forward, because it helps executives and stakeholders hold onto something. Even if they know they won’t be able to understand all of the nuances, and that it may take time to figure out all of the good practices specific to their company, they’ll be able to point to the connections that the team is making in and through the community they’re serving. They’ll be able to point to a known value, which, as we all know, is an important piece of maintaining a sustainable community team.

It’s because of all of these reasons that I propose this metric: DevRel Qualified Leads , as one accepted metric by which to prove the value of our Developer Relations and Community teams across the industry.

This post was originally presented in the form of a talk at CMX Summit 2019 and again at DevRelCon London 2019. You can view the slides for each on Notist.

Comments? Thoughts? Reactions? I always love to hear what you think! Leave a comment below or reach out on Twitter.

What do you wish you knew about Developer Relations?

Mary Thengvall — Fri, 10 May 2019 17:58:41 +0000

Developers (and Ops folks!) - what do you wish you knew (or better understood) about DevRel?

And DevRel folks - what do you wish developers knew about your job?

Inclusion & Economic Efficiency Go Hand-in-Hand for Jen Gilbert, Tech Learning Manager at Lyft

Mary Thengvall — Fri, 02 Nov 2018 15:39:26 +0000

It’s no longer a question whether a diverse workplace is beneficial. Article after article has proven that a more diverse and inclusive team results in better products as well as a healthier work environment. But what if catering to a diverse audience is also economically efficient?

Jen Gilbert, Tech Learning Manager at Lyft, has spent the past year creating a strong onboarding program that sets their entire engineering team up for success.

“Often when I talk to people in the Learning & Development industry who are working with technical teams, they aren’t engineers themselves. I’m in a unique position, where I’m both an engineer and passionate about empowering engineers to teach, which means I’ve spent a lot of time thinking about how to improve technical education for folks who are already working in technology roles.

“There’s a tendency to see quality education as less critical once you’re teaching experienced engineers, but from a diversity perspective, I don’t think your company can say that it cares about diversity if you don’t have a strong onboarding program. If your onboarding is just a series of talks, some people leave the session feeling confused and nervous about moving forward. In order to ensure that everyone has the same chance at success at your company, you need to check for comprehension throughout the onboarding, as well as gather feedback and collect metrics afterward.”

This data-first approach isn’t just a diversity initiative, however. It’s also a lesson in economic efficiency. It’s in every company’s best interest to get their new staff up-and-running as quickly as possible, and learning programs like the one Lyft has instituted allow for that. Gilbert’s goal is to make each course even more useful for the employees that are present:

“It’s really hard for me to see inefficient learning experiences. Early on, there were times when I could tell that half of the people in the room were tuned out and not paying attention to the instructor. Either they weren’t the right audience or we weren’t communicating the right information. Whatever the issue, it was our responsibility to fix the problem. It’s not cheap to have inefficient learning experiences, but they’re relatively easy to fix.”

Think of it as a spectrum: on one end, you have a (supposedly) one-size-fits-all program that’s quick and easy to design. On the other end, you have a completely personalized training experience which is time-consuming and difficult to create. As Gilbert describes, Lyft falls somewhere in the middle.

“We publish our entire catalog with a very discrete skills list and we rely on the manager to know which particular data query tools their team members will need to use or which dashboards are uniquely important. Each listed session includes a description of the exact skills that it covers so you know what you can expect your new hires to be able to accomplish at the end of the course.

“We’ve iterated over time as we gather feedback on what people find helpful. For instance, we’ve made a lot of adjustments to the list of courses for the hardware folks because they face very different challenges than most of our engineering staff.”

These iterations are based on qualitative as well as quantitative metrics. The team at Lyft starts by measuring the satisfaction of the employees who just completed a course — a simple gut check to see whether they feel like the session was worth their time. Feedback such as “I feel so comfortable now. I feel so much more prepared.” motivates the Tech Learning team to keep providing quality content. On the other hand, hearing about problem areas where new employees get confused or tripped up in a particular section allows the team to work with the instructor to provide additional information or context around a topic.

Quantitative metrics reveal problem areas as well. Is there a particular set of questions that seem to be particularly confusing? Is there a scenario that’s consistently being solved incorrectly? Following the patterns that pop up allows Gilbert and her team to fix documentation issues and improve the session for the next cohort.

Adjusting the variables of audience size or the length and depth of a session allows Gilbert to hone in on the perfect ratios as well. Some sessions do better with a smaller, niche audience, while others do better as a more general, intro-level topic.

“We listen to what people are telling us and leave room for that human experience element because we recognize that we can’t understand everything about the sessions based solely on the comprehension scores. But we ultimately try to translate the qualitative feedback into numbers in order to avoid bias or outside circumstances that might have impacted the employee during that particular session.”

This balance of qualitative feedback and quantitative measures driven by comprehension checks allows Gilbert and her team to build successful onboarding courses as well as ongoing learning experiences for the technical employees at Lyft. These courses, in addition to allowing new hires to get up-and-running quickly, also enable employees to drive their own learning experiences, which in turn encourages company-wide diversity and inclusion as well as job performance.

Originally published at plusplus.co on November 1, 2018.

3 Ways to Foster a Learning Environment in Your Engineering Team

Mary Thengvall — Wed, 31 Oct 2018 01:14:39 +0000

Learning is an essential part of any career path, but especially that of a software engineer. As people responsible for continually building something new, they need to enjoy and be motivated by the challenge of always learning on their feet.

Through the years, Ron Lichty has worked at well-known companies such as Apple, Berkeley Systems, Fujitsu, Charles Schwab, and more. At each of these companies, he observed that learning is not only a motivational tool for software engineers, but it’s one of the top reasons why engineers choose to stay at companies.

Learning isn’t just about picking up new skills or even being trained on a particular piece of software; it’s also learning from mistakes and victories alike. It’s gathering as a team and recounting what happened so that you (collectively) can make changes that will help move the whole company, as well as the customer experience, forward.

So how do you, as a manager, go about building an environment that encourages this at your company?

1) Be a Guide.

Like most things, there’s a “dark side” to learning. In this case, the dark side of the force is the potential to get distracted by all of the shiny new technologies that can pop up.

As Lichty says, “You want to keep your team on the path of discovery while encouraging them to not step in the woods and get caught up in the poison oak.”

Lichty’s co-author, Mickey W. Mantle, puts it this way in their book Managing the Unmanageable:

“Ensure that your staff is not seduced by the allure of new ‘shiny things.’ …New technologies are the ‘dark side of the force’ for programmers, who will spend countless hours exploring unproved technologies rife with potential to introduce risk if embraced before broad acceptance, extensive field testing, and guaranteed support by those promoting the technologies.”

As a manager, it’s your responsibility to foster an environment that encourages learning in a focused and systematic way. Limiting your engineers too much might keep them from discovering an out-of-the-box, creative solution, but it’s important to keep their focus on finding the best solution for your customers.

2) Practice Agile Principles.

Agile has been an undercurrent for several decades now, but this movement only seems to pick up steam, and for good reason. One thing to keep in mind, however, is that agile is much more than practices. By implementing the values and principles, you become a more agile team creating a more agile product, better able to serve your community of customers.

One way to do this is through holding regular retrospectives. Lichty explains:

“One of the aspects of every agile practice is breaking large projects down into short iterations or sprints. At the end of each sprint, we hold a retrospective. The point of doing them frequently is obviously not to set long-term objectives, but to solidify what we learned from the past two weeks that could inform a change.

“Then we can experiment over the next two or four weeks to see whether this change improves our quality, productivity, performance, or teamwork and collaboration. It might also improve our ability to bring the customer into the picture more.

“The end-goal might change every sprint, but these frequent check-ins allow us to focus on one specific experiment over the period, with the result that we’re making constant incremental improvements.”

A team that is successfully learning is not just learning about new open source projects, new programming languages, or even new solutions. They’re also learning and growing as a team; figuring out which processes work for them, which projects went well and which didn’t, and how they can either improve upon or change the effectiveness of their work in the future.

3) Foster teamwork rather than independence.

When presented with a new problem, it’s easy for a team to approach it from many different angles in an attempt to find a solution quickly. In reality, a more holistic solution is often found when the team is willing to work together, integrating multiple viewpoints from across the company.

Lichty makes this critical point about who should make up these teams:

“Agile is fundamentally about values and principles, which include valuing customers, bringing delight to customers, and solving hard problems collaboratively, as a team. The team reaches beyond the programmers — it’s the programmers, product owner, QA folks, and the Ops team. Ideally, this team includes the customer as well. Before the team pushes the solution to production, the product owner should bring key customers into the team’s environment to offer feedback and insight into what will delight them.

“This emphasis on teamwork is driven by customer empathy. Instead of finding a piece of code that will solve one problem, let’s dig into what’s going to truly delight our customers. It’s possible that one line of code will be part of the solution, but it’s equally possible that if we focus on the root of the problem, we’ll find a completely different issue at hand. At Apple, where user experience constitutes the crown jewels, I learned to hire not just for stellar C++ coding ability, but for customer empathy as well. Whether we’re looking at Apple’s at that time or how companies are operating these days, delighting customers is what keeps us in business.”

These basic principles are the building blocks of an effective team focused on providing value for their customers. By implementing these principles, you’ll not only build a stronger team but enable your engineers to take on more significant challenges in the future.

To understand why fostering this learning environment is so essential to maintaining a successful and long-lasting engineering team, read our previous interview with Ron Lichty.

Originally published at plusplus.co on October 24, 2018.

Why is Creating a Learning Environment Essential for Technical Teams?

Mary Thengvall — Thu, 18 Oct 2018 04:58:00 +0000

Companies are shifting away from hiring for specific programming skills and know-how in lieu of finding candidates who are adaptable and quick to learn on their feet. But once you find these individuals, it’s crucial that you maintain that learning environment, for the sake of the software engineer as well as the company.

Ron Lichty, consultant and co-author of Managing the Unmanageable, has decades of experience in this area. From leading Apple’s Finder and Applications group — the team developing the Macintosh’s user interface, which some say is what set Apple apart from their competition — to building the first investor tools at Charles Schwab, he’s seen just how much learning opportunities can motivate and empower software engineers.

Furthermore, he’s seen these learning opportunities not only make for a stronger team but a more robust product. In Managing the Unmanageable, Lichty and co-author Mickey W. Mantle explore Frederick Herzberg’s seminal work from the 1950s, which identified what people are motivated (and demotivated) by. Lichty and Mantle took this one step further and applied it to software engineers. Learning is second in the list for satisfaction and as they point out, is not only essential for keeping your software engineers happy, but for making your product successful.

There are two primary reasons why this principle is important:

1) To maintain client or customer advantage, we need our programming teams to find the best solutions.

2) To maintain stability (and with stable code, the ability to go fast), we need to identify and hone in on best practices.

Enabling your software engineering team to find the best solution possible while maintaining the stability of your product is key to a successful business. This can be facilitated a few different ways:

Inspire Exploration.

Let your engineering team know that their feedback is valued and that all opinions are welcome. Empowering them to bring different options to the table encourages a thirst for knowledge as well as an awareness of advances in their specific field of technology. This exploration should be balanced with making sure you don’t reinvent the wheel. Lichty explains:

“It’s really important not to solve problems that have already been solved. The Internet is a crucial tool for looking for and seeing if a solution already exists. One reason why programming is hard is that it’s hard to estimate whether we should be doing something new or simply reusing what’s already out there. If there’s a stable and reliable solution that already exists, our mission should be to find that solution, rather than create our own.”

Allow for Mistakes.

Blameless postmortems are an important part of DevOps and Agile cultures. This means you view mistakes and errors with a perspective of learning instead of liability. As John Allspaw, Founder of Adaptive Capacity Labs, says,

“Having a Just Culture means that you’re making effort to balance safety and accountability. It means that by investigating mistakes in a way that focuses on the situational aspects of a failure’s mechanism and the decision-making process of individuals proximate to the failure, an organization can come out safer than it would normally be if it had simply punished the actors involved as a remediation.”

Hire for Empathy.

Make sure that the problem you’re solving for addresses the root of the issue, not just the superficial complaint. By building a team of software engineers who are excited about solving problems for customers, you’ll not only be taking care of bugs but building out features and solutions that will facilitate further success for your customers.

The next question is, how do you, as a manager, foster this type of effective learning environment? Stay tuned for more advice from Ron Lichty and the team at PlusPlus, coming soon.

—

Originally published at plusplus.co on October 10, 2018.

Nylas Developer Event: Building Systems that Scale

Mary Thengvall — Wed, 02 May 2018 18:40:11 +0000

How to Navigate Technical Challenges While Scaling Your API Or SaaS Company

At our second Nylas Developer Event, we’ll be exploring the difficulties of scaling API and SaaS companies from an MVP product to one that can attract (and support) thousands of customers of all sizes.

The panelists:

Mike Atkins: Software Engineer @ LaunchDarkly
Liz Acosta: Software Developer @ Twilio
Christine Spang: CTO and CoFounder @ Nylas
Keith Horwood: Founder & CEO @ StdLib

We’ll kick things off with a quick ice-breaker and then turn it over to our panel of technical leaders as they talk about their technical tricks and techniques to achieve growth as you scale. We’ll be answering questions like:
How do you know when it’s time to scale or change systems?
How do you balance scaling quickly without breaking systems? What kinds of monitoring systems are in place?
What specific tools have been most helpful as you scale?
How did you balance scaling for the number of transactions with scaling for your number of customers?
How do you scale while maintaining what's special about the project?

We’ll hear from people who have been in the trenches and can help you find your way out. Beverages (alcoholic and non-alcoholic) and light appetizers will be provided.

Tickets are free but limited — claim yours now!

Learn about more upcoming Nylas Developer events on the Meetup page here: https://www.meetup.com/Nylas-Developer-Events/

Nylas is Hiring a Senior Software Engineer

Mary Thengvall — Thu, 08 Feb 2018 01:23:33 +0000

About Us

The Nylas Cloud API makes it an order of magnitude easier for companies to add email, calendar, and contacts integrations to their applications. By being at the core of business communication, scheduling, and contacts, we believe we can shape the future of how people work.

Our team is roughly equal by identified gender (including engineering) and includes startup founders, Debian contributors, alums, MIT, Columbia, Yale, CMU, and Olin alums, and a professional dancer from the San Francisco Ballet. We actively and regularly work with the entire team to shape our culture to our ideal of empowerment, transparency, and kindness.

About The Opportunity

We’re hiring senior engineers to help us scale and build new products on top of our APIs. Right now, our open-source Python sync engine regularly archives terabytes of data across a massive SQL cluster, and our Flask APIs handle tens of millions of requests a day. We aim to scale that several times over in the next year.

Our senior engineers end-to-end own and ship new features, like offering Contact sync, while providing mentorship through pairing. They shard our webhook systems, then re-architect in Kafka as we scale. They solve tricky customer issues, debug slow MySQL queries, and sometimes get into the depths of MIME and other email protocols. On the side, they improve our internal developer experience, most recently with MyPy, and open-source our custom-built tools. They talk at conferences, write blog posts, and make strong showings at local events.

While our main headquarters is in the heart of San Francisco, we have recently opened an office in the Financial District of NYC. We are open to conversations about remote employees in other locations as well.

Skill & Qualifications

You should have a growth mindset, enough engineering experience to architect complex systems, a track record of managing your own projects, and a strong sense of practical shippability over engineering purity. You should also tend toward humbleness in your abilities and have an innate desire to pass knowledge onto others.

Our team collaboratively wrote about our values, benefits, perks, and published them in our open-source handbook. Read it to learn more about Nylas. You can also find more details at: https://www.keyvalues.com/nylas

How To Apply

If this job piques your interest, don't hesitate to apply today!

Please feel free to leave questions in the comments section.