06-reference

commoncog career moats chapter 3 what is valuable

Tue Apr 14 2026 20:00:00 GMT-0400 (Eastern Daylight Time) ·reference ·source: Commoncog ·by Cedric Chin

“What is Valuable?” — @CedricChin

Why this is in the vault

Chapter 3 of the Career Moats Guide is the operational “how” to chapters 1-2’s “why”: if moats must start from demand, then you need a perch — a vantage point from which to observe what your market actually wants. This piece lands at exactly the right moment for RDCO, because Ben is currently evaluating phData vs MG vs going full-time on Ray Data Co, and Chin’s “find a perch” frame is directly useful for consulting positioning. It also gives us language (“less-legible skillsets,” “the shape of all possible careers”) for why the agent-deployer bet looks right now rather than in two years.

The core argument (paraphrased)

You can’t build a moat without first understanding demand, and you can’t understand demand without a perch inside your industry.

Chin’s framing: the question every career-moat-builder needs to answer is “What roles are very important or valuable in my industry, but difficult to hire for?” That question cannot be answered from the outside. “You really only know what is rare and valuable when you’re embedded.”

A perch is any vantage point that lets you see the shape of demand. Chin enumerates five:

  1. Jobs as perches. Working inside a company gives front-row seats to hiring pain. Even as a non-manager, volunteering to interview candidates is a cheat code — every interview is a probe into a competitor’s org. Mark Roberge’s tactic: interview at least one person from every company in your region, even mediocre candidates, to map the labour market.
  2. Industry conferences and meetups. The real value isn’t the talks — it’s the peripheral dinners, cocktails, and after-parties. The “second beer rule”: people talk candidly about the truly valuable stuff once they relax. Three killer questions: What’s working at X like? What’s the hardest role your team is hiring for? How much should I pay a Y?
  3. LinkedIn networking — low-engagement norms let you maintain a small set of high-quality industry friendships over years. Don’t automate the outreach.
  4. Job-description inspection — Nick Moore’s database approach. Good for mapping entry-level skills; weaker for spotting what’s rare and valuable. Patterns over time matter more than any individual listing.
  5. Being a conference organiser — time-expensive but buys credibility in a local scene.

Chin then generalises: evaluate any information source along accuracy, timeliness, effort. A university professor has low accuracy on current demand; an active hiring manager has high. Collect multiple sources to triangulate. Match your cadence to your industry’s cadence — most industries shift on yearly (not monthly) timescales.

The punchline, which Chin makes explicit: “starting from demand means starting with the territory.” Everything else in the guide (picking which moat, testing whether it stays rare) is downstream of this.

A subtle but important thread: Chin is describing what the literature calls informational interviews, but reframed as a disciplined intelligence-gathering practice rather than job-hunting etiquette. The reframe matters — most people do informational interviews episodically when between jobs. Chin is prescribing it as continuous industry telemetry.

Mapping against Ray Data Co

This chapter is unusually load-bearing for the current decision (phData / MG / RDCO full-time). Four mappings:

1. The three options map onto three different perches, with very different visibility into demand. phData is a jobs-as-perch in the agent-deployer / data consulting space — Ben would see, daily, which engagements enterprises actually pay for, which skills are painful to hire, which roles are mis-scoped. MG is a narrower perch (one company’s internal data needs). RDCO full-time is a conference-organiser-style perch — you see the market only through whoever happens to book you, which is a biased sample early on. Chin’s framework suggests the phData perch has the highest accuracy on agent-deployer demand specifically, at the cost of more effort and slower cadence. This is not an argument for phData over RDCO, but it is an argument that full-time RDCO is perch-poor until a referral flywheel kicks in — which means a deliberate secondary perch (conferences, LinkedIn calls with data leaders, interviewing for roles you don’t want to take) needs to be baked into RDCO’s first 90 days if that’s the path.

2. Agent-deployer literacy is currently a “less-legible skillset” — that’s the moat window. Chin’s whole guide is built on the premise that the valuable skills are the ones the market hasn’t figured out how to name yet. Per 2026-04-14-levie-agent-deployer-role-jd, the JD for this role exists (Levie), but it isn’t yet a recognised function with standard titles, comp bands, or hiring playbooks. Enterprises will realise they need it — the window is the gap between now and when HR catalogues catch up. Chin’s framework: if you can see the demand before the market names the role, the moat is unusually cheap to build.

3. MAC is a less-legible skillset that becomes legible as enterprises realise they need it. The MAC (Model Acceptance Criteria) framework described in ../04-tooling/rdco-state-ownership-architecture and ../01-projects/data-quality-framework/testing-matrix-template sits in the same not-yet-named zone as the agent-deployer role. No RFP says “we need MAC.” They say “we need data quality” or “we need AI evals” and then blow up on the second production incident. Chin’s move here is to find the specific operational pain the less-legible skill solves, and market toward the pain, not the skill. For RDCO that means pitching “stop your AI agents from silently corrupting the warehouse” not “we do MAC consulting.”

4. The “second beer rule” and the three questions are immediately actionable. Ben attends a handful of data/AI events per year. Chin’s three questions (what’s working at X like / hardest role to hire / how much should I pay a Y) should replace whatever he’s currently doing at those events. In particular the “how much should I pay a Y” question is a cheat code for price discovery on the agent-deployer / MAC consulting engagement — it surfaces real budgets without asking anyone to quote you.

One thing this chapter challenges us on: Chin is explicit that you need multiple perches, and that a single job is insufficient. If Ben takes phData, that is a perch, not the perch, and he still needs conference/LinkedIn/interview perches running in parallel. If he goes RDCO full-time, the perch problem gets worse, not easier, because client sampling is biased toward whoever already knows him. Either path requires deliberate perch diversification. Worth naming in the decision doc.