Operational Architect, Marketing

About this job posting\n

\n

We’re experimenting with hiring. Mainstream candidates won’t fit this role, so this is not a mainstream process.

\n

\n

If this role fits, apply through LinkedIn.

About the role\n

\n

We are not hiring a traditional marketer, and we are not hiring a traditional software engineer.

\n

\n

We are hiring an Architectural Operator—someone who designs systems that produce software (and the motion around it), not someone who writes one-off campaigns or one-off code.

\n

\n

With AI (“vibe coding”), generation is no longer the constraint. The bottleneck is making what gets produced correct, reproducible, and architecturally sound.

\n

\n

Your job is to define systems that rapidly generate high-quality software whose outcome is marketing: community, distribution, events, and repeatable go-to-market motion.

\n

\n

You will build and evolve agent-driven systems… that build and evolve agent-driven systems… that execute real marketing functions.

\n

\n

This seat is scoped to marketing operations. The agents you ship must produce marketing outcomes we can run: meetup and community operations, content and distribution systems, candidate/community funnels, event coverage, and the operating system for building our own meetup circuit in-market. If it doesn’t create or run a marketing system, it doesn’t count.

\n

\n

This month the company is on the ground in San Francisco (meetups, coverage, hackathons). This role exists so that motion becomes a system—not a heroic calendar.

The pre-interview process (mandatory)\n

\n

To qualify for an interview, you must build and submit an agent system. This is not theoretical.

\n

\n

After you apply on LinkedIn, we will send a set of use cases. You pick one.

\n

\n

Example use case (illustrative):

\n

• \n
• Monitor Gmail and identify work-related emails
• \n
• Convert emails into structured tasks
• \n
• Use Asana as the system of record
• \n
• Suggest or generate responses
• \n
• Maintain state across systems and workflows
• \n

\n

\n

For this role, prefer a use case that produces a marketing outcome—for example: ingest inbound interest, turn it into a campaign or event workflow, keep state across CRM/calendar/content tools, and generate the next action (invite, follow-up, recap, distribution).

What we evaluate (all four at once)\n

\n

1. Speed (vibe coding in practice)

\n

\n

Build with AI-assisted development (Cursor or similar). Record a video of the full build (~1–2 hours). We watch velocity, how you use AI, and how you iterate. Control, not theater.

\n

\n

2. Architecture first

\n

\n

Structure first. Consistent patterns. Event-driven flows, orchestration, defined data movement. Short architecture overview (diagram or written) as the agent’s skill(s).

\n

\n

3. Runnable, deployed system

\n

\n

Clean, runnable, deployed. We run it end-to-end without babysitting.

\n

\n

4. Reproducibility + iteration

\n

\n

On video, change something real (different list, different channel, different “account”) and regenerate. We will also try to break/adapt it ourselves.

Evaluation and outcome\n

\n

Same bar as every Operational Architect seat: architecture, speed, reproducibility, practical usefulness—scored as a marketing system, not a brochure.

\n

\n

If selected: interview.

\n

\n

If exceptional and usable: offer + signing bonus for the submitted system.

What you’ll do on the team\n

\n

1. \n
2. Design software manufacturing systems for marketing work—guardrails and patterns so campaigns, events, and community ops are generated, not reinvented.
3. \n
4. Architect data-first systems — people, events, content, and funnel state; graph + event-driven where it helps; observable so we know what actually moved.
5. \n
6. Build and evolve agents that run marketing functions: sourcing and covering meetups, turning conversations into follow-up systems, producing distribution artifacts, operating a community calendar.
7. \n
8. Replace work with systems — stop running GTM as a pile of Slack messages and spreadsheets.
9. \n
10. Operate at high velocity in-office in San Francisco, with AI as a default tool.
11. \n

\n

\n

Marketing outcomes we care about: a system that can stand up and run community/meetup operations, keep coverage across events without one person hero-ops, and turn “we showed up” into a repeatable machine.

Technical environment\n

\n

Same stack as the rest of the company:

\n

\n

AWS: Lambda, Step Functions, EventBridge, SQS, SNS, DynamoDB

\n

\n

Serverless-first, event-driven

\n

\n

Data: graph databases (Neo4j or similar), pipelines, observability

\n

\n

Plus the marketing surface area those agents will touch (email, calendar, social, CRM/task tools).

Principles\n

\n

• \n
• Code is disposable. Architecture is permanent.
• \n
• Reproducibility > reusability
• \n
• Speed without structure creates failure
• \n
• If it can be done twice, systematize it
• \n
• The best system is one you never need to fix
  
• \n

Who fits\n

\n

You think in systems. You would rather manufacture a community/GTM machine than “do marketing.” You use AI as a core tool. You care about structure. You want fewer heroics, not more campaigns to babysit.

Compensation philosophy\n

\n

Same as the other Operational Architect seat: pay for systems that remove future work.

Why this role exists\n

\n

We are building software manufacturing for the whole company—including distribution. Marketing should be performed by agents, generated by agents. Architecture is the asset.

\n

If you can build systems that build marketing systems, apply on LinkedIn.