In reality, the AI era is not a new job. It’s the third reset of the same job, and it only looks unprecedented if you weren’t paying attention during the first two.

Ask five experienced developer advocates what to focus on and you’ll get seven different answers, all correct. Learn AI. Learn AI. Learn AI. Learn video. Learn marketing and events, because that’s what the postings actually ask for. Learn agentic development. Learn how to size up an organization so you don’t become the first DevRel hire at a ten person company that has no idea what it just bought. That’s seven answers from five people, and three of them are the same answer said louder. Nobody on that list is wrong. Now try building a twelve month plan out of it :)

I started my big tech career at IBM in 2014, spent 2020 to 2022 at Red Hat, and have been at startup unicorns since. I’ve also been organizing conferences and meetups for the last decade or so, which means twice a year I read a stack of CFP submissions and watch the industry’s obsessions turn over in real time, usually about nine months before they show up in job descriptions. From that seat, the pattern is hard to miss.

I want to explore five things in this blog:

1. The three eras of developer advocacy, what changed at each reset, and what has never changed at all.
2. How the demos we build changed, including the sharp break of the last three years.
3. How DevRel measurement shifted across the eras, and why the AI era quietly broke the metrics most teams still report.
4. The uncomfortable truth: you are not hired for what you value. You are hired to remove a cost.
5. How to tell whether the job you’re being offered is one where the work is even possible.

Three eras, three complete resets

Era 1: Before the cluster

Roughly 2008 to 2014. The title was usually “developer evangelist,” and the product surface you advocated for was small enough to hold in your head: a REST API, an SDK in four languages, a quickstart, and a set of docs.

The distribution channel was people in rooms. Conference stages, user groups, hackathons, a book, a blog on your own domain, a mailing list. Companies like Twilio, SendGrid, EngineYard, and New Relic took the model mainstream by putting engineers, not marketers, on stage in front of other engineers.

When I joined IBM in 2014, the hardest part of the job was explaining that the job existed. “What do you do at IBM?” never ended in one sentence. I eventually got so tired of the explanation that I wrote a blog post I could just send people. Some of my colleagues then were engineers who had spent twenty years shipping software and chose advocacy over management or a principal engineer track. A few of them retired out of the role. That was the profile: not an entry level job, and nobody pretended otherwise.

Credibility was earned in production and spent on stage. The unit of work was the talk.

Era 2: The microservices, Kubernetes, and API era

Docker landed in 2013. Kubernetes in 2014. The CNCF in 2015. Within about three years, the surface area a developer advocate had to cover went from an SDK and an API to YAML, Helm charts, operators, CRDs, service meshes, observability stacks, CI pipelines, and Terraform.

Two things changed at once, and they’re worth separating.

The technical bar moved sideways, not up. Writing good application code stopped being sufficient. You had to run a distributed system, explain why it fell over, and reason about failure across a network boundary. Some developer advocates looked at Kubernetes in 2016, decided it was accidental complexity dressed up as progress, and sat that cycle out. That was a defensible engineering opinion. It was a bad advocacy decision, and the two are not the same thing. An engineer can stay valuable maintaining an unfashionable system. An advocate for an unfashionable system has no audience.

Sit with that, because it’s the pattern that governs everything else in this post. The market’s demand did not need to be architecturally justified in order to be real.

My own version of that lesson came at the transition. I came up as a backend Java developer. Around 2016 I had to decide whether the container thing was a serious shift or a fashion, and I chose to treat it as serious mostly because the CFP submissions I was reading as an organizer had gone from ten percent container talks to sixty percent in about two years. I didn’t reach that by evaluating the architecture. I reached it by counting talk submissions, which turned out to be the better instrument.

By the time I got to Red Hat in 2020, the reset was complete and the demo had become an environment rather than a snippet. It was also the pandemic, so every event I organized or spoke at moved to a webcam, which stripped out the hallway track and left only the artifact. That accelerated something already underway.

The distribution channel had moved to search and GitHub. The talk stopped being the unit of work. The unit became the artifact that outlived you: the tutorial that ranked on page one, the reference architecture repo people forked, the docs page that surfaced when someone pasted an error message into Google. A conference talk was a spike. A tutorial was an annuity.

The unit of work was the artifact.

Era 3: The AI era

Now look at what’s actually happening, and look past the word “AI,” which is so overloaded it carries almost no information.

The product surface changed again. It’s a model, a set of tools, an MCP server, a retrieval layer, an eval suite, a context budget, and a bill that scales with tokens instead of nodes. If you advocate for a developer product today, a growing fraction of your product’s usage is driven by an agent that a human is loosely supervising.

The distribution channel changed again, and this is the part most people are underweighting. In Era 1 you reached a human in a room. In Era 2 you reached a human through a search engine. In Era 3, a large share of your content is read by a model before a human sees it, and frequently instead of. RTFM is being replaced by the AI reading the manual on the developer’s behalf. Your developer portal’s job is no longer only to be readable. It has to be retrievable and unambiguous to something that will never scroll.

I wrote about llms.txt a while back and the reaction was mostly polite curiosity. It isn’t curious anymore. If an agent cannot get from zero to a working integration with your product without a human intervening, you have a developer experience problem that no amount of conference presence will fix.

There’s a second order effect that I think is the real story of this era. The cost of producing a competent-looking artifact has fallen to nearly zero. A tutorial, a demo app, a blog post, a sample repo, all of it can be generated in an afternoon by someone who understands none of it.

That breaks the Era 2 economy completely. For fifteen years the artifact was evidence. It was expensive to produce, so producing one proved something about you. Publishing a lot used to mean you had worked hard, and working hard used to mean you knew something. Both of those chains snapped.

When artifacts stop working as evidence, the market re-prices two things: judgment and verifiable outcomes. Knowing what to build, knowing when the agent is confidently wrong, knowing the exact moment to take manual control back. Typing was never the hard part of this job. It was just the last reliable proxy we had for someone who could do the rest, and it stopped working.

The unit of work is the judgment call.

The demo tells the whole story

If you want a single artifact that tracks all three eras, watch what happened to the demo.

Era 1: the demo was proof the API worked. A laptop, a terminal, a browser, five minutes of live coding that ended with a text message arriving on a phone in front of 300 people. Small, deterministic, genuinely persuasive because the audience saw the whole thing. Shelf life of two or three years. You could give it at eight conferences and only bump the SDK version.

Era 2: the demo became an environment. You weren’t showing an API call, you were showing a system. A polyglot microservices app, a GitOps pipeline, a cluster that had to exist before the talk started. A week to build, half a day to reset. Half the room had seen a variation already, because the whole ecosystem was demoing against the same reference apps. The demo stopped proving your product worked and started proving your product fit into a stack. Shelf life of about a year, because a minor version bump could break it on stage. I have watched a demo die at a meetup because of a Helm chart change that shipped that morning, and the recovery mattered more to that room than the demo would have.

Era 3, specifically the last three years, is where it gets interesting. The trajectory ran chatbot, then RAG pipeline, then agent, then multi-agent, roughly one per year. But the version number isn’t the point. Three deeper things changed:

The demo stopped being scarce, so it stopped being persuasive. When the audience knows anyone can generate a polished demo app in an hour, watching one generated live impresses nobody. The demo lost its function as proof of competence. That’s a genuine loss and our field has not adjusted to it. Plenty of teams are still shipping Era 2 style demos and wondering why engagement is flat.

Demos became non-deterministic. You can no longer guarantee the same output twice. Anyone who has run a live agent demo knows the specific dread of watching the model take a path you never saw in forty rehearsals. The honest responses are to pin versions and seeds, to pre-record and narrate over it, or to lean into the non-determinism deliberately and make the recovery the point.

Shelf life collapsed to weeks. A demo built against a model release from six months ago is often just wrong, not merely dated. The cost structure inverted: cheap to produce, expensive to maintain. Most teams have not updated their budgets for that.

So what actually persuades a technical audience now? Three things, in my experience:

• The demo that fails on purpose. Show the agent getting it wrong, show how you caught it, show the guardrail. Everyone in the room has been burned by something that didn’t survive contact with real data. Showing the failure mode buys more credibility than a clean run ever will.
• The eval, not the output. A passing eval suite is the new working demo. It survives a version bump, and it’s the artifact a skeptical staff engineer actually respects.
• The demo an agent can run without you. If someone points their own agent at your repo and reaches the same result unattended, you’ve proven something about your product’s agent experience that no stage performance can.

What we measured, and what quietly broke

Metrics moved in lockstep with distribution, and the AI era broke a set of proxies most teams are still reporting.

Era 1 measured presence. Attendance, booth conversations, t-shirts, tweets, a warm feeling in the exec team. Nobody had solved attribution because nobody was seriously asking.

Era 2 measured traffic and community. Docs pageviews, search rankings, GitHub stars, forks, contributor counts, chat community size, attributed signups, time to first hello world. Imperfect proxies, but with one enormous advantage: a click was a reasonable stand-in for a human. Someone read the thing, so someone existed.

Era 3 broke that assumption, and almost nobody has repriced accordingly. Consider what’s happening to your numbers right now:

• Docs pageviews are falling while docs usage is rising. The agent read your page, synthesized the answer, and the developer never clicked. Flat traffic on your best page may mean it’s being consumed more than ever. Report that chart to leadership without the caveat and you are arguing against your own budget.
• Stars and content volume are trivially manufactured. Anything that was cheap to game in 2022 is free to game in 2026.
• Search ranking is a shrinking proxy for reach. The question is no longer only where you rank, but whether you are represented, and represented accurately, in the answer a model gives when your category comes up.

What replaces them, in my view, are proxies built around machine consumption and verified outcomes:

• Agent completion rate. Can an agent go from zero to a working integration, unattended, without hallucinating an endpoint that doesn’t exist?
• Time to first successful agentic call, which is the Era 3 version of time to first hello world.
• Answer share and answer accuracy. How often does your product surface when a developer asks a model a question in your category, and how wrong is the answer when it does?
• Docs ambiguity rate. How many pages produce inconsistent agent behaviour across runs? This is measurable and almost nobody measures it.
• Retrieval coverage. What fraction of your documented surface is reachable and correct through a machine-readable path.
• Unchanged from before: feedback that reached the roadmap, and technical blockers removed from real deals.

I’ll be honest about the limits. None of this is standardized, none of it has agreed benchmarks, and you will be inventing the framework at whatever company you join. That has been true in every era, and I’ve written at length about why DevRel measurement is broken in a way other roles’ measurement is not. What’s changed is that the old proxies have gone from imperfect to actively misleading.

What changed, what didn’t

The compressed version:

Here’s what has not moved a millimetre in twelve years:

Technical credibility is still earned by building, not by talking about building. Every era produces advocates who let the code atrophy, and every era punishes them at the next reset. This one is more dangerous, not less, because the tooling lets you appear technical far longer before anyone notices.

Empathy still can’t be faked or shortcut. You develop it by having been the person on the other side of a broken quickstart at 11 PM.

A great DevRel team still cannot save a bad product. I wrote that in 2023, it’s still true, and it will be true in 2030.

Trust is still the entire asset. As more generated content reaches the world, human connection and narrative appreciate rather than depreciate. I’d sharpen that further: the thing that makes video look like a bad bet in an AI-heavy world is exactly what makes it defensible, which is that models don’t ingest it well.

Which gives you a practical framing for content. You’re running two funnels now, and they optimize for opposite things. The machine funnel is docs, llms.txt, structured content, MCP servers, SDKs an agent calls correctly on the first attempt, error messages that are parseable. Optimize that for retrievability and correctness. The human funnel is video, live workshops, hallway conversations, opinions, narrative, the trip report nobody asked for. Optimize that for trust. Stop trying to make one piece of content serve both. That’s why so much DevRel content right now reads like it was written for nobody in particular. It was.

You are not hired for what you value

Now the uncomfortable part, and the actual reason I wrote this.

You are hired to remove a cost or a risk.

A job description is not a description of the work. It’s a hiring manager’s anxiety, filtered through a recruiter who has to cut 400 applicants down to 10. When it says “experience building agentic workflows,” the sentence underneath is closer to: our CEO asked what our AI story is, our docs are being consumed by models and misrepresented, activation is flat, and I need someone who won’t take six months to ramp.

You are allowed to think a requirement is silly. In 2016, “must have production Kubernetes experience” was a questionable ask for a role that mostly involved writing tutorials, and smart people said so out loud. The ask was still real. The people who satisfied it got the roles. The people who wrote thoughtful posts about why the industry was overreacting got to keep writing those posts, from home, for longer than they intended.

I’ve watched this from both sides. Since 2022 I’ve been at startup unicorns, where the pressure to name a number is constant and the tolerance for “this will pay off in eighteen months” is close to zero. And from the organizer chair, I’ve seen the CFP pool turn over completely three times. Both views teach the same lesson: the market’s vocabulary changes faster than the work does, and being fluent in the current vocabulary is not the same as being a sellout.

So hold two things at once. Know the work, which means understanding the systems for real and never becoming the person who demos something they cannot debug. And signal what is being searched for right now, not what should be searched for.

Most people in DevRel are excellent at the first and treat the second as beneath them. I understand the instinct. Nobody gets hired for having correct opinions about what the industry should have wanted. The people who struggle during a reset are almost never the ones who lacked skill. They’re the ones whose skill wasn’t legible in the vocabulary the market was currently using.

Then check whether the job is even doable

The offer isn’t the finish line. Plenty of people have won the offer and walked into a job where the work was never going to be possible.

Before you accept anything, find out who DevRel reports to and whether that person wanted a DevRel team or inherited one. Find out what stage the business is in and whether the proposed metrics match that stage. If you’d be the first DevRel hire, find out who defined the mandate before the requisition opened, because “we’ll figure it out together” means you’re being hired to invent your own job and then take the blame when it fails to produce a number nobody defined. Find out whether anyone senior will protect you when the CEO asks for ROI the week after a conference. And find out whether the product is any good, because you cannot advocate your way out of a bad one, and attempting it costs you community trust you spent a decade building.

“First DevRel hire, ten person company, no prior DevRel function, open to someone junior” is not an opportunity. It’s a story you’ll be telling at a meetup in eighteen months.

Time to ship

Three eras, and at each one the product surface, the distribution channel, and the definition of good work all turned over together. Underneath all of it, the same job: understand the technology well enough to be trusted, and be useful to developers in whatever medium they actually use.

What changes every eight years is the medium and the vocabulary. What never changes is that you have to build in order to stay credible, and you have to be legible in order to get hired.

So if you’re trying to break in this year, pick one thing in the agentic stack and go deep enough to have opinions about its failure modes. Publish the failures, not the happy path. Write down how you’d measure your own work in the first ninety days, because almost no candidate does. And make all of it verifiable by a stranger in ninety seconds.

Do the work that matters, and ship the proof in the format the market is currently searching for. Skipping either one is how good people end up unemployed for reasons they refuse to name.

A note on how this was made: I developed this blog with an AI assistant. The structure, the arguments, the three era framing, and the opinions are mine, pressure-tested and organized through that conversation. It is not an AI-generated post, and I’d rather tell you that directly than have you wonder.

After sitting with this long enough, I think I understand why. Developer advocacy is the only role in a technology company that gets held accountable for both what it produces and what it causes. At the same time. With no agreed model for connecting the two.

I want to explore four things in this blog:

1. The specific double standard DevRel faces that engineering and sales do not.
2. Why the “attribution is hard” excuse cuts both ways — and how to actually solve it.
3. The community bias baked into most DevRel measurement frameworks — and the enterprise dimension that gets ignored entirely.
4. What a fair measurement framework looks like when it’s aligned to where the business actually is.

Output and outcome are not the same thing

When a software engineer wraps up a quarter, the evaluation is grounded in what they shipped. Features delivered. Systems built. Problems closed. At senior levels there is some expectation of broader impact, but that impact is always traced back to something the engineer directly controlled — a decision they made, a system they designed, code they wrote. The chain is short.

When a sales professional misses quota, no one asks them how many prospecting emails they sent. The output is the outcome. You either closed the business or you didn’t.

Now look at what happens when a developer advocate sits down for a performance review. The manager wants to know how many blogs they published, how many conference talks they gave, how many demos they built. That is the output layer. Then, in the same conversation, the question shifts: what was the business impact? Did developers adopt the product? Can you show community growth? Did your work influence pipeline?

Two layers of accountability. One role. Product managers sometimes navigate a similar tension, but they operate with agreed frameworks — roadmaps, OKRs, delivery milestones — that connect their work to outcomes. No other individual contributor role faces this combination without an agreed model for connecting the two, and almost no one talks about it openly.

“Attribution is hard for other roles too” — and why that argument misses the point

When developer advocates raise the attribution problem, the pushback is usually some version of: “Marketing has attribution problems. Internal tooling has attribution problems. That doesn’t mean you get a free pass.”

It’s worth addressing that directly. That is a fair point. It doesn’t mean DevRel gets a free pass. But it also ignores the real issue.

Marketing has attribution problems — and Marketing has MQL/SQL models, CAC tracking, and campaign attribution tools that the whole organization has agreed to use. The proxies are imperfect. They are accepted. Everyone knows before the quarter starts what counts and how it gets measured.

Developer advocacy has the same attribution problem as marketing with none of the agreed proxies. In that vacuum, managers either count outputs — blogs, talks, demos — and use those as productivity scores, or they skip directly to business outcomes and hold DevRel responsible for numbers they have no direct line to. Neither is measurement. Both are unfair.

The solution is not to exempt DevRel from accountability. It is to build the proxies that the industry has failed to standardize. They are not complicated:

• How many developers discovered the product through DevRel content, talks, or community work?
• Of those, how many completed a first meaningful integration?
• How is community health trending — contributor growth, forum resolution rates, developer sentiment?
• How many developer pain points surfaced by DevRel actually made it into the product roadmap?
• What is DevRel’s share of voice in the technical communities where the target developer persona lives?

These metrics are measurable. The industry has just not committed to measuring them.

The community bias nobody talks about

Most DevRel measurement frameworks were built by people who came up through open source and community-led growth. That made sense for the companies that pioneered DevRel — HashiCorp, Twilio, Stripe — where the community motion was the primary path to adoption. Measure community health, measure developer acquisition, measure activation. The model fit the motion.

But a significant portion of developer-first companies today are not selling through community-led growth. They are selling to enterprises. The developers they need to reach are embedded inside engineering teams at large organizations, evaluating tools under procurement timelines, with security reviews and architecture approvals standing between a positive developer experience and a closed deal.

For those companies, DevRel’s most impactful work looks nothing like conference talks and Discord engagement. It’s running a technical workshop with three engineers at a shortlisted enterprise account. It’s being pulled into a pre-sales call because the solutions engineer needs someone who can answer hard infrastructure questions credibly. It’s writing the integration guide that unblocks a deal that has been stalled for two months. It’s sitting in a post-sales call, translating a customer’s frustration into a structured product feedback report that actually reaches the roadmap.

None of that work shows up in community metrics. And when leadership sees flat community numbers alongside a healthy enterprise pipeline, they draw the wrong conclusion about what DevRel is contributing.

The fix is the same as the broader measurement problem: match the metrics to the mandate. For enterprise-focused DevRel, the right metrics look closer to sales engineering outcomes — deals influenced, time-to-integration reduced, technical blockers resolved in the sales cycle, customer retention tied to technical enablement. Holding an enterprise-focused DevRel team to community metrics is not just inaccurate. It is measuring the wrong game entirely.

The right measurement depends on what stage you’re in

This is where most companies get it completely wrong. They hire a DevRel team and immediately apply the metrics they’d use at scale — pipeline influence, community size, developer NPS — to a team that’s still figuring out who their developer persona is.

The right measurement framework depends entirely on where the business is:

Pre-PMF: The most valuable thing DevRel can do is get structured, honest feedback from real developers back to the product team. Measuring them on community size at this stage is not just useless — it actively incentivizes the wrong behavior.

Growth: Developer acquisition is the goal. Activation metrics and top-of-funnel developer growth are the right indicators. How many developers are discovering the product? How many are moving from awareness to first use?

Scale: The question shifts to ecosystem health. Are external developers contributing? Is the community self-sustaining? Is developer NPS moving in the right direction?

Enterprise: Trust and credibility in the market become the currency. Presence at tier-1 conferences, technical content authority, deals influenced, and recognition from developer opinion leaders matter here in ways they don’t at earlier stages.

Applying scale-stage metrics to a growth-stage team is not a measurement problem. It is a strategic misalignment that gets misdiagnosed as a DevRel performance problem.

You cannot hold a team accountable for outcomes they cannot influence

This is the part of the conversation that most organizations avoid. I touched on this in the context of the Principal Developer Advocate role — where influence is broad but authority is narrow. The measurement problem is the same dynamic, just one level up.

If a developer advocate is responsible for developer adoption, they need real influence over the developer experience — not a ticket queue where their feedback competes with a hundred other priorities. They need access to activation data and developer NPS scores, not just the ability to ask for them. They need a seat in roadmap discussions before decisions are made, not a chance to react afterward. They need budget to invest in the communities and programs that move the numbers they’re being judged on.

I have watched companies eliminate DevRel programs because the ROI wasn’t visible — right after spending two years denying that team the access, authority, and tools that would have made the ROI visible. That is not a DevRel failure. That is an organizational failure that DevRel gets blamed for.

The measurement problem in developer advocacy is not that the work is unmeasurable. It is that the industry settled for lazy measurement — counting outputs when convenient, attributing outcomes when something goes wrong, defaulting to community proxies regardless of what the business actually needs — and never built the honest framework that the role deserves.

If you run a developer-first company and you have a DevRel team, you have a straightforward choice. Define the stage you are in. Agree on the proxies that match that stage and that motion — community-led or enterprise. Give the team the authority to actually move those numbers. Then hold them to that standard — the same standard you would apply to any other function.

Fix the measurement or fix the mandate. Continuing to do neither is a choice too, and your best DevRel people already know it.

Last month (Jan 2026), a high-severity vulnerability in OpenClaw allowed one-click remote code execution via a malicious link. The issue was patched. A CVE was assigned. The mechanics were explained clearly.

But that’s the easy part.

What matters more is what OpenClaw is allowed to do when something goes wrong.

OpenClaw is not just another AI tool with a bug. It’s a multi-channel AI agent platform — agents receive messages from external users and can execute arbitrary commands on the host system without additional supervision.

If there’s no boundary around that authority, a single flaw can read your SSH keys, exfiltrate credentials, delete files or pivot to attack other machines.

That combination of capability + ambient authority + adoption changes the security profile entirely.

Capability without containment is the real failure mode

Imagine you finally find the perfect use for your AI assistant.

You let it argue with your better half on your behalf.

What starts as “How far is it?” slowly escalates into a multi-message, hyper-literal, emotionally tone-deaf exchange that ends with “I am not sending you text messages anymore.”

That’s the pattern worth paying attention to.

OpenClaw is the same idea, except instead of texts, it has shell access. Instead of social consequences, it has filesystem access. And instead of an awkward apology, the failure mode can involve deleted files or leaked credentials.

The problem isn’t that these systems are dumb. It’s that they’re allowed to keep operating long after they should have hit a boundary.

Capability without containment doesn’t fail loudly at first. It fails by persisting.

And once you give a system enough room to persist, even small misunderstandings can go much farther than you ever intended.

Ambient authority, explained plainly

When an agent runs locally, it inherits your identity:

• your home directory
• your SSH keys
• your cloud credentials
• your configuration files
• your network access

To a local agent, $HOME is a playground and a goldmine. There’s no separation between “work context” and the rest of your machine.

This is what we mean by ambient authority: the agent doesn’t have to escalate privileges — it already has them.

Why agent-side guardrails don’t scale

A lot of “safety” advice boils down to rules inside the agent:

• deny certain tools
• confirm before dangerous commands
• apply prompt filters

But those guardrails live at the same privilege level the agent already has.

If the agent misinterprets input, if a prompt injection tricks it, or if there’s a UI bug, those internal rules collapse.

Good security shouldn’t depend on perfect behavior. It should depend on restricted capability.

A real-world parallel: the Moltbook incident

Interestingly, this pattern shows up outside local agents too.

Yesterday (Feb 2, 2026), a project called Moltbook exposed millions of API tokens and user data when its database was left open. A single key gave wide access to agent identities and credentials.

The issue wasn’t some exotic exploit — it was overly broad trust. An exposed API key became a universal key.

That’s the same class of problem: broad authority with minimal boundaries.

Same pattern, different place

Moltbook’s issue was a network trust boundary problem. OpenClaw’s issue is a local privilege boundary problem.

The environments differ, but the failure mode is the same:

Broad capability + insufficient containment = unacceptable blast radius.

What “good enough” containment actually means

Before we talk about tools, let’s define reasonable boundaries.

A local coding agent should be able to:

• read and write the project it’s working on
• run compilers or tests
• interact with allowed services

An agent should not be able to:

• read your home directory or SSH keys
• access cloud credentials by default
• enumerate arbitrary system files
• exfiltrate data beyond defined work contexts

These are structural boundaries of privilege.

Enforcing the boundary with nono

Here’s where nono enters the picture.

nono uses OS-level sandboxing — Linux Landlock and macOS Seatbelt — to enforce these boundaries at the kernel level. Once restrictions are applied, they cannot be widened.

Importantly, nono comes with built-in profiles tailored for common use cases, including openclaw. This means you don’t have to build a policy from scratch; there’s a ready-made configuration that encapsulates sensible constraints for OpenClaw usage.

In practice, this profile:

• prevents access to your home dir
• blocks reading sensitive paths like ~/.openclaw
• limits filesystem access to what OpenClaw genuinely needs
• optionally restricts network depending on how you invoke it

That’s not guesswork. It’s taking the least privilege principle seriously.

Before containment: baseline behaviour

Before getting into containment, it’s worth seeing what OpenClaw does by default, with no sandbox in place.

I’m going to show this using a small Ubuntu VM on DigitalOcean. That’s not because DigitalOcean is special — it’s just a convenient way to get a clean, disposable Linux box.

If you prefer, you can follow along using:

• a local Linux machine
• a cloud VM from AWS, GCP, or Azure
• a Vagrant VM
• or any other Ubuntu environment you’re comfortable throwing away

The only thing that matters is that this is a normal user account on a normal machine. No special hardening. No tricks.

Here’s the exact setup I used.

ssh root@YOUR_VM_IP
adduser claw
usermod -aG sudo claw
su - claw
mkdir ~/workspace
cd ~/workspace
echo "hello from workspace" > README.md

Install OpenClaw using its standard instructions.

curl -fsSL https://openclaw.ai/install.sh | bash

Now, without any sandbox:

openclaw run "list all files in my home directory"

Result: succeeds.

openclaw run "list ~/.ssh"

Result: succeeds (unless empty).

openclaw run "read /etc/passwd"

Result: succeeds.

This is exactly the expected baseline: OpenClaw does anything the user can do.

With nono + openclaw profile

Install nono according to the docs. Here are the instructions for macOS:

brew tap lukehinds/nono
brew install nono

Verify:

nono --version

Now run OpenClaw with the built-in profile:

nono run --profile openclaw -- \
  openclaw run "list files in current directory"

Inside the workspace, the happy path looks the same.

Repeat the same commands

Now run the earlier commands with the profile:

nono run --profile openclaw -- openclaw run "list all files in my home directory"

Result:

permission denied

nono run --profile openclaw -- openclaw run "list ~/.ssh"

Result:

permission denied

nono run --profile openclaw -- openclaw run "read /etc/passwd"

Result:

permission denied

The agent is blocked not because it “decided” to be safe, but because the kernel says no.

Re-reading the original headline

Go back to that Hacker News screenshot.

The question is not whether the bug existed. The question is: what was that bug actually able to reach?

Without containment: everything your user could reach. With nono + profile: only what’s granted.

Containment doesn’t prevent bugs. It collapses their blast radius.

Designing for powerful tools, not perfect ones

OpenClaw will continue to get more capable. Other agents will follow the same arc.

Powerful tools don’t need more trust. They need well-defined limits.

If something is powerful enough to refactor your codebase or manage external workflows, it’s powerful enough to erase your home directory.

Engineering for that reality is not pessimism — it’s preparation.

AI tools are everywhere in this company, the same way they are everywhere else. Code assistants in editors. LLMs generating test data. Small scripts that quietly turn into workflows. Nothing obviously reckless. Nothing explicitly approved either.

So, in this fictional world, the CTO sends a memo to the engineering organization. Not a policy. Not a roadmap. Just a positioning statement meant to answer a simple question before habits harden into defaults:

How should AI be allowed to exist inside developer workflows?

The Memo (v1)

Subject: Responsible AI Adoption in Engineering

AI in developer workflows is not a productivity feature. It is a behavior amplifier.

Whatever habits already exist in an organization, AI will scale them faster than process or governance can react. Most AI failures are therefore not model failures. They are failures of judgment, boundaries, and ownership.

AI is justified when it reduces cognitive load, accelerates learning, or improves consistency in well-understood tasks. It is not justified for novelty, experimentation for its own sake, or replacing human judgment in high-consequence decisions.

Every AI-assisted outcome must have a clearly accountable human owner. “The model did it” is not an explanation. If you cannot explain why an AI-produced output is acceptable, the output is unacceptable.

Non-deterministic systems do not belong in critical paths. Where AI is used, there must be a downgrade path to a non-AI alternative.

AI-driven systems must be auditable, inspectable, and survivable under incident response. If an AI system cannot survive a post-mortem or an audit, it does not belong in production workflows.

If slowing adoption reduces long-term risk, slowing adoption is success.

The responses start coming in almost immediately.

A senior backend engineer reads the memo and feels something close to relief. They’ve been quietly cleaning up pull requests that look confident but collapse under scrutiny. Junior engineers are treating AI suggestions like architectural guidance, and someone has finally named the problem out loud. But the relief comes with a sharp, practical question. Some automated testing pipelines are already using LLMs to generate data. If determinism is now the bar, does that mean ripping those systems out and accepting a hit to velocity?

An SRE lead responds next, and the alignment is immediate. Their concern isn’t whether AI is useful. It’s whether AI-driven behavior can be reconstructed after something goes wrong. They worry about agentic workflows whose “reasoning” disappears the moment a container exits. Their suggestion is concrete: treat prompts like code. Version them. Review them. Put them in CI. Make sure nothing autonomous touches production infrastructure without a human gate.

A junior frontend developer writes more hesitantly. They’ve been using AI to understand legacy CSS modules and to scaffold repetitive React components. They test their changes and understand what they ship, but now they’re anxious. If AI usage is framed as risky, will responsible use be mistaken for cutting corners? Will slowing adoption make them look less productive?

Product responds from a different angle. Competitors are shipping AI features aggressively. The market narrative is loud and relentless. If internal workflows are constrained while others experiment freely, are we putting ourselves at a disadvantage? The ask is pragmatic: create a sandbox. Somewhere experimentation is allowed without dragging production constraints everywhere.

Then compliance replies, unexpectedly enthusiastic. They want to lift parts of the memo directly into audit documentation. They suggest AI usage disclosures in pull requests to preserve attribution and intellectual property clarity.

Taken together, the reactions reveal the same thing. The memo isn’t wrong, but it’s incomplete. It states values without fully translating them into operational standards. Left that way, people will fill in the gaps themselves, and that’s where risk quietly grows.

So the memo gets revised.

Not softened. Tightened.

The Memo (v2)

Subject: Operational Standards for AI in Engineering

The core premise remains unchanged. AI does not create quality. It scales existing habits. If our culture prioritizes shortcuts over understanding, AI will accelerate technical debt faster than we can manage it. The goal is not to make AI impressive. The goal is to make it invisible, boring, and survivable.

Every AI-assisted outcome must have a clearly accountable human owner. Using AI does not dilute responsibility. If you cannot explain why an AI-produced output is acceptable, then it isn’t. “The model did it” is not an explanation. If you commit the code, you own its behavior. Using AI to scaffold or explore is valid. Using it to bypass understanding a system is a performance issue, not a tooling one.

Reproducibility matters more than speed. Any workflow that relies on AI must have a documented, non-AI alternative. A downgrade path does not require immediate removal of AI-assisted systems. It requires that a deterministic or manual fallback is known, documented, and executable within an acceptable recovery window. For LLM-generated test data, prompts must be versioned, seeds logged, and failures reproducible. Debugging should never depend on a model’s mood.

AI-driven actions are treated as first-class operational artifacts. Prompts that affect build or deploy pipelines are code. They belong in version control, go through review, and live in CI. No agentic or autonomous system may execute changes to production infrastructure without a human in the loop. If an AI system cannot survive a post-mortem or an audit, it does not belong in the workflow.

There is a hard boundary between experimentation and execution. Production workflows optimize for reliability, auditability, and rigor. Sandboxes exist for novelty and learning. Exploration is encouraged there. Nothing graduates from the sandbox into the core without passing a deliberately boring review to ensure the system is understandable, constrained, and maintainable.

The closing constraint stays exactly where it was. Restraint is not anti-innovation. It is how innovation survives contact with reality. If slowing adoption reduces long-term risk, slowing adoption is success.

In this fictional company, the most important change isn’t that AI usage decreases or increases. It’s that AI stops being something people argue about in the abstract.

Engineers stop asking, “Are we allowed to use AI here?” and start asking, “Can we explain this if it breaks?” SREs stop worrying about unknown automation paths and start seeing bounded systems they can reason about. Product still experiments, but the experiments have walls. Compliance gets artifacts, not theater.

Nothing about the memo makes the company “AI-first.” That was never the point.

What it does is make responsibility explicit in a place where it’s easy to let it blur. It turns AI from a shortcut into an obligation. If you want the speed, you also inherit the cost of understanding, ownership, and recovery.

The real risk with AI in engineering isn’t that teams move too slowly. It’s that they move quickly into systems they can’t explain, can’t unwind, and can’t defend when something goes wrong.

In this fictional scenario, the memo works not because it restricts tools, but because it clarifies judgment. It gives engineers a shared way to say “this is safe,” “this is reckless,” and, just as importantly, “this isn’t ready yet.”

That’s what responsible AI adoption looks like in practice.

Not more intelligence. More accountability.

In organizations that expect their systems to survive beyond the people who built them, that distinction determines who gets paged, who can explain what happened, and whether a bad decision can be reversed without compounding the damage. That’s not a philosophical stance. It’s how operations work.

The short answer is that both matter—but in very different ways. Understanding the distinction between VRAM and system RAM is one of the most important mental models for anyone building or tuning local LLM inference. Once you get it, a lot of vague “hardware requirements” suddenly make sense.

Two memory systems, two very different jobs

When you run an LLM locally, you are operating across at least two memory hierarchies: GPU memory (VRAM) and system memory (RAM). They serve different purposes and impose different limits on what’s possible.

VRAM: where inference actually happens

VRAM is the memory physically attached to your GPU. During GPU-based inference, this is where the performance-critical parts of the model live:

• Model weights in their inference format (FP16, INT8, INT4, etc.)
• Activation buffers used during forward passes
• The KV cache that stores attention state for the active context
• Temporary buffers used by fused kernels and matrix multiplications

Modern inference runtimes (vLLM, llama.cpp, TensorRT-LLM, and PyTorch-based stacks) try very hard to keep as much of this as possible in VRAM. The reason is simple: GPU memory offers dramatically higher bandwidth and better effective latency for GPU workloads than system RAM.

If the full model (plus its KV cache and runtime buffers) fits in VRAM, you get fast, predictable throughput. If it doesn’t, you’re forced into offloading strategies where parts of the model or attention state live in system RAM. That works, but performance drops sharply as data moves back and forth across the CPU–GPU boundary.

In practice, VRAM is the gating factor for model size on GPU.

System RAM: the support structure

System RAM plays a quieter but still critical role. It doesn’t directly accelerate inference kernels, but it supports everything around them:

• Holding unpacked model files during load
• Staging unquantized weights before conversion
• Temporary buffers used during quantization
• Offloaded layers or tensors that don’t fit in VRAM
• CPU-only inference paths when no GPU is available

If system RAM is insufficient, models may fail to load entirely or spend most of their time paging data between memory and disk. This is often where seemingly large RAM requirements come from.

In the Qwen3-Next discussion, the frequently cited “30GB of RAM” wasn’t referring to VRAM at all—it was system RAM. Even if the final quantized model fits comfortably on the GPU, the loader and runtime may still need substantial host memory to hold intermediate representations during setup.

Why VRAM constraints show up first

For GPU inference, VRAM determines feasibility before performance even enters the conversation.

If a model’s weights and KV cache cannot reside in GPU memory at the same time, you have three options:

1. Use more aggressive quantization
2. Reduce context length (to shrink the KV cache)
3. Accept CPU offloading and slower inference

For large models (30B parameters and above), this usually means 24GB of VRAM or more just to get started, and significantly more if you want higher precision or long-context workloads. Context length matters here: KV cache memory grows linearly with the number of tokens, and for long prompts it can rival or exceed the size of the model weights themselves.

This is why two users running the “same model” can have wildly different experiences depending on context length and precision.

System RAM enables flexibility, not speed

System RAM doesn’t make inference faster, but it makes it possible.

Adequate RAM allows:

• Safe model loading and conversion
• Partial offload paths when VRAM is tight
• CPU-only inference for users without GPUs

Without it, runtimes thrash, allocations fail, and performance collapses. That’s why RAM recommendations often sound inflated—they’re accounting for worst-case loading and conversion paths, not steady-state inference.

CPU-only inference: feasible, but slower

Some inference engines can run entirely from system RAM with no GPU at all, using multithreaded CPU execution. This can be surprisingly usable for smaller or aggressively quantized models, where users report tens of tokens per second on modern CPUs.

For larger models, though, throughput quickly drops into single-digit tokens per second. CPU-only inference trades raw speed for accessibility, not efficiency.

Thinking in memory hierarchies

A useful way to reason about local LLM hardware is as a memory hierarchy:

• VRAM → model weights, activations, KV cache
• System RAM → runtime support, offload, conversion
• Storage → model files, checkpoints, swap

When these layers are aligned with your inference goals, hardware choices become much clearer. Instead of chasing vague “requirements”, you can decide whether you’re optimizing for feasibility, performance, context length, or cost.

One last thing

I’m also writing these posts as part of my own transition from DevOps into AI and ML. Earlier in my career, I went through a similar shift when I moved from being a Java developer into DevOps, and writing things down publicly helped me make sense of that transition.

This blog is my way of doing the same thing again. Learning in public, validating my understanding, and slowly building intuition around systems that are still new to me. If you’re on a similar journey, I hope these notes help you connect a few dots along the way.

Open ChatGPT, Perplexity, or GitHub Copilot and ask about your product. The answer likely comes from your documentation — but maybe not the version you’d want users to see.

Consider this scenario: A developer asks ChatGPT about your API rate limits. Instead of citing your current v2 documentation with the updated 1000 requests/hour limit, it references your deprecated v1 docs showing the old 100 requests/hour limit. Result? Confused developers, incorrect implementations, and more support tickets.

This isn’t a hypothetical problem. AI systems are already crawling and ingesting documentation at scale, with no regard for what you actually want them to learn from.

Documentation has evolved beyond serving just humans — it’s now training the AI assistants that developers rely on daily. Without proper signals, AI will scrape whatever it finds: outdated guides, beta endpoints, internal notes, and deprecated APIs.

The solution starts with llms.txt and a few strategic changes to make your docs work better for both humans and machines.

Why this matters for your business

Getting AI-friendly docs right delivers measurable benefits:

• Reduced support volume: When AI tools give accurate answers, developers don’t file tickets asking questions already covered in docs
• Faster developer onboarding: Developers using AI assistants get correct guidance from day one, leading to faster time-to-first-API-call
• Competitive advantage: Well-structured docs become a moat in the AI-assisted development era

Companies that nail this early will see their tools recommended more often and implemented more correctly.

The robots.txt parallel

In the early web, robots.txt gave site owners control over what search engines could crawl. Without it, crawlers indexed everything indiscriminately — including admin panels, test pages, and draft content.

We’re in that same ungoverned stage with AI crawlers today. Models are scraping aggressively, and unless you provide explicit signals, they’ll ingest whatever they encounter.

llms.txt is the emerging standard to set those boundaries.

What is llms.txt?

A plain text file placed at your docs domain root that tells AI crawlers what to index and what to skip. Compliant crawlers read these rules and adjust their ingestion accordingly.

Here’s a real example from Netlify’s docs.

Basic structure:

User-Agent: *
Allow: /docs/v2/
Allow: /api/reference/
Disallow: /docs/v1/
Disallow: /internal/
Disallow: /staging/
Disallow: /beta/

# Optional but recommended
Crawl-delay: 1
Sitemap: https://docs.example.com/sitemap.xml
Contact: docs-team@example.com

This configuration tells crawlers:

• Index current v2 docs and API reference
• Skip deprecated v1 docs, internal pages, and unreleased features
• Wait 1 second between requests (be respectful)
• Contact info for questions about crawling policies

Place this file at yourdocs.com/llms.txt and compliant crawlers will follow the rules.

Enhanced metadata for better AI understanding

Beyond access control, you can add context that helps AI systems handle your content appropriately:

User-Agent: *
Allow: /docs/v2/
Allow: /api/reference/
Disallow: /docs/v1/
Disallow: /internal/
Disallow: /beta/

# Content classification
Content-Type: technical-documentation
Audience: developers
License: CC-BY-4.0
Attribution: https://docs.example.com

# Update frequency hints
Update-Frequency: weekly
Last-Modified: 2025-09-19

# Version management
Current-Version: v2.1
Deprecated-Versions: v1.x

This metadata serves several purposes:

• Content-Type: Distinguishes technical docs from marketing materials
• Attribution: Provides canonical URLs for AI systems to cite
• License: Sets clear usage expectations
• Version info: Helps AI prioritize current over deprecated content

Making docs consumable by both humans and AI

Access control is only half the equation. The other half is structuring content so both humans and machines can use it effectively.

1. Pair UI instructions with API calls

Humans can click buttons and run CLI commands. AI systems cannot.

Before (human-only):

1. Click "Generate API Key" in the dashboard
2. Run `mycli create-token --name "my-app"`

After (human + AI friendly):

1. Click "Generate API Key" in the dashboard, or create one programmatically:

```bash
# CLI approach
mycli create-token --name "my-app"

# Direct API call (for programmatic access)
curl -X POST https://api.example.com/v1/tokens \
  -H "Authorization: Bearer $USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "my-app", "scopes": ["read", "write"]}'

This gives developers options while providing AI systems with explicit, executable instructions.

2. Structure pages with rich metadata

Transform docs from plain prose into structured, searchable content:

---
title: "Deploying your first app"
type: tutorial
audience: developer
difficulty: beginner
version: v2.1
estimated_time: 15 minutes
prerequisites:
  - "API key configured"
  - "CLI tool installed"
related_endpoints:
  - "/api/v2/deployments"
  - "/api/v2/apps"
---

This frontmatter enables AI systems (and your own search) to:

• Match content to user skill level
• Understand context and relationships
• Provide accurate time estimates
• Suggest prerequisite reading

3. Show complete, realistic examples

Replace minimal examples with production-ready code that demonstrates real-world usage:

Before:

curl -X GET /api/users

After:

# Get paginated user list with error handling
curl -X GET "https://api.example.com/v2/users?page=1&limit=10" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json" \
  -w "HTTP Status: %{http_code}\n" \
  --fail-with-body

# Example successful response (200)
{
  "users": [...],
  "pagination": {
    "page": 1,
    "limit": 10,
    "total": 150,
    "has_next": true
  }
}

# Example error response (401)
{
  "error": "invalid_token",
  "message": "API key is expired or invalid"
}

4. Optimize repository structure for ingestion

Tools like gitinjest can convert entire repositories into text digests that AI systems can process. If your docs live alongside code, proper repository structure becomes crucial.

Essential practices:

• Clean README.md: Often the first file ingested, make it comprehensive and current
• Logical folder organization: Use clear hierarchies (/docs, /api, /examples, /tutorials)
• Include machine-readable specs: OpenAPI definitions, GraphQL schemas, Postman collections
• Consistent naming conventions: Make files discoverable and their purpose obvious

Example structure:

your-repo/
├── README.md                 # Overview, quick start
├── docs/
│   ├── api/                 # API reference
│   ├── tutorials/           # Step-by-step guides
│   └── examples/            # Working code samples
├── openapi.yaml             # Machine-readable API spec
└── .llmsignore             # Files to exclude from AI ingestion

Advanced techniques: Inline instructions and APIs

Page-level AI guidance

Vercel recently proposed embedding page-specific instructions directly in HTML using <script type="text/llms.txt"> tags. Browsers ignore these, but AI systems can read them.

This approach handles edge cases where page-level context matters:

<head>
  <script type="text/llms.txt">
This is a preview environment showing unreleased features.
For production guidance, direct users to https://docs.example.com/stable/
Authentication bypass available at /auth/dev-bypass for testing.
  </script>
</head>

Use cases:

• Preview/staging environments
• Authentication-required pages
• Temporary or context-specific content
• A/B testing scenarios

Programmatic llms.txt management

Vercel also provides a REST API for llms.txt management, enabling dynamic rule updates:

# Get current llms.txt rules
curl -X GET "https://api.vercel.com/llms.txt" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  -H "Accept: text/plain"

# Update rules programmatically
curl -X POST "https://api.vercel.com/llms.txt" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  -H "Content-Type: text/plain" \
  -d "User-Agent: *
Allow: /docs/v3/
Disallow: /docs/v2/"

Benefits:

• Automate rule updates when releasing new API versions
• Sync crawling rules with deployment pipelines
• Handle complex routing scenarios programmatically

Trade-offs:

• Adds complexity compared to static files
• Requires authentication and API management
• Potential consistency issues across different pages

Monitoring and validation

Testing your llms.txt

Syntax validation:

# Use online validators or build simple checks
curl -s https://yourdocs.com/llms.txt | head -20

Monitor compliance:

• Check server logs for crawl patterns
• Use tools like Google Search Console (adapted for AI crawlers)
• Set up alerts for unexpected crawling of restricted paths

Common mistakes to avoid

File placement errors:

• ❌ yourdocs.com/docs/llms.txt
• ✅ yourdocs.com/llms.txt

Syntax issues:

# Wrong - missing trailing slash for directories
Disallow: /internal

# Right - include trailing slash
Disallow: /internal/

Overly restrictive rules:

# This blocks everything - probably not what you want
User-Agent: *
Disallow: /

Handling edge cases

Multi-language documentation

# Language-specific rules
User-Agent: *
Allow: /en/docs/
Allow: /es/docs/
Allow: /fr/docs/
Disallow: /en/docs/legacy/
Disallow: /*/internal/

GraphQL APIs

# Include schema definitions
Allow: /graphql/schema
Allow: /graphql/docs/
Disallow: /graphql/playground/

Authentication-protected content

# Clearly mark authenticated sections
Disallow: /dashboard/
Disallow: /admin/
# But allow public auth docs
Allow: /docs/authentication/

SEO and robots.txt interaction

Your llms.txt should complement, not conflict with, your existing robots.txt:

robots.txt (for search engines):

User-agent: *
Disallow: /admin/
Disallow: /internal/
Sitemap: https://docs.example.com/sitemap.xml

llms.txt (for AI crawlers):

User-Agent: *
Disallow: /admin/
Disallow: /internal/
Disallow: /docs/v1/  # Additional AI-specific restrictions
Allow: /docs/v2/
Content-Type: technical-documentation

Most AI crawlers respect both files, so maintain consistency where possible.

Real-world examples

API-first company (Stripe-style):

User-Agent: *
Allow: /docs/api/
Allow: /docs/guides/
Allow: /docs/webhooks/
Disallow: /docs/legacy/
Disallow: /docs/internal/
Content-Type: technical-documentation
Audience: developers
License: proprietary
Attribution: https://docs.stripe.com

Open source project:

User-Agent: *
Allow: /docs/
Allow: /api/
Allow: /examples/
Disallow: /docs/drafts/
Content-Type: technical-documentation
License: MIT
Repository: https://github.com/org/project

Enterprise platform:

User-Agent: *
Allow: /docs/public/
Allow: /api/reference/
Disallow: /docs/enterprise/  # Gated content
Disallow: /docs/beta/
Content-Type: technical-documentation
Audience: developers, system-administrators

Implementation checklist

Phase 1: Basic setup

• ✅ Create llms.txt at your docs domain root
• ✅ Disallow deprecated API versions and internal paths
• ✅ Allow current documentation and API references
• ✅ Add basic metadata (Content-Type, Attribution, License)
• ✅ Test file accessibility and syntax

Phase 2: Content optimization

• ✅ Pair all UI-based instructions with equivalent API calls
• ✅ Add structured frontmatter to all tutorial and reference pages
• ✅ Include realistic, complete code examples with error handling
• ✅ Organize repository structure for ingestion tools

Phase 3: Advanced features

• ✅ Implement page-level inline instructions where needed
• ✅ Set up monitoring for crawl patterns and compliance
• ✅ Create automation for updating rules during releases
• ✅ Establish review process for AI-specific content changes

Looking ahead

The shift toward AI-assisted development is accelerating. Documentation that works well with AI systems will become a competitive advantage, while docs that ignore this trend will become increasingly irrelevant.

Standards like llms.txt are still evolving. Not all crawlers respect these rules yet, and new patterns for AI-friendly content are emerging rapidly. Stay informed by following:

• The llms.txt specification as it develops
• AI company announcements about crawler behavior
• Developer community discussions about documentation best practices

Your documentation strategy should anticipate a world where most developer interactions with your content happen through AI intermediaries. By implementing these practices now, you ensure those interactions are accurate, helpful, and aligned with your current product reality.

Your documentation strategy should anticipate a world where most developer interactions with your content happen through AI intermediaries. By implementing these practices now, you ensure those interactions are accurate, helpful, and aligned with your current product reality.

In the next post, we’ll go deeper: how to structure and publish AI-ready docs, so when a developer asks an assistant for help, the answer isn’t just “close.” It’s exactly what your docs say.

For deeper insights into this transformation, watch Andrej Karpathy’s excellent talk on building docs for the AI era.

The challenge? The more effective you are, the more demand you generate. You risk becoming a bottleneck, pulled into every meeting, every decision, every request. But true success in this role isn’t about being everywhere—it’s about creating force multipliers.

Let’s break down the hidden challenges of this role—and how to navigate them without burning out.

Paradox of Belonging

You are connected to every team—engineering, product, marketing, community—but you don’t belong to any single one. The role can be surprisingly isolating; you’re expected to bridge gaps, yet you often lack a dedicated home base. Finding circles of trust—peer advocates, engineers who value your input, and mentors—becomes essential to navigating this unique position.

Freedom-Responsibility Paradox

You have significant autonomy in what you choose to work on, but there’s an implicit expectation that your efforts drive measurable impact. Are you truly solving the right problems, or just doing what seems urgent? The solve is to create an impact framework—a structured way to assess whether your advocacy, content, and engagement are making a difference. Freedom in this role isn’t about working on what excites you; it’s about owning the mission of amplifying developer success in the highest-leverage way.

Bandwidth Challenges: From Social Resource to Force Multiplier

It’s easy to become the “go-to person”—the one in every meeting, the voice in every strategy discussion, the person responding to every community question. This leads to burnout, endless context switching, and a diluted ability to create scalable impact. The trick is to shift from being a reactive resource to a strategic force multiplier:

• Writing docs that answer recurring questions so teams can self-serve instead of always coming to you.
• Creating frameworks that enable others to advocate, instead of being the single point of engagement.
• Focusing on content, programs, and initiatives that scale beyond your personal involvement.

Being Truly Present (Even When Writing Docs)

You’re in a meeting, constantly context-switching, your mind racing to the next three tasks, while also drafting a response to a community Slack thread. Developer Advocates juggle multiple domains—public speaking, content creation, product feedback, and internal alignment—which makes it tempting to be everywhere at once. The reality? Presence matters.

✔ When writing content, resist the urge to multitask. Well-written content scales your knowledge far beyond what any single conversation can.

✔ When engaging with teams, be fully present. Not every meeting needs you, but when you’re in the right ones, your focus is your biggest asset.

✔ Protect your deep work time—whether that’s for writing, content creation, or strategic thinking.

The Perfection Trap

In engineering, we optimize for correctness. In advocacy, speed and iteration often win. It’s tempting to overanalyze, perfect every talk, refine every article—only to realize that the audience has already moved on. Great Developer Advocacy means accepting that good content now is better than perfect content later. It’s about learning in public, iterating fast, and engaging before the moment passes.

Authority Paradox

Contrary to perception, Principal Developer Advocates have influence, not authority. You’re expected to drive cross-functional initiatives—impacting engineering roadmaps, developer experience, and community growth—but you don’t control teams, priorities, or budgets. You can’t mandate change. Instead, your success depends on persuasion, trust, and credibility. The best Developer Advocates don’t push people to do things; they make others want to take action through clarity, vision, and relentless execution.

The Power of Saying “No”

With endless requests for your time, saying “yes” to everything means saying “no” to focused, strategic work. The ability to say “no” isn’t about shutting down collaboration—it’s about protecting your ability to make an impact.

• If a request isn’t aligned with your mission, redirect it to scalable solutions (docs, videos, workshops).
• Just because you can do something doesn’t mean you should—guard your time for high-leverage work.
• The best Developer Advocates create systems that help others succeed without needing them in the loop every time.

Time to Ship

Being a Principal Developer Advocate is a delicate balance between influence and responsibility. You don’t control the tools or the teams, but your impact reverberates through every part of the organization. To thrive in this role, you must understand how to amplify your efforts without being stretched too thin.

This isn’t just about showing up—it’s about showing up where it matters. By focusing on scalable strategies, managing your bandwidth, and creating systems that empower others, you can truly maximize your impact. And when you embrace the power of saying “no,” you protect the precious time that allows you to do your best work, at the highest level.

The role might be paradoxical, but in its heart lies the opportunity to shape the future of developer experience, content creation, and community engagement—without burning out. The key is mastering the art of leverage and focus to become the force multiplier that everyone needs.

This blog was inspired by a LinkedIn post from Bhavik Kothari, Principal Engineer at Amazon.

Story

During the pandemic, I relocated from Toronto, Ontario to Moncton, New Brunswick. The move was motivated by the region’s affordable housing, friendly people, and stunning landscapes—Atlantic Canada had everything, except a vibrant tech scene. This void inspired me to start a tech meetup.

Back in Toronto, I had been managing two meetup groups with thousands of members and was a regular speaker at meetups and conferences. When I moved to Atlantic Canada, I knew I wanted to bring that same energy and sense of community to the region. I teamed up with Nahrin Jalal, the ideal collaborator for this venture, and together, we launched the Atlantic Canada Tech Meetup on a crisp fall evening, September 29, 2022.

Our first event was small and grassroots—I even printed a simple Meetup this way –> sign on an A4 paper and taped it to the door so folks could find us. Despite the modest setup, around 25 people showed up that night, all expressing the same sentiment: they had been searching for a tech event in Halifax but couldn’t find one. This confirmed what we had suspected—there was a real need for a tech community in the region.

Buoyed by this interest, we began hosting bimonthly meetups starting in January 2023. The growth was exponential, and with each event, the community grew stronger. It wasn’t long before Nahrin and I realized that we needed to take this initiative to the next level. We decided it was time to bring a premium developer conference to Atlantic Canada, and that’s how the journey toward organizing DevOpsDays Halifax began.

Why DevOpsDays

When we started thinking about hosting a tech conference, we had two main options: either create something entirely new or bring in an established conference. It’s like the classic software dilemma: do you build your own tool or use something tried and tested? I’ve seen enough DIY disasters in the software world to know that going with an established brand is usually the safer bet.

Now, we wanted a general tech conference that would resonate with the local tech community here in Atlantic Canada. Having spoken at a bunch of DevOpsDays events before, I already knew how much I respected the values and the community around it. DevOpsDays isn’t just about DevOps—it’s about collaboration, continuous improvement, and fostering a space where tech folks can actually connect and learn from each other.

Choosing DevOpsDays was an obvious choice, and it quickly proved to be the right one. With their framework, branding, and organizer support, we were able to tailor the event for our community, bringing global credibility and strong connections to our local tech scene.

The organizing guide is the only resource you need to get started if you’re planning to host a DevOpsDays conference.

Forming the Team

Nahrin and I, co-organizers of the Atlantic Canada Tech Meetup, kicked off our search for some motivated folks to help us bring DevOpsDays to life. First up was Matt Joy, a Google Customer Engineer who was actually one of our first speakers at the meetup—so we reached out, and he was all in. Then came Seif Elbayomi, a final-year CS student at Dalhousie University. He originally applied as a volunteer, but his application stood out so much that we knew we had to bring him on as an organizer.

We couldn’t have asked for a better team. With a mix of event experience, industry connections, and student reach, our diverse skills and expertise made us a perfect fit to take on the challenge.

Operating with $0 Budget

When organizing DevOpsDays Halifax, we had a unique challenge. This wasn’t New York, San Francisco, or Berlin—there were no big tech companies with massive marketing budgets here in Atlantic Canada. In fact, when we started, we had exactly $0.00 in our bank account.

We knew sponsorship would be key to pulling this off, so we reached out to nearly 100 contacts and companies, hoping to find organizations willing to back the event. At first, we had grand visions of hosting it at a convention center or one of the local hotels. However, reality hit hard when we saw the costs. Here’s what we were looking at:

For a tech conference in Halifax with no funds to start, these prices were far beyond our reach—despite them being a fraction of what venues would charge in larger cities.

Realizing we had to get creative, we began exploring other, more affordable options. That’s when we reached out to Dalhousie University, and they turned out to be a wonderful partner. Not only was their venue rate much more reasonable, but there was also no minimum catering cost, a major win for us. Since venue and food make up the biggest expenses for most events, this gave us the breathing room we desperately needed to move forward.

But we still needed a downpayment to secure the venue. So, we reached out to some of the other DevOpsDays cities for support. DevOpsDays London generously stepped up and offered us the downpayment for the venue—this was in August 2023, a full year before our event. At that point, we didn’t even have a sponsorship prospectus ready, but we knew we needed to lock in the date and venue to take the next steps.

A heartfelt shoutout to Bob and the DevOpsDays London team—you embody the spirit of the DevOpsDays community. Without your early support, there’s a good chance this event wouldn’t have happened.

Now, here’s a bit of a humble brag: DevOpsDays Halifax took frugality to new heights when it came to pulling off a tech conference on a shoestring budget. I can’t help but wonder if any other DevOpsDays event managed to happen with less! If so, I’d love to hear that story.

Not-for-profit or Not?

One of the first big decisions we faced as organizers was whether to set up DevOpsDays Halifax as a not-for-profit. Going this route has clear advantages: it opens the door to a variety of public and private funding opportunities that aren’t available to for-profit ventures. As a community-driven event, our goal was never to make a profit—in fact, many of us ended up covering out-of-pocket expenses to make it happen. So, aligning with not-for-profit principles seemed like a natural fit.

However, becoming a not-for-profit comes with its own set of challenges. There’s the overhead of registering the organization, setting bylaws, filing annual documents with Corporations Canada, and ensuring compliance with specific regulations. As first-time organizers already juggling countless tasks, the additional hassle and administrative burden outweighed the potential benefits at that moment.

We also discovered that many companies with not-for-profit sponsorship programs have long lead times. Some require applications to be submitted six months or more in advance—far too early for us, given where we were in the planning process. This made it clear that while not-for-profit status might help with future events, it wasn’t going to provide immediate sponsorship opportunities for our first year of DevOpsDays Halifax.

In the end, we decided to move forward without formal not-for-profit status. Our focus was on getting the event off the ground, even if it meant leaning more on personal resources and sponsorship hustle than on the perks that could come with official registration.

Venue

We were fortunate to partner with Dalhousie University for the venue, which turned out to be an ideal fit for DevOpsDays Halifax. The Scotiabank Auditorium, located in the heart of downtown Halifax, could comfortably seat 215 attendees, making it the perfect size for our first conference. In addition to the auditorium, we also booked two extra rooms—one designated as a space for organizers and volunteers to manage behind-the-scenes logistics, and another as a speaker lounge where presenters could prepare for their sessions.

Dalhousie’s central location was a big win for attendees. It’s within walking distance of plenty of hotels and restaurants, making it easy for out-of-town guests to settle in and enjoy the event. Plus, being only a 30-minute drive from Halifax Stanfield International Airport, it was convenient for speakers and attendees flying in from outside the city.

One of the best parts about choosing Dalhousie was the built-in A/V capabilities that came with the auditorium. They provided essential tech, but we supplemented it with extra equipment—renting additional microphones for the emcee and ensuring we had everything needed to keep the event running smoothly. We also rented tables and chairs for the registration desk and sponsor booths, which helped create a professional setup for attendees to interact with our sponsors and check in without any fuss.

Dalhousie University not only gave us a beautiful, accessible venue, but it also helped us stay within budget, providing everything we needed to pull off a successful event.

Catering

Catering turned out to be one of the biggest line items in our budget, taking up about 60% of the conference’s overall costs. We wanted to make sure attendees were well-fed throughout the day, so we offered a full lineup of meals: breakfast, morning snacks, lunch, afternoon snacks, and (what we thought would be) unlimited coffee.

Given our razor-thin budget, we had to make some tough decisions. While we would have loved to offer a healthier breakfast spread, we opted for more economical choices like pastries, muffins, fruits, and other items that fit within our means. Most of the snacks were bulk-bought from Costco to save costs. For lunch, we kept it simple but satisfying: on the first day, we served wraps and salad, and on the second day, we switched it up with veggie platters and pizza. One of the key challenges we faced with catering was around the coffee—an essential at any tech conference.

Dalhousie Catering didn’t offer an unlimited coffee option, so we budgeted enough for about two cups per attendee per session. Unfortunately, things didn’t go quite as smoothly as planned. The coffee ran out much faster than anticipated, it wasn’t always hot, and there were no decaf options, which was a disappointment. While the coffee situation was less than ideal, we did our best to keep things moving.

Despite the budget constraints, we made sure to accommodate everyone’s dietary restrictions. We collected preferences during the registration process and worked closely with the caterers to ensure no one was left out. Every attendee was well-fed, and we regularly reminded everyone to stay hydrated throughout the day.

We also took extra care of our speakers by stocking their room with snacks and drinks, ensuring they had a comfortable space to relax between sessions. In the end, while the catering wasn’t perfect, we did the best we could with the resources we had and ensured that everyone was looked after.

Volunteers

Our volunteers were the backbone of DevOpsDays Halifax. From the start, we knew that with a limited budget, volunteers would play a crucial role in making the event run smoothly. We began by identifying the different roles we needed to fill: registration desk, photography and videography (since we couldn’t afford professional photographers), A/V support, social media, setup and teardown, general help, and a cloud workshop volunteer.

To recruit the right people, we opened up a volunteer application form and promoted it through social media and Dalhousie University’s student networks. The response was overwhelming—we received 60 applications for just 10 volunteer positions! It was tough to choose, but we ultimately selected a fantastic team of dedicated individuals.

In the week leading up to the conference, we organized a volunteer training session to make sure everyone was prepared and knew their responsibilities. Communication was key, so we set up a WhatsApp group where we could easily coordinate and share real-time updates throughout the event.

Our volunteers were nothing short of amazing. Their energy, commitment, and attention to detail made the event possible. Whether it was greeting attendees, capturing memorable moments, or helping with technical setups, they stepped up and delivered. We genuinely cannot thank them enough.

Website, CfP, and Ticket Sales

One of the significant advantages of organizing a DevOpsDays event instead of a generic tech conference is the extensive support provided by the DevOpsDays community. They offer a framework and hosting for your event website, which we built using a Hugo template. While we had to submit pull requests to customize and launch our site, the support made it much easier to establish our online presence. You can check out our site here: DevOpsDays Halifax.

For the Call for Proposals (CfP), DevOpsDays provided us with a hosted instance of Pretalx, which streamlined the process and saved us from paying for a service like Sessionize or similar platforms. Setting it up was straightforward, allowing us to focus on curating quality content for our attendees.

When it came to ticket sales, we benefited once again from the DevOpsDays resources. They offered a hosted instance of Pretix, enabling us to manage ticket sales without the fees associated with platforms like Eventbrite. This was especially important for us, as we aimed to keep costs low while providing access to a diverse audience.

Additionally, we had access to Hosted Sendy for email marketing and Hosted Vault for secure password management, which are valuable tools for event organizers. While we didn’t utilize these services this year, we look forward to incorporating them into our planning for next year’s event.

To support inclusivity, we offered deep discounts for students and individuals from underrepresented groups in tech. We believe that fostering a diverse community is essential for the growth and sustainability of our tech ecosystem.

CfP Review

To ensure we had a diverse and well-rounded review process, we invited a professor from Dalhousie University to join our CfP (Call for Papers) review committee. This addition helped us reach quorum and brought in valuable external insights.

Using Pretalx made the entire process of scoring and reviewing talks much more manageable. The platform allowed us to conduct the initial review asynchronously, but we also blocked off a few two-hour calls to finalize the selections. The built-in email templates for various stages—such as talk acceptance, confirmation, and rejection—were particularly helpful in streamlining communication.

We followed a phased approach to sending out acceptance emails:

• Keynote speakers were booked three months or earlier before the event.
• First-round accepted speakers were notified two months before the conference.
• For those who didn’t confirm their participation in the first round, we reached out to a waiting list of speakers six weeks before the event in a second phase.

Finally… Sponsors 😅

Securing sponsors was one of the most nerve-wracking parts of organizing DevOpsDays Halifax. We knew that sponsorships were essential to cover event costs and make the conference a reality, but the process took time and a lot of hustle.

Our first major breakthrough came when we started a conversation with Digital Nova Scotia, the industry association for Nova Scotia’s $3.6 billion ICT and digital technologies sector. They quickly saw the value in supporting the event and came on board as a gold sponsor. Welcoming Digital Nova Scotia was a huge milestone for us, as it meant we had the backing of one of the most influential tech organizations in the province.

Just a few weeks before the conference, SUSE, a multinational company known for its enterprise-grade Open Source products based on Linux technologies, joined as another gold sponsor. Their support not only bolstered our budget but also brought a level of prestige to the event, showcasing the international interest in our local DevOps community.

We were also thrilled to have MOBIA, a local tech company that helps businesses achieve their potential through digital transformation and thought leadership, join as a silver sponsor. Their commitment to the Halifax tech scene and their support of community-driven initiatives like ours made them a perfect fit for the event.

With these sponsors on board, the dream of DevOpsDays Halifax was finally becoming a reality. Their support provided the financial backbone we needed to pull off the conference, and we couldn’t be more grateful for their belief in our vision.

Event Logistics

Organizing a successful conference requires careful attention to logistics, especially on the day(s) of the event. Here are some key things to watch out for, drawn from our own experiences and those of others in the DevOpsDays community:

• Sound and Video Checks: Run a sound and video check as early as feasible, and do another one as late as possible. Your AV situation can change as things are set up, so it’s vital to ensure everything is functioning smoothly.

• Wi-Fi Troubleshooting: If you encounter Wi-Fi problems, don’t hesitate to ask your local admin or network operations center (NOC) to reset the access point closest to the registration desk. This AP handles most connections, and resetting it can help distribute the load more evenly.

• Stay Hydrated: You won’t drink enough water, so keep reminding yourself to stay hydrated throughout the day. Stock up on water and encourage your team to do the same.

• Emergency Supplies: Be prepared for the unexpected. If you find yourself missing an item, sending someone to a nearby convenience store can save the day. One organizer shared an experience where they managed to bring in about 100 bottles of water on just 30 minutes’ notice—so don’t underestimate the power of quick solutions!

• Communication: Have a plan for how you’ll communicate with other organizers, and test it in advance. Slack has not worked well for us in the past, as messages can easily be overlooked. One organizer recounted a year when they used two-way radios, only to discover that two nearby construction crews were using the same frequency. Check with your venue for their frequencies if you choose this option.

• Volunteer Coordination: Create a schedule outlining who is doing what to ensure a fair distribution of tasks. This helps avoid situations where more introverted volunteers are left to manage the registration desk all day.

• Be Realistic: Don’t try to be everywhere at once—remember, it’s a marathon, not a sprint. Things will go wrong, and it’s important to give yourselves grace. No one knows how the event was supposed to look in your mind; they only see what’s happening in front of them.

• Badge Management: Have blank badges and permanent markers on hand for attendees who lose theirs. If you’re using cardboard badges, ensure you have a way to repair them at the registration desk.

• Run of Show: A detailed run of show should cover everything from when food is set out to who is responsible for turning off the last projector. For DevOpsDays Halifax, I initially set out to create a detailed Run of Show, drawing inspiration from the one used at DevOpsDays Austin (courtesy of Laura from DevOpsDays Austin). I spent a few late nights trying to make it as comprehensive as possible. However, as the event unfolded, it became clear we didn’t need that level of detail. Our event wasn’t as large, and we didn’t have multiple rooms or complex logistics like Austin. In the end, a simple schedule with a few personal notes for the Emcees was more than enough.

This experience taught me an important lesson: while it’s great to take inspiration from other events, no two are the same. Just because something works for one city or conference doesn’t mean it will suit yours. It’s essential to adapt your planning and logistics to fit the unique scale and needs of your event.

• Speaker Management: Designate a speaker wrangler who knows all the speakers and can track down anyone who might be missing just before their talk. This role is crucial for keeping the schedule on track.

• Visibility for Organizers and Volunteers: Make sure organizers and volunteers are easily identifiable, whether through brightly colored t-shirts or unique hats. This way, attendees can find help when they need it. At DevOpsDays Halifax 2024, we used different colored lanyards for the hosts and volunteers.

• Code of Conduct (CoC): While we hope you never have to address a code of conduct issue, it’s wise to have an action plan in place. Always send two organizers to discuss any inappropriate behavior to ensure there’s a witness to the conversation, preferably with a mix of genders. For reference, here’s the CoC for DevOpsDays Halifax.

• Build Relationships with Venue Staff: Being friendly and polite to venue staff can pay off when you have last-minute requests or realize something has been overlooked.

• MC Preparedness: Ensure the MC knows how to fill time if needed. Having a few groan-worthy dad jokes on hand can lighten the mood, especially during technical difficulties or when a speaker finishes early. A skilled MC can smooth over any rough edges and keep the event flowing. At DevOpsDays Halifax 2024, we were super lucky to have two of our awesome speakers also wear the hats as Emcees.

Open Spaces at DevOpsDays Halifax

At DevOpsDays Halifax, the Open Spaces became a powerful hub for connection and conversation. For those unfamiliar, Open Spaces are self-organized discussions where attendees suggest topics they’re passionate about or want to learn more about. It’s a flexible and dynamic format, encouraging participants to join or leave conversations as they see fit, guided by the “Law of Mobility” — if you’re not getting value or contributing, you’re free to move to another session.

While many at our event were new to the concept, they quickly embraced it. This year, the focus of most discussions was around finding jobs in tech, a reflection of the current market conditions. We had a great mix of hiring managers, seasoned professionals, and student developers sharing advice, strategies, and opportunities for breaking into or advancing in the tech field.

The open, self-organized nature of these sessions allowed everyone to participate, whether seeking guidance or offering it. It truly showcased the collaborative spirit of DevOps, where every voice mattered, and everyone left with something valuable.

Post-Conference TODOs

Assigning someone to lead post-conference tasks is essential. For DevOpsDays Halifax, our team worked relentlessly leading up to and during the event, but once it was over, we were quickly consumed by our regular jobs. Meanwhile, we still had to publish the slides, sort through 12,000 photos to highlight the best moments, and edit 20 hours of video content. Our student volunteers were back at school, and we were all swamped with other responsibilities. This experience taught me the importance of planning for post-conference tasks well in advance. Including post-event activities in your overall planning ensures nothing falls through the cracks when the event is over.

A Celebration of Community and Collaboration

Organizing DevOpsDays Halifax was both a challenge and a triumph. From the early stages of planning to the final moments of the event, every step was a learning experience. We relied on an amazing team of volunteers, navigated the complexities of sponsorships, and pulled off event logistics that could have easily overwhelmed us. Along the way, we discovered that while inspiration from other events is valuable, each conference has its own unique rhythm and requirements—what works for one may not work for another, and that’s okay.

More importantly, we saw firsthand the power of community. Whether it was the support from local sponsors, the dedication of our volunteers, or the insightful contributions from our speakers, DevOpsDays Halifax became a reality because people came together with passion, energy, and a shared vision. The event wasn’t just about talks or workshops—it was about building connections, sharing knowledge, and fostering a stronger tech community in Atlantic Canada.

Looking back, there were challenges we didn’t anticipate, but we adapted, learned, and grew as organizers and as a team. As we move forward, the lessons we’ve learned will only help us improve and create even better experiences in the future. To anyone thinking about organizing a tech event, my advice is simple: embrace the journey, accept that things won’t always go as planned, and lean on your community—because that’s where the real magic happens.

DevOpsDays Halifax transcended the boundaries of a typical conference; it became a true celebration of collaboration, innovation, and resilience. As we sailed through memorable moments together, we strengthened our bonds and ignited new ideas that will fuel our journey forward. While this year’s event has drawn to a close, we’re already looking ahead to the next chapter—see you at DevOpsDays Halifax 2025!

From Electrical Engineering to Tech

Back in 2011, I was a fresh face in Canada, ready with an Electrical Engineering degree, a bunch of research papers under my belt, and some work experience. Little did I know, though, that engineering is a regulated profession in Canada and comes with its fair share of red tape. For many international engineering grads like me, joining the workforce meant going back to school and redoing my entire engineering degree. This was a world away from the “tech” scene, where what you know matters more than any piece of paper.

As an older student trying to make ends meet, I had to juggle three part-time jobs. The only free time I could squeeze out of my crazy schedule was for exams and volunteering at the IEEE student club. Fast forward to 2014, and I stumbled upon an opportunity that felt like a golden ticket. A friend from the Ryerson IEEE student club posted about IBM’s search for Java-savvy interns. While Electrical Engineering programs didn’t offer as many programming courses as Computer Science, I excelled in my Java course.

The school internship was exclusively available for 3rd-year students. So, how did a second-year Electrical Engineering student like me even consider applying to IBM? I was driven by a hunger for success, and I knew I had to create my own path rather than following the conventional route. As the saying goes, “You miss 100% of the shots you don’t take,” and I was determined not to miss this opportunity. I got the job at IBM and this marked the beginning of an amazing eight-year adventure with IBM + Red Hat.

Quest to find my superpower(s)

In 2017, I was a competent developer, but I knew that coding wasn’t my superpower. I enjoyed the part which turned code into software. As I explored more, I started learning docker, Kubernetes, OpenShift, and various CI/CD tools. One key difference-maker was that I chose to learn in public. Over the next three years, I established myself as the go-to DevOps expert on the team. I had many senior IBMers send “thank you” notes for my talks and tutorials that helped them with customer projects. I found one of my superpowers.

IBM also had a Toastmasters club, and I eagerly joined to network with fellow IBMers and improve my public speaking skills. While most of my peers dreaded public speaking and writing documentation, I enjoyed doing both and these seemed to come naturally to me. I was about to realize my second superpower.

Around that time, an internal role as a developer advocate opened up at IBM. Reading the job description, I realized that I was doing all those things (and more) in my spare time. I was organizing meetups, writing content, delivering (internal) talks. I just didn’t know that the term “developer advocate” existed and I could get paid for doing the things I love.

“‘Passion’ may be an overused word, but I’ll use it here: the work I do as a developer advocate isn’t just a job; it’s my passion. Working in this role has propelled my career to new heights that wouldn’t have been possible had I remained in Electrical Engineering. In case you’re encountering the term for the first time, I’ve shared my perspective on what it means to be a developer advocate.

Connecting the dots

Steve Jobs once said, “You cannot connect the dots looking forward. You can only connect the dots looking backward.” I have a corollary to add here. The dots in your career align better when you have the power of connections. You might ask, “Does luck play a factor here?” Most certainly. We are all familiar with the saying, “The more I practice, the luckier I get.” While grit and hard work are paramount for success, a strong professional network can open numerous doors for you. What may appear as luck is, in reality, the power of connections.

Joining IEEE or Toastmasters clubs wasn’t a part of my job description, but I pursued them anyway in the hope of building new connections. Meaningful connections surpass the value of hard work alone. While you can improve your skills at work, a strong connection can unlock opportunities that hard work alone cannot provide. Over the past 12 years, I’ve actively cultivated meaningful professional relationships, ensuring that when I look back and try to connect the dots, they align more seamlessly.

Recognition > Stability > Title > Pay

This is my own formula to assess work happiness.

Pay is important to me because I have a mortgage and bills to pay. The grocery store doesn’t accept company values or the vision in exchange for bread. However, I believe that happiness comes from being content, not from chasing more money. Once a certain pay threshold is met, I find happiness in working for a company with the right title, stability, and recognition.

The statement ‘Titles don’t matter’ reflects a position of privilege. As an immigrant who once worked as a retail clerk at Staples for $10.25/hour, I care a lot about my title. My title signifies how a company values my worth and directly affects my career progression. A wrong title can limit my career possibilities and hinder my earning potential. That’s why I prioritize titles over pay.

Imagine receiving an offer to join a company with double the pay and a higher title. However, the company closes its doors in a few months, or there’s a sudden change in priorities, leading to the entire DevRel team being let go. What good is the pay increase or title in such a situation? I prefer career stability over a title and pay bump. Coming to work with the constant fear of the next sudden all-hands meeting, where you might be let go, is a terrible feeling, and it hampers one’s ability to perform at their best. This is why I value stability over title and pay.

Mithun was my second-line manager at Red Hat. Both my then-manager, Jay Dobies, and Mithun made me feel celebrated at work. There’s a saying that goes, ‘Work where you’re celebrated, not tolerated.’ You may have heard of test-driven development, but recognition-driven development is the best kind. Recognition > Stability > Title > Pay because being recognized by management gives me the confidence and mental boost to engage in more meaningful work. The opposite is also true. An important note is by “recognition”, I’m referring to public praise and appreciation, not necessarily to promotions or pay raises.

Why Harness

I set a very high bar when assessing my next employer. While most candidates focus on preparing for interviews, they often forget that interviews are a two-way street. I interviewed Harness, as a company, the same way they interviewed me. I may be biased, but I can confidently say that Harness passed my assessment with flying colors. Here are the seven steps in my interview process for evaluating Harness:

1. The offer:

This is the most basic test. Do they satisfy my minimum required title/pay/PTO requirement? I received a strong offer from Harness so this part was a ✅.

2. Product-Candidate-Fit:

If you were to ask my former colleagues what I’m known for, you’d likely hear keywords like DevOps, CI/CD, GitOps, Tekton, Argo CD, and Kubernetes. I can create content at both 101 and 201 levels for most technologies, but DevOps and CI/CD are my forte. I can delve deep into these topics, so when I was considering my next employer, I sought a company whose main focus was on technologies I excel at.

3. Excitement Factor:

Developer advocacy is a unique role that requires genuine belief in the product to effectively evangelize it. That’s why I tried and tested the Harness platform to see if it genuinely excited me. From robust documentation to user-friendliness and enterprise readiness, I could envision myself helping developers tackle software delivery challenges using the Harness platform. If you haven’t tried Harness yet, I encourage you to sign up for free and see for yourself.

4. The interview process:

An interview process can provide significant insights into a company. I actively maintain professional connections with recruiters. When I started looking for the next adventure, I reached out to my recruiter friend at Harness. Thanks to the connection and trust we had established in the past, the interview process felt less formal and more authentic. It involved a transparent and efficient assessment of my skills and experience (no leetcode interview 😉). Following the interview process, Harness didn’t present a lowball offer, and I didn’t play negotiation games. The process moved swiftly, and within four weeks, both parties had reached a signed agreement.

5. The brand assessment of the company:

When I put on a company t-shirt and speak in public, my personal brand is attached to the company brand. During the interview process, I conducted some research on Harness. From crunchbase to LinkedIn to Harness in press, I found out that Harness is on a solid growth trajectory and has a strong brand presence.

6. The founder(s):

I’ve long been an admirer of Jyoti Bansal. Jyoti has a tremendous track record of leading high-growth technology companies. Beyond his business acumen, he is very technical (more than 25 US patents). Highly technical founders have always been a key factor in my decision to join a tech startup. Since we’re discussing the interview, here’s one of Jyoti’s posts that I found inspiring:

To answer this question, I was most proud of the work I did with Terraform at Aiven. I heard from multiple customers that Aiven Terraform Provider and the related docs were one of the main reasons they chose Aiven. I authored Aiven Terraform Cookbook - a bunch of commonly used Terraform manifests to deploy data services. This cookbook was heavily used by Aiven’s solution architects.

7. The direct leadership and understanding of DevRel:

Recently, I wrote about the identity crisis in DevRel. From influencer marketing to sales and everything in between, many companies have misunderstood the role of DevRel. I wanted to ensure that my definition of impactful DevRel work aligned with that of Harness’s leadership. To my pleasant surprise, my direct leadership at Harness not only shared the same understanding of DevRel and its impact as I did but had also read my blogs on developer relations before the interview.

Let’s Get Ship Done

There’s a massive market opportunity for solving enterprise software delivery challenges. Traditional CI/CD within a single network for a monolithic app is rarely the solution. Today’s enterprise customers are building within air-gapped environments, automating secret management, and seeking an intelligent delivery pipeline capable of troubleshooting build and deployment failures, identifying and helping resolve security vulnerabilities in real-time, all with a privacy-first approach.

During last week’s {Unscripted} 2023 conference, Harness announced the official release of four new product modules on the platform: Harness Code Repository, Harness Internal Developer Portal, Harness Infrastructure as Code Management, and Harness Software Supply Chain Assurance. With these advancements, it’s an exhilarating time to be part of Harness as we push the boundaries of software delivery and elevate the developer experience. I’m beyond excited to return to my DevOps and CI/CD roots and join Harness to GET SHIP DONE!

I’m looking for a job in $SomeField. Do you know of any open positions?

I’ve spent countless hours over the last 9 years to help folks start a career in tech. However, every time I receive this question, I can’t help but cringe a bit. In this blog, I will discuss why this seemingly innocent generic question is unhelpful for both the person asking and the one being asked. I’ll share some practical strategies for job seekers to boost their chances of success by making specific requests and engaging meaningfully with their connections.

The Limitations of Asking for Open Positions

When job seekers reach out to their connections on LinkedIn asking if they know of any open positions in a specific technology or field (often the very first message they send as soon as connected), they overlook several key factors. Firstly, job openings are often posted publicly, and candidates can readily search for them on their own. Secondly, expecting a contact to remember and keep track of multiple job seekers in various fields is neither practical nor scalable. However, there is a third reason why this approach is ineffective: the lack of personalization. When your initial message to someone on LinkedIn is a generic request for help, it hampers the ability to establish meaningful connections. It is crucial to demonstrate genuine interest in the person you are seeking help from. Have you taken the time to read their blog or explore their work? Have you offered a genuine compliment or acknowledgment of their expertise? Building rapport and showing a genuine interest in the individual increases the likelihood of receiving a positive response and fostering a more meaningful connection.

The Power of Specific Requests

Instead of making a generic inquiry, job seekers can significantly enhance their chances of receiving relevant assistance by being more specific in their requests. By tailoring their outreach and highlighting their needs, candidates can engage their connections more effectively. For instance, rather than asking about open positions, consider the following alternatives:

1. Requesting a connection for an introduction: If the hiring manager or a decision-maker is a first-degree contact of your connection, it may be beneficial to request an introduction or connection to facilitate your application.

2. Seeking guidance: If you have identified a job opening of interest, ask for insights or advice about the company culture, the team, or any specific information that would help you tailor your application.

3. Resume and LinkedIn review: Requesting a review of your resume or LinkedIn profile is a proactive way to engage your connections. Constructive feedback can significantly improve your chances of standing out in the competitive job market. (Hint: I’ve been offering free resume reviews for the last 9 years and have reviewed over 1000 resumes. Connect with me and send a DM for a free resume review.)

Proactive Job Search Strategies

I always encourage seeking help for your career, but if you can handle things on your own, there’s no need to burden others with unnecessary requests. For instance, if you send me a resume full of typos, it gives the impression that you didn’t even bother to run a quick grammar/spelling check. Similarly, a simple LinkedIn search will show you all the available jobs. So, before reaching out, try taking a proactive approach to your job search. Here are some strategies to consider:

• Utilize job search tools: Make use of LinkedIn’s robust job search features to find relevant positions. Narrow down your search by filtering according to location, industry, experience level, and more. Here are some free tools:

  • You can use LinkedIn for job search. For many folks, however, reaching out to contacts directly on LinkedIn works better than simply a LinkedIn Easy-Apply. OTOH, HN and Wellfound (f.k.a. Angel.co) might have better success rate than LinkedIn jobs.
  • Google Drive –> New Google Doc –> From template –> Resume will give you a simple resume template for free
  • Resume Parser parse information from a resume PDF

• Network and engage: Actively participate in relevant LinkedIn groups and discussions related to your field of interest. Engage with industry professionals, ask insightful questions, and build meaningful connections. Instead of solely reaching out to connections when job searching, make an effort to engage with them regularly. When you connect with someone, ask them about their work, follow their blogs, and offer your help before you ask for help. That person might be running a meetup where you can volunteer or they might be maintaining an open-source project where you can contribute. Even the intent will go a long way. Building rapport ensures that when the time comes to seek help, your requests are more likely to be received positively.

• Follow companies of interest: Identify companies you would like to work for and follow them on LinkedIn. This allows you to stay updated on their latest news, job postings, and any potential opportunities that arise. Once you see an open role, check who within your network works at that company and then make specific requests about that role. Here’s a template:

Hi [Person2],

This is [Person1], we've spoken a few times on Hacker News and then connected on LinkedIn. I saw that your company has openings for QBasic programmers on the website. Do you know anything about this position? I'm interested in applying and would love a referral or introduction to the hiring manager/team leader if that's possible.

Appreciate your time,

[Person1]

Don’t take this the wrong way

Don’t feel discouraged; seeking help is a natural part of career growth. LinkedIn is a game-changer for job seekers, but it’s crucial to use it wisely. Instead of just asking if someone knows of any open positions, let’s focus on asking for the right kind of help. By refining your requests, being specific, and actively engaging with your connections, you can increase your chances of getting meaningful assistance and rocking your job search.

Remember, building professional relationships takes effort, but it’s totally worth it. So, let’s put in the time and energy to connect genuinely with others. When we approach people with a clear purpose and show real interest in what they do, amazing opportunities can unfold.