DEV Community: Jeremy Meiss

Developer Experience is More Than Just Productivity Metrics

Jeremy Meiss — Tue, 24 Feb 2026 23:08:12 +0000

In the frantic world of tech, we’ve become obsessed with the "bottom line." Engineering leaders are under constant pressure to measure output, leading to an over-reliance on productivity frameworks that often miss the mark. While frameworks like SPACE, getDX, and DORA provide valuable insights, they often focus strictly on the company's bottom line while ignoring the practitioner's reality.

If we want to foster true innovation, we have to realize that Developer Experience (DevEx) is the journey, while Developer Productivity is simply the destination.

The "Disaster" Reality Check

We’ve all had that experience using a tool or service that was a disaster. Common culprits that ruin the day-to-day experience include:

Documentation Fails: Poorly documented features (or bugs) and "access-gated" documentation—or worse, docs that only exist as a downloadable PDF.
Infrastructure Gaps: Missing OpenAPI specs or platforms that claim to be for developers but lack actual APIs.
CI as a "Magic 8-Ball": A process where you are just throwing code against the wall like pasta to see if it’s "done".
Bad Design: Websites like the Yale School of Art serve as a reminder that even prestigious institutions can fail at the basics of user experience.

In contrast, Heroku was long considered the gold standard because of its simple CLI and "git push" workflow that allowed developers to focus solely on building and delivering.

git push heroku master

Defining the Difference: Experience vs. Productivity

There is a subtle but critical difference between these two concepts. Sustainable productivity isn’t forced; it’s a natural outcome of a superior Developer Experience.

Developer Experience (The Cause): Jessica West (@jesswest, Chronosphere) defines this as

"the journey of developers as they learn and deploy technology."

It represents the Roots: the tools, processes, cognitive load, and flow state.

Developer Productivity (The Effect): Defined by LinearB as the effectiveness and efficiency with which developers produce code. It represents the Fruit: the high-quality software that drives business value.

The Evolutionary Path of Measurement

For decades, engineering leaders grappled with how to effectively measure productivity, often relying on flawed metrics like "lines of code" which are easily gamed incentives that miss the bigger picture.

Today, the focus has shifted to understanding the entire value stream, leading to sophisticated, research-backed frameworks that provide a holistic view of performance. A few of the more popular frameworks are DORA, SPACE, and GetDX Core 4.

The conversation has shifted from simple pipeline metrics to holistic, business-aligned frameworks, and the audience from engineers to the C-suite. All of this is fine, in and of itself, but this shift has put the focus on the business and not the developer, creating a lot of confusion.

We can track this evolution through three major milestones:

2014: DORA Metrics Emerge: Established the gold standard for measuring pipeline health, proving that speed and reliability are not trade-offs.
2021: SPACE Framework: Introduced a human-centric model, arguing that productivity is multi-dimensional and includes satisfaction and well-being.
2024: GetDX Core 4: A practical, prescriptive framework attempting to unify DORA and SPACE to link engineering efforts to tangible business outcomes like ROI.

Framework Comparison at a Glance

Framework	Scope	Philosophy	Data Type
DORA	Narrow (Pipeline)	Prescriptive Recipe	Quantitative (System)
SPACE	Broad (Socio-technical)	Flexible Menu	Hybrid (System + Survey)
GetDX Core 4	Hybrid (Eng + Business)	Prescriptive Pillars	Hybrid (System + Financial)

The Three Pillars of World-Class DevEx

Building a great Developer Experience is not accidental. It's built with the developer in mind, and designed to minimize friction, reduce mental overhead, and enable deep, focused work.

To move beyond abstract frameworks, focus on these three pillars built with the developer and practitioner in mind:

1. Fast, High-Quality Feedback Loops

Slow, ambiguous feedback is a primary source of frustration. A few things to think about when addressing feedback loops (a core component of DevOps as well):

Culture: Use "Mob Programming" for complex tasks and schedule "Bug Bashes" to uncover issues from diverse perspectives.
Action: Implement automated visual regression testing and "Shift Left" by integrating static code analysis and linting directly into the IDE and pre-commit hooks.
Progressively Deliver: Implement a robust monitoring system and adopt canary deployments (or other progressive delivery methods like feature flags), and measure those deployments over time.

2. Low Cognitive Load

Human working memory is limited, and we're really bad at repetitive tasks. When developers wrestle with complex systems, less mental energy is available for solutions.

Action: Standardize code style rules (Prettier/ESLint) and prioritize refactoring technical debt incrementally (aim for a percentage of time during each sprint and commit to it).
Documentation: Establish a single source of truth for project documentation and knowledge sharing, and encourage documentation as part of the workflow.
Automation: Implement comprehensive and automated test suites (unit, integration, end-to-end) to get that rapid feedback on code changes. Integrate testing into the CI/CD pipeline to ensure tests are run automatically on every commit.

3. Enabled "Flow State"

Flow is where deep, creative work happens. It requires clear goals and protection from interruptions.

Action: Standardize development environments with containerized setups to ensure everyone works from the same baseline. Document them for the next person who jumps into your team or project.
Tactics: Use "Pomodoro" or timeboxing to maintain focus, and replace generic "email everything" notifications with a high-signal, prioritized system that only notifies on the things which matter.
Meeting Budgets: Keep track of how often your team is in those useless meetings, which directly equates to time lost. Give each team member a meeting budget (based on their role), and make sure it's communicated.

A Practitioner-Centric Scorecard

Avoid the "Gamification Trap." According to Goodhart's Law,

"when a measure becomes a target, it ceases to be a good measure".

Instead, here are some suggested metrics to find systemic blockers:

Cycle Time: From commit to production (target: decreasing trend).
PR Review Time: From open to reviewed (target: < 3 hours).
Rework Rate: Percentage of code churned post-commit (target: < 15%).
Meeting Load: Protecting time for deep work (target: low and stable).
Time to First Commit: Measuring onboarding efficiency (target: hours, not weeks).
Perceived Focus Time: Subjective but critical uninterrupted time (target: high and protected).

Building a healthy measurement culture is foundational to the success of any DevEx initiative. These are some good things to keep in mind, but remember, no framework is a silver bullet. The goal is continuous improvement, not judgment. Communicate the 'why', involve your team in reviewing and coming up with measurements, focus on trends, and always combine quantitative data with qualitative human insights.

I do want to stress that these are not a one-size-fits-all set of metrics, and should be tailored to the specific needs and context of your team. They are a starting point, not an end point. Identify the baseline for your team, and then set realistic goals instead of arbitrary numbers that were built for some other team or company.

Conclusion

Investing in Developer Experience is a direct investment in your organization's capacity to innovate. At its core, DevEx is ruthlessly eliminating the barriers and blockers that keep your practitioners from being successful.

I would love to hear in the comments what ways you keep track of developer experience.

It's Not Rocket Science, It's a Flywheel: Engineering Open Source Communities with DevEx

Jeremy Meiss — Fri, 26 Dec 2025 13:13:00 +0000

I have done just about everything in IT over the past few decades, including being a janitor at some point. I remember the days when we used to build servers by hand, and I still have the scars to prove it, because, evidently, innovation stopped at figuring out how to sand down the sharp steel inside a server chassis.

While hardware has changed, one thing in open source remains a constant struggle: The Maintainer's Dilemma.

(Source: XKCD)

You want to grow your project and community, but doing so requires a massive amount of time and effort—resources you likely don’t have. Often, the default response is to simply wait and "hope" for the best: we hope people get involved; we hope for pull requests; we hope we don't burn out.

But as I discussed at Community over Code North America 2025, hope is not a strategy.

Building a thriving open source community shouldn't be a mystery, and it doesn't have to be a grind that leads to burnout. Instead of hoping for growth, we need to start engineering the conditions for success. To do that, we can combine the physics of a flywheel with the principles of Developer Experience (DevEx).

Quick DevEx Primer

We define Developer Experience (DevEx) as "the journey of developers as they learn and deploy technology... focusing on eliminating obstacles that hinder a developer or practitioner from achieving success" ( courtesy of @jesswest ).

There are 3 core dimensions that you can measure (and improve) in Developer Experience:

Feedback Loops: This dimension concerns the speed and quality of the learning cycles that define a developer's workflow. It answers the question: "How quickly do I learn if my change is correct?" Fast, high-quality feedback loops are characterized by rapid build and test times, swift code reviews, and smooth, predictable deployments. Slow or noisy feedback loops, in contrast, kill momentum and create frustration.
Cognitive Load: This refers to the total amount of mental effort required to perform a task. In software development, cognitive load is increased by factors such as complex architectures, poorly documented code, inconsistent tooling, and ambiguous processes. Reducing unnecessary cognitive load allows developers to dedicate their finite mental energy to solving the core problem at hand, rather than fighting their environment.
Flow State: Often described as "being in the zone," flow state is a mental state of deep, energized focus and full immersion in a task. It is in this state that developers are at their most productive, creative, and satisfied. Achieving flow state requires long, uninterrupted blocks of time, clear goals, and an environment free from distractions and context-switching.

A positive DevEx is characterized by frictionless workflows that empower developers, reduce unnecessary cognitive overhead, and allow them to focus on high-value, creative work.

(I've written a few things about DevEx if you'd like to read more)

Why DevEx is (Slightly) Different in Open Source

In a corporate environment, developers are paid to be there. In open source, they are volunteers. They have a choice about where they spend their energy. This means the stakes are higher, and the barriers to entry must be lower than they would be for employees who are forced to use tools like Jira ("apologies" to Atlassian).

While DevEx is often discussed in the context of enterprise productivity (saving time, reducing churn), it is just as critical for open source (and hint: that's "developer productivity", not "developer experience"). If a potential contributor faces friction (bad docs, confusing tooling, or silence on a PR) they stop. We lose not just their contribution, but the opportunity for a long-term community member.

The Physics of Community

In engineering, a flywheel is a mechanical device designed to efficiently store rotational energy. It’s a heavy wheel that requires significant effort to start spinning, but once it gains momentum, it becomes a self-reinforcing loop.

In the context of business and community, the concept is identical. There is no single "lucky break" or "killer innovation" that builds a massive community in one swoop. It is a process of relentlessly pushing a giant, heavy flywheel, turn upon turn, building momentum over time.

Jim Collins, in his book "Good to Great," popularized the concept of the "flywheel effect" in business. His research identified that no matter how dramatic the end result, good-to-great transformations never happen in one fell swoop. In building a great company or social sector enterprise, there is no single defining action, no grand program, no one killer innovation, no solitary lucky break, no miracle moment. Rather, the process he described was relentlessly pushing a giant, heavy flywheel, turn upon turn, building momentum until a point of breakthrough, and beyond. The key to the flywheel effect is that it requires consistent, focused effort over time to build momentum. Each small push adds to the overall momentum, and as the flywheel spins faster, it becomes easier to keep it going.

If you stop pushing, (or worse, if you constantly change your process) you lose that stored energy and have to start over.

Metaphorically, this is exactly what we want for our communities: a self-reinforcing loop that, once set in motion, gains its own momentum and drives continuous growth and improvement without requiring constant, heavy lifting from the maintainer.

To get the flywheel spinning, we need to engineer specific "pushes" that remove friction and increase "joy."

Components of the OSS DevEx Flywheel

1. The Welcome Mat (Onboarding)

The README.md is your community's front door. If it’s locked or hard to find, no one enters. It needs to clearly answer: What is this? How do I run it? How do I contribute?

Essentials: Ensure your README.md, CONTRIBUTING.md, and Code of Conduct are clear and accessible.
Templates are vital: Use Issue and PR templates to guide contributors and set the tone.
Make the Ask: People often want to help but don't know how. Don't just wait for code. List your needs explicitly, whether it's testing, answering questions, or writing blog posts (see Andy Lester’s "14 ways" on the Wayback Machine for some ideas).
Good First Issues: Label issues clearly so newcomers can get an easy win.

2. "Time to Joy" & Tooling

How quickly can a contributor go from zero to a result? We have called this "Time to Joy" (and other variations) for many years. We love serotonin; you need to give your contributors that feeling as early as possible.

The "Hello World" Standard: Ensure there is a simple example that runs in minutes.
Automate the Environment: Environment setup is a killer. Use tools like devcontainer.json so a contributor can hit a button in GitHub, open a Codespace, and be ready to code without fighting local dependencies.
Linting: Use automated linters to handle style debates. It keeps the codebase consistent and removes the awkward "you missed a semicolon" conversations from code reviews. Things like Prettier, ESLint, and Conventional Commits are great options.

3. Feedback Loops

A contribution without feedback feels like shouting into the void. Silence kills momentum.

Automate the First Response: Use GitHub Actions (some examples) to thank a contributor immediately when they open a PR.
Office Hours: If you can, hold office hours. Being available for open conversation helps people get past barriers they can't solve via text.
Code Reviews: Be timely and constructive.

Handling the "Dead End" Thread

We’ve all seen it: someone posts an issue about an error, replies later with "Oh, I figured it out," and vanishes. This is incredibly frustrating for the next person who hits that error.

Even if the user has vanished, you must ask the question: "How did you fix it?". Even if they don't reply, you keep the issue visible so someone else can provide the answer later. If you know the fix, document it publicly. Poorly documented bugs are a massive DevEx fail.

4. Recognition & Value

Recognition is the currency of open source, and people contribute where they feel valued.

Celebrate Everything: Use tools like the "All Contributors" bot to recognize documentation, triage, and design work — not just code.
Re-engaging the Core: If you have contributors who have gone silent, reach out to them. Send a message just to say, "I appreciate what you've been doing". Understanding their motivations—or why they left—is critical to helping your project. People contribute where they feel valued.
Public Thanks: Shout out contributors in release notes, blogs, and on social media. Put them on your README.md with a GitHub Action.

5. Leadership Pipeline

Finally, a flywheel needs stability. Create clear paths to maintainership. If a task is important, it needs a name attached to it. As your community grows, identify promising contributors and give them specific roles, like "Documentation Lead" or "Release Team". A good example of this is the Kubernetes Community, with SIG Docs, and also defining and documenting what it means to contribute.

Empower them to own that domain. This shares the emotional labor and mitigates the burnout that comes from trying to do it all yourself.

The DevEx Flywheel in Action

When we put it all together:

Good Docs -> New contributor arrives, feels confident.
Great Tooling -> They get set up quickly ("Time to Joy"!).
Helpful Feedback -> Their first PR is a positive experience.
Public Recognition -> They feel valued and stick around.
New Leaders Emerge -> Growing community, less burnout, more sustainability.

Now you have an engaged contributor who helps improve the project and mentor others. The flywheel is spinning. But how do you measure that?

Measuring the Spin

How do you know if your engineering is working? You can look to metrics from CHAOSS (Community Health Analytics Open Source Software):

New Contributors, and Who are They? (CHAOSS, OpenSource.com)
Contributor Absence Factor: How reliant is a project on a small number of contributors? (CHAOSS)
Time to First Response: Are people getting feedback quickly? (CHAOSS First Response, Time to Close)
Retention: Are contributors staying for more than one PR?

It Starts With a Single Push

You don't have to fix everything at once. The goal is small, consistent pushes on the flywheel.

Dogfood your guide: Follow your own CONTRIBUTING.md from scratch. Where do you get stuck?
The "Friend Test": Ask a friend unfamiliar with the project to try and run it. Compare notes.
Fix one thing: Pick the single biggest point of friction you found and fix it this week.

Conclusion

Stop hoping for community growth - start "engineering" it through the principles of Developer Experience. Small, consistent improvements will create the powerful, sustainable momentum your project needs.

Measuring the impact of Developer Relations on Revenue

Jeremy Meiss — Thu, 18 Jul 2024 13:00:00 +0000

If you've spent any amount of time either in, or within earshot of, a gaggle of Developer Relations (DevRel) professionals, you've probably heard this phrase, or a variation of it:

"DevRel is not {marketing|sales|customer success|insert whatever here}."

I know I've uttered it myself. And the statement wouldn't be wrong. It also couldn't be more wrong. Let me explain.

For many people, DevRel is a practice, a discipline. It's a way of building community with developers using a company's products or services. It's a way of advocating for the community while at the same time advocating for the company. A lot has been written about the importance of DevRel and how it can and should move forward.

But it's also something that is incredibly hard to measure. It's hard to measure the impact of DevRel on the company, and on the community. I spent a little time on that recently, but I wanted to go a little different direction and talk about DevRel's impact on an area no one wants to talk about: Revenue.

DevRel and the bottom line

A friend of mine, Adam Zimman, once said to me, "If you're not building it, you're selling it," and I think that's a great way to think about DevRel and how it fits at a company. For some companies, the DevRel organization is inside of Product or Engineering, where they directly impact the building of the product or service, usually through direct feedback or driving a positive developer experience. For others, DevRel is inside of Marketing where they're really close to the messaging to developers and can act as the "voice of the developer." Often, DevRel will move around over time as the needs and stages (like funding, product, etc.) of the company change.

Wherever it is located, DevRel can bring value to each area. But what is its impact on the bottom line?

One of the first things I did when I joined CircleCI in early 2020 was to start looking into what the Customer journey looked like. During that process, I identified various ways that my team could contribute to the journey a potential customer (developers, DevOps practitioners, etc.) took. What followed was a lot of meetings and interactions with the Marketing Ops team to understand how the existing tooling and processes worked, what the inputs were, and how everything flowed into the reporting (in this case, Salesforce). I then talked to my Demand Generation and Revenue counterparts to identify the reporting and metrics they were using to measure their impact.

What I came away with was a process that helped me not only measure the impact of our activities but also make decisions on what to change or try next time. For example:

Identify the pipeline generated by an event based on the developers we had conversations with, who participated in a workshop, etc. We then used that pipeline to help understand the company's benefit from the event, and we reported on it.
- For instance, if we spent $25k on the event (travel, expenses, sponsorship, etc.), then I would look over the next 6-12 months (typical cycle at the time - you might see shorter or longer sales cycles), and see what those leads we were able to generate ended up contributing. In many cases, we would see a net positive return on the investment, often in multiples of 2x or 3x. Other times, we would see a net negative return, and we would need to revisit the event to determine whether or not it made sense to do it again.
When we reported on the benefit, we would capture things like:
- Number of DevRel-Qualified Leads (DRQLs) generated
- Number of big logos we were able to interact with and the connection we made internally for that next conversation to happen
- Net positive/negative ROI for the event
- Other things that helped us understand the impact of the event or that provided a specific benefit back to a particular business unit

I do want to stress that I do not, at all, believe or encourage that DevRel should have a KPI for revenue. Once you start driving revenue through DevRel, developers are going to be more hesitant to participate in DevRel activities, and they're going to be more reluctant to join the community if they see that your team is just trying to get sales for the sake of the sale. They know that you work for the company, that the company makes money, and that, ultimately, you want to get paid by the company. But when you put the sale first and the relationship with the developer audience and community second (and even if your product isn't the best thing for them at this time), you're going to see a negative impact on the trust that your Developer Advocates and Community Managers have built, and that will negatively impact the bottom line for a very long time.

However, I believe that DevRel should be taking a closer look at things like Revenue, leads, pipeline, and other metrics to help drive the company to revenue. In times like these, when companies are really taking a hard look at what they spend money on, it's important that DevRel embraces this and starts being able to provide specific examples of what provides value to the company, i.e., what their impact is on the bottom line.

Ways to start tracking

How you track the revenue impact could be different than it was for me because every company is different and uses various tools, processes, etc. The core idea, though, will be the same. So here are some things to think about:

Talk to your Revenue teams to see how they are reporting on revenue from their specific activities. Talk to your Demand Generation team or the equivalent Marketing team responsible for bringing in the sales pipeline to see how they identify a lead through the customer journey, track it, and assign value and ROI to their activities.
Talk to your Marketing Ops team or the equivalent team responsible for the tooling (like Marketo and Salesforce) to identify the processes you can use or replicate for your purposes (like Salesforce / Marketo Campaigns, workflows, email segmentation, etc.). Don't recreate the wheel if you can avoid it. Here is a quick example of how I used our Marketing Ops team to help me track the impact of a conference event:
- The developer community conference didn't provide lead scanners (I hate them, but that's another conversation); instead, we had to generate our own mechanism for tracking leads. We used raffles for things of value that people would want to provide their contact info for ($300 Lego Star Wars sets, Sony noise-canceling headphones, etc.), and on the raffle form, we asked a few questions about how they used CI/CD (which were great data points for our Product teams - HINT HINT ask them what they want to know from users!).
- We included a question, "Would you like our Sales team to contact you?" and a question, "Would you like to receive developer content and information about upcoming community activities?"
- After the event, we would sanitize the data (removing dupes, fakes, etc.) and then make sure to mark it with the specific Salesforce campaign for the event, mark it as sourced from the DevRel team, and then depending on the answer to those last 2 questions, they would get routed 1 of 2 ways via Marketo:
- If they answered "Yes" to the sales question, they would get routed through the CRM pipeline as sales leads. And since they came in from the DevRel team, they were scored higher than just a typical lead.
- If they answered "Yes" to the Dev Content question, they would get routed through a content-only pipeline and given regular Dev content. But that also meant that if at any time they clicked a specific link or did an activity that put them into a different segmentation, then that activity would still show as being influenced by the DevRel team, and we would be able to track. Once you've talked to the different teams, go back to the Customer journey and fill in any gaps on where you fit in. Then, identify the activities you can perform and how you're going to track them.

Examples like the above helped my team track the impact of our DevRel activities (events, conferences, meetups, content, workshops, etc.) to contribute over $3.5mil of the pipeline while I was there. That didn't count all the connections we made with Partners and how those connections paid off in the future. It would be reasonable to quantify the impact of our work with our Partners and the new connections we made to be 10x+ over the next few years.

One advantage of starting to tie every conversation you have with a developer, a company, a Partner, etc., to a lead or campaign in Salesforce or Marketo is that you can track the impact of that interaction on the revenue pipeline. You'll also be able to see how that interaction influences the bottom line, which means you will have specific data to use to make informed decisions or bolster your case for the value you bring to the company.

As always, don't hesitate to reach out to discuss this topic further.

Developer Experience is essential for DevOps success

Jeremy Meiss — Fri, 21 Jun 2024 07:12:00 +0000

The ease with which a developer or ops practitioner interacts with a tool or service, from setup to even issue resolution, directly impacts their productivity, satisfaction, and even the quality of the products they build and use. DevEx is crucial throughout the development process and is influenced by chosen tools, technologies, and platforms. Ease of use, reliability, accessibility, documentation clarity, build efficiency, testing effectiveness, and deployment smoothness all impact the overall dev experience.

This blog post dives into this world of DevEx, exploring its impact, benefits, and how it intertwines with DevOps practices. But first, let's define "Developer Experience".

A working definition of Developer Experience

Developer Experience (DevEx) encompasses everything a developer, or ops practitioner, interacts with throughout the software development lifecycle. It includes the tools they use, the processes they follow, and their work environment. To quote a fantastic DevEx practitioner:

DevEx is the journey of developers as they learn and deploy technology. When successful, it focuses on eliminating obstacles that hinder a developer or practitioner from achieving success in their endeavors.
-Jessica West

It is about their every interaction with systems, tools, and processes. I touched on this with my post on the evolution of Integrated Development Environments (IDEs) from text-based editors to Cloud-based IDEs. The post explains how the overall Developer Experience with software development has evolved, leading to where we sit with IDEs now. Things we didn't know we would want back in the 1960s are commonplace and the expected norm now in the 2020s.

Modern Development

DevEx strategies have evolved to meet contemporary development challenges and opportunities. From basic, manually configured environments to sophisticated, cloud-based, and automated setups, the journey reflects a relentless pursuit of efficiency, usability, and developer productivity.

In the highly competitive landscape of modern software development, DevEx is the critical differentiator that makes a company and its products and services stand out. A positive DevEx translates into the ability to attract top talent, helps companies increase team performance and product quality, have more engaged and productive development teams, and also enhances a brand reputation, directly impacting the bottom line.

DevEx touches environment management

Like the evolution of the IDE, the setup of development and production environments has experienced a transition. In the early days, setting up an environment involved manually configuring each tool, library, and dependency, which was time-consuming and error-prone. Developers often struggled with version conflicts and compatibility issues between tools and libraries. In the mid-to late 1990s, systems like CFEngine emerged to automate this process.

The advent of tools like Puppet, Chef, Saltstack, and Ansible allowed for automated setup and configuration of development environments, reducing manual effort. When Docker was introduced in 2013, it marked a significant shift, allowing developers to package applications with all their dependencies into containers, ensuring consistency across environments.

Tools like Terraform and AWS CloudFormation enable developers to define infrastructure through code, making setup reproducible and scalable. And as we've started integrating development environments with CI/CD pipelines and DevOps practices, we now have streamlined development processes, allowing for faster and more reliable builds and deployments.

DevEx aligns perfectly with DevOps

A good DevEx facilitates smoother transitions between your dev and ops teams, helps minimize bottlenecks, and enhances collaboration. Proper feedback loops are part of both DevEx and DevOps, and with them in place, you have a positive DevEx that ensures those loops are efficient and productive. This helps DevOps principles take a firm hold within an organization.

Here is a basic definition of what DevOps is:

the combination of practices and tools designed to increase an organization's ability to deliver applications and services faster than traditional software development processes

A few of the core principles found in DevOps (Collaboration, Communication, Shared Responsibility) really bring this all together.

Collaboration

Collaboration in DevOps is about creating an environment where silos are broken down and cross-functional teams are empowered to work as a single unit. It's people and culture first and tools second. When we have alignment between DevEx and DevOps, we enhance collaboration through tools and processes that reduce friction and barriers in the development process, enabling teams to focus more on solving business problems together, leading to innovative solutions and a more harmonious working environment.

Communication

The backbone of DevOps is effective Communication, which ensures all members of the development, operations, and broader organizational team are on the same page. When we agree on the importance of communication between our teams, we can implement and improve communication practices through platforms and tools that streamline information sharing and feedback across teams. That includes your CI/CD pipelines, shared dashboards, and automated alerting systems, which ensure all team members have visibility into the development process, can easily share updates, and can quickly address issues.

Shared responsibility

Collective accountability for the quality and reliability of software is another critical component of DevOps. It blurs the lines between roles traditionally separated by development and operations, moving from a "not my job" mentality to a "we're in this together" mindset, where success and failures are shared equally. To activate this shared responsibility, focusing on the developer experience will empower all team members with access to the tools and information they need to contribute across the entire software lifecycle. Democratizing this access results from pursuing good DevEx, which encourages a culture where everyone feels ownership of the product and is motivated to contribute to its success.

DevEx is ruthlessly eliminating barriers (and blockers) that keep your developers from being successful.
-Jeremy Meiss

By integrating DevEx with these core DevOps principles, organizations can build more cohesive, agile, and effective teams that are better equipped to meet the demands of modern software development. This mix improves workflow and productivity and enhances the overall quality of the software delivered, ultimately benefiting end-users.

A robust Developer Experience (DevEx) fosters more integrated and efficient collaboration between development (Dev) and operations (Ops) teams and highlights best practices for achieving this unity and efficiency. There's no better example than what we've seen with Platform Engineering over the last few years.

The rise of Platform Engineering

The rise of platform engineering represents a paradigm shift towards creating comprehensive, integrated environments that cater specifically to the needs of developers. Focusing on abstracting the complexities of infrastructure and backend services allows developers to concentrate on writing code and creating value. Platform engineering embodies the principles of DevEx by ensuring that developers have access to robust, scalable, and easy-to-use platforms, which streamlines development processes, reduces setup time, and allows for a focus on innovation rather than maintenance, removing a lot of developer toil.

Self-service platforms embody the evolution of DevEx by empowering developers to independently provision resources, deploy applications, and manage their lifecycles without waiting for operational support. These platforms leverage automation, templates, and predefined policies to ensure compliance and governance while offering the agility needed for rapid development cycles. By providing developers with the tools to perform tasks traditionally in IT operations, self-service platforms accelerate development, enhance productivity, and foster a culture of autonomy and innovation.

Bringing DevOps and DevEx together

When organizations prioritize DevEx, they ensure that devs have access to tools and processes that streamline their workflow and facilitate a smoother code transition from development to production. This alignment encourages both teams to work closely from the outset of projects, sharing insights, feedback, and responsibilities, enhancing the efficiency of the development lifecycle and leading to higher-quality outcomes, strengthening DevOps culture and practices.

Some of the better practices to keep in mind when leveling up with DevEx are:

Equip teams with integrated, user-friendly tools that support automation, collaboration, and real-time Communication. Choose the tools that align with both Dev and Ops needs. Get their input in the decision. Just because your buddy's IT startup says they offer 10x developer productivity doesn't mean it works for your teams, much less that it works at all.
Establish cross-functional teams that include roles with diverse expertise (e.g., development, operations, quality assurance) to foster a shared understanding and responsibility from project inception through deployment and maintenance.
Establishing robust feedback mechanisms allows for continuous learning and improvement. Conduct regular retrospectives, incorporate user feedback into development cycles, and use monitoring tools to gather performance and user experience insights.
Reduce toil and free up team members to focus on more strategic activities by automating repetitive and manual tasks wherever possible. This includes automating testing, deployments, and infrastructure provisioning.
Ensure team members have opportunities to learn and grow their skills in development and operations domains. This helps build empathy between teams and equips individuals with the knowledge to understand and contribute to different stages of the development lifecycle.

Commitment to DevEx and employee well-being

A company's investment level in DevEx can reflect its values toward its employees, especially its developers. A strong focus on DevEx shows a commitment to employee well-being and efficiency. Prioritizing DevEx helps foster a culture of excellence and innovation. When developers have the right tools, support, and environment, they are more likely to produce high-quality work and push the boundaries of what's possible.

// Detect dark theme var iframe = document.getElementById('tweet-1750563607266410692-715'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1750563607266410692&theme=dark" }

Cover image by freepik

From Text Editors to Cloud-based IDEs - a DevEx journey

Jeremy Meiss — Thu, 13 Jun 2024 16:07:00 +0000

Remember the days of text-based editors like Vim and Emacs? It’s a far cry from today’s sophisticated IDEs with features like code completion and debugging tools, and “developer experience” is one of the biggest reasons why.

Before we get too nostalgic, I'm going to define Developer Experience (DevEx).

What is Developer Experience?

DevEx encompasses everything a developer, or ops practitioner, interacts with throughout the software development lifecycle. It includes the tools they use, the processes they follow, and their work environment. To quote a fantastic DevEx practitioner:

DevEx is the journey of developers as they learn and deploy technology. When successful, it focuses on eliminating obstacles that hinder a developer or practitioner from achieving success in their endeavors.
JessicaWest

With that in place, here’s a brief and wholly incomplete timeline to illustrate the impact of DevEx on software development.

Text only editors

Before the 1990s, you primarily had text-based editors for writing code, like Vi, which evidently is supposed to be called “SIX.”

Who knew? It was created in 1976 (originally as ex) and included in the first BSD Linux release.

Then we had Emacs in 1985, Vim in 1991, and my personal favorite, Nano. And only partially because I can exit it without throwing out the computer and buying a new one like I do with Vim. Saving the planet, one less computer thrown away because of Vim at a time.

The cutting edge: HP Softbench?

One of the first IDEs with a plugin concept was HP Softbench, released in 1989. HP Softbench was one of the first plugin IDEs, shipped with its own library, and was extensively discussed in the June 1990 edition of the HP Journal.

It’s a fascinating read as HP lays out its software architecture and development vision, including automated testing, distributed computing, integrated and interchangeable tools, and more. Here is the link to the PDF—I highly recommend reading it.

The early reviews of IDEs as a concept weren’t great, though. In 1995, Computer Week in Germany commented that:

...the use of an IDE was not well received by developers since it would fence in their creativity. -Computerwoche, Germany, 1995

Native IDEs enter the scene

Around the same time HP was releasing Softbench, native IDEs were emerging: Turbo Pascal in 1983 and Apple’s Macintosh Programmer’s Workshop in 1986. Borland Delphi was released in 1995 and was really the first to focus on Rapid Application Development (RAD) as a concept. Fun fact: Delphi is still around today, courtesy of Embarcadero.

The World Wide Web expansion

With the launch of the World Wide Web and its subsequent explosion of growth, IDEs started becoming more graphical and having a more modern look and feel. The first HTML WYSIWYG editor, WebMagic, was built by Silicon Graphics and released in January 1995 (in less than 90 days!). I recommend reading the series of blog posts that its creator, John McCrea, wrote about the history of WebMagic, which really begins here, and following the next few posts afterward.

FrontPage soon followed in October 1995 after Microsoft acquired it from Vermeer. Then Macromedia’s Dreamweaver broke onto the scene in 1997, after they acquired Backstage (a different “Backstage” product) from iBand in 1996). Dreamweaver completely changed the game in many respects, as Macromedia had a history of their products getting community-sourced tools, plugins, scripts, etc.

Microsoft FrontPage 2000 saw the first inclusion of plugins and integrations in early 1999 to make web management easier via FrontPage Server Extensions. NetBeans was released in 2000 for Java. IntelliJ IDEA and Eclipse followed in 2001, along with Visual Studio, which offered enhanced functionality and more sophisticated features like intelligent code completion, refactoring tools, and improved version control integration. We saw a noticeable increase in support for multiple languages and frameworks, making these IDEs more versatile.

Lightweight, extensible, and now Cloud-based

In the late 2000s, Sublime Text entered the scene, followed later by Atom and VS Code. All of these focused on speed, user-friendly interfaces, extensible plugin ecosystems, and more. They catered to a range of developers by being less resource-intensive and more customizable.

Then, we had the rise of the cloud and the arrival of cloud-based IDEs. The first cloud-based IDE was PHPanywhere (eventually becoming CodeAnywhere) in 2009, followed by Cloud9 in 2010 (before AWS bought it in 2016), Glitch (2018), GitPod (2019), GitHub Codespaces (2020), and Google’s Project IDX (2024).

Yes, I know I’m probably missing quite a few others.

These cloud-based IDEs all share the same idea: they offer fully configured development environments in the cloud that are accessible from anywhere and anyone, reducing the need for complex local setups.

Developer Experience can drive innovation

Who, in 1976, could have imagined that a developer could have a fully configured development environment in the “cloud”? As technology evolved, the need for more robust and integrated development environments grew, and options emerged for developers to choose the best tool for the job. Or what they want to use since Vim and Emacs still have avid followings.

We went from the feeling that IDEs aren't well received, (see above quote from Computerwoche) to features like these being essential for developer experience:

Code completion
Syntax highlighting
Debugging
VCS integration (no more FTPing files around)
Multi-language support
Framework integration
Pair programming

As should be the case, DevEx strategies have evolved to meet contemporary development challenges and opportunities. The journey reflects a relentless pursuit of efficiency, usability, and developer productivity, from basic, manually configured environments to sophisticated, cloud-based, and automated setups.

In the highly competitive landscape of modern software development, DevEx is the critical differentiator that makes a company and its products and services stand out. A positive DevEx translates into the ability to attract top talent, helps companies increase team performance and product quality, has more engaged and productive development teams, and enhances a brand’s reputation, directly impacting the bottom line. I’ll talk about these in more detail in a coming post.

Where will we find ourselves in the next few years, especially with “AI”-driven features being the new thing and added to IDEs?

The role of CI/CD interoperability in Developer Experience

Jeremy Meiss — Tue, 21 May 2024 20:38:27 +0000

Cover image created by ChatGPT / DALL-E

Author's Note: What follows is the second post of a series, which is the foundation of a conference talk first given at FOSDEM 2024.

As mentioned in the previous article on CI/CD standardization, the landscape of modern software development, tools, and services constantly changes - just look at the CNCF Landscape. A study conducted by DemandSage states that organizations are using 371 SaaS applications on average, which illustrates the importance of a good Developer Experience (DevEx) for your developers and practitioners to ensure productivity.

Developer Experience (DevEx) encompasses developers' journey as they learn and deploy technology. When successful, it focuses on eliminating obstacles that hinder a developer or practitioner from achieving success in their endeavors. It also refers to developers' overall satisfaction and efficiency while working on software projects. That includes the tools, processes, and environments that shape developers' interactions with code, infrastructure, and each other. A positive DevEx is crucial for enhancing productivity as it directly influences how quickly and effectively developers can build, test, and deploy software.

Continuous Integration and Continuous Deployment (commonly referred to together as “CI/CD”) is significant, and since its inception as an idea and practice has offered a dynamic shift in how developers collaborate, create, and deliver software. By automating integration, testing, and deployment processes, CI/CD accelerates the development cycles, empowering developers with faster feedback loops, improved code quality, and the ability to iterate swiftly. CI/CD interoperability ensures seamless integration across diverse toolsets, fostering flexibility in development environments. Let’s look deeper into this and the impact of interoperability on DevEx.

Interoperability in CI/CD systems

Interoperability is crucial for collaboration among development teams, operations teams, and other stakeholders involved in the software delivery process. In the context of CI/CD systems, it refers to the ability of different tools, technologies, and processes to work seamlessly and efficiently within the software delivery pipeline. It involves integrating and interacting with various components, such as version control systems, building automation tools, testing frameworks, and deployment platforms, to enable smooth transitions and handoffs between different development lifecycle stages.

If you’re currently in an organization or team that doesn’t already have some of these practices in place, here are some key ones to remember as you get started.

Streamlined workflows

When we think about “streamlined workflows” in CI/CD systems, we’re referring to the efficient and optimized processes that enable the continuous integration, delivery, and deployment of software applications. Streamlined workflows minimize manual intervention and optimize the automation of repetitive tasks, resulting in faster and more efficient software delivery. By automating build, test, and deployment processes, teams can accelerate the pace of development cycles and deliver features to users more rapidly.

Too often, when building a new product, tool, service, process, etc., we end up with a lot of overhead. Streamlining our workflows helps to eliminate unnecessary steps, redundant processes, and manual handoffs, reducing waste and overhead in the development process. This allows teams to focus their efforts on value-added activities and maximize productivity.

Streamlined workflows are essential for maximizing efficiency, collaboration, and reliability in CI/CD systems. By optimizing processes, automating tasks, and fostering collaboration, organizations can accelerate the pace of software delivery, improve product quality, and enhance the Developer Experience.

Cross-functional collaboration

Cross-functional collaboration becomes necessary to drive innovation, efficiency, and customer value through your CI/CD systems, especially when you have varying tool preferences or use different systems between departments. By breaking down silos, promoting communication, and leveraging diverse expertise, organizations can unleash the full potential of their teams and deliver high-quality software products more effectively.

Fostering a shared understanding of project goals, objectives, and priorities among development, operations, quality assurance, and other teams ensures that everyone works towards common objectives and reduces the risk of miscommunication or misunderstandings. Teams with broader backgrounds and perspectives often lead to innovative solutions and creative problem-solving. By bringing together individuals with differing skill sets, experiences, and viewpoints — organizations enable cross-functional collaboration, which allows teams to leverage each other's strengths and expertise to tackle complex challenges more effectively.

Leveraging multiple teams' collective capabilities and resources enables efficient resource utilization, sharing knowledge, tools, and infrastructure, optimizing resource allocation, and maximizing productivity. Delays can also be reduced when, instead of waiting for handoffs between teams, individuals can collaborate in real-time, addressing issues promptly and keeping projects moving forward smoothly.

Flexibility and adaptability

In today's dynamic software development landscape, requirements, technologies, and market conditions can change rapidly. Flexible CI/CD systems enable teams to respond quickly to these changes by adjusting workflows, incorporating new tools, or adopting emerging practices. This agility allows organizations to stay ahead of the curve and remain competitive.

Flexibility encourages experimentation and innovation by allowing teams to explore new ideas, technologies, and approaches. It allows teams to test hypotheses, iterate on solutions, and adapt their processes based on feedback and learnings. This fosters a culture of innovation and continuous improvement within the organization.

By embracing flexibility, organizations can future-proof their CI/CD processes and remain agile, resilient, and competitive in a rapidly evolving landscape. Organizations can bridge gaps between diverse toolsets by prioritizing interoperability, enhancing flexibility and adaptability, and ultimately elevating the Developer Experience.

Advancing interoperability in your organization

Once you have adopted the above practices or already have them, the following can help you reach “Advanced Mode,” taking your organization to another level within the DevEx world and can continue advancing across several aspects.

Ecosystem integration

Ecosystem integration in CI/CD systems involves seamlessly incorporating and interacting with various tools, services, and platforms within the software development and delivery ecosystem. Whether it's version control systems, build automation tools, testing frameworks, or deployment platforms, integration allows teams to assemble a customized toolchain tailored to their requirements.

Humans are not good at manual processes and repetitive tasks, so implementing end-to-end automation of your CI/CD processes — from code commit to deployment and monitoring — helps your teams minimize manual intervention and accelerate the delivery of high-quality software.

Greater visibility and traceability in the software delivery process are essential to keep track of the disparate tools and services used. Teams can comprehensively view project status, progress, and performance by aggregating information from version control systems, issue trackers, CI servers, and deployment platforms.

The role of community and open-source

A quick note here about community and open source: Participation in the broader ecosystem, like communities, open source projects, forums, and professional groups centered around the tools you use, vastly enriches DevEx for your company. It offers developers a chance to contribute to larger projects, learn from peers outside their organization, and stay abreast of industry trends and better practices.

Companies that encourage collaboration within communities help to address potential interoperability challenges. This can take the form of sharing success stories and case studies about how your company uses the specific tool or service to submit fixes and improvements for others to benefit from. Don’t underestimate how much this can contribute to the overall developer experience within your company.

At the same time, creating an external community for your users, especially if you have an open-source product or service, allows opportunities for developers to give feedback directly to your company. This helps your company succeed with Developer Experience, particularly for the broader community.

Troubleshooting and debugging

Two crucial components of CI/CD systems are: troubleshooting and debugging. Together, they help ensure the smooth operation and reliability of software delivery pipelines in complex CI/CD environments, where issues and errors may arise at various pipeline stages: from code integration to deployment and beyond. As such, having robust troubleshooting and debugging mechanisms in place is critical for identifying, isolating, and resolving these issues promptly to minimize downtime and maintain the integrity of the software delivery process.

Effectively implementing them requires comprehensive monitoring and logging capabilities throughout the CI/CD pipeline. This means that each stage of the pipeline is instrumented with monitoring tools and logging mechanisms so that organizations can capture valuable data and insights into the behavior of their workflows. This data enables teams to detect anomalies, track performance metrics, and diagnose issues in real-time, empowering them to address potential problems before they escalate proactively. Additionally, advanced analytics and visualization tools can help teams analyze vast amounts of data, identify patterns, and gain deeper insights into the root causes of issues, facilitating faster resolution and continuous improvement of the CI/CD process.

Automation also plays a pivotal role in streamlining troubleshooting and debugging processes by integrating testing, validation, and verification steps into the pipeline. Organizations can detect defects and errors early in the development lifecycle, reducing the likelihood of issues manifesting in production. Automated remediation mechanisms can even be implemented to automatically respond to common problems or trigger alerts for human intervention when necessary. This proactive approach to troubleshooting and debugging minimizes manual effort, accelerates issue resolution, and enhances the overall reliability and resilience of CI/CD pipelines, ensuring consistent delivery of high-quality software products to end-users.

Cross-platform deployment

Seamless deployment of software applications across a spectrum of platforms, which often span various operating systems, cloud services, and infrastructure configurations, from your CI/CD systems is foundational in modern software delivery strategies. It ensures that applications can efficiently reach diverse user bases while accommodating the wide-ranging nature of contemporary computing environments.

Cross-platform deployment streamlines the deployment process by providing a unified approach to packaging and distributing applications across different platforms. By abstracting the complexities and dependencies of other platforms, organizations can simplify their deployment pipelines, reducing the overhead associated with managing multiple deployment targets. This unified approach saves time and effort and enhances consistency and reliability in application deployment, ensuring a seamless experience for end-users — regardless of their platform.

With this, organizations are empowered to leverage the full potential of their software applications by enabling them to reach broader audiences and target diverse market segments. Whether deploying applications to desktops, mobile devices, or cloud environments, organizations can capitalize on cross-platform deployment to maximize their software's accessibility and impact. This versatility expands the reach of applications and enhances their marketability and competitiveness, driving business growth and success in an increasingly interconnected world.

In essence, CI/CD systems interoperability acts as a bridge, connecting different parts of the development and delivery process, fostering collaboration, and ensuring that teams can work cohesively and efficiently, even using diverse toolsets and technologies. This flexibility and adaptability are essential for modern software development, where agility and collaboration are paramount. But that doesn’t mean we don’t face challenges in implementing interoperability.

Challenges implementing interoperability, and steps to overcome them

Diverse toolsets

Navigating the landscape of diverse toolsets utilized across different teams and departments within an organization (hopefully smaller than the CNCF landscape) is a real challenge to implementing interoperability. Each team may have adopted specific tools and technologies tailored to their unique workflows and requirements, resulting in a fragmented ecosystem of solutions. These toolsets often vary in functionality, compatibility, and data formats, making seamless integration and communication challenging. Moreover, proprietary interfaces and protocols further complicate efforts to establish interoperability standards across the organization's CI/CD ecosystem.

To overcome the challenge of diverse toolsets and achieve interoperability, organizations should first conduct a comprehensive assessment of existing toolsets and workflows that can help identify commonalities, overlaps, and integration points. Prioritizing interoperability efforts based on critical dependencies and business objectives allows organizations to focus resources effectively. Next would be to adopt standardized protocols and interfaces, such as RESTful APIs or message queues, to facilitate communication and data exchange between disparate systems. Additionally, implementing middleware solutions or integration platforms can act as intermediaries, translating and harmonizing data between incompatible tools and formats. Don’t forget that fostering a culture of collaboration and knowledge sharing across teams encourages the adoption of standard tools and practices, reducing the proliferation of divergent toolsets and promoting interoperability within the organization's CI/CD ecosystem.

Data format and schema differences

With many data formats and schema differences between the tools and services used in a typical organization, it’s no surprise it is a significant challenge. Each tool may produce or consume data in specific formats or adhere to particular schemas, leading to discrepancies that hinder seamless information exchange across the CI/CD pipeline. These differences can result in data loss, corruption, or misinterpretation during integration, impeding the automation and orchestration of workflows.

Overcoming this challenge requires the development of robust data transformation and mapping strategies to harmonize disparate formats and schemas, ensuring accurate data exchange throughout the CI/CD ecosystem. This may involve implementing middleware solutions, data transformation pipelines, or standardization efforts to promote consistency and interoperability in data handling practices across the software delivery process.

Authentication and Authorization

Authentication and authorization (commonly called Authn and Authz) present notable challenges in implementing interoperability within CI/CD systems. Different tools and services may employ distinct authentication mechanisms and authorization protocols, complicating establishing secure and seamless communication between them. Incompatibilities in authentication methods, such as token-based authentication versus OAuth, and authorization schemes, such as role-based access control versus attribute-based access control, can hinder integration efforts and pose security risks if not adequately addressed.

Organizations can adopt several strategies to overcome these, starting with implementing standardized authentication mechanisms, such as OAuth 2.0 or OpenID Connect. This promotes interoperability by providing a common framework for secure authentication across diverse systems. Employing federated identity management solutions allows centralized authentication and single sign-on capabilities, streamlining access control and reducing administrative overhead. Furthermore, enforcing consistent authorization policies based on industry best practices, such as least privilege principles and role-based access control, helps ensure secure access to resources across the CI/CD ecosystem. Finally, integrating identity and access management (IAM) solutions with existing CI/CD pipelines enables seamless authentication and authorization workflows, enhancing security and interoperability in software delivery processes.

Versioning and compatibility testing

Versioning and compatibility issues pose significant challenges in implementing interoperability within CI/CD systems, with different tools and services that will likely evolve independently, leading to disparities in versioning schemes, feature sets, and compatibility requirements. Incompatible versions of software components can result in integration failures, functionality gaps, or unexpected behavior, disrupting the continuity and reliability of the CI/CD pipeline. Furthermore, managing dependencies and ensuring backward and forward compatibility across disparate systems can be complex and time-consuming, particularly in dynamic and rapidly evolving software environments.

Overcoming these challenges requires organizations to be very intentional and systematic. First, they must establish clear versioning policies and compatibility guidelines, which help ensure consistency and alignment across the CI/CD ecosystem. This includes defining versioning schemes, semantic versioning practices, and compatibility matrices to facilitate interoperability between different versions of software components. Additionally, implementing automated dependency management tools and dependency resolution mechanisms streamlines the management of dependencies and ensures that compatible versions of software components are used throughout the CI/CD pipeline. Furthermore, regular compatibility testing and validation across integrated systems helps proactively identify and address compatibility issues, minimizing the risk of integration failures and ensuring smooth interoperability between disparate tools and services.

Lack of documentation

We’ve all been presented with instances where inadequate or outdated documentation hinders our ability to get something done. When developers work with various tools, APIs, products, and integration points, it hinders their ability to understand, integrate, and maintain interoperable systems effectively. Without clear documentation, developers may struggle to comprehend different components' functionalities, usage, and constraints, leading to delays, errors, and inefficiencies in the integration process. Additionally, the absence of comprehensive documentation exacerbates knowledge gaps and increases the reliance on tribal knowledge, impeding collaboration and hindering the scalability and sustainability of interoperable CI/CD systems.

Taking the time to address this will pay off immediately and continually for the organization. To begin, prioritizing documentation efforts and allocating resources to document critical components, interfaces, and integration points enhances transparency and promotes understanding among developers. Establishing documentation standards and templates ensures consistency and completeness in documentation across the CI/CD ecosystem, facilitating comprehension and reducing ambiguity. Additionally, fostering a culture of documentation and knowledge sharing encourages developers to contribute to documentation efforts, capture tribal knowledge, and disseminate best practices, enhancing collaboration and promoting self-sufficiency in maintaining interoperable systems. Leveraging documentation tools and platforms, such as wikis, knowledge bases, and version control systems, provides centralized repositories for storing, updating, and accessing documentation, ensuring accessibility and traceability of information across the organization.

Closing

The efficiencies gained by making sure you're using tools that provide CI/CD standardization as well as being interoperable between all of the systems your developers are using is at the core of what Developer Experience is all about… ruthlessly eliminating barriers (and blockers) that keep your developers from being successful. Hopefully, this post (and the one preceding it) helps you or your organizatiofn work through some of those challenges and gives you a better roadmap for achieving key DevEx. Developers have their choice of tools and companies, so give them a fighting chance by helping them have the most seamless experience possible.

Streamlining your Developer Experience through CI/CD standardization

Jeremy Meiss — Tue, 21 May 2024 20:38:19 +0000

Cover image created by ChatGPT / DALL-E

Author's Note: What follows is the foundation of a conference talk first given at FOSDEM 2024, and has been split up into 2 parts for easy reading.

With the rapidly evolving landscape of modern software development, tools, and services (e.g., the CNCF Landscape), Continuous Integration and Continuous Deployment (commonly referred to together as “CI/CD”) stand as transformative pillars — reshaping how software is delivered and the very experience of those crafting it. Developer Experience (DevEx) encompasses developers' journey as they learn and deploy technology.

A successful DevEx focuses on eliminating obstacles that hinder a developer or practitioner from achieving success. It also refers to developers' overall satisfaction and efficiency while working on software projects. That includes the tools, processes, and environments that shape developers' interactions with code, infrastructure, and each other. A positive DevEx is crucial for enhancing productivity as it directly influences how quickly and effectively developers can build, test, and deploy software.

CI/CD's impact on the software engineering industry’s collective DevEx is significant, offering a dynamic shift in how developers collaborate, create, and deliver software. By automating integration, testing, and deployment processes, CI/CD accelerates the development cycles, empowering developers with faster feedback loops, improved code quality, and the ability to iterate swiftly.

By streamlining workflows, reducing friction, and providing intuitive tools, a good DevEx empowers developers to focus on creating high-quality code, fostering innovation, and ultimately contributing to faster and more reliable software delivery. For now, we will hone in on two critical pillars: standardization and interoperability.

CI/CD standardization brings consistency to development pipelines, reducing friction and enhancing collaboration. At the same time, interoperability ensures seamless integration across diverse toolsets, fostering flexibility in development environments. Together, they both play pivotal roles in optimizing DevEx and improving overall productivity in the software development lifecycle. For this post, however, we will focus on CI/CD standardization.

What is “CI/CD Standardization?”

CI/CD Standardization aims to minimize variability, reduce errors, and foster an environment where developers can efficiently collaborate. You can achieve standardization by defining explicit, repeatable code integration, testing, and deployment processes, thus ensuring a smooth development journey. Implementing CI/CD pipeline standardization is crucial for streamlining the development process and enhancing DevEx.

Here are some critical steps and better practices to start with for achieving pipeline standardization.

🔬 Assessment and analysis

Streamlining the developer experience with CI/CD standardization begins with a thorough assessment and analysis of current pipelines. This allows us to make informed decisions and implement the changes that will lead to more efficient and effective development processes. This involves everything from understanding existing workflows, tools, and processes to identifying pain points, bottlenecks, and areas requiring standardization. Evaluating specific project requirements and constraints helps prioritize the standardization efforts effectively, laying the foundation for a cohesive and efficient CI/CD ecosystem.

After assessment, organizations should establish clear goals, prioritize standardization (and subsequently interoperability), and invest in comprehensive documentation and training to overcome challenges and ensure successful adoption. Standardizing pipelines, selecting compatible tools, and integrating them seamlessly – promotes consistency and reliability across the CI/CD process.

💹 Define your goals

Clearly defining the goals for your standardization efforts should be done before you make any process changes. An important step is understanding the desired outcome for your organization and articulating the specific objectives, such as improving workflow efficiency, enhancing collaboration, and ensuring consistency across pipelines. Aligning your standardization goals with the broader business objectives helps prioritize your efforts and drive tangible improvements.

Regularly measuring and evaluating your progress and adjusting as needed fosters a culture of collaboration and knowledge-sharing, promoting continuous improvement. Once you succeed in your standardization efforts, you’ll be able to start making interoperability a priority, which we will discuss in the next post.

🧰 Select tools and practices

When selecting tools, organizations should prioritize compatibility and ease of integration to standardize across pipelines. By choosing tools that seamlessly integrate with existing systems and align with standardized practices, organizations can streamline workflows and promote consistency throughout the CI/CD process. Whatever you select must be aligned with your organization’s specific requirements and objectives. The templates and patterns you base your standardization efforts on must be consistent and reliable across all of your projects while being flexible enough to adapt to project-specific requirements.

As mentioned, documentation and training ensure that teams have the knowledge and skills to effectively utilize standardized tools and practices. By providing clear guidance and resources, organizations can facilitate a more robust and seamless adoption and ensure standardization efforts translate into tangible improvements in the Developer Experience. Again, this approach helps foster a culture of collaboration and knowledge sharing, enabling teams to work more efficiently and effectively within standardized CI/CD environments.

💾 The role of version control

A quick note here is how vital Version Control Systems (VCS) are for Developer Experience and your standardization efforts. Organizations can ensure consistency and reliability across development workflows by centralizing code repositories and enforcing versioning practices. Utilizing version control systems such as Git enables teams to track changes, collaborate effectively, and maintain a single source of truth for code, promoting transparency and accountability within the development process.

Version control facilitates automated testing, validation, and deployment processes, enabling organizations to establish standardized pipelines and workflows. By integrating version control with CI/CD tools and practices, organizations can automate code reviews, testing, and deployment tasks, reducing manual intervention and ensuring consistent and reliable software delivery.

🏋️ Automated testing and validation

Automated validation processes integrated into your CI/CD pipelines promote a culture of continuous improvement and innovation by removing many of the manual steps we’ve done over the years. The levels of consistency necessary to ensure reliable code and releases are highly difficult to achieve through manual processes. It turns out that humans are not really good at doing manual, repetitive tasks.

Utilizing automated testing frameworks and tools enables teams to execute tests efficiently, identify issues early in the development cycle, and maintain high-quality codebases. This helps organizations streamline their release processes, accelerate time-to-market, and deliver value to customers more rapidly. This approach fosters collaboration, efficiency, and agility within development teams, enhancing productivity.

📚 Documentation and training

Documentation and training play a pivotal role in streamlining the Developer Experience. When organizations invest in comprehensive documentation and training programs, they see more robust internal and external results for their company. Clear and accessible documentation guides standardized workflows and empowers teams to work efficiently within standardized CI/CD environments.

Robust training programs are a tremendous asset to the company to help teams understand the rationale behind standardization efforts and how to implement standardized practices in their workflows effectively. By providing hands-on training sessions and educational resources, organizations can foster a culture of continuous learning and improvement internally and externally — ensuring standardization efforts translate into tangible improvements in the Developer Experience.

Starting on this path from each section above ensures you are providing a better experience for the developers and practitioners inside your organization, with the following helping you to hit that boost toward DevEx optimization.

Optimizing your standardization efforts

Once you’ve ensured the core practices are in place, it’s time to look at some key, optimized practices that can help you take the next step in your standardization efforts.

📡 Continuous monitoring and improvement

Implementing robust monitoring systems allows for tracking key performance metrics and identifying areas for optimization within an organization’s CI/CD pipelines. Automated monitoring tools enable teams to detect issues in real time, allowing for prompt remediation and ensuring the reliability and stability of the development process.

Continuous improvement initiatives, such as retrospective meetings and post-mortems, facilitate learning and innovation within development teams. By fostering a culture of reflection and feedback, organizations can identify opportunities for process optimization, refine best practices, and drive continuous enhancements to the developer experience.

🏛️ Governance and compliance

Any organization’s CI/CD standardization efforts should consider vital governance and compliance considerations. Clear governance policies and compliance frameworks ensure consistency, security, and regulatory adherence across CI/CD pipelines. Organizations can mitigate risks, enforce quality standards, and maintain compliance with industry regulations and internal policies by defining standardized processes, roles, and responsibilities.

Implementing automated compliance checks and controls within CI/CD pipelines enables organizations to enforce governance policies consistently and efficiently. By integrating compliance checks into automated workflows, organizations can identify and remediate compliance violations in real time, reducing manual effort and ensuring the integrity of software releases. This allows for transparency, accountability, and trust, which development teams need to achieve positive developer productivity.

📈 Scaling and adaptation

Scaling and adaptation are critical to accommodating growth and evolving CI/CD workflow requirements. Organizations must design CI/CD pipelines that scale seamlessly to accommodate growing development teams, increasing workloads, and changing business requirements. By leveraging scalable infrastructure and automation tools, organizations can ensure that CI/CD processes remain efficient and effective even as demands change over time.

A culture of adaptation and innovation enables organizations to continuously evolve their CI/CD practices to meet new challenges and opportunities. By encouraging experimentation, learning, and feedback, organizations can identify areas for improvement and implement iterative enhancements to their CI/CD pipelines. This ensures that your CI/CD pipelines remain responsive and resilient in the face of changing demands.

👐 Feedback loop and collaboration

The biggest key to a good Developer Experience, and even DevOps itself, is having a working and collaborative feedback loop. Establishing this feedback loop allows teams to gather insights, identify areas for improvement, and iterate on their CI/CD processes continuously. By soliciting feedback from stakeholders, including developers, testers, operations teams, and even customers, organizations can gain valuable insights into pain points, bottlenecks, and opportunities for optimization within their CI/CD pipelines.

Moreover, collaboration among cross-functional teams promotes transparency, accountability, and innovation within the CI/CD ecosystem. By breaking down silos and encouraging communication and knowledge sharing, organizations can leverage diverse perspectives and expertise to drive improvements in CI/CD workflows, which in turn fosters the necessary culture of collaboration, trust, and continuous improvement.

CI/CD pipeline standards are just the first step

So, we have touched on the importance of standardizing your pipelines and how that reduces friction and enhances collaboration within your organization. We’ve also identified several vital steps, like assessment and analysis and defining your goals, as well as the tools, practices, documentation, and feedback loops that help optimize your efforts. Implementing these better practices will help you improve your CI/CD pipeline and the overall Developer Experience and quality of your software delivery process. However, it's not the finish line. Next, we’ll talk about the role of interoperability in your CI/CD systems.

So let's talk about DevRel metrics

Jeremy Meiss — Sat, 16 Sep 2023 18:18:43 +0000

Author's Note: What follows is Part 6 of a (now) 6 Part (and probably a 7th part to come) series on Developer Relations, and how we can move it forward into the years to come. It is not meant as a definitive roadmap, but more as a kickstart down the road of conversation. Please comment as you see fit, and be part of what Developer Relations can become.

On DevRel Metrics

One of the consistent things I have heard (and have even said over the years) is, "Metrics are terrible for DevRel", or "Anything we could track with DevRel is all anecdotal, and doesn't really tell anything meaningful." It's even come up recently in conversations and responses after I started my "Moving DevRel Forward" series. So I figured this would be a good next post to follow up with.

Let's face it: OKRs suck. I don't think anyone disagrees with that sentiment. But they (or whatever form your company does goals, objectives, initiatives, etc.) are essential in helping you understand what is expected of you, and what success means. How else are you going to understand, achieve, communicate, and show the value of the work you and your team does?

🎶 The Times They Are A-Changin' 🎶

Gone are the days, with rare exception in companies (usually early stage) where budget doesn't matter or you're small enough that everybody knows what everybody and their pet is doing at any given time, when you can just tell your manager and above, "Trust me. Things are going well and DevRel is kicking it and our community is growing!" Gone are the days where a company hires a Cult of Personality as the defining characteristic of their DevRel team. Gone are the days when DevRel just flies all over the world and everyone in the company just accepts that they're "doing DevRel things", or "it's for the community!" The times they (truly) are a-changin'. _(thank you, Bob Dylan and Keb Mo, whose version is below)

But is that such a bad thing? If you're not changing, you're dying. Some would argue that DevRel is dying because it has "a lack of useful outcomes", and as a result it must change. And now. And I would posit that the reason it's dying is because the discipline (and many who practice it) has been so resistant to change, and to metrics.

I'm one of the Admins for the DevRel Collective, a community "of DevRel professionals, Community Managers, and others to share resources, learn best practices, support one another, and be amongst our peers", and the subject of metrics and KPIs is never without discussion, opinions, and even mind-blowing ideas. There's even a channel devoted to it.

So what do we do?

Metrics as the measuring stick

Growing up, did you ever measure yourself on the wall to figure out how much you’d grown over the last week or year? You could easily visualise where you were, and where you are, even if it was a miniscule difference. It meant something! And maybe you even had a line above that which represented where you wanted to be, or a parent or sibling whose height you wanted to match or even beat.

DevRel as a discipline is basically 30 years old, and yet there’s such a general resistance about measuring DevRel, either as a general discipline, or the individual program in the company. Why is that?

I think there are a couple reasons why:

Data and statistics and figuring out how to pull and display metrics is hard, and not everyone has that skillset.
“If I put down a specific number to achieve, then I’m going to be held to it and my boss and/or the executives don’t know that this stuff is hard and could change.”

To borrow from my earlier statement, if you're not measuring your DevRel program, how do you know where you were, where you are, and be able to plan where you're going to go?

Let’s start with the second one first.

Accountability in DevRel

Let’s face it. For a long time, DevRel has existed as this “thing” that companies know they want, but often don’t know why they want it. This usually comes from their VCs, who heard about it either from some company they were at previously which had the function and it seemed to work and was really “cool”, or they heard about it from a VC-colleague with the same experience. This has allowed many DevRel teams to become quite large while also existing in this nebulous “we kinda have an idea of the love we have from developers, and we’re seeing growth, so that’s all you need to know there, Board Member!” All while flying all over the world, doing really whatever the hell they wanted to. And it worked.

Until it didn’t.

Over the past few years, the DevRel profession (as a whole) and many DevRel teams have come under the microscope (oddly enough just like every other team in a company), largely brought on by a combination of the following factors:

the COVID pandemic-influenced economic downturn, requiring heightened calls for efficiencies across the Business
DevRel no longer traveling and having to pivot and do things online, which was usually the realm of marketing teams (social media, SEO, Demand Gen, etc.) who all had real metrics they reported on
a general tech bubble burst that had been in the works before COVID

All of a sudden, these teams started to face those dreaded questions previously mentioned (“What is it you do here?” and “What’s the ROI of that thing?”) and, for a lot of those teams and practitioners, largely yielded a predictable response:

But, why should we in DevRel be any different? Why should we be treated special from any other department in a company? The answer, of course, is that we shouldn’t. We have to be accountable to the Business for how we run our programs and what we spend our time and money on. That’s going to build trust with our leadership and the departments we interact with, and that’s essential if you want to try a new thing or do something collaborative with another department.

We’ll explore what this could look like a bit later. For now, let’s tackle the data excuse.

Crunching numbers is hard

To start diving into metrics, you generally need a familiarity with spreadsheets and probably how to access an API. Throw in a potential need to write some queries against your company’s main database or utilize different tools to visualize them. And that’s not counting the cognitive load for many people when dealing with statistics. It’s a skillset all its own, which makes it difficult for those who don’t have that skill set to dive into - so they don’t.

And that’s all valid. But it’s also something that can be overcome. There are plenty of ways to do that:

Work with your company’s Data or Marketing Ops teams to help understand and work with the data
Access communities, resources, and even SaaS tools which help aggregate the data into something consumable
- SavannahHQ
- Common Room
- CHAOSS
- Effective Data Storytelling by Brent Dykes
- How To Find The Data To Prove Your ROI, Richard Millington & Feverbee

The data about your Community and DevRel program has got to tell a story, and that story needs to be easy to follow and draw parallels to the activities you are doing to show the impact.

"In a world full of data, storytelling is an art." - attributed to Brent Dykes

At the same time, the data you are pulling will not stay static throughout the maturity of the DevRel program. It needs to evolve, and so you'll need to constantly stretch and exercise this skill.

So how do we measure to show impact?

“Define what you want to measure for success, THEN measure the things which indicate that.” Morgan Ramsey, Pluralsight at Monktoberfest 2023

The first step in figuring out what to measure is to ask a couple of questions of yourself, your team, your management, your department, and even other departments you interact with:

What outcome are we trying to achieve?
What problem are we trying to solve?
What result are we driving to, and what would let us know we were successful?
What are the business' goals?

The answers to those questions will give you the framework for identifying the metrics, KPIs, etc. that you should be using.

// Detect dark theme var iframe = document.getElementById('tweet-1363177613498458114-69'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1363177613498458114&theme=dark" }

Let's take this scenario as an example: Your company has put an emphasis on "land and expand" activities to drive growth within customers using your company's product. In the course of the conversations about how your team can help contribute (note: there are many ways and opportunities for a DevRel team to provide value here), you find out that the Sales Team wants to drive awareness of the product to new teams within existing customers, and they're looking for ways to do so. Here are some activities, and metrics, that you could start doing and begin to track:

Activity	Possible metric(s)
Perform workshops onsite at existing customer	# of workshops performed, # of attendees at workshops, % of increase in new users
Give a talk or webinar about X feature which drives increased usage and/or customer retention	# of webinar attendees, # of new users, % increase of feature usage

Now you may want to set a specific number, if you have a baseline already of what the number of existing users are, or usage of X feature, etc., or you may want to use that activity to set the baseline to the improve against. Either way, these are real numbers and you can (and should) be tying your activities and accomplishments to them, while also making sure other areas of the company know about your efforts and what you did. Then rinse and repeat, continuously learning and improving and iterating.

Another scenario: you feel that your team really needs to be out meeting with developers and being where they're at. This could be meetups, conference speaking or sponsoring (or both), etc. You likely will need to show ROI to get approval, or may have to in the future so it's best to start now. You first will want to identify the current goals across the company that you could tie this activity to, and then put some metrics in place to show success.

Goals	Possible metrics
Product wants feedback on X feature	# of specific feedback received
Sales wants to land X new SMB deals	# of direct contacts made and passed on
Marketing wants X new use cases	# of users interested in providing use case
People team wants to grow pool of candidates for roles	# of recruiter contacts made, # of candidates that fit roles

You might notice that all of these would qualify as a DRQL (DevRel Qualified Lead) that I talked about earlier. This is a real example of how you can prove the value of your activities. It's important though to make sure that you follow up directly with the specific team so that they know what you did and what next step needs to be taken to move forward with it.

// Detect dark theme var iframe = document.getElementById('tweet-976186666988769280-885'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=976186666988769280&theme=dark" }

It's not all fuzzy metrics

Metrics for DevRel are not all fuzzy, or qualitative. You can get some really good quantitative metrics if you aren't afraid to start interacting with other business units, and to start asking yourself the difficult questions ("What does success look like?", "What is the ROI?", etc.) before someone else does.

Positioning DevRel as a resource within your company

Jeremy Meiss — Wed, 06 Sep 2023 22:35:14 +0000

Author's Note: What follows is Part 5 of a (currently) 6 Part series on Developer Relations, and how we can move it forward into the years to come. It is not meant as a definitive roadmap, but more as a kickstart down the road of conversation. Please comment as you see fit, and be part of what Developer Relations can become.

As we continue in this series, another benefit that DevRel offers is that, as its general definition states, building relationships with Developers is what it’s all about. That means that within your company, you should not be hesitant to be seen as a resource, and even a partner (!!!), to Sales, Marketing, Product, and even Recruiting!

Drawing back from the earlier notes on DRQLs, DevRel has enormous potential within your company because of its close proximity to your target audience: Developers (or Practitioners, Users, etc.). You are their voice back to the company, but you’re also the voice from the company back to them. This ideally positions you to continuously demonstrate your value. Here are some of the ways I have driven this, and seen it played out.

Revenue collaboration

Multiple orgs within the company are pushing the need for “upsell” and “land and expand”, two initiatives which mean essentially the same thing: Grow usage of the Product within a company by selling new services, or getting more people (and teams) within a company to start using the Product. DevRel can be a resource to help these teams get either renewal deals across the line, or to grow usage within the customer, maybe around new or advanced features that the customer isn’t using yet. This can be done in a number of ways, but a couple of the more significant ways are:

Workshops at the customer for their technical teams to learn about the new feature(s), or to make new teams aware of the Product.
Webinars, presentations, seminars, etc. that can be repurposed via campaigns to customers around new concepts and features to grow the awareness of the Product with those who can influence the usage.

Marketing collaboration

Marketing wants to grow the awareness of the Product, and is looking for new ways to show how developers can be using it in their normal workflow. The DevRel team can be a great resource to help in some of the following ways:

Help source case studies, as previously mentioned, from developers in the Community. This is a great way for a Champion program, or a group of highly active community members, to get involved and raise their profile in the community, inside your company, and even within their own job.
Provide Marketing teams with the different tools that developers use your Product with, and make connections through your network to that other company to do some co-marketing activities. Some of them could be webinars, live-streams, workshops at conferences, meetups, blog posts, etc.

These are just some of the bigger examples of how you can be a resource to other teams in your Company. Let your creativity fly, and see what you come up with! This is another example of how the question-asking exercise comes into play, helping you understand what other organizations have a need for.

“But Jeremy, DevRel isn’t Sales/Marketing!”

I hear this retort/excuse as to why a DevRel team shouldn’t be doing these sorts of things all of the time. It’s usually followed up with:

”Developers don’t like Sales/Marketing, and now you’re telling me that we need to be doing Sales/Marketing things!?!”

Well, Yes. Also, No.

It is a common (and basically true) statement. Traditional marketing is all about the “shots on goal” concept, where you want to get as many views/leads as possible to get your message to them with the hope of getting 2%-5% conversion. If your DevRel team is constantly out there trying to get the 500 scans at a conference; or calling up developers and pitching them to switch from a competitor; or even does a conference talk where it’s a pitch about your Product instead of talking about a concept or principle that would make the audience want to have a conversation, etc. you’re going to be seen as a shill and you’re not going to build the necessary trust. That’s not going to make for a very successful DevRel program.

But yet, devs respond to “marketing” all of the time! It's all in how the DevRel team builds that relationship, builds that trust. Giving a conference talk about a DevOps concept or principle that aligns with what your Product does, while having your company logo on the slide, and being introduced with where you work, and maybe even mentioning at the end, “I would be glad to chat with you about what my company does, or to learn more about this concept I’ve just shared”, all are ways that build trust while still making people aware of your company. Oh, and also being truthful about what your product can/can’t do when they ask. Don’t force them to use it with wild claims that won’t be backed up, or that they’re not going to use, when another product might actually be better for them in the stage they’re in. Believe me, they will remember. And they will come calling when they need something that better fits what your company does.

So here’s the rub. In business you're either making the thing, or selling the thing. Whichever one you are, your objectives need to line up accordingly. If they don't, you'll be out of a job. DevRel teams must always balance the needs of the customer and the needs of the business. If customers (devs) don't end up using your product you'll be out of a job. That's basic economics.

And I’ll say this now: DevRel as a profession needs to grow the fuck up and recognize that it's not a bad thing to participate in the marketing/sales process. You can do so and still keep the trust with devs.

In closing… for now

The point with all of this, is that DevRel needs to wake up and recognize that it must show its value to the Business, and in as many areas as possible, in order to stay ahead of the dreaded “what do you do?” and “what’s the ROI?” questions. Any attempt by DevRel to distance itself from areas of the Business will ultimately result in the Business distancing itself from that DevRel team.

I will continue to add more to this, and likely break it up into an easily consumable series soon. In the meantime, please comment below, or reach out on my socials, to chat more.

And if your company, or even your DevRel team, is in need of some help around these things, let’s chat.

You can find me at:

Cover photo by Vlad Hilitanu on Unsplash

Developer Relations and the customer journey

Jeremy Meiss — Wed, 06 Sep 2023 22:35:05 +0000

Author's Note: What follows is Part 4 of a (currently) 6 Part series on Developer Relations, and how we can move it forward into the years to come. It is not meant as a definitive roadmap, but more as a kickstart down the road of conversation. Please comment as you see fit, and be part of what Developer Relations can become.

As previously mentioned I’ve spent the last 15 years in DevRel and Community, the first few as a volunteer in online communities and the last 12 in a full-time capacity. During that time, the debate often comes up around DevRel not being Sales or Marketing, and then morphs into a debate of what metrics are, or aren’t, important, and usually ends with everyone throwing their hands up in the air and going away frustrated until their Twitter alert goes off the next time someone asks, “What is DevRel?”

DevRel is not a revenue-generating organization - it’s a cost center. As a result, it is the first area of the company that gets cut when Finance starts looking for areas to save money. But that is all too often a short-sighted move, because DevRel (and Community) teams are the ones closest to the very audience and customer the company is trying to acquire, get feedback from, retain, etc.

One of the best ways these teams can avoid the value-oriented questions, is by proving their value long before it gets to that point. The value DevRel adds for a company must be aligned with the needs of the business and its bottomline. It MUST, or else it will be gone. DevRel needs to understand what the inputs are the business has/need and then shape its activities accordingly. But how do you do it?

One of the first things I have done whenever I join a new company, is start asking questions. I won’t bore you with all of the details, as I already wrote about them here. The purpose of these questions is really threefold:

Get myself in front of as many people within the organization and company as possible. It’s a great way to meet new people, and to make connections for what will come later.
Identify all of the wants, needs, and perceptions of DevRel early on instead of finding out months down the road. Sure, that is bound to still happen, but this helps to limit it early on.
Find out all of the existing business challenges, objectives, and KPIs that these different teams are reporting against. This will help in shaping our own and we know what we can, and sometimes can’t, contribute towards.

DevRel teams, especially their leadership, should be having regular syncs with other Business units to understand their challenges & objectives/KPIs/goals/OKRs/etc. This is how you’ll identify what activities your team can do with/for those other organizations to support them, thus raising the value of DevRel.

The next part really can take awhile, but it really is oh, so important.

Positioning DevRel in the Customer journey

To be able to position your team in the Customer journey, you need to:

Find out what the Customer journey currently looks like,
Identify what activities your team is currently performing,
Match up the activities with their spot in the Customer journey,
Automate wherever possible,
Build your reporting, and
Rinse. Repeat regularly.

Let’s break these down.

Find out the Customer journey at your company

When you’re first joining the company, or when you’re going back to perform the Q&A steps I mention above, making sure to ask the different groups what the Customer journey looks like, and who owns it. It is not uncommon to get different answers from each department, which is its own exercise later in really nailing down ownership for something very crucial like this.

In different companies at different stages and sizes, and even customer-base, who you end up talking to will be different. Here are a few that I have chatted with in the past who owned, or at least had some input into, the Customer journey:

Marketing Operations
Demand Generation
Product Marketing
Product
Customer Success

What you are looking for in the Customer journey is to capture all of the touch points, which are moments when the customer interacts with your brand, and all of the stages that have been identified, which are goal-driven actions to take. These have all been put together and (should) drive all of the customer-driven activities taking place.

Ex. customer journey (source)

Note: this is also a great opportunity to start to identify what the elusive DevRel Qualified Leads (DRQLs) could look like for your team.

Identify your team’s activities

Identifying all of the things that your team does can be a bit of a challenge, but it’s an important one. It’s also good to recognize that the list you create will change, either because you remember some you missed, or your team starts doing new things - and that’s ok. Just get started with the list, being as specific as you can. You don’t need to categorize them yet, as you might find it better to group them into the categories that are identified in the Customer journey at a later date. I would instead start by breaking them down into two groups:

Activities community members perform
Activities the team perform

If you’re finding it difficult to identify them, here are some that my previous team identified:

Community activities	Team activities
Attended company meetup Conversation at a conference Entered raffle Visited booth Gave product feedback	Conference talk Workshop Blog post written Sample created Demo given at customer

As I mentioned, these are all just a few of the many activities that we identified. One thing that also helped us identify, and track, all of the activities being performed in the community and by the team was by using Orbit and the Orbit Love model. You can read about some of the ways I implemented Orbit at CircleCI here. There are other tools like Common Room which help you achieve the same thing, but it’s important that you have a way to capture all of the activities in order to accurately report on them.

Match up the activities with their spot in the Customer journey

You will go through multiple iterations of this, and that’s a good thing. It’s important to consistently revisit all of the activities and the customer journey with the other teams who need input into it. This will help to identify areas or activities you potentially missed, and to even look for ways that you can connect other systems, like HubSpot and Salesforce, into the system(s) you use for tracking your activities to make it even easier to report on what your team is doing and how it all fits together.

Automate wherever possible

This will follow very closely with the previous step. With systems like Orbit and Common Room, you can integrate external systems into the platform to make capturing activities much easier. Here are a few examples of what that might look like:

Inputs into your community platform

Integrate your GitHub organization (or specific repos) for capturing those community activities
Integrate forums and communities like Discourse, Reddit, and StackOverflow
Integrate customer feedback and product ideas
Import raffle entries or booth visits

Outputs from your community platform

Daily export into company data warehouse for inclusion in other reporting data
Import into Salesforce to show if someone is part of the community, or if they’re a Champion, etc.
The ideas are limitless

All of this should be automated as much as possible, and in the instances where it needs to be manual, make sure you set aside the time to do so. It is important to make sure you capture as many activities that you perform which can be tracked back to making an impact on the Customer journey.

Reporting

This step is one that is difficult, but extremely necessary. You can’t prove the value of what you’re doing as a team or organization unless you provide the reports for other departments and the rest of the company to disseminate. To be able to report though, you need to make sure the previous steps are in progress - they don’t need to be done though, because they’re never done. Here are a few thoughts to get you down the road though.

Use the information gathered when you go on [your info-gathering spree] to understand what is important to different business units to identify which areas your team could be contributing towards. Prioritize those within your department first, and use the others as ones you can start to show over time. It is important though to make sure that you align your activities to the overall objectives, KPIs, etc. that YOUR department has first, and then make sure that you track them back also to the overall company OKRs.
If possible, make sure these reports can be accessed at any time, by anyone within the company. I’ve done this with integrations to Confluence, charts and tables housed in Excel or Google Sheets linked to Powerpoint or Google Slides, reports in Looker, etc. It’s also good to regularly post inside your company comms tool, like Slack, general information about some highlight and then link to the report(s). This helps keep your team and what you’re doing top of mind.
Make sure you report on any cross-team / interdepartmental collaboration that you and your team do as well. You should be actively looking for these anyways, and reporting on them will raise the value-prop that DevRel has.

A quick note on DevRel Qualified Leads

As I mentioned above, this whole activity can help to unlock DRQLs for your team. These are not “leads” in the traditional sales or marketing sense, but instead are specific developers, or companies even, that your team is able to connect with internal teams to satisfy some need or business requirement. For instance, here’s a quick breakdown of what could be included in these:

Marketing: Case studies, guest writers, co-marketing opportunities
Product & Engineering: Alpha/Beta testers, product feedback, new feature requests
Sales: Direct asks for demos, proof of concepts, etc.
Business Development: New partners, collaboration opportunities
Recruiting: Diverse candidates, collaboration opportunities

Making sure to identify these for your team, and to include them in your reporting, will help increase the knowledge of the value your team is bringing in terms and phrases that the business knows well (“X-qualified leads”).

Rinse. Repeat (regularly).

Businesses are always changing. One week the focus could be to raise awareness in developer communities about your company and the product and get people trying it out. The next week is that it’s important to target Enterprises, and next month it’s imperative that your team push the limits on what the company could do and/or become with AI. As a result, your activity inputs and outputs will change on a pretty consistent basis, and so it’s imperative that you continually perform these activities.

Cover photo by Jannes Glas on Unsplash

Asking the right questions for DevRel impact

Jeremy Meiss — Wed, 06 Sep 2023 22:34:55 +0000

Author's Note: What follows is Part 3 of a (currently) 6 Part series on Developer Relations, and how we can move it forward into the years to come. It is not meant as a definitive roadmap, but more as a kickstart down the road of conversation. Please comment as you see fit, and be part of what Developer Relations can become.

Also of note: much of this specific content comes from a previous post I wrote, "So you're starting a new DevRel job"

When you start a new Developer Relations or Community role at a company, you may well be their first hire, or you're coming in after someone else (or a group) has left, or you’re coming in to take over the team (or any variety of these and others not mentioned). During that initial onboarding you'll usually be asked to provide a 30/60/90 plan along with a strategy for the next year. This may seem daunting, but it’s something you should be prepared to do. You may also be coming at this as someone who's already in the role at the company, but you're wanting to reshape your DevRel Program to gain the maximum impact at your company. What follows

I’ve personally spent roughly the last 15 years in the Community and/or DevRel space, with the last 12 or so in an official capacity. What follows are the questions and steps I’ve learned to apply which are by no means a complete list - I’ve added to this list after each role change - but should be a good starting point for you.

If you haven't already, I highly suggest you take a look at the great resources that @blackgirlbytes has put together in her DevRel Journey Series, with a specific call out to her Tips to Succeed in your First DevRel Job.

Before joining

One of the first steps is to make sure you fully understand everything you can about the job you’re potentially taking. Making sure you ask some of these questions will help you to be a bit more informed about what you might expect before you start.

How does the company make, and lose, money?
What area of the company is the DevRel team a part of? Who would you report to?
What are the “big rocks” the department and company are tackling this quarter/year?
How are objectives identified and handled?
What is expected over the first 30/60/90 days?
Why do they want or need a DevRel team?

These will help to give you an idea of the company and how it’s structured and what you might be faced with on Day 1. All of the above come with the caveat that businesses can, and do, change from the time you receive the answers above to the time you start. However, this will give you a foundation to build off of.

photo by Tim Marshall on Unsplash

When you start

That first day, or week(s) in some cases, is usually full of all of the onboarding tasks which will occupy your time. That is, however, a good time to start your own personal onboarding to the team and company with some of the below steps:

If you’re onboarding with more than just yourself, build relationships with your fellow “first day-ers” - you never know when your paths might cross again and it’s good to have a frame of reference.
Meet with your manager and clarify the job as you understood it when you took the position to make sure you’re both on the same page. Also,
- Make sure you understand the timeframe they have for the first deliverables for the position (30/60/90 day plan, strategy, etc.) and how they would like to receive it.
- What is the budget that I have for the team? What was last year’s budget? What amount of discretionary spending do I have?
- Identify how they would like to receive information like metrics, status, objectives, etc.
- Identify who they would like you to meet with. This will likely be a high-level list, and you will want to drill down with each person when you meet with them.

After the onboarding

Once you’ve gotten through the “administrative” pieces of joining the company, you want to get started with the “roadshow”. This involves meeting with those identified by your manager, along with leaders in the following areas:

Product Managers, Owners, etc.
Product Marketing, Content, Demand Gen, etc.
Engineering, Sales Engineering, etc.
C-Level
Customer Success

In those conversations, make sure to ask “Who else should I talk to?” and setup those meetings soon after. Below I will provide the questions that I use for the respective areas, some of which are duplicated across different teams. If you use any of these, it’s important that you customize them to your respective company.

Questions for everyone

What is the mission, vision, and values for the company? What are they for {insert department here}?
What are your priorities and goals? What wins do you need? How can DevRel help you accomplish those? How can I help you?
What are your biggest concerns about working with developers?
Do you have any concerns about the Developer Relations team and the way they’ve worked cross-functionally in the past?

Questions for Product teams

What are the pillars of our product?
What is our threshold for a new account for them having successfully “onboarded”?
What are the things we are currently hearing from users about our product?
Do we know when developers make the transition from checking us out, to “swiping the card”? Do we know why?
Do we know why developers do / do not choose us?

Questions for Marketing teams

[Demand Gen] What is our process for identifying developers at conferences/trade shows/events? How do we decide what to send to them? Any examples?
[Demand Gen] What is our current process around swag? Who is responsible?
[Demand Gen] What is the process for attending/sponsoring conferences?
[Demand Gen] Where in the funnel do you see DevRel helping?
[Demand Gen] What are our currently targeted developer communities? Regions?
[Demand Gen] Do we know when developers make the transition from checking us out, to “swiping the card”? Do we know why?
[Demand Gen] What is the current geographic customer breakdown, and what are the goals for this year and beyond? Any regions we’re avoiding specifically?
[Demand Gen] Where are our current, target markets? What are our current, targeted technologies?
[Product Marketing] Do we know why developers do / do not choose us?

Questions for Customer Success teams

What are the customer pain points that your teams are currently hearing about?
Are there any identified users who are already passionate about us?
Is there a space where we collect and share common issues or FAQ with the community?

If there is already a community….

What is the current community forum process? Who owns what?
- The system?
- Answering questions?
- Outreach activities?
- Any current processes to get an answer from someone in the company?
What metrics are currently collecting about the community? Programming languages? Functions/roles? Geographic locations?

What now?

Once you’ve gathered all of the answers, it’s time to look for common themes from each which can help you identify potential opportunities as you build your strategy and program. In theory, you should be able to have the beginnings of a strategy and program to present within the first 60 days to the key stakeholders who you identified during your “roadshow” in order to get their feedback, and then modify as needed by the 90th day.

Over the next 3 months (equal to the first 6 months on the job), start to implement the first steps of your strategy and tweak it as needed, with a mind to seeing results within the first year. This doesn’t mean that everything would be done and yielding results in the first year, but rather that you should start to see progress around your strategy, and that you’re hitting specific milestones that were identified. Then rinse and repeat.

So now let’s return to those dreaded questions around value.

Cover photo by Zach Lucero on Unsplash

The foundations of Developer Relations

Jeremy Meiss — Wed, 06 Sep 2023 22:34:41 +0000

Author's Note: What follows is Part 2 of a (currently) 6 Part series on Developer Relations, and how we can move it forward into the years to come. It is not meant as a definitive roadmap, but more as a kickstart down the road of conversation. Please comment as you see fit, and be part of what Developer Relations can become.

”Begin at the beginning!”

“Developer Relations”, commonly referred to as “DevRel” for short, is generally defined quite simply as

“a business organization or function that builds relationships with Developers”.

Without making this too much of a history lesson, DevRel as a role or function goes back to at least 1995 with Donna Simonides, who in 1995 was Netscape’s Director of Developer Relations. They weren’t alone: Microsoft had a VP of DevRel and Marketing (yes, the symbiotic relationship between these two departments is not new) in 1997; Apple had one of their own before Steve Jobs returned (and it was even treated as “the chief contact with the development community”) and then renewed their developer outreach in late 1997; and even InstallShield had a DevRel team in 1998. Modern DevRel, as we tend to recognize it today, started at Twilio and Engine Yard, neither of whom still perform DevRel in the same way as they did then.

I mention all this to say that DevRel is not a new thing. It’s been around for almost 30 years (fwiw 1995 is when I started my tech career, the same year DevRel was mentioned with Netscape).

And as I wrote about in another post on my path to DevRel, I was a Technical Liaison at Hallmark Cards in 1999, which was literally Internal DevRel.

Much has been written on the subject by many people far smarter than myself, so I won’t go further on defining the function. Here are a few for starters:

Rizèl Scarlett’s DevRel Journey Series
Mary Thengvall’s The Business Value of Developer Relations

The next post in this series is going to talk about the different questions that you should be asking when you either a) start a new DevRel role at a company, or b) are wanting to help shape your DevRel Program to gain the maximum impact at your company.

Cover photo by v2osk on Unsplash

DEV Community: Jeremy Meiss

Developer Experience is More Than Just Productivity Metrics

The "Disaster" Reality Check

Defining the Difference: Experience vs. Productivity

The Evolutionary Path of Measurement

Framework Comparison at a Glance

The Three Pillars of World-Class DevEx

1. Fast, High-Quality Feedback Loops

2. Low Cognitive Load

3. Enabled "Flow State"

A Practitioner-Centric Scorecard

Conclusion

It's Not Rocket Science, It's a Flywheel: Engineering Open Source Communities with DevEx

Quick DevEx Primer

Why DevEx is (Slightly) Different in Open Source

The Physics of Community

Components of the OSS DevEx Flywheel

1. The Welcome Mat (Onboarding)

2. "Time to Joy" & Tooling

3. Feedback Loops

Handling the "Dead End" Thread

4. Recognition & Value

5. Leadership Pipeline

The DevEx Flywheel in Action

Measuring the Spin

It Starts With a Single Push

Conclusion

Further Reading

Measuring the impact of Developer Relations on Revenue

DevRel and the bottom line

Ways to start tracking

Developer Experience is essential for DevOps success

A working definition of Developer Experience

Modern Development

DevEx touches environment management

DevEx aligns perfectly with DevOps

Collaboration

Communication

Shared responsibility

The rise of Platform Engineering

Bringing DevOps and DevEx together

Commitment to DevEx and employee well-being

From Text Editors to Cloud-based IDEs - a DevEx journey

What is Developer Experience?

Text only editors

The cutting edge: HP Softbench?

Native IDEs enter the scene

The World Wide Web expansion

Lightweight, extensible, and now Cloud-based

Developer Experience can drive innovation

The role of CI/CD interoperability in Developer Experience

Interoperability in CI/CD systems

Streamlined workflows

Cross-functional collaboration

Flexibility and adaptability

Advancing interoperability in your organization

Ecosystem integration

The role of community and open-source

Troubleshooting and debugging

Cross-platform deployment

Challenges implementing interoperability, and steps to overcome them

Diverse toolsets

Data format and schema differences

Authentication and Authorization

Versioning and compatibility testing

Lack of documentation

Closing

Streamlining your Developer Experience through CI/CD standardization

What is “CI/CD Standardization?”

🔬 Assessment and analysis

💹 Define your goals

🧰 Select tools and practices

💾 The role of version control

🏋️ Automated testing and validation

📚 Documentation and training

Optimizing your standardization efforts

📡 Continuous monitoring and improvement

🏛️ Governance and compliance

📈 Scaling and adaptation

👐 Feedback loop and collaboration