What Running DevRel at 1Password Taught Me About Open Source and Developer Trust
1Password is a product that developers already love. That’s a rare starting position for a DevRel program. Most companies have to convince developers to care. At 1Password, the challenge was different: how do you build a formal developer relations function around a product that already has organic developer affinity, without breaking the trust that earned it?
The Starting Point
When I came in, 1Password had over 900 open source projects in its ecosystem but no unified DevRel vision tying them together. There was developer interest, technical content being produced in pockets, and a strong engineering brand. What was missing was a strategy connecting all of it.
My role was to establish that strategy: define what developer relations meant for 1Password, build the content engine, manage the open source program, and serve as the company’s developer advocate across channels.
Open Source at Scale
Managing 900+ open source projects is a fundamentally different challenge than running a handful of flagship repos. At that scale, the questions shift from “how do we maintain this project” to “how do we maintain a coherent developer experience across hundreds of touchpoints.”
The approach I took was to focus on the developer’s perspective rather than the project’s perspective. A developer interacting with 1Password’s open source ecosystem doesn’t think in terms of individual repos. They think in terms of tasks: “I want to integrate 1Password into my CI/CD pipeline,” “I want to manage secrets in my Kubernetes cluster,” “I want to add password management to my app.”
Organizing the open source program around those developer journeys, rather than around project maintenance, changed how we prioritized work, wrote documentation, and communicated with the community.
Content as Developer Advocacy
At 1Password, I produced and directed technical content at scale, contributing to my career total of over 123 developer tutorial videos. But the lesson I took away wasn’t about volume. It was about the role content plays in a trust-driven product.
Security products live and die on trust. Developers won’t adopt a password manager, a secrets management tool, or an authentication SDK unless they trust the company behind it. Traditional marketing erodes that trust. Technical content builds it.
The content strategy at 1Password was built around demonstrating competence rather than making claims. Show a developer exactly how the CLI works. Walk through the architecture of the secrets management system. Explain the encryption model in detail. Every piece of content was an opportunity to prove that the people behind the product understand the developer’s world.
This approach to content, lead with technical depth rather than marketing polish, is something I now bring to every engagement. It’s especially relevant for API-first companies where the buyer and the user are often the same technical person.
Cross-Functional GTM
One of the more valuable parts of the 1Password experience was leading cross-functional go-to-market efforts. Developer relations doesn’t operate in a vacuum. Launches involve product, engineering, marketing, sales, and support, and someone needs to be the connective tissue between the developer’s perspective and the rest of the organization.
At 1Password, I served that function: translating developer needs into product priorities, coordinating launch timelines across teams, and ensuring that the developer experience was considered in every GTM decision. This is a skill that doesn’t show up in most DevRel job descriptions but determines whether a DevRel program actually influences product direction or just produces content on the side.
Three Lessons from 1Password
Trust is the product. For security-focused developer tools, every interaction is either building or eroding trust. Content, documentation, community engagement, and open source contributions all need to be measured against that standard.
Open source at scale requires journey-based thinking. When you have hundreds of projects, organizing around developer tasks rather than individual repos makes the ecosystem navigable and the priorities clear.
DevRel is cross-functional or it’s just marketing. The value of developer relations comes from influencing product decisions, not just producing content. If DevRel doesn’t have a seat at the GTM table, it’s operating at a fraction of its potential.
1Password was the most recent chapter in a career spent building developer programs at companies that hadn’t had them before. Each one, BMW, GoPro, HERE Technologies, and 1Password, taught me something different. Together, they form the foundation of the fractional DevRel practice I run today.