Forem: Matty Stratton

How Do PostgreSQL Indices Work, Anyways?

Matty Stratton — Wed, 18 Mar 2026 14:35:21 +0000

You've probably created a hundred indexes in your career. Maybe a thousand. You ran EXPLAIN ANALYZE, saw "Index Scan" instead of "Seq Scan," pumped your fist, and moved on.

But do you actually know what's happening underneath? Because once you do, a lot of things about PostgreSQL performance start to make a lot more sense. And some of the pain points you've been fighting start to feel less like mysteries and more like, well, physics.

It's a tree. Obviously.

The default index type in PostgreSQL is a B-tree. You knew that. But let's talk about what that actually means for your data.

When you create an index on, say, a timestamp column, PostgreSQL builds a balanced tree structure where each node contains keys and pointers. The leaf nodes point to actual heap tuples (your rows on disk). The internal nodes just help you navigate. Think of it like a phone book. (Do people still know what phone books are? I'm aging myself.)

The key thing to understand: the index is a separate data structure from your table. It lives in its own pages on disk. When you insert a row, PostgreSQL doesn't just write your row. It also has to update every index on that table. Every. Single. One.

So if you have a table with five indexes and you're doing 50,000 inserts per second, that's not 50K write operations. That's 250K+ B-tree insertions per second, plus the heap write. Oof.

You can see exactly how much space each index is consuming with \di+ in psql:

\di+ public.*

-- Or if you want programmatic access:
SELECT indexrelid::regclass AS index_name,
       pg_size_pretty(pg_relation_size(indexrelid)) AS index_size,
       idx_scan AS times_used,
       idx_tup_read AS tuples_read
FROM   pg_stat_user_indexes
WHERE  schemaname = 'public'
ORDER  BY pg_relation_size(indexrelid) DESC;

Run that on your biggest table. If you see indexes measured in gigabytes that have idx_scan = 0, those indexes are costing you writes and giving you nothing back. They're dead weight.

Pages, not rows

Here's where it gets interesting. PostgreSQL doesn't read individual rows from disk. It reads 8KB pages. Always. Even if you only want one tiny row, you're pulling in a full 8KB page.

Your B-tree is also organized into 8KB pages. Each page holds as many index entries as it can fit. For a simple index on a bigint column, you can fit a few hundred entries per page. For a compound index on (tenant_id, event_type, created_at), you're fitting fewer because each entry is wider.

When PostgreSQL traverses your B-tree, it starts at the root page, reads it, follows a pointer to the right internal page, reads that, and eventually gets to a leaf page that tells it where your actual row lives on the heap. For a table with a million rows, that's maybe three or four page reads. For a billion rows, it might be five or six. Logarithmic scaling is your friend here.

You can see this in action with EXPLAIN (ANALYZE, BUFFERS):

EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM events WHERE created_at > now() - interval '1 hour';

-- Look for lines like:
--   Index Scan using events_created_at_idx on events
--     Buffers: shared hit=4 read=2

The shared hit count tells you how many pages came from the buffer cache. The read count tells you how many had to come from disk. If you're seeing high read values on a query you run frequently, your working set has outgrown your shared_buffers.

But. (There's always a but.)

The part nobody thinks about

Those leaf pages need to stay ordered. When you insert a new value that belongs in the middle of a page that's already full, PostgreSQL has to split that page. Page splits are expensive. They cause write amplification and can fragment your index over time.

For time-series data (timestamps always increasing), you mostly dodge this problem because new values go to the rightmost leaf. That's nice. But it creates a different problem: hot-page contention. Every concurrent insert is fighting to write to the same leaf page at the end of the tree.

And then there's the part that really gets you: MVCC overhead.

PostgreSQL's multiversion concurrency control means that even your index has to deal with tuple visibility. Index entries don't get removed immediately when a row is deleted or updated. They stick around until VACUUM cleans them up. So your index isn't just tracking live rows. It's tracking all the versions of your rows until the cleanup crew gets around to it.

For a high-churn table, your index can be significantly larger than you'd expect just from the row count. I've seen cases where the index is effectively 2-3x the "expected" size because of dead tuple bloat.

Here's how to check if bloat is eating your indexes alive:

SELECT relname,
       n_dead_tup,
       n_live_tup,
       round(n_dead_tup * 100.0 / nullif(n_live_tup + n_dead_tup, 0), 1) AS dead_pct,
       last_autovacuum
FROM   pg_stat_user_tables
WHERE  n_dead_tup > 10000
ORDER  BY n_dead_tup DESC;

If dead_pct is climbing above 10-20% and last_autovacuum was hours ago (or null), autovacuum is falling behind. That bloat isn't just wasting space. It's making every index scan touch more pages than it should.

Index-only scans (and why they're worth understanding)

There's one more behavior worth knowing about, because it changes how you think about index design.

Normally, PostgreSQL uses the index to find where a row lives on the heap, then goes and reads the actual row. That's two separate lookups: the index, then the heap.

But if every column your query needs is already in the index, PostgreSQL can skip the heap entirely. That's an index-only scan, and it's significantly faster.

-- This index covers both the WHERE clause and the SELECT list:
CREATE INDEX idx_events_covering ON events (created_at) INCLUDE (event_type, value);

-- Now this query never touches the heap:
EXPLAIN (ANALYZE, BUFFERS)
SELECT event_type, value FROM events WHERE created_at > now() - interval '1 hour';

-- Look for:
--   Index Only Scan using idx_events_covering on events
--     Heap Fetches: 0

The Heap Fetches: 0 is what you want. That means PostgreSQL answered the entire query from the index alone.

The catch: index-only scans only work well when the visibility map is up to date, which brings us right back to VACUUM. If VACUUM hasn't visited a page recently, PostgreSQL can't trust the index alone and has to check the heap anyway. So even this optimization depends on keeping autovacuum healthy.

Partial indexes (less is more)

One more tool that's underused: partial indexes. If you only query a subset of your data most of the time, you can index just that subset.

-- Instead of indexing every row:
CREATE INDEX idx_events_status ON events (status);

-- Index only the rows that matter:
CREATE INDEX idx_events_active ON events (status) WHERE status = 'active';

The partial index is smaller, faster to scan, and cheaper to maintain on writes. For high-churn tables where most queries filter to a small slice of data, this is free performance.

So why does this matter?

Understanding this stuff isn't just academic. It explains real problems you hit in production:

Why adding indexes slows down writes. Every index is another B-tree that needs to be maintained on every insert. It's not free. It's never been free. The cost just hides until you're at scale.

Why your queries get slower over time even though nothing changed. Index bloat from dead tuples. Pages that used to be tightly packed are now half-empty after splits and vacuuming. Your three-page-read query is now a six-page-read query.

Why VACUUM matters so much. It's not just reclaiming table space. It's keeping your indexes healthy. If autovacuum can't keep up, your indexes degrade. And if you're inserting fast enough, autovacuum can fall behind. That's not a bug. That's just the architecture working as designed.

Why partitioning helps (and then stops helping). Smaller partitions mean smaller indexes mean fewer tree levels. Great. But now your query planner has to evaluate all those partitions to figure out which ones to scan. And that planning cost scales linearly with partition count. You're trading one bottleneck for another.

The bigger picture

I wrote about this cycle more extensively in a piece about the PostgreSQL optimization treadmill. The short version: there's a pretty predictable progression that teams go through. Optimize indexes. Partition tables. Tune autovacuum. Scale vertically. Add read replicas. Each phase buys you a few months.

That's not a criticism of PostgreSQL. Postgres is an incredible database. But it's a general-purpose relational database, and its architecture reflects that. The heap storage model, MVCC, the query planner, B-trees. They're all designed to handle a wide range of workloads really well. The tradeoff is that for very specific access patterns (like time-series data at scale), those general-purpose design choices start working against you instead of for you.

Understanding how your indexes work is the first step to understanding when they stop being enough. And knowing when you're fighting the architecture instead of optimizing within it can save you months of whack-a-mole performance tuning.

But that's a topic for another day. For now, go run these queries on your biggest table:

-- How big are your indexes, really?
SELECT indexrelid::regclass AS index_name,
       pg_size_pretty(pg_relation_size(indexrelid)) AS size,
       idx_scan AS scans
FROM   pg_stat_user_indexes
WHERE  relname = 'your_table_here'
ORDER  BY pg_relation_size(indexrelid) DESC;

-- Are any of them unused?
SELECT indexrelid::regclass AS index_name,
       idx_scan
FROM   pg_stat_user_indexes
WHERE  idx_scan = 0
  AND  schemaname = 'public'
ORDER  BY pg_relation_size(indexrelid) DESC;

You might be surprised.

Coding Agents Are Actually Good at This One Thing

Matty Stratton — Sun, 01 Mar 2026 20:31:28 +0000

The discourse around AI coding tools tends to collapse into two camps: people who think they're going to replace developers, and people dunking on "vibe coding" demos that fall apart the moment you look at them sideways.

Both camps are mostly arguing about the wrong thing.

I've been using coding agents heavily for the past few months, and the use case where they've actually changed how I work isn't production applications or greenfield SaaS ideas. It's internal tooling. And that distinction matters more than people are giving it credit for.

The Airtable Problem

For years, I built internal tools the way most of us did: I found something close enough and made it work. Airtable was great for this. I built conference talk trackers, content inventories, planning dashboards... all kinds of things. The spreadsheet-meets-database model was genuinely useful, and for a while, it was the right call.

But you're always fighting two things with tools like Airtable or Notion or even Asana when you're bending them to a purpose they weren't built for. First, you fight the constraints of the tool itself: the data model it has, the views it supports, the automations it allows. Second, you fight the cost and friction of giving your whole team access to yet another SaaS platform.

At some point the juice stops being worth the squeeze. You're not building what you actually need, you're building the closest approximation that fits inside someone else's product.

Just Build the Thing

What coding agents have unlocked for me is the ability to just build the thing.

The project I've been heads-down on is called Tiger Den: an internal content management system for our Marketing team at Tiger Data. It's a Next.js app, Drizzle ORM, tRPC, Postgres (running on Tiger Data, natch). A real web app with a real database, exactly structured for how we actually work.

Tiger Den manages our content library, tracks blog posts and videos, stores voice profiles for different authors so we can make sure our content matches our voices, generates UTM links, and surfaces the right content for the right workflow. It's not a product. It's not trying to be. It's a tool that fits our team's exact needs because we built it for our team's exact needs.

A few folks on the team are starting to use it. Workflows that used to involve a bunch of spreadsheet wrangling and web search gymnastics are getting simpler. It's not fully baked (it's somewhere between "mostly works for me" and "the team is starting to play with it") but it's already more useful than what it replaced (a combination of "nothing" plus "not very updated spreadsheet"), and I've been iterating on it continuously.

That iteration speed is the point.

Why Internal Tooling Specifically

The reason coding agents shine here, and why I keep coming back to this use case, is the risk profile.

When you're building a public-facing application, you have to worry about edge cases at scale, security hardening, performance under load, what happens when a user does something unexpected, what happens when a thousand users do something unexpected. The cost of getting it wrong is high.

Internal tools have a completely different calculus. The user population is small and known. The stakes for any individual bug are low. You can ship something that's 80% right and fix the other 20% next week. You can move fast and it's actually fine.

This is the Microsoft Access model, honestly. In the 90s and early 2000s, people built remarkably functional internal tools in Access (forms, reports, relational data, real logic) because the barrier was low enough that you could actually do it. Then the web happened, the complexity went way up, and that era of "just build the thing" basically ended for most people.

Coding agents are bringing it back. The barrier is low again. You can describe what you want, iterate in a tight loop, and end up with something that actually fits your use case instead of something that almost fits someone else's template.

What About Retool?

When I posted about this, someone brought up Retool — fair question. Isn't that exactly what Retool is for?

Maybe. But my reaction was: isn't that just trading one set of constraints for another? Now I'm stuck on how Retool thinks about the world instead of how Airtable thinks about the world. I haven't dug deep into Retool, so I'm not going to trash it, but the pattern is the same: you're building inside someone else's model of what your tool should be.

The thing I actually want is to build the thing I want. That's what "just use Next.js and a database" gives me.

Some Honest Caveats

I want to be careful not to oversell this, because the context matters a lot.

I'm a systems guy. Infrastructure, security, DevOps, that's my background. I could build Tiger Den without a coding agent; it would just take a lot longer because I'm coming at software development somewhat sideways. The agent collapses that time gap significantly. But I'm still making real architectural decisions, reviewing what gets generated, and understanding the codebase well enough to maintain it. This isn't "describe what you want and walk away."

Someone also asked about maintenance (a reasonable concern!). My answer: for Tiger Den specifically, I'm only writing to my own database. I'm not doing write operations against external systems, I'm not touching production data, and the blast radius of any given bug is small. That's a deliberate choice, and it's part of why internal tooling is the right framing. If I were building something that talked to our customers' data or integrated deeply with critical external systems, I'd be a lot more careful.

The low-stakes calculus stops applying the moment you have real users, real consequences for downtime, or data you can't afford to mess up. Keep that boundary clear and this approach works really well. Blur it and you're asking for trouble.

But for "my team needs a thing and the existing tools don't quite fit"? This is legitimately transformative. I've wanted to be able to build internal tools this easily for a long time. Now I can.

Airtable, it's been real. Tiger Den is better.

Product 101: Your Secret Weapon for Understanding the Business

Matty Stratton — Tue, 04 Nov 2025 14:58:55 +0000

This is Part 5 of my 7-part series on business literacy for DevRel. Start with Part 1 if you missed it.

We've covered sales, marketing, and finance. But there's one group we haven't talked about yet - and they might be your most valuable partnership in the entire company: Product.

Not because product managers are inherently better than anyone else (though the good ones are pretty great). But because strategic product leaders sit at the intersection of everything. They see the business from a unique vantage point that can be incredibly valuable to DevRel.

A good product partner is worth their weight in gold. They're your early warning system, your business intelligence source, and your reality check all rolled into one.

What Product Actually Does

At the most basic level, product management is about figuring out what to build, why to build it, and making sure it actually gets built.

But that simple description hides a ton of complexity:

Product managers (PMs) are responsible for:

Deciding what features/capabilities to prioritize
Understanding user needs and market opportunities
Working with engineering to build the right things
Collaborating with go-to-market teams (sales, marketing) to position and launch features
Measuring whether what they built is actually working
Saying "no" to a lot of things (this is actually most of the job)

Product sits at the center of a bunch of competing pressures:

Sales wants features that will close deals
Marketing wants things that will generate buzz
Engineering wants to build technically interesting things
Finance wants efficient use of resources
Customers want their specific problems solved
Executives want the product to support business strategy

The PM's job is to synthesize all of this and make decisions about what the product should become.

Meet the Product Team: Roles You Need to Know

Chief Product Officer (CPO) / VP of Product: Sets the overall product vision and strategy. They're thinking about where the product needs to be in 2-3 years, not just next quarter. They usually report directly to the CEO.

Director of Product / Senior PM: Usually owns a major product area or domain. They're thinking strategically about their area while managing other PMs.

Product Manager (PM): Owns a specific product or feature area. They work day-to-day with engineering teams to ship features. This is who you'll probably work with most.

Technical Product Manager (TPM): Like a PM but more technical. Often owns platform, API, or developer-facing products. If you work at a developer tools company, TPMs are your people.

Product Marketing Manager (PMM): We talked about these folks in the marketing post, but they sit between product and marketing. They take what product builds and figure out how to position and message it.

Product Operations / Product Ops: Help PMs be more effective by managing tools, processes, and data. They're the behind-the-scenes folks making product teams run smoothly.

How Product Thinks About the World

Product managers live in a few key frameworks. Understanding these helps you speak their language:

The Product Roadmap

This is the plan for what gets built when. Roadmaps are usually organized by quarters or releases, and they're always wrong (because priorities change).

Roadmaps are political documents as much as planning documents. What makes it onto the roadmap and what doesn't tells you a lot about what the business values.

User Stories and Jobs to Be Done

PMs think about user needs in terms of "user stories" (as a [role], I want to [do something] so that [outcome]) or "jobs to be done" (when [situation], I want to [motivation], so I can [expected outcome]).

This is useful for DevRel because it's how you can frame developer feedback. Instead of "developers want feature X," try "when developers are trying to debug production issues, they want observability into what the system is doing, so they can identify root causes faster."

Prioritization Frameworks

PMs are always prioritizing. Common frameworks:

RICE: Reach, Impact, Confidence, Effort
Value vs. Effort: Classic 2x2 matrix
Kano Model: Basic needs vs. performance needs vs. delighters

Understanding how your product team prioritizes helps you frame feedback effectively.

Success Metrics

Good PMs are all about metrics:

Activation: Did users do the key action that shows they "get" the product?
Engagement: Are users coming back? How often?
Retention: Are users sticking around over time?
Feature adoption: Are users actually using the new thing we built?
Time to value: How quickly can users get value from the product?

Notice how some of these overlap with PLG metrics? That's not an accident.

Why Product Matters So Much to DevRel

Here's where it gets interesting. Product is uniquely positioned to give you intelligence about the business that you can't get anywhere else.

They See Across Functions

A strategic PM talks to:

Sales (what's blocking deals?)
Marketing (what's resonating in the market?)
Customer success (what are customers struggling with?)
Engineering (what's technically feasible?)
Finance (what can we afford?)
Executives (what's the strategy?)

They're synthesizing information from everywhere. If you have a good relationship with product leadership, they can give you context on what's really happening across the business that you'd never get from any single function.

They Know What's Coming

Product knows what's on the roadmap before it's public. This is incredibly valuable for DevRel:

You can prep content in advance
You can understand strategic direction
You can give early feedback on how developers will react
You can plan your activities around major releases

They Need What You Have

As a devrel, you're sitting on a goldmine of information that product desperately needs:

What developers are actually struggling with
What features developers are asking for (and why)
How developers talk about problems in their own language
What the competition is doing (you see it at conferences and in communities)
Which parts of your product confuse people

This creates natural reciprocity. You help them, they help you.

They Fight Similar Battles

Good PMs face the same challenge you do: they have to translate between technical reality and business objectives. They have to advocate for what's right while acknowledging business constraints.

You're natural allies.

The Product/DevRel Partnership

When done right, the Product/DevRel partnership is incredibly powerful:

DevRel provides Product:

Raw, unfiltered user feedback from communities
Market intelligence from conferences and events
Early signals about what developers care about
Reality checks on how features will be received
Developer perspective on product decisions

Product provides DevRel:

Early access to roadmap and upcoming features
Context on why decisions were made
Understanding of strategic priorities
Cross-functional intelligence
Air cover when you need to push back on requests

The Feedback Loop

One of DevRel's most valuable contributions is being a structured feedback channel from developers to product. But this only works if you do it right:

Bad feedback: "Developers want dark mode"

Good feedback: "I'm seeing consistent requests for dark mode from developers who code at night. The specific pain point is eye strain during long coding sessions. This came up in 15+ community conversations last month, and competitors X and Y both shipped this recently."

Bad feedback: "This new feature is confusing"

Good feedback: "In office hours, 3 out of 5 developers got stuck at the same step in the new onboarding flow. The confusion is around [specific thing]. Here's a recording of where they got stuck."

Strategic product leaders eat this stuff up because it's specific, actionable, and helps them make better decisions.

Not All PMs Are Created Equal

That said, not every PM is strategic. Some are just feature factories, cranking out roadmap items without understanding the broader context.

A comment that inspired this post mentioned this perfectly: not every product leader can "get their heads out of the sands of features/roadmap, nor are they all observant of business value themselves."

Look for PMs who:

Understand the business model, not just the feature list
Can articulate why something is being built, not just what
Talk to customers and users regularly
Have opinions about strategy, not just execution
Are curious about the market and competition
Actually understand the technical implications of their decisions

These are the ones worth partnering closely with. The others... well, you can still work with them, but don't expect the strategic partnership.

How Product Decisions Happen (And Where You Fit In)

Understanding how product decisions get made helps you influence them:

Input gathering: PMs collect input from sales, customers, community, market research, executives, etc.

Prioritization: PMs use frameworks to decide what's most important

Roadmap planning: Decisions get formalized into "we're building X in Q2"

Execution: Engineering builds it

Launch: Product goes to market with help from marketing, sales, and (hopefully) DevRel

Measurement: Did it work?

DevRel can influence at almost every stage:

Input: Share developer feedback
Prioritization: Provide market context
Roadmap: React to plans, suggest adjustments
Execution: Give technical feedback during development
Launch: Create content, drive awareness
Measurement: Share qualitative feedback on how it's landing

But you have to be in the conversation to have influence. Which means building relationships.

The DevRel Seat at the Product Table

Some DevRel teams are deeply integrated with product. Others are completely disconnected. If you're in the latter camp, here's how to change that:

Start small: Ask to sit in on a product planning meeting as an observer
Provide value first: Share useful feedback before asking for anything
Speak their language: Frame things in terms of user problems and business impact
Be consistent: Show up regularly with valuable input
Don't be precious: Accept that you won't always get what you want
Understand constraints: Product is making trade-offs; understand what they are

Regular Touchpoints That Work

Consider establishing:

Monthly sync with product leadership: Share what you're hearing, get context on roadmap
Feedback review sessions: Present synthesized developer feedback quarterly
Early access to betas: Get hands-on with features before launch
Launch planning collaboration: Work together on go-to-market for major features
Roadmap input sessions: Provide perspective on upcoming priorities

Product Gives You Business Intelligence

Here's something nobody talks about: a good product partner can be your best source of business intelligence.

They'll tell you things like:

"Sales is really struggling in the enterprise segment right now"
"We're shifting strategy toward [market] next year"
"The exec team is worried about [competitive threat]"
"Marketing's campaigns aren't converting well"
"There might be budget cuts coming"

Why do they know this? Because they're in all the meetings. They see the cross-functional dynamics. They hear what's really going on.

And if they trust you, they'll share it. This is incredibly valuable for planning your DevRel strategy and seeing what's coming.

Essential Product Terminology

Let me give you the vocabulary:

MVP (Minimum Viable Product): The smallest version of something that delivers value. Often used as an excuse to ship incomplete things, but the concept is sound.

Product-Market Fit: The magical moment when you've built something that a market actually wants. Most products never achieve this.

Feature parity: Having the same features as competitors. Often overvalued by sales, undervalued by product.

Technical debt: The accumulated cost of quick-and-dirty technical decisions. Always more than you think.

Dogfooding: Using your own product internally. Good PMs do this religiously.

Beta / Alpha: Early versions for testing. Alpha is usually internal, beta is usually external but limited.

GA (General Availability): The feature is fully launched and available to everyone.

Sunset / Deprecation: Retiring a feature or product. Always painful, usually necessary.

OKRs (Objectives and Key Results): How many product teams set goals. Objectives are qualitative, key results are measurable.

What This Means For Your Work

Understanding product doesn't mean becoming a PM. It means:

You can provide product with valuable, actionable feedback
You can anticipate what's coming and plan accordingly
You can understand why certain decisions are made (even when you disagree)
You can be a strategic partner instead of just a feedback conduit
You have access to cross-functional intelligence that helps you navigate the business

Product is your window into how the whole business is working - the headwinds, the tailwinds, the tensions, the priorities. Use it.

Finding Your Product Partner

Not sure who to connect with in product? Start here:

Identify the PM who owns your developer-facing products (API, SDK, CLI, etc.)
Reach out with value: "Hey, I'm hearing a lot of feedback about [thing]. Want to chat?"
Be low-maintenance: Respect their time, be organized, come prepared
Look for strategic thinkers: Find the PMs who see the bigger picture
Build the relationship over time: This is a long game

And if you find a great product partner? Hold onto them. They're rare and incredibly valuable.

Next up: we'll talk about Product-Led Growth and how it changes everything about the relationship between product, DevRel, and go-to-market. Spoiler: in PLG companies, product and DevRel become deeply intertwined.

Questions about working with product? War stories about great (or terrible) product partnerships? Let's hear them in the comments!

Previously: Part 4: Finance 101

Next up: Product-Led Growth

Putting It All Together: Speaking Business as a DevRel Professional

Matty Stratton — Tue, 28 Oct 2025 18:54:34 +0000

This is Part 7 of my 7-part series on business literacy for DevRel. Start with Part 1 if you missed it.

We've covered a lot of ground in this series. Sales pipelines and forecast accuracy. Marketing funnels and MQLs. P&Ls and CapEx vs OpEx. Product-Led Growth and how it changes the game for developer tools companies. If your brain feels a little full right now, that's normal. This is a lot of new vocabulary and new ways of thinking.

But you now have the foundation. You understand the basics of how the key parts of your business operate, what they care about, and what language they speak. You understand how modern go-to-market models work and where DevRel fits in.

Now let's talk about what you actually do with all this knowledge.

Where DevRel Sits in the Business Landscape

If you think about your company as an ecosystem, DevRel occupies a unique position. You're not sales, but you influence deals. You're not marketing, but you create awareness and demand. You're not product, but you deeply understand user needs. You're not support, but you help developers be successful.

I often say "DevRel rhymes with lots of different parts of the business"

You're the bridge. You're the translator. You're uniquely positioned to connect the technical world of developers with the commercial world of business.

And that's actually a superpower, not a weakness. The question is, are you using it?

The DevRel Translation Guide

Let's get practical. Here's how you translate common DevRel activities into language that resonates with different stakeholders:

Example 1: Conference Talks

What you do: Give a technical talk at a conference about solving a real problem using your technology

How different stakeholders hear it:

To Sales: "This is TOFU content that builds awareness and credibility in a target market. Prospects who attend or watch this talk are more likely to trust us when we're in their consideration set."

To Marketing: "This creates thought leadership content at the top of the funnel, reaching developers in our target persona. The recorded talk becomes an asset we can promote for months."

To Finance: "For a $5K investment (travel, event costs), we reach 200 in-person developers and potentially 10K+ via the recorded talk. Compared to paid advertising costs of $50-100 per qualified lead, this is highly efficient awareness generation."

To Your CEO: "This positions our company as a technical leader in [space], increases brand awareness with our target audience, and creates trust that accelerates the sales cycle."

Example 2: Office Hours Program

What you do: Run weekly office hours where developers can get help with technical challenges

How different stakeholders hear it:

To Sales: "This is MOFU activity that helps prospects overcome technical blockers that might prevent deals from closing. Sales can invite prospects to office hours as a value-add during the evaluation phase."

To Marketing: "This creates ongoing touchpoints with developers in the consideration phase, moving them down the funnel. It also generates insights about common pain points we can address in our content."

To Finance: "This program costs approximately $X per quarter (staff time) and supports Y developers, reducing the load on our paid support team (saving $Z) while accelerating deal velocity."

To Product: "This is a direct line to user feedback. We're hearing real problems from real users, which informs our product roadmap and helps prioritize features."

Example 3: Documentation Improvements

What you do: Rewrite documentation to make it clearer and more accessible for developers

How different stakeholders hear it:

To Sales: "Better docs reduce technical objections during the sales cycle. When prospects can self-serve and get quick answers, it reduces friction in the buying process."

To Marketing: "Great docs are a conversion tool. When someone is evaluating our product, comprehensive docs signal quality and reduce perceived risk."

To Finance: "Improved docs reduce support ticket volume by X%, which translates to $Y in reduced support costs. It also improves trial-to-paid conversion, impacting revenue."

To Product: "Quality documentation improves user experience and product adoption, which reduces churn and improves LTV."

Example 4: Community Building

What you do: Build and nurture an active community where developers help each other

How different stakeholders hear it:

To Sales: "An active community is social proof. When prospects see thousands of engaged developers, it reduces perceived risk and speeds up the sales cycle."

To Marketing: "Community creates network effects that reduce our CAC over time. Developers in the community become advocates who bring in new users organically."

To Finance: "The community provides peer-to-peer support that would otherwise require paid support resources. If 70% of questions are answered by community members, that's saving us $X in support costs annually."

To Your CEO: "Our community is a competitive moat. It's relationship capital that competitors can't easily replicate, and it creates switching costs that improve retention."

Having Better Conversations With Stakeholders

The key to using your business literacy isn't just knowing the vocabulary. It's understanding what different stakeholders care about and framing your work in those terms.

With Sales

Talk about: pipeline influence, deal velocity, technical credibility, competitive positioning, removing buying blockers

Example: "I'd like to pilot a program where DevRel joins strategic deals for technical deep dives. Based on what I've seen, this could reduce time-to-close by 2-3 weeks by addressing technical concerns earlier in the cycle. Want to try this with three opportunities next quarter and measure the impact?"

With Marketing

Talk about: funnel stages, campaign support, content performance, lead quality, brand awareness

Example: "I noticed the marketing team is planning a campaign around [topic]. DevRel can support this by creating technical deep-dive content that serves the MOFU stage. We'll own the technical accuracy and authentic voice, which should improve conversion from awareness to consideration."

With Finance

Talk about: budget allocation, ROI, cost efficiency, strategic investment, measurable outcomes

Example: "I'm requesting $30K for three conference sponsorships next quarter. Based on last year's data, this typically generates 150 qualified conversations, with 10-15 entering our pipeline. At our average deal size, if just two deals close, that's $200K in revenue from a $30K investment."

With Executives

Talk about: business objectives, market position, competitive advantage, growth levers, strategic priorities

Example: "Our community strategy supports three key company objectives: it reduces CAC through organic growth, it creates customer stickiness that improves retention, and it provides product insights that help us build what developers actually need. This quarter we'll focus on [specific initiative] to accelerate growth in [target segment]."

Common Pitfalls to Avoid

As you develop your business literacy and start speaking this language, watch out for these traps:

Over-rotating to business speak: Don't become so focused on business outcomes that you lose sight of serving developers. If developers don't genuinely benefit from what you're doing, it's not sustainable DevRel work.

Claiming direct attribution when it's influence: Be honest about what you can and can't directly attribute to DevRel. Influence is still valuable, but don't claim you "closed the deal" when you participated in one discovery call.

Using business literacy to justify work that doesn't serve developers: Business literacy should help you advocate for developer-serving work, not rationalize doing things that only benefit the business.

Becoming a "mini-marketer": You're not marketing. You can use marketing language to communicate, but don't let that change what you actually do or how you do it.

Overpromising to get budget: It's tempting to make big claims to secure resources, but if you can't deliver, you damage your credibility for future asks.

Business Literacy ≠ Selling Out

Let's address this head-on one more time: learning to speak business language doesn't mean you're selling out.

You're still serving developers first. You're still advocating for their needs. You're still building authentic relationships and creating genuine value.

What you're doing is making sure the people who control resources understand why that work matters to the business. You're ensuring that the work you believe in gets funded. You're protecting your team and your programs by being able to articulate their value.

The alternative - being "too pure" to speak business language - often ends with your team getting cut and your programs getting defunded. And then who does that serve?

Some of the most authentic, developer-focused DevRel professionals I know are also fluent in business language. They use that fluency to advocate more effectively for developers. They're bilingual, not sell-outs.

Now You're Ready for the Next Level

With the foundation of business literacy, you can now tackle the more advanced challenges:

Developing meaningful DevRel metrics that map to business objectives
Building attribution models that give you credit for influence without overclaiming
Creating business cases for new DevRel initiatives
Demonstrating ROI in ways that are credible to finance teams
Advocating for budget and headcount using compelling business logic

These advanced topics deserve their own deep dives (and there are good resources out there on these topics). But without the foundation we've built in this series, those advanced topics don't make sense. You'd be trying to build a measurement framework without understanding what matters to the business. You'd be creating attribution models without understanding how marketing thinks about attribution. You'd be requesting budget without speaking the language of finance.

Work as Imagined vs Work as Done

There's this concept from safety science: "work as imagined" vs "work as done." Work as imagined is how things are supposed to work in theory. Work as done is the messy reality of how things actually work.

A lot of the DevRel discourse happens in "work as imagined" territory. In theory, we should just be able to show our impact through beautiful metrics. In theory, executives should just trust that DevRel is valuable. In theory, we shouldn't have to speak business language because our work should speak for itself.

But that's not work as done. In reality, we operate in companies with finite resources, competing priorities, and stakeholders who think in different frameworks. In reality, business literacy is table stakes for being taken seriously.

Focus on work as done. Learn the language. Have the conversations. Bridge the gaps.

Your Network Is Vast: DevRel as BizDev

Here's one more thing to consider: your network is one of your most valuable assets, both personally and for your company.

You know people at other companies. You have relationships in the developer community. You're connected to potential partners, customers, and advocates.

This makes you valuable in ways that go beyond traditional DevRel metrics. Want to explore a partnership with another company? You probably know someone there. Need to get into a strategic account? Your network can probably help with an introduction.

I'm not saying you should become a business development person. But I am saying that leveraging your network thoughtfully (and with appropriate boundaries) is another way DevRel creates business value.

Show Value But Set Boundaries

As you become more business-literate and better at articulating your value, you'll likely get more requests. Sales will want you on more calls. Marketing will want you to support more campaigns. Executives will want you to do more things that "require less imagination to show value."

This is where boundaries matter:

"I'll call in a favor from my network - once."
"I'll share company news on social media, but in my own words and only if I genuinely think it's interesting."
"I'll meet with prospects for technical discussions, but I won't do sales demos or pitch."
"I'll write about new features after I've used them, and I'll share my honest impression."

Your boundaries might be different. The key is being intentional about what you will and won't do. And remember: boundaries can be flexible and situational. But they should be conscious choices, not things that happen to you.

Final Thoughts

Business literacy is power. It's the power to advocate effectively. The power to protect your team. The power to fund the programs that serve developers. The power to have a seat at the strategic table.

You don't need to become a finance expert or a sales leader or a marketing strategist. But you need to understand enough about how these functions work to translate between their world and yours.

The cognitive dissonance a lot of DevRel folks feel - between "DevRel is good and pure and unsullied by capitalism" and "the company has to generate revenue and DevRel is part of that" - that dissonance is real. But it's also false tension.

You can serve developers AND contribute to business success. You can be authentic AND speak business language. You can maintain your integrity AND work effectively with sales and marketing.

In fact, you kind of have to. Because if you're not connected in a measurable way to either building the thing or selling the thing, it's going to be really hard to stick around for the encore.

Get over yourself. Learn the language. Bridge the gap. And go be awesome...together with the rest of your company.

Resources for Continued Learning

Want to deepen your business literacy? Here are some places to start:

Take a basic business finance course (lots of free options on Coursera, edX)
Read your company's financial statements (if public) to understand how they talk about the business
Ask to shadow someone in sales/marketing/finance for a day
Read business books focused on SaaS/tech companies (I recommend "Crossing the Chasm" by Geoffrey Moore as a starting point)
Follow finance and business leaders on social media to absorb how they think

And most importantly: ask questions. The folks in sales, marketing, and finance usually love explaining their world to people who are genuinely curious.

Jeremy Meiss has written some great next step posts for you to consider:

What's Next For You?

So here's my question for you: what's one thing you're going to do differently based on this series?

Maybe you're going to schedule coffee with someone from your sales team to understand their pipeline better. Maybe you're going to reframe how you talk about your work in your next stakeholder meeting. Maybe you're going to actually read through your company's budget process documentation (I know, thrilling stuff).

Whatever it is, don't let this just be information you consumed. Make it actionable.

If you want to continue this conversation, I'm always available on Mastodon, LinkedIn, and BlueSky. Share your experiences, your questions, your disagreements. This is work in progress for all of us.

Thanks for sticking with this series. Now go forth and speak business fluently while never forgetting who you're really here to serve: the developers.

Build the thing. Sell the thing. But most importantly, make developers' lives better. That's the job.

Product-Led Growth and What It Means for DevRel

Matty Stratton — Tue, 28 Oct 2025 18:54:05 +0000

This is Part 5 of my 7-part series on business literacy for DevRel. Start with Part 1 if you missed it.

We've covered sales, marketing, and finance - the three core business functions you need to understand. But there's one more concept that ties everything together, and it's especially critical if you work at a developer tools company or any company with a self-serve product: Product-Led Growth (PLG).

If you've been around tech for the past five years, you've definitely heard this term thrown around. And if you're like most people, you might have a vague sense that it means "the product sells itself" but aren't totally clear on what that actually means or how DevRel fits in.

This is the missing piece. Because understanding PLG fundamentally changes how you think about the relationship between DevRel, sales, marketing, and product.

What Product-Led Growth Actually Means

Product-Led Growth is a go-to-market strategy where the product itself is the primary driver of customer acquisition, expansion, and retention. Instead of relying heavily on sales teams to convince people to buy, the product experience convinces them.

Think about how you adopted tools like Slack, Figma, or GitHub. You probably didn't talk to a sales rep first. You or someone on your team just started using it. The product was good enough that you kept using it. Eventually you needed more features or more seats, so you paid for it. Maybe your whole company ended up adopting it, even though it started with one team.

That's PLG in action.

In a traditional sales-led model, the sequence is: Sales → Trial → Adoption → Payment

In a product-led model, it's: Product → Adoption → Payment → Sales (maybe)

Why PLG Matters (Especially For Developer Tools)

Developers hate being sold to. You know this. I know this. We all know this.

Developers want to:

Try things before buying
Evaluate on their own terms, not on a sales rep's calendar
Get hands-on experience without talking to anyone
Make technical decisions based on actual experience, not marketing claims

This is why so many successful developer tools companies use PLG. It aligns with how developers actually want to evaluate and adopt tools.

Companies like Stripe, Twilio, HashiCorp, MongoDB, and countless others have proven that PLG works incredibly well for developer products. And it's a model where DevRel can be absolutely critical to success.

The PLG Funnel (It's Different)

In a traditional sales-led company, the funnel looks like:

Awareness → Lead → MQL → SQL → Opportunity → Customer

In a PLG company, it's more like:

Awareness → Sign-up → Activation → Active Usage → Power User → Paying Customer → Expansion

Let's break down these stages:

Sign-up: User creates an account. This is easy - usually just an email address. The barrier is intentionally low.

Activation: User completes the critical actions that demonstrate they "get" the product. For GitHub, this might be creating their first repository. For Stripe, it's making a test API call. This is often called the "aha moment."

Active Usage: User is regularly using the product and getting value from it. They've integrated it into their workflow.

Power User: User is deeply engaged, using advanced features, bringing in teammates. They're getting significant value.

Paying Customer: User hits some limit (features, usage, seats) and converts to paid. Critically, this often happens without ever talking to sales.

Expansion: Customer uses more features, adds more users, upgrades tiers. Again, often self-serve.

Where DevRel Fits in PLG

Here's where it gets interesting for you: DevRel is absolutely critical at almost every stage of the PLG funnel.

Awareness Stage

This is classic DevRel territory. Your conference talks, blog posts, podcasts, social media presence - all of this drives awareness. The difference in PLG is that you're not trying to generate leads for sales; you're trying to get people to sign up and try the product.

Your call-to-action isn't "talk to sales" - it's "try it yourself right now."

Sign-up to Activation (The Critical Gap)

This is where a LOT of PLG companies struggle. People sign up, poke around, don't understand the value, and leave. The activation rate might be 20-30%.

DevRel can massively impact this through:

Great documentation that gets people to their "aha moment" fast
Quick-start guides and tutorials
Sample projects and templates
Video walkthroughs
Office hours where people can get unstuck

You're essentially reducing time-to-value. The faster someone gets value, the more likely they activate.

Active Usage to Power User

Once someone is using the product, DevRel keeps them engaged and helps them go deeper:

Advanced tutorials and use cases
Community where they can learn from peers
Content about best practices and patterns
Events and workshops that teach advanced features

You're helping users get more value from the product, which increases stickiness.

Power User to Paying Customer

This conversion often happens naturally when users hit limits, but DevRel can influence it:

Case studies showing how others use paid features
Content that highlights the value of premium capabilities
Community members sharing their experiences with paid tiers

You're not selling, but you're helping people understand when and why to upgrade.

Paying Customer to Expansion

DevRel helps customers expand their usage:

Training on enterprise features
Best practices for scaling
Community connections that show what's possible
Advocacy that keeps them engaged and excited

PLG Metrics That Matter to DevRel

In a PLG company, the metrics you care about shift a bit:

Sign-ups: How many people are creating accounts? Your awareness activities drive this.

Activation Rate: What percentage of sign-ups reach the "aha moment"? Your onboarding content affects this.

Time to Value: How quickly do users get value? Your documentation and tutorials impact this.

Product Qualified Leads (PQLs): Users who have demonstrated high engagement and fit the profile for conversion to paid. This is PLG's version of an MQL.

Free-to-Paid Conversion Rate: What percentage of free users convert to paid? Your content about premium features influences this.

Net Revenue Retention (NRR): Are existing customers expanding their usage? Your community and advanced content affect this.

Community Engagement: Active community members are more likely to convert and expand. Your community building directly impacts this.

The beautiful thing about PLG is that DevRel activities have clearer, more direct metrics. You can often see: this piece of content led to X sign-ups, Y of whom activated, and Z of whom converted to paid.

The Sales-Assist Model (PLG + Sales)

Here's where it gets nuanced: most PLG companies still have sales teams. They just work differently.

In a PLG company, sales typically does one of two things:

1. Sales-Assist for Expansion: Free users become paid users on their own, but when they want to expand significantly (more seats, enterprise features), sales gets involved to help close bigger deals.

2. Land-and-Expand: Sales might not touch small deals at all, but once an account reaches a certain size or shows certain behaviors, sales reaches out to help them expand.

This is sometimes called "Product-Led Sales" - sales that's triggered by product usage signals, not traditional lead gen.

What This Means for DevRel in a PLG Company

If you work at a PLG company (or your company is moving toward PLG), your role is even more critical:

You're a growth driver, not just brand building: In traditional sales-led companies, DevRel is often seen as brand/awareness. In PLG companies, DevRel directly impacts the metrics that matter - sign-ups, activation, and conversion.

Documentation and onboarding are strategic: These aren't afterthoughts; they're core to the business model. Investing in great docs isn't nice-to-have; it's mission-critical.

Community is a growth engine: Active community members are more likely to convert, expand, and bring in new users. Community building isn't just feel-good work; it's a competitive advantage.

Your content directly impacts the funnel: That tutorial you wrote? It's not just TOFU content - it might be what gets someone from sign-up to activation. That's directly impacting conversion.

You work more closely with product: In PLG, the line between product and go-to-market blurs. You need to work closely with product teams to ensure the product experience supports the PLG motion.

PLG Changes the Business Literacy Conversation

Remember all that stuff we talked about in earlier posts about explaining your value? In PLG companies, it's often easier because the connection is more direct:

To Sales: "DevRel is filling the top of the funnel and helping users get to PQL status faster, which gives you higher-quality accounts to work with."

To Marketing: "DevRel is driving sign-ups and activation, which are our primary growth metrics. We're also reducing time-to-value, which improves our conversion rates."

To Finance: "DevRel investments directly correlate with sign-up growth and activation improvements. Here's the data showing how tutorial usage maps to activation rate."

To Product: "DevRel is hearing user feedback at scale and seeing where people get stuck in the onboarding flow. This intelligence helps you improve the product experience."

The Dark Side of PLG (That Nobody Talks About)

PLG isn't magic. It has challenges:

The Free User Problem: In PLG, you have tons of free users who may never convert. Supporting them costs money. DevRel needs to help free users get enough value to convert, without providing so much support that it's not sustainable.

Activation is Hard: Most people who sign up for a product never activate. This can be demoralizing if your sign-up numbers look great but activation is terrible. DevRel can help, but can't fix a fundamentally confusing product.

Self-Serve Isn't Always Better: Some products are complex enough that they need human help. Forcing a pure PLG motion when the product isn't ready for it doesn't work.

Support Burden: When you have thousands of free users, the support and community management burden can be enormous. DevRel often ends up carrying this, and it needs resources.

Traditional Sales-Led vs PLG: Not Either/Or

Here's the thing: most companies aren't purely PLG or purely sales-led. They're hybrid.

You might have a free tier and self-serve paid tier (PLG), but also have a sales team for enterprise deals (sales-led). This is really common.

Or you might start PLG for small teams, but sales gets involved when an account grows to a certain size.

Understanding both models - and how they work together - makes you more effective. You can support the PLG motion for individual developers and small teams while also supporting sales when they're working with larger accounts.

How to Think About PLG as a DevRel Professional

If your company is PLG or moving toward PLG:

Embrace it: PLG aligns really well with DevRel values. Letting the product speak for itself, empowering users to evaluate on their own terms, removing barriers - this is all good stuff.

Get closer to product data: Work with your product team to understand metrics like activation rate, time-to-value, and conversion funnel. Ask for access to dashboards. Understand what users are actually doing in the product.

Focus on onboarding: The period between sign-up and activation is critical. Invest heavily in making this smooth.

Build feedback loops: PLG gives you tons of data about what's working and what's not. Use it to improve docs, content, and even influence product decisions.

Think about the full journey: Don't just focus on awareness. Think about how your work impacts every stage from sign-up to expansion.

The Bottom Line

Product-Led Growth isn't a replacement for sales or marketing. It's a different go-to-market motion that changes how everything works, including DevRel.

In PLG companies, DevRel isn't just "nice to have" - it's essential infrastructure. Great docs aren't a nice-to-have; they're what makes the PLG motion work. Active community isn't just engagement; it's what drives retention and expansion.

Understanding PLG helps you:

Position your work more strategically
Focus on the right activities
Measure impact more directly
Collaborate better with product, marketing, and sales
Advocate for resources more effectively

If you're at a PLG company and you haven't been thinking about your work through this lens, start now. And if you're at a traditional sales-led company but serve developers, consider whether some PLG principles could make your work more effective.

Either way, understanding PLG is part of business literacy for modern DevRel. Add it to your toolkit.

Want to Go Deeper?

Some resources on PLG:

Product-Led Growth by Wes Bush (book)
OpenView's PLG resources (they coined the term)
Is Product Led Growth the DevOps of DevRel? (Daniel Bryant's talk at DevRelCon 2022)

Next up, we're bringing it all together in the final post - how to actually use this business literacy in your day-to-day DevRel work. How to translate what you do into language that resonates with stakeholders. How to speak business without losing your soul.

As always, comments are open below if you want to discuss, debate, or share your PLG experiences.

Previously: Part 5: Product 101

Next up: Wrapping it all up

Finance 101: Budgets, P&Ls, and the Language of Money

Matty Stratton — Tue, 28 Oct 2025 18:53:35 +0000

This is Part 4 of my 7-part series on business literacy for DevRel. Start with Part 1 if you missed it.

Time for everyone's favorite topic: money. Specifically, how companies think about money, track money, and make decisions about money.

If your eyes are already glazing over, I get it. When I was first a sysadmin, I thought finance was just "the people who make it difficult to buy the things I need." As a DevRel professional, you might think finance is "the people who keep asking me to justify my conference budget."

However, understanding finance might be the single most important business skill you develop. Because at the end of the day, no matter how amazing your DevRel work is, if you can't speak the language of money, you're going to struggle to advocate for your team, defend your budget, and demonstrate your value.

What Finance Actually Does

Finance manages the company's money. All of it. They track where money comes from (revenue) and where it goes (expenses). They plan for the future (budgeting). They make sure the company stays financially healthy. They report to investors or the board on the company's financial performance.

But finance isn't just about counting beans (though there is some bean counting). Strategic finance helps the company make smart decisions about where to invest resources. They're asking questions like:

"Should we hire more sales people or invest in marketing?"
"Can we afford to expand to a new market?"
"Which initiatives are giving us the best return on investment?"

For a company to survive, revenue needs to exceed expenses. Finance's job is to make sure that happens (or at least make sure the company is on a path to make it happen, because early-stage companies often operate at a loss while they're growing).

Meet the Finance Team

CFO (Chief Financial Officer): The top finance executive. They own the overall financial strategy and health of the company. They report to the CEO and often the board. When big financial decisions get made, the CFO is in the room.

VP Finance / Controller: Usually manages day-to-day finance operations. They might oversee accounting, financial planning, and the finance team members.

FP&A (Financial Planning & Analysis): These folks do the budgeting, forecasting, and financial modeling. When you submit your budget request, FP&A is reviewing it. When the company is trying to figure out if they can afford something, FP&A is running the numbers.

Accounting Team: They track and record all financial transactions, make sure bills get paid, ensure compliance with financial regulations, and generally keep the books in order.

How DevRel Interacts With Finance: Mostly through budget requests, expense management, and ROI discussions. Unless your company is really small, you probably won't interact with the CFO regularly, but you might work with FP&A on planning and budgets.

Understanding the P&L (Profit and Loss Statement)

A P&L is basically a report card for how the company is doing financially. Here's the simple version:

Revenue (money coming in)

minus Expenses (money going out)

equals Profit or Loss

If revenue is bigger than expenses, you have profit. If expenses are bigger than revenue, you have a loss.

Now let's break down the expense side, because that's where you live:

Cost of Goods Sold (COGS): The direct costs of delivering your product or service. For SaaS companies, this is things like cloud infrastructure, hosting costs, and support. Generally, you want this to be relatively low compared to revenue.

Operating Expenses (OpEx): Everything else it costs to run the business:

Sales & Marketing: Sales team salaries, marketing programs, advertising, events, tools
Research & Development (R&D): Engineering team, product team, technical infrastructure
General & Administrative (G&A): Finance, HR, legal, executive team, office costs

DevRel usually shows up in Sales & Marketing or sometimes in R&D, depending on where you report. Either way, you're an operating expense.

Cost Center vs Profit Center

Most DevRel teams are cost centers - meaning you cost money but don't directly generate revenue. Sales is usually a profit center because they directly bring in revenue (though they also cost money in salaries and commissions).

Being a cost center isn't bad! Most of the company is cost centers. But it does mean that during budget cuts, cost centers are scrutinized more heavily. This is why being able to articulate your value in business terms matters so much.

Budgeting: The Annual Stress Fest

Budgeting is the process of planning how much money each part of the company gets to spend. Most companies do annual budgets, often with quarterly reviews and adjustments.

The Budgeting Cycle usually goes something like this:

Leadership sets revenue targets and high-level spending parameters
Each department builds a budget showing what they need to spend to hit their goals
Finance reviews all the requests (which always add up to more than the company can afford)
Negotiation happens. Priorities get set. Cuts get made.
Final budget gets approved
Everyone complains it's not enough (it never is)
Throughout the year, actual spending gets tracked against the budget

Top-Down vs Bottom-Up Budgeting:

Top-down: Leadership says "Sales & Marketing gets $5M" and then that team figures out how to allocate it
Bottom-up: Each team builds their ideal budget and submits it up the chain

Most companies do some combination. You might be told "DevRel has a budget of $X" or you might be asked "What do you need for next year?"

Building a DevRel Budget

Your budget probably includes:

Headcount: Salaries and benefits for your team (usually your biggest expense by far)
Programs: Events, sponsorships, community programs, swag
Tools: Software subscriptions, community platforms, content creation tools
Travel: Flights, hotels, meals for conferences and events
Content Production: Video production, freelance writers, design services

When you build a budget, you need to:

Tie it to goals: "We need $X to do Y, which will result in Z outcome"
Show your math: "Three conferences at $10K each = $30K"
Prioritize: What's must-have vs nice-to-have
Be realistic: Under-budgeting doesn't help anyone

And here's what nobody tells you: always expect cuts. Budget a little high if you can, knowing you'll probably need to trim. But don't budget ridiculous things you don't actually need, because that damages your credibility.

Managing Your Budget Throughout The Year

Once you have a budget, you need to track it. Finance is definitely tracking it, and you should be too. Know at any given time:

How much you've spent
How much you have left
What big expenses are coming
Whether you're on track or over/under budget

If you're going to go over budget, flag it early. Finance hates surprises. If you're going to be way under budget, that's also worth flagging - sometimes you can reallocate or carry forward savings.

Essential Finance Terminology

CapEx vs OpEx: This is a big one.

CapEx (Capital Expenditure): Large purchases that are assets - things like equipment, buildings, major infrastructure. These get depreciated over time.
OpEx (Operating Expenditure): Day-to-day operating costs like salaries, subscriptions, travel, programs.

Most DevRel spending is OpEx. Why does this matter? Because CapEx and OpEx are treated differently for accounting and tax purposes, and companies often have different budgets for each.

If you want to buy a $50K piece of video production equipment, that's CapEx and comes from a different bucket than your $50K event sponsorship (OpEx). Understanding this helps you navigate budget conversations.

EBITDA: Earnings Before Interest, Taxes, Depreciation, and Amortization. This is a measure of operational profitability. Basically, it's trying to show how much cash the core business operations are generating.

Why should you care? Because companies that aren't profitable yet but are showing strong EBITDA growth are demonstrating they're on a path to profitability. This affects investment decisions and budget allocations.

Burn Rate: How quickly a company is spending money. Especially relevant for startups. If you're spending $1M/month and bringing in $500K/month, your burn rate is $500K/month.

Runway: How long the company can operate at current burn rate before running out of money. If you have $6M in the bank and a burn rate of $500K/month, you have 12 months of runway.

Why this matters to you: when runway gets short, budget cuts happen. Understanding runway gives you early warning signals.

CAC (Customer Acquisition Cost): The total cost to acquire a new customer. Add up all your Sales & Marketing spend and divide by number of new customers.

LTV (Lifetime Value): The total revenue you expect from a customer over their entire relationship with you.

LTV:CAC Ratio: This is super important. If it costs you $10,000 to acquire a customer (CAC) and they generate $30,000 in revenue over their lifetime (LTV), your ratio is 3:1.

Generally, you want this ratio to be 3:1 or better. Lower than 3:1 and you're spending too much on acquisition. Higher than 3:1 and you might not be spending enough (you could grow faster).

Why DevRel should care: If you can show that DevRel activities reduce CAC or increase LTV, you're speaking directly to metrics that executives obsess about.

Gross Margin: Revenue minus COGS, expressed as a percentage. If you have $100 in revenue and $30 in COGS, your gross margin is 70%. SaaS companies typically have gross margins of 70-80%+.

Why this matters: High gross margin means you have more money available for operating expenses (like DevRel). If margins are shrinking, operating budgets get squeezed.

How DevRel Costs Are Viewed

Let's be honest about how finance sees DevRel:

Headcount is usually your biggest cost. For example, if you have a team of 5 people with an average total compensation (salary + benefits) of $150K, that's $750K/year just in people costs.

Programs are visible and often questioned. That $50K conference sponsorship? Finance is asking "What do we get for that?" The more clearly you can connect program spend to outcomes, the easier budget conversations get.

Tools are usually easier to justify, especially if you can show ROI. A $10K/year community platform that supports 10,000 active developers is pretty easy math.

Travel is often the first thing to get cut in tough times. It's visible, feels expensive, and is easy to reduce. This is why many DevRel budgets got decimated during COVID.

Finance asks questions like:

"What's the return on this investment?"
"Could we get similar outcomes spending less?"
"Is this must-have or nice-to-have?"
"Can we measure the impact?"

The better you can answer these questions, the easier your budget conversations.

The Hard Truth About Budget Cuts

When companies need to reduce costs, they look at what they can cut with the least immediate impact on revenue. Unfortunately, DevRel often falls into this category because:

The connection to revenue isn't always direct or immediate
The impact of cutting DevRel isn't felt right away
It's easy to say "we'll just stop doing conferences for a year"

This is why business literacy matters. If you can articulate DevRel's impact in financial terms - "DevRel activities influenced $2M in pipeline" or "Our community reduces support costs by $X" - you're much better positioned to defend your budget.

Making The Business Case

When you need to advocate for budget, you need to speak finance's language:

Connect to revenue: "This program helps accelerate deals by X days, which means we close Y more deals per quarter"

Show efficiency: "This investment of $X reduces costs in other areas by $Y"

Demonstrate ROI: "Last year we spent $X on this and it resulted in Y measurable outcome worth $Z"

Frame in terms of risk: "Not investing in this creates risk of A, B, C"

Use benchmarks: "Industry standard for companies our size is X, we're at Y"

You don't have to have perfect data for all of this. But you need to be able to tell a credible story using numbers and business logic.

What Finance Wants From You

Honestly? Finance wants you to:

Stay on budget - Don't surprise them
Track your spending - Know your numbers
Justify requests - Explain the why
Show impact - Connect to business outcomes
Be realistic - Don't ask for things you can't defend

Finance people aren't the enemy. They're trying to make sure the company doesn't run out of money. Help them understand why DevRel is a good investment, and they'll often advocate for you.

What This Means For Your Work

Understanding finance doesn't mean becoming an accountant. It means:

You can build and defend a budget
You can have informed conversations with finance leadership
You can speak credibly about financial trade-offs
You can frame DevRel's value in financial terms
You can see early warning signals when budget cuts might be coming

Look, finance isn't the hippest part of business literacy. But it might be the most important. Because at the end of the day, companies are resource-constrained, and the teams that can effectively advocate for resources in financial terms are the ones that thrive.

Questions about budgets? Confused about the difference between CapEx and OpEx? Want to share your budget horror stories? Comments are open.

Previously: Part 3: Marketing 101

Next up: Product 101

Marketing 101: Funnels, Campaigns, and What Marketing Actually Means

Matty Stratton — Tue, 28 Oct 2025 16:09:00 +0000

This is Part 3 of my 7-part series on business literacy for DevRel. Start with Part 1 if you missed it.

Let's talk about the relationship between DevRel and marketing. And if you just shuddered uncontrollably, you're exactly who I'm writing this for.

A lot of people believe really hard that DevRel is not developer marketing, because somehow a lot of folks decided that sales and marketing are icky. But I think that in a lot of ways, DevRel IS developer marketing (or at least a lot of it), and that is NOT BAD.

Before the pitchforks come out, let me state clearly that DevRel serves developers first. That's non-negotiable. But DevRel also exists within companies that need to generate awareness, create demand, and ultimately get developers to evaluate and adopt their products. That's ... marketing. And pretending otherwise doesn't make us more authentic; it just makes us harder to work with.

DevRel Is Not Marketing (But You Still Need To Understand It)

Okay, so maybe you're at a company where DevRel definitely isn't marketing. Maybe you report up through engineering, or you're your own thing, or you roll up to the CEO. That's cool. Lots of different org structures can work.

But regardless of where you sit on the org chart, you work at a company that has a marketing function. And that marketing function has goals, processes, and metrics that affect you whether you like it or not.

Understanding how marketing works doesn't mean you become a marketer. It means you can collaborate effectively, communicate your value in terms they understand, and (critically) advocate for why DevRel's approach is different and valuable.

What Marketing Actually Does

At the highest level, marketing's job is to create awareness of your product, generate demand for it, and nurture prospects until they're ready to talk to sales.

But within that simple description, there's a ton of nuance:

Brand Marketing focuses on building awareness and perception of your company and product. They care about things like "do people know who we are?" and "do they associate us with quality/innovation/trust?"

Demand Generation (or demand gen) is about creating interest in your product and generating leads that sales can work with. They're running campaigns, creating content, managing paid ads, and generally trying to fill the top of the funnel.

Product Marketing sits between product and go-to-market teams. They're figuring out positioning, messaging, competitive analysis, and creating the narrative around your product. They're the ones writing the website copy and creating the slide decks that sales uses.

Content Marketing creates educational content (blogs, guides, videos) to attract and engage potential customers. This is where things get really overlappy with DevRel, and we'll dig into that.

Field Marketing handles events, sponsorships, and local/regional marketing activities. If you've ever coordinated with someone about booth staffing or event sponsorships, you've worked with field marketing.

Meet the Marketing Team: Roles You Need to Know

CMO (Chief Marketing Officer): The top marketing executive. They own the overall marketing strategy and are usually accountable for things like lead generation and pipeline contribution.

VP/Director of Demand Generation: Focused specifically on creating and nurturing leads. They often own the lead generation targets and are judged on how much pipeline they help create.

Product Marketing Manager (PMM): These folks are the bridge between product and go-to-market. They craft positioning, create sales enablement materials, and often lead product launches. If you're launching a new feature, you're probably working with a PMM.

Content Marketing Manager: Owns the content strategy and often manages writers/creators. If DevRel is creating content, you're probably coordinating with this person to avoid duplication and ensure alignment.

Marketing Operations (MOps): The behind-the-scenes folks who manage the marketing tech stack, set up campaigns, and make sure data flows between systems correctly. You might not work with them directly, but they're critical to how marketing measures success.

Where DevRel Sits: This varies wildly by company. Sometimes DevRel reports into marketing. Sometimes engineering. Sometimes it's its own thing. Sometimes it doesn't exist at all and marketing just has "developer marketers." None of these are inherently right or wrong, but each has implications for how you operate.

The Marketing Funnel: How Marketing Thinks About the World

If you've spent any time near marketing, you've heard about "the funnel." And if you're like most DevRel folks, you've probably rolled your eyes at it because it feels overly simplistic and doesn't capture the messy reality of how developers actually discover and adopt tools.

You're not wrong. But the funnel is still a useful mental model for understanding how marketing thinks about the buyer's journey. So let's decode it.

TOFU (Top of Funnel): This is the awareness stage. People don't know about your product, or they're just starting to become aware they have a problem. Content at this stage is broad, educational, and not product-specific. Think: blog posts about industry trends, conference talks about best practices, social media content.

Sound familiar? Yeah. A lot of DevRel activities live here.

MOFU (Middle of Funnel): This is the consideration stage. People know they have a problem and they're evaluating potential solutions. Content here is more specific - webinars, comparison guides, technical deep dives, case studies.

DevRel definitely plays here too, although marketing might own it more directly.

BOFU (Bottom of Funnel): This is the decision stage. People are ready to buy; they just need the final push. Content here includes things like product demos, free trials, detailed pricing information, customer references.

This is mostly sales and marketing territory, but DevRel can still have influence here.

Why The Funnel Matters To You

Even if you think the funnel is reductive (and it kind of is), understanding it helps you:

Communicate with marketing in their language
Explain where your DevRel activities fit in their mental model
Understand why they care about certain metrics at different stages

When marketing says they need "more TOFU content," they're saying they need content that builds awareness. When they talk about "MOFU conversion rates," they're talking about how effectively they're moving people from awareness to consideration.

You don't have to love the funnel. You just need to understand it well enough to translate.

Campaigns: More Than Just "That Thing Marketing Does"

In marketing speak, a campaign is a coordinated set of activities designed to achieve a specific goal. It might be promoting a new product feature, driving registrations for an event, or generating leads in a specific market segment.

A campaign usually includes multiple touchpoints: maybe a blog post, some social media content, a webinar, some paid ads, and an email sequence. All of these pieces work together toward the campaign goal.

Why does this matter to DevRel? Because your content and activities might feed into campaigns, and understanding this helps you:

Coordinate timing (so your blog post goes live when the campaign launches, not two weeks later)
Understand why marketing wants you to promote certain things at certain times
Negotiate for resources ("if this blog post is part of a campaign, can we get some paid promotion behind it?")

Attribution: The Thing Marketing Obsesses Over

Marketing really cares about attribution - basically, which activities led to which outcomes. They want to know: did that blog post result in signups? Did the webinar generate qualified leads? Did the conference sponsorship create pipeline?

There are different attribution models:

First-touch attribution: Credits the first thing that touched a lead (like if they first found you via a blog post)
Last-touch attribution: Credits the last thing before they converted (like filling out a demo request)
Multi-touch attribution: Tries to credit everything that touched them along the way

DevRel activities often show up in attribution models, which is great! But also tricky, because we might be influencing things without directly converting them.

Essential Marketing Terminology

Let me give you the vocabulary you need for marketing conversations:

MQL (Marketing Qualified Lead): A lead that marketing has determined meets certain criteria indicating they might be ready to talk to sales. Usually based on factors like company size, job title, engagement level, and specific actions taken (like requesting a demo).

SQL (Sales Qualified Lead): A lead that sales has accepted and is actively working. Not every MQL becomes an SQL - sales might reject leads that aren't actually a good fit.

Lead Scoring: The system for determining when a lead is "qualified." Might be based on demographics (right company size, right role) and behavior (visited pricing page, downloaded a whitepaper, attended a webinar).

Marketing-Sourced Pipeline: Opportunities where marketing was the first touch. If someone found you via a blog post, then eventually became a customer, that's marketing-sourced.

Marketing-Influenced Pipeline: Opportunities where marketing touched the lead at any point in the journey, even if they weren't the first touch. This number is always bigger than marketing-sourced, and there's often debate about how much credit marketing should get.

Cost Per Lead (CPL): How much it costs to acquire a lead. If you spent $10,000 on a campaign and got 100 leads, your CPL is $100. Marketing uses this to figure out which channels are most efficient.

Conversion Rate: The percentage of people who take a desired action. If 1,000 people visit a landing page and 50 fill out the form, that's a 5% conversion rate.

Key Marketing KPIs (And Why They Matter)

Marketing gets measured on things like:

Lead volume and quality: How many leads are we generating, and are they actually good fits?
MQL to SQL conversion: Are the leads we're calling "qualified" actually accepted by sales?
Pipeline contribution: How much revenue opportunity has marketing created?
Website traffic and engagement: Are people finding and consuming our content?
Content performance: Which pieces of content are actually driving outcomes?

When you understand what marketing is measured on, you can better position DevRel's value. If marketing is struggling to hit lead gen targets, and you can show that DevRel activities drive leads, that's valuable. If marketing is worried about content performance, and your technical content is crushing it, that's worth highlighting.

Where DevRel Overlaps With Marketing (And Where It Doesn't)

Let's address the tension directly: DevRel and marketing both create content, both engage with communities, both attend events. So what's the difference?

The Core Difference: Who You Serve First

DevRel serves developers first, business second. You're creating content because it helps developers, not because it generates leads. You're building community because developers need support, not because you need a lead gen channel.

Marketing serves the business first. They're creating content to generate awareness and demand. They're engaging with communities to create business opportunities.

This doesn't make marketing evil or inauthentic. It just means they have a different primary goal.

Where The Overlap Happens

Both DevRel and marketing might:

Write blog posts (but DevRel's are deeply technical and educational; marketing's might be more promotional)
Run events (but DevRel's are focused on learning and community; marketing's are focused on pipeline generation)
Manage social media (but DevRel is having authentic conversations; marketing is running campaigns)
Create videos (but DevRel's are tutorials and deep dives; marketing's are product demos and testimonials)

You can see how these overlap but aren't the same thing. The key is being clear about your different goals and respecting those differences.

The Tension Is Real (And That's Okay)

Here's where it gets tricky: even though DevRel serves developers first, you still exist within a company that needs business outcomes. So sometimes you'll be asked to do things that feel more marketing-y than you'd like.

My take? "One for them, one for you." Sometimes you might need to create some TOFU content that supports a marketing campaign. I mean, even Iggy Pop had a song in a cruise ship commercial. You can participate in business-focused activities without losing your integrity, as long as you maintain boundaries and keep the majority of your work focused on genuinely serving developers.

How To Collaborate Effectively With Marketing

Be clear about what DevRel is and isn't. Don't let marketing assume DevRel is just "developer marketing." Explain how you're different, why that matters, and how you can complement what they do.

Coordinate on content. Marketing is probably creating content about similar topics. Coordinate so you're not duplicating effort or worse, creating conflicting messages.

Share insights about developers. You're closer to your developer audience than anyone else at the company. That intelligence is gold for marketing - what developers care about, what resonates, what doesn't.

Help them understand developer audiences. Developers don't respond to typical marketing tactics. Help marketing understand this so they can be more effective.

Set boundaries, but be collaborative. You can support marketing goals without becoming a marketing resource. Be clear about what you will and won't do.

The Thing Nobody Wants To Admit

Here's my controversial take that I mentioned at the beginning: a lot of DevRel work IS marketing, and that's not a bad thing.

Creating content that helps developers discover and understand your product? That's marketing.

Building a community that helps developers be successful with your technology? That's marketing.

Speaking at conferences to raise awareness of your company and product? That's marketing.

The difference is in the approach and the authenticity. You're not creating fake urgency or using manipulative tactics. You're genuinely helping developers. But the outcome - increased awareness, consideration, and adoption of your product - that's what marketing is supposed to do too.

The best marketing doesn't feel like marketing. It feels like genuine help. And that's what great DevRel should be.

What This Means For Your Work

Understanding marketing doesn't mean becoming a marketer. It means:

You can communicate with marketing in terms they understand
You can explain where DevRel fits in their mental model (even if it doesn't fit perfectly)
You can collaborate more effectively on shared goals
You can articulate DevRel's unique value proposition vs. traditional marketing

Next up: Finance 101. Because understanding budgets, P&Ls, and why your CFO cares about CapEx vs OpEx might be the most important thing you learn in this series. See you there.

Got thoughts on the DevRel/marketing relationship? Think I'm totally wrong about something? Let's talk about it in the comments.

Previously: Part 2: Sales 101

Next up: Finance 101

Sales 101: What Your Sales Team Does (And How DevRel Fits In)

Matty Stratton — Tue, 28 Oct 2025 13:41:03 +0000

This is Part 2 of my 7-part series on business literacy for DevRel. Start with Part 1 if you missed it.

Let's talk about sales folks. And I need you to stick with me here, because I know what you're thinking.

You've got a mental image, don't you? The stereotypical sales rep ... smooth-talking, coin-operated, willing to promise anything to close a deal. Someone who doesn't understand the product and just wants to hit their quota so they can get their commission check.

Yeah, that person exists. I've met them. You've probably met them too.

But here's the thing: that's not most salespeople. And holding onto that stereotype is hurting you, your DevRel work, and honestly, the developers you're trying to serve.

Get Over Yourself

I'm going to say something that might ruffle some feathers: if you're the kind of DevRel person who gets mad when people say "devrels are people who can't code and just travel around to conferences," but you also make snarky comments about sales reps or marketing professionals, you're kind of a hypocrite.

You can't demand respect for your discipline while simultaneously disrespecting others. Sales and marketing aren't bad people. They're professionals doing a different job than you, with different objectives and different measures of success.

And guess what? The best account executives and sales engineers I've ever worked with knew way more about how our technology products and organizations worked than a lot of the people looking down their noses at them.

What Sales Actually Does

At its core, sales exists to convert prospects into paying customers. That's it. That's the tweet.

But how that happens varies wildly depending on your company's business model, your product, and your market. The person selling enterprise software to Fortune 500 companies has a completely different job than the person selling SMB deals on a self-service platform.

In most B2B tech companies (which is probably where you work if you're reading this), sales tends to be consultative. The best sales reps aren't just trying to push a product; they're trying to understand a prospect's pain and figure out if your product can actually solve it. There's a name for this - it's called The Challenger Sale. And guess what - it is a lot like DevRel.

When done well, sales is helping people. It's connecting a real problem with a real solution. And if you've ever spent time in a painful, legacy system wondering why your company doesn't adopt better tooling, you've experienced the flip side. That's what happens when sales doesn't reach people who need your product.

Meet the Sales Team: Roles and Titles

Let's deconstruct the org chart, because understanding who does what will help you figure out how to work with them.

SDR/BDR (Sales Development Rep / Business Development Rep): These are usually the folks making cold calls and cold emails. They're looking for prospects who might have a need for your product. Their job is to qualify leads and book meetings for the Account Executives. If you're at a conference and someone from your sales team wants to book meetings with prospects while you're in town, they're probably working with an SDR/BDR to set those up.

AE (Account Executive): These are the folks actually running the sales cycle and closing deals. They take the meetings that SDRs book, run demos, handle negotiations, and ultimately get the contract signed. When people say "sales rep," they usually mean the AE.

SA or SE (Solutions Architect / Sales Engineer): This is the technical person on the sales team. They can do deep technical demos, answer the hard technical questions, and generally provide credibility that yes, the product actually does what the AE says it does. Fun fact: I spent two years in this role at Chef, and it's where I learned that I could translate between technical and business folks.

CSM (Customer Success Manager): Technically post-sales, but important to understand. Once a deal closes, the CSM is responsible for making sure the customer is successful with the product. They're trying to prevent churn and identify opportunities for expansion/upsell. If you're doing DevRel activities with existing customers, you're probably working closely with CSMs.

Sales Leadership: Your VP of Sales, Chief Revenue Officer (CRO), or other sales leaders are the folks setting strategy, managing the team, and (critically) forecasting revenue. They're the ones in the room with the CEO and CFO explaining whether the company is going to hit its numbers.

The Sales Pipeline: What It Is and Why It Matters

Here's where things get interesting for DevRel. The sales pipeline is basically a visual representation of all the deals that are currently in progress, organized by what stage they're in.

A typical pipeline looks something like this:

Prospecting/Lead - Identified a potential customer
Qualified - Confirmed they have budget, authority, need, and timeline (sometimes called BANT)
Demo/Discovery - Showing them the product, understanding their needs
Proposal - Sent them a formal proposal with pricing
Negotiation - Working through the contract details
Closed-Won or Closed-Lost - They either became a customer or they didn't

Each opportunity (or "opp") in the pipeline has a value attached to it - how much revenue this deal would bring in if it closes. Sales leaders use this to forecast revenue and figure out if they're going to hit their targets.

Here's the important distinction: the pipeline includes every opportunity a sales rep is working on, regardless of how likely it is to close. The forecast is a subset of the pipeline - it's the opportunities that are likely to close within a specific timeframe (usually a quarter).

New Logo vs. Expansion

You'll hear salespeople talk about "new logo" versus expansion deals. A new logo is a brand new customer - a company that's never given you money before. An expansion (or upsell) is selling more to an existing customer.

Why does this matter to you? Because the marketing and DevRel activities that influence a new logo deal are different from what influences an expansion. A new customer needs to be educated about what you do. An existing customer needs to see new value or new capabilities.

Essential Sales Terminology (That You'll Hear All The Time)

Let me give you the vocabulary you need to not look confused in meetings:

ARR (Annual Recurring Revenue): The yearly value of all your subscription contracts. If you have 100 customers each paying $10,000/year, your ARR is $1 million. This is the number SaaS companies obsess about.

ACV (Annual Contract Value): The average annual value of a customer contract. If your contracts are all different sizes, ACV helps you understand your typical deal size.

TCV (Total Contract Value): The full value of a contract over its entire term. If someone signs a 3-year deal worth $30,000/year, the TCV is $90,000.

Opportunity: A potential deal in the pipeline. When someone says "we have a $250K opp in negotiation," they mean a potential sale worth $250,000 that's currently in the negotiation stage.

Deal Velocity: How quickly deals move through your pipeline. If it takes 90 days on average from first contact to closed deal, that's your deal velocity. Faster is generally better.

Win Rate: The percentage of opportunities that actually close. If your AEs win 25% of the deals they work on, that's a 25% win rate.

Where DevRel Impacts Sales (Whether You Realize It Or Not)

Here's the part where I tell you that you're probably already impacting sales, you just might not know it. And more importantly, you might not be communicating it effectively.

Technical Content Builds Credibility: That blog post you wrote explaining how to solve a tough technical problem? A prospect found it, realized your team knows what they're doing, and it gave them confidence that your product is built by people who understand the problem space. That's pipeline influence.

Community Creates Trust: When a prospect sees that you have an active, helpful community, it reduces perceived risk. "If I get stuck, there are people who can help me" is a powerful buying motivator. That's helping close deals.

Developer Advocates Provide Technical Validation: When you jump on a call with a prospect to answer technical questions (not to sell, just to educate), you're de-risking the purchase. You're helping deals move faster through the pipeline.

Events Accelerate Deals: That workshop you ran where customers and prospects attended? Those conversations and connections can absolutely accelerate deals that are currently in the pipeline. Sales teams love this.

Product Feedback Influences Sales Conversations: When you channel developer feedback back to the product team and features get built, that gives sales new things to talk about. "Based on feedback from our community, we built X" is a powerful sales narrative.

How To Work With Sales (Without Losing Your Soul)

I know some of you are getting nervous right now. "Wait, are you saying DevRel should do sales?"

No. That's not what I'm saying.

What I'm saying is that DevRel and sales can have a mutually beneficial relationship that serves developers and supports the business. Here's how:

Meet with customers and prospects, but not to demo the product. You're offering something special to them - technical deep dives, architecture discussions, real talk about challenges. This is valuable time that you're offering, not a sales pitch. The SA or AE can follow up later about how that conversation connects to using your product. You stay authentic, they get to do their job.

Share competitive intelligence (gently). When you hear at a conference that developers are struggling with Competitor X's approach to something, that's useful for sales to know. You're not being a spy; you're sharing market intelligence.

Help create technical content that educates. Sales is always looking for content to share with prospects. If you've got killer technical content, that's gold for them. Just make sure it's educational, not a thinly veiled sales pitch.

Facilitate connections. Your network is vast. If a sales rep is trying to get into an account and you know someone there, making an introduction can be hugely valuable. But set boundaries - you'll do it once, and they need to respect the relationship.

The One Quote That Changed How I Think About This

When I was at Chef, I always used to say: "The most effective salesperson at Chef was Nathen Harvey (VP of Community)."

Nathen wasn't doing sales. He wasn't on sales calls pitching the product. But through his community work, his advocacy for developers, and his authentic engagement, he built trust and credibility that absolutely influenced people's decisions to adopt Chef.

That's the power of DevRel done well. You're not selling. But your work sells.

Set Boundaries (But Be Flexible)

One more thing: just because you understand sales and can work effectively with sales doesn't mean you become a tool for sales. You need boundaries.

Some examples of boundaries I've set:

"I'll call in a favor from someone in my network - ONCE."
"I will talk about new features on my social media, but I'll use my own words and my honest take."
"I will meet with prospects to discuss technical challenges, but I won't be on sales calls or do product demos."

Your boundaries might be different. That's fine. The key is to be intentional about what you will and won't do, and communicate that clearly.

And here's the thing about boundaries - they can be flexible and situational. Maybe you generally don't want to be pulled into sales calls, but there's a strategic deal with a company that could really benefit from your product, and you genuinely want to help. You can make exceptions. Just make them intentionally, not because you couldn't say no.

Do Things That Require Less Imagination to Show Value

I'm going to level with you here. Some DevRel activities require stakeholders to have a lot of imagination to connect them to business value. A blog post about a cool technical topic? A conference talk about a new framework? These things have value, but the connection to business outcomes requires some imagination and trust.

Other things require a lot less imagination. Meeting with a prospect who's evaluating your product to discuss their technical challenges? That's directly connected to a deal. Creating content that sales can use in their conversations with prospects? That's clearly valuable to the business.

I'm not saying you should only do the things that are obvious wins. But I am saying that in uncertain times, having a portfolio of work that includes some "obviously valuable to the business" activities gives you more stability.

What This Means For Your Work

Understanding sales doesn't mean becoming sales. It means:

You can have informed conversations with sales leaders about how DevRel supports their goals
You can identify opportunities to collaborate in ways that serve developers and support the business
You can articulate the value of your work in terms that sales leadership understands and cares about
You can spot when your DevRel activities are actually influencing pipeline, and communicate that

Next up, we're tackling marketing. Because if you thought sales was misunderstood, wait until we dig into what marketing actually does (and why DevRel is definitely not just "developer marketing").

Questions? Confused about pipeline? Want to argue with me about whether DevRel should ever talk to sales? Drop a comment!

Previously: Part 1: Why Business Literacy Matters

Next up: Marketing 101

Why Business Literacy Matters for DevRel (And Why You Can't Skip This Step)

Matty Stratton — Mon, 27 Oct 2025 18:51:10 +0000

I hear over and over again, "the business doesn't understand DevRel." I'm here to tell you that is backwards - the problem is that DevRel doesn't understand business.

Look, I get it. You didn't get into DevRel to spend your days talking about pipeline contribution and EBITDA. You got into this because you genuinely care about developers, you love building communities, and somewhere deep in your soul, you believe that if you make developers' lives better, good things will happen for everyone.

And you're not wrong. Well, mostly not wrong.

But here's some tough love for you, from me: if you can't translate that work into language that resonates with the folks who control the budget, you're going to have a really hard time getting to do that work at all.

This Series

This is Part 1 of a 6-part series on business literacy for DevRel:

Why Business Literacy Matters (you are here)

Sales 101

Marketing 101

Finance 101

Product-Led Growth

Product 101

Putting It All Together

The Uncomfortable Truth About DevRel Right Now

It's rough out there for DevRel teams. I've watched talented people get laid off. I've seen entire DevRel orgs dismantled. I've had conversations with DevRel leaders who are fighting for their team's survival. What's the common thread that I see again and again? They couldn't effectively communicate their value to the business.

And I want to be really clear about something before we go any further. This isn't about "selling out." This isn't about abandoning your principles or becoming a shill for marketing. This is about learning to speak a second language so you can advocate more effectively for the work you believe in.

I mean, if you're a Developer Advocate who only speaks English, and your CFO only speaks French, you're not going to get very far by just speaking English louder. You need to learn some French. Or at least enough French to explain why your conference budget isn't a waste of money.

You're Playing a Different Game Than Everyone Else

All the time, I see DevRel teams out there doing amazing work. They're building thriving communities, creating killer content, supporting developers through real problems. They're measuring engagement, tracking sentiment, monitoring their community health.

And then budget season comes around and people start asking questions like:

"How does this impact our ARR?"
"What's the cost per lead for these activities?"
"How much pipeline did DevRel source last quarter?"

And the DevRel team responds with things like:

"Well, we had 50,000 impressions on that blog post..."
"Our Discord community grew by 30%..."
"Developers really love when we do office hours..."

You know what happens next? Crickets. Blank stares. Nothing gets approved.

This is the disconnect. You're speaking different languages. And the frustrating part is that your work DOES have business impact. You're just not articulating it in terms that land with the people making decisions. You don't understand the APIs of the rest of your company.

Why "Just Prove Your Value" Isn't Helpful Advice

If you've been in this space for more than five minutes, you've probably heard some variation of "DevRel needs to prove its value." And there are approximately one million blog posts out there about metrics and attribution and ROI frameworks for DevRel.

None of this is helpful for you without tattooing this on your eyeballs: you can't effectively measure and demonstrate your value if you don't understand the fundamentals of how the business actually works.

All those fancy attribution models and measurement frameworks are less than useless if you don't know what ARR means, why finance cares about the difference between CapEx and OpEx, or how marketing thinks about funnel stages.

It's like trying to optimize your database queries before you understand how indexes work. Sure, you can learn about advanced caching strategies all day long, but if you don't understand the fundamentals, you're just guessing.

The Real Goal: Becoming Bilingual

I'm not saying you should become a mini-marketer or a sales shadow. You're still a DevRel professional. Your primary job is still to serve and advocate for developers.

For a second though, think about how amazing it would be if you could:

Walk into a meeting with your VP of Sales and have a meaningful conversation about how DevRel activities are accelerating deals in the pipeline
Sit down with your CFO and explain your budget in terms that make sense to them, using language they actually use
Talk to your CMO about how DevRel's activities map to different funnel stages and why that matters
Advocate for your team's budget and headcount in terms that resonate with executives

That's what business literacy gets you. It's a translation layer that lets you bridge the gap between the technical community work you do and the commercial realities of the company you work for.

And yes, I said "commercial realities." Because unless you work at a non-profit (and even then, maybe), your company exists to make money. DevRel is part of that. You can have feelings about capitalism all you want, but if you want to keep doing DevRel work, you need to understand this.

What This Series Will (And Won't) Cover

Over the next few posts, I'm going to walk you through the fundamentals of three key business functions:

Sales - What your sales team actually does, how they measure success, and where DevRel fits in
Marketing - How marketing thinks about the world, what they care about, and why DevRel isn't the same thing (but needs to speak their language)
Finance - The basics of budgets, P&Ls, and why your CFO cares about things you've never thought about

And then we'll also dig into what Product-Led Growth is, and why it is such a nice complement to DevRel.

What I'm NOT going to cover in this series:

Specific DevRel metrics or KPIs
Attribution models
ROI calculation frameworks
How to build a business case for DevRel

Why? Because those things are the next level. You need the foundation first. And that foundation is understanding how the core functions of your business work. Get smart about that, and then get into the implementation details.

The Payoff

Here's what you can do once you develop this business literacy:

You can advocate more effectively. When you understand what matters to your stakeholders, you can frame your work in ways that resonate with them. You're not compromising your values; you're translating them.

You can align better. When you understand the company's business objectives, you can intentionally align your DevRel strategy and activities to support them. This makes you more strategic, not less authentic.

You can fight for your team. When budget cuts are coming, the teams that can articulate their value in business terms are the ones that survive. Full stop.

You can build better partnerships. Understanding how sales and marketing work means you can collaborate with them more effectively, which amplifies your impact.

Look, I spent years as a sales engineer before I moved into DevRel and community work. I've sat in sales pipeline reviews. I've defended budgets to finance teams. I've worked with marketing on campaigns. And I'm here to tell you that learning to speak the language of business didn't make me a worse developer advocate. It made me a more effective one.

One More Thing

Before we dive into the specifics in the next posts, I want to get this out of the way. Some of you are probably thinking "but DevRel isn't sales" or "we're not marketing" or "we serve developers, not the business."

And you're right. DevRel is its own discipline. But DevRel exists within companies that have to generate revenue to survive. And unless you're independently wealthy and running a DevRel program as a hobby, you need to understand how your company makes money and how your work connects to that.

The best part about "selling out"? You get paid. And you get to keep doing the work you love.

So let's get started. In the next post (coming soon! Give me a minute!), we'll tackle Sales 101 - what your sales team actually does all day, and why understanding their world will make you better at yours.

What's Your Take?

Have you struggled to communicate DevRel value to non-technical stakeholders? What's been your biggest challenge? Drop a comment - I'd love to hear your stories.

Next in this series: Sales 101

From Bureaucracy to Brilliance: How DevOps Culture Can Transform Cloud Governance

Matty Stratton — Tue, 05 Aug 2025 16:28:13 +0000

The Governance Theater Problem

Imagine this - your CTO announces a major cloud governance initiative. Super critical to the business, all hands on deck, yada yada yada.

Six months later, you have a 60-page policy document, monitoring dashboards generating 1,000+ alerts per week, and a SharePoint site full of standards that developers have bookmarked but never actually read.

Sound familiar?

This is governance theater - a classic example of "work as imagined vs. work as done". It looks impressive from the executive level, but teams on the ground know it's completely disconnected from how they actually work. The real kick in the teeth? Most of these governance programs fail because they're built with a bureaucratic mindset trying to control a generative technology.

Why Traditional Governance Breaks in the Cloud

Traditional IT governance worked (for some value of "worked") when deploying a server took three weeks and changing a firewall rule required approval from the bi-weekly CCRB. The slow pace meant cumbersome and heavy processes could keep up. Rules, approvals, and documentation made sense. Or at least they didn't get in the way too much.

The cloud flipped this model upside down - the Jevons paradox in full effect. Developers can now spin up entire environments in minutes, auto-scale based on demand, and deploy code dozens of times per day. The old governance playbook doesn't just slow things down anymore. It breaks them completely.

Here's what happens when bureaucratic governance meets cloud velocity

Information Flow Problems: Critical security findings get buried in noise because there's no way to distinguish between "fix this now" and "fix this eventually." Teams ignore most alerts because the signal-to-noise ratio is terrible. Our old friend normalization of deviance rears its familiar head.

Ownership Confusion: When something breaks, nobody knows whose responsibility it is to fix it. The cloud's shared responsibility model collides with traditional departmental silos.

Process Overhead: By the time a security exception gets approved through the proper channels, the project has already shipped to production three times.

This is where Ron Westrum's research becomes incredibly relevant. Westrum studied organizational culture in high-risk, high-tempo environments like aviation and healthcare. He found that organizations fall into three cultural types, and the type directly predicts how well information flows through the organization.

Cloud Governance meets the Westrum Model

Pathological (Power-Oriented): Fear dominates decision-making. Teams hoard information, cover up problems, and focus on self-preservation. Cloud governance becomes about blame assignment and political maneuvering.

Bureaucratic (Rule-Oriented): Following the process matters more than achieving the outcome. Each department protects its turf and insists on its own rules. Cloud governance becomes a collection of disconnected policies that teams work around rather than with.

Generative (Performance-Oriented): The mission comes first. Teams collaborate across boundaries, share risks, and treat failures as learning opportunities. Cloud governance becomes an enabler that helps teams move faster while staying secure and compliant.

The research is clear: generative cultures don't just feel better to work in; they deliver better business outcomes. And business outcomes are why we are here, right? Companies with generative cultures have higher software delivery performance, better organizational performance, and more satisfied employees. And research shows they are funnier and more popular with their friends (research may not actually show this last part).

CALMS: The Cultural Operating System for Cloud Governance

The CALMS model gives us the foundation for building generative governance. CALMS represents the key tenets and foundational principles of DevOps (if you prefer, you can use the acronym CLAMS; I'm not here to judge you).

If these principles can transform how development and operations teams work together, they can also transform how governance works. Roll out!

Culture: Shared Responsibility Over Departmental Silos

Instead of the governance team owning all policies while engineering teams follow them, create cross-functional teams responsible for each of the 5 Pillars. Your security pillar team should include security professionals, platform engineers, and application developers. Your cost pillar team should include FinOps practitioners, engineering managers, and product owners.

This breaks down the "us versus them" dynamic that kills most governance programs. When the people who have to live with the policies help create them, you get policies that actually work in practice. It's like magic (with fewer sparkly vests).

Automation: Policy as Code Over Process Documents

Documentation-heavy governance fails because it can't keep up with cloud velocity. Teams need governance decisions at code-commit time, not committee-meeting time.

Move your governance policies into code. Security baselines become Terraform modules. Cost controls become automated budget alerts and resource right-sizing. Compliance requirements become pipeline gates that provide immediate feedback.

When governance is automated, it becomes invisible to teams when they're doing the right thing and immediately visible when they're not. The mantra for success here is "make the right way the easy way".

Lean: Value Stream Thinking Over Approval Chains

Traditional governance optimizes for risk avoidance. Generative governance optimizes for value delivery while managing risk intelligently.

Apply lean thinking to your governance processes. Map the value stream from "developer wants to deploy something" to "secure, compliant workload running in production." Identify waste, eliminate unnecessary handoffs, and remove approval steps that don't actually reduce risk.

The goal isn't to remove all controls. It's to remove controls that create friction without creating safety, and to implement controls that create safety without creating friction. Often times, we are focused on our small slice of the flow, and it's always beneficial to zoom out to the entire stream.

Measurement: Leading Indicators Over Compliance Theater

Most governance programs measure lagging indicators like "number of policy violations found during audit." By the time you measure these, the damage is already done.

Generative governance focuses on leading indicators that predict problems before they happen. How long does it take teams to get security exceptions? How often do cost alerts lead to actual cost reduction? How many governance policies have teams automated away versus worked around?

Measure governance effectiveness by measuring whether it helps teams move faster or just creates more overhead. And make sure you don't have bloat on "feel good" metrics that don't drive any improvement or change.

Sharing: Transparent Information Over Information Hoarding

Bureaucratic governance treats governance information as something to be controlled and dispensed carefully. Generative governance makes governance information radically transparent.

Create public dashboards showing security posture, cost trends, and operational health across all teams. When everyone can see the same data, you eliminate the political games and focus on solving actual problems.

Share governance successes and failures openly. When the platform team figures out how to automate compliance for PCI workloads, that knowledge should spread to every team, not stay locked in one department. Success breeds success - teams will see others having improvements and want that for themselves.

What This Looks Like in Practice

Before: A security team creates a 40-page cloud security policy. Teams ignore it. Security violations accumulate. Quarterly audit finds hundreds of issues. Finger-pointing ensues. Nothing improves. There is much wailing and gnashing of teeth.

After: Security and DevOps teams collaborate to embed security policies directly into infrastructure templates. Teams get immediate feedback when they violate policies. Most violations get auto-remediated. Manual violations trigger helpful guidance, not punishment. Security posture improves continuously. Teeth-gnashing is reduced by 96%.

Before: Finance gets a shocking cloud bill. They demand cost controls. IT implements manual approval processes. Innovation slows to a crawl. Shadow IT proliferates. Costs actually increase. The CFO's corporate card gets declined and the entire AWS infrastructure shuts off.

After: Cost policies are embedded in infrastructure automation. Teams get real-time feedback on spending. Optimization recommendations appear automatically. Cost accountability is clear and immediate. Teams self-optimize because they can see the impact. CFO treats the cloud team to a pizza party.

The Transformation Playbook

Start with Culture Assessment: Where is your organization today? Use Westrum's model to honestly assess whether your governance culture is pathological, bureaucratic, or generative. Most organizations discover they're more bureaucratic than they thought.

Pick One Pillar: Don't try to transform everything at once. Pick the pillar where you have the most pain and the most organizational support for change. Security and cost are often good starting points.

Apply CALMS Principles: For your chosen pillar, deliberately apply each CALMS principle. How can you make the culture more collaborative? What manual processes can you automate? How can you eliminate waste? What should you measure? How can you share information better?

Build Feedback Loops: Implement mechanisms to measure whether your governance changes are actually helping teams move faster while staying secure and compliant. If governance changes don't improve both velocity and control, they're not working.

Scale What Works: Once you've proven the approach on one pillar, expand to others. The cultural changes you make will compound across all areas of governance.

The Bottom Line

Cloud governance isn't failing because teams don't want to follow rules. It's failing because we're applying bureaucratic solutions to generative problems.

When you build cloud governance using the same cultural principles that make DevOps successful, something interesting happens. Governance stops being something teams work around and becomes something they work with. Security improves, because controls are consistent and automated. Costs become predictable, because spending is visible and controlled. Compliance shifts from quarterly fire drills to continuous confidence (wait, did I just coin a new industry buzzword?).

The cloud demands governance that moves at cloud speed (vroom vroom). That means governance built on generative culture, collaborative ownership, intelligent automation, and continuous improvement.

Your governance framework should enable teams to move fast and stay safe. Not force them to choose between the two.

The CloudGovernance.org framework gives you the 5 Pillars to define what you govern. DevOps culture gives you the principles to govern it effectively. When you combine them, you get governance that actually works.

What's your governance horror story? Drop a comment about the most bureaucratic, useless, or downright bizarre governance process you've encountered in the cloud. Bonus points if you've successfully transformed it into something that actually helps teams move faster.

Check if you are breaking your admin rules in your GitHub repos

Matty Stratton — Mon, 24 Mar 2025 14:03:01 +0000

Branch protection rules in GitHub are powerful! We can set rules that don't allow folks to commit directly to main, as well as enforce that PRs need to be reviewed and approved, and have required checks before merging.

However, often we allow admin folks on the repo to be able to bypass these restrictions (the infamous "Merge without waiting for requirements to be met (bypass rules)" checkbox), which can be useful - checks can get stuck, sometimes we do need to do an emergency fix, etc.

It can be really helpful to easily track and report on when these protections are bypassed. I'll show you here how to use Tailpipe in combination with your GitHub Audit Logs to find out who has been sneaking past the rules!

In my example, I'll be querying from the audit logs for the DevOpsDays GitHub org, since I'm an admin there and...maybe have broken my own rules a few times :)

Getting started with Tailpipe

Tailpipe is a lightweight and open source tool which you can use to analyze all kinds of logs directly in your terminal, using familar SQL syntax.

Here's how to install Tailpipe and the GitHub plugin:

Install and Configure Tailpipe

If you use Homebrew, it's as simple as

brew install turbot/tap/tailpipe

otherwise, use the install script

sudo /bin/sh -c "$(curl -fsSL https://tailpipe.io/install/tailpipe.sh)"

Install the GitHub Tailpipe plugin

tailpipe plugin install github

Download your GitHub Audit Logs and save them to a directory, perhaps /Users/USERNAME/github_audit_logs

Once you've done this, we need to configure Tailpipe's table partition and data source. Create a file at ~/.tailpipe/config/github.tpc with the following config (replace the path in the third line with the directory you saved the logs to)

partition "github_audit_log" "my_logs" {
  source "file"  {
    paths       = ["/Users/myuser/github_audit_logs"]
    file_layout = "%{DATA}.json.gz"
  }
}

Finally, let's collect the logs. One simple Tailpipe command slurps all the log data into our table:

tailpipe collect github_audit_log

Run some queries

The awesome thing about Tailpipe is that it lets us search and filter our log data using SQL queries (another awesome thing is that this all happens locally, so you don't have to pay for some cloud service to analyze it, or ship your sensitive logs somewhere else).

We can run our queries in a few ways - either run tailpipe query (for the interactive query shell) or you can save them as .sql files and run them using tailpipe query <filename.sql>.

What options do we have?

If I want to see the columns available to me for my queries, when I'm in the query shell, I can use the inspect command, like so:

$ tailpipe query
> .inspect github_audit_log
Column                     Type
action                     varchar
actor                      varchar
actor_id                   bigint
actor_ip                   varchar
actor_location             json
additional_fields          json
business                   varchar
business_id                bigint
created_at                 timestamp
document_id                varchar
external_identity_name_id  varchar
external_identity_username varchar
hashed_token               varchar
operation_type             varchar
org                        varchar
org_id                     varchar
repo                       varchar
              timestamp
token_id                   bigint
token_scopes               varchar
tp_akas                    varchar[]
tp_date                    date
tp_destination_ip          varchar
tp_domains                 varchar[]
tp_emails                  varchar[]
tp_id                      varchar
tp_index                   varchar
tp_ingest_timestamp        timestamp
tp_ips                     varchar[]
tp_partition               varchar
tp_source_ip               varchar
tp_source_location         varchar
tp_source_name             varchar
tp_source_type             varchar
tp_table                   varchar
tp_tags                    varchar[]
tp_timestamp               timestamp
tp_usernames               varchar[]
user                       varchar
user_id                    bigint

Simple query

For starters, let's find out all the times someone bypassed branch rules protection in general. If we run tailpipe query without arguments, it opens the interactive query shell:

$ tailpipe query
> select created_at, actor, repo, action from github_audit_log where action='protected_branch.policy_override' order by created_at desc
+---------------------+--------------+--------------------------------+----------------------------------+
| created_at          | actor        | repo                           | action                           |
+---------------------+--------------+--------------------------------+----------------------------------+
| 2025-03-20 19:59:15 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-20 13:44:00 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-20 13:14:51 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-19 19:41:08 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-19 19:37:01 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-18 18:22:41 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-18 17:23:08 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-17 22:44:35 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-13 15:31:54 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-10 14:54:54 | yvovandoorn  | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-05 18:54:00 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-05 17:25:21 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-04 17:16:41 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-03 23:37:29 | mattstratton | devopsdays/devopsdays-assets   | protected_branch.policy_override |
| 2025-03-02 23:13:30 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-27 15:45:55 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-25 23:27:24 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-22 02:47:13 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-17 11:20:34 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-14 23:09:25 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-12 09:10:46 | yvovandoorn  | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-11 19:26:17 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-10 16:59:19 | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-10 16:08:52 | phrawzty     | devopsdays/devopsdays-web      | protected_branch.policy_override |
(output truncated)

This is a good start; we can see that the most egregious abuser of the admin privilege is, well, me.

Add another column to the query

Now let's find out where it happened. For this, we can add the referrer column to our query.

$ tailpipe query
> select created_at, additional_fields.referrer, actor, repo, action from github_audit_log where action='protected_branch.policy_override' order by created_at desc 
+---------------------+-------------------------------------------------------------------------------------------------+--------------+--------------------------------+----------------------------------+
| created_at          | referrer                                                                                        | actor        | repo                           | action                           |
+---------------------+-------------------------------------------------------------------------------------------------+--------------+--------------------------------+----------------------------------+
| 2025-03-20 19:59:15 | "https://github.com/devopsdays/devopsdays-web/pull/15001"                                       | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-20 13:44:00 | "https://github.com/devopsdays/devopsdays-web/edit/main/content/events/2025-chicago/program.md" | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-20 13:14:51 | "https://github.com/devopsdays/devopsdays-web/pull/14998"                                       | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-19 19:41:08 | "https://github.com/devopsdays/devopsdays-web/pull/14997"                                       | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-19 19:37:01 | "https://github.com/devopsdays/devopsdays-web/pull/14996"                                       | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-18 18:22:41 | <null>                                                                                          | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-18 17:23:08 | <null>                                                                                          | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-17 22:44:35 | "https://github.com/devopsdays/devopsdays-web/pull/14988"                                       | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-13 15:31:54 | "https://github.com/devopsdays/devopsdays-web/pull/14974"                                       | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-10 14:54:54 | "https://github.com/devopsdays/devopsdays-web/pull/14955"                                       | yvovandoorn  | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-05 18:54:00 | "https://github.com/devopsdays/devopsdays-web/edit/main/data/events/2025/chicago/main.yml"      | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-05 17:25:21 | <null>                                                                                          | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-04 17:16:41 | "https://github.com/devopsdays/devopsdays-web/pull/14939"                                       | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-03-03 23:37:29 | "https://github.com/devopsdays/devopsdays-assets/pull/226"                                      | mattstratton | devopsdays/devopsdays-assets   | protected_branch.policy_override |
| 2025-03-02 23:13:30 | "https://github.com/devopsdays/devopsdays-web/pull/14933"                                       | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-27 15:45:55 | <null>                                                                                          | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-25 23:27:24 | <null>                                                                                          | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-22 02:47:13 | <null>                                                                                          | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-17 11:20:34 | <null>                                                                                          | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-14 23:09:25 | "https://github.com/devopsdays/devopsdays-web/pull/14883"                                       | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-12 09:10:46 | <null>                                                                                          | yvovandoorn  | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-11 19:26:17 | "https://github.com/devopsdays/devopsdays-web/pull/14870"                                       | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-10 16:59:19 | <null>                                                                                          | mattstratton | devopsdays/devopsdays-web      | protected_branch.policy_override |
| 2025-02-10 16:08:52 | "https://github.com/devopsdays/devopsdays-web/pull/14858"                                       | phrawzty     | devopsdays/devopsdays-web      | protected_branch.policy_override |


(output truncated)

This shows us the pull requests that were overridden, but also if you look at the second record, it refers to a single file, which means it wasn't a PR...that was a yolo commit to main (made via the GitHub web interface)

A more complicated query

Speaking of that... if we want to just filter based on yolo commit to main? This query works for that, but also uses some more complicated SQL in order to make the output more readable:

select 
  created_at, 
  actor, 
  repo,
  referrer 
from (
  select 
    created_at, 
    action, 
    additional_fields.overridden_codes, 
    additional_fields.referrer as referrer, 
    additional_fields.reasons, 
    action,
    repo,
    actor 
  from 
    github_audit_log 
  where 
    action = 'protected_branch.policy_override' 
    and CONTAINS(additional_fields.reasons,'Changes must be made through a pull request')
  order by 
    created_at desc
  ) 
as s

If we take that query and save it as query.sql, we can run tailpipe at the command line and use that file for the query:

$ tailpipe query query.sql
+---------------------+--------------+---------------------------+-------------------------------------------------------------------------------------------------+
| created_at          | actor        | repo                      | referrer                                                                                        |
+---------------------+--------------+---------------------------+-------------------------------------------------------------------------------------------------+
| 2025-03-20 13:44:00 | mattstratton | devopsdays/devopsdays-web | "https://github.com/devopsdays/devopsdays-web/edit/main/content/events/2025-chicago/program.md" |
| 2025-03-18 18:22:41 | mattstratton | devopsdays/devopsdays-web | <null>                                                                                          |
| 2025-03-05 18:54:00 | mattstratton | devopsdays/devopsdays-web | "https://github.com/devopsdays/devopsdays-web/edit/main/data/events/2025/chicago/main.yml"      |
| 2025-02-27 15:45:55 | mattstratton | devopsdays/devopsdays-web | <null>                                                                                          |
| 2025-02-10 16:59:19 | mattstratton | devopsdays/devopsdays-web | <null>                                                                                          |
| 2025-01-24 15:36:02 | mattstratton | devopsdays/devopsdays-cli | <null>                                                                                          |
| 2024-09-13 20:46:02 | mattstratton | devopsdays/devopsdays-web | <null>                                                                                          |
| 2024-08-29 11:33:06 | mattstratton | devopsdays/devopsdays-web | "https://github.com/devopsdays/devopsdays-web/delete/main/mattytest.txt"                        |
| 2024-08-28 13:59:20 | mattstratton | devopsdays/devopsdays-web | <null>                                                                                          |
+---------------------+--------------+---------------------------+-------------------------------------------------------------------------------------------------+

(The entries with "null" for the referrer mean that the commits were made directly to main outside of the web interface, i.e., I did a git push origin main)

Conclusion

Being able to query and report on GitHub audit actions in a local, fast way (without having to upload our sensitive logs to another service) gives us a lot of flexibility to dig into actions take on our repos!

Verifying identity

Matty Stratton — Fri, 11 Nov 2022 14:34:52 +0000

https://keyoxide.org/6529B08F20194D84FFAC7C5850F46247289D3110

(please feel free to ignore this!)