Overview
You write technical content that helps developers understand why they need durable workflows for their backend infrastructure. You're translating complex distributed systems conceptsâretries, event-driven architectures, observabilityâinto blogs, guides, videos, and benchmark reports. You work directly with Lauren (Head of Marketing) and likely pull technical details from the founding team.
Role Snapshot
| Aspect | Details |
|---|---|
| Role Type | Developer Content Marketer (individual contributor) |
| Content Motion | Research-driven / Educational / Technical storytelling |
| Audience | Backend engineers, platform engineers, CTOs at software companies |
| Output | Blogs, guides, videos, benchmark reports, white papers |
| Distribution | Likely developer-focused: HackerNews, Reddit, dev.to, technical newsletters |
| Team | You + Head of Marketing + possibly 1-2 others |
Company Context
Stage: Likely Seed or Series A (25 employees, actively hiring across marketing)
Size: 25 employees
Growth: Just hired Growth/Demand lead and DevRel leadâscaling go-to-market now
Market Position: Challenger in the durable execution space (competing against Temporal, AWS Step Functions, Windmill, custom solutions)
What Inngest Actually Does
Inngest makes backend code "durable"âmeaning if your workflow fails (API timeout, rate limit, server crash), it automatically retries and recovers without you building that infrastructure. You can run workflows, AI agents, background jobs with built-in retry logic, flow control, and observability.
The problem they solve: Developers currently build retry logic, error handling, and monitoring manually for every workflow. Inngest abstracts that away.
Target buyers: Engineering teams at software companies building products with complex backend workflowsâespecially AI-powered products where you need to chain multiple API calls, handle rate limits, and ensure reliability.
Content Landscape Reality
What's working in this space:
- Deep technical posts that show code examples ("How we built X with Y")
- Benchmark reports comparing solutions (latency, reliability, cost)
- Educational content on distributed systems concepts (retries, idempotency, event-driven design)
- Real customer stories with actual architecture diagrams
Competition's content:
- Temporal has strong documentation and architectural guides
- AWS Step Functions has enterprise case studies
- Most competitors lean heavily on docsâless on narrative storytelling
Your challenge: Make event-driven architectures and durable execution "feel FUN" (Lauren's words) while staying technical enough for backend engineers to trust you.
What You'll Actually Do
Time Breakdown
Research/Interviews (30%) | Writing/Producing (40%) | Strategy/Planning (15%) | Distribution/Promotion (15%)
Key Activities
-
Research and interviews: Talk to Inngest's engineering team to understand technical details. Interview customers about their use cases. Research competitors' approaches and developer pain points in forums/GitHub issues.
-
Content creation: Write 2-3 technical blog posts per month, create guides ("Building resilient AI agents with Inngest"), produce videos or code walkthroughs, develop benchmark reports comparing workflow solutions.
-
Strategy setting: Decide what topics to cover based on customer conversations, search trends, competitive gaps. Map content to different stages of developer awareness (problem-aware vs solution-aware).
-
Distribution: Post to HackerNews, Reddit (r/programming, r/devops), dev.to. Work with DevRel lead on community amplification. Optimize for developer SEO (long-tail technical searches).
The Honest Reality
What's Hard
-
Technical depth required: You can't fake it with developers. If you don't understand event-driven architectures, retry strategies, and distributed systems basics, your content will get torn apart in comments. You need to do real research and possibly learn new concepts constantly.
-
Developer skepticism: Developers are allergic to marketing speak. One "synergy" or "transform your business" and you've lost credibility. You're writing for an audience that will fact-check your code examples and call out inaccuracies publicly.
-
Small team = wearing many hats: At 25 people, there's no video producer, no designer, no editor. If you want a video, you're figuring out how to record and edit it (or keeping it very simple). If you need graphics, you're making them or coordinating with whoever has Figma skills.
-
Proving ROI: Developer content has a long feedback loop. A blog post might drive awareness but not convert to trials for 3-6 months. You need patience and Lauren's trust that you're building the right foundation.
What Success Looks Like
-
Engagement metrics: Posts consistently hit front page of HackerNews or top of relevant subreddits. Comments show developers actually read and understood the content.
-
SEO traction: Ranking for high-intent searches like "durable workflows python" or "event-driven architecture patterns" within 6-9 months.
-
Sales enablement: AEs start sending your content to prospects during deals. Customer engineers reference your guides during onboarding.
-
Thought leadership: Other companies cite your benchmark reports or architectural guides. Conference organizers reach out asking you or Inngest engineers to speak.
Who You're Writing For
Primary Audience:
- Backend engineers (mid to senior level) building complex workflows
- Platform engineers responsible for infrastructure reliability
- CTOs at startups/mid-size companies evaluating workflow solutions
What They Care About:
- Does this actually solve my problem or is it just another tool to learn?
- How does it compare to what I'm doing now (custom code, Temporal, Step Functions)?
- What's the performance/latency overhead?
- Can I trust this for production workloads?
- How much lock-in am I accepting?
Requirements
-
Technical writing experience: You've written for developers beforeâdocumentation, technical blogs, or engineering content. You know how to explain complex concepts clearly without dumbing them down.
-
Backend/infrastructure knowledge: You understand what an API is, what retries and idempotency mean, and why distributed systems are hard. You don't need to be a senior engineer, but you need enough context to have intelligent conversations with them.
-
Self-direction: Lauren wants someone who can "do the research, set the strategy, and execute." You're not getting detailed briefsâyou're figuring out what to write and why.
-
Portfolio of technical content: Show examples where you made complex technical topics accessible and interesting. Bonus if you've worked in developer tools, infrastructure, or B2B SaaS targeting engineers.
-
Comfort with ambiguity: This role doesn't fully exist yet. You're defining what developer content marketing looks like at Inngest. If you need clear processes and established playbooks, this isn't it.