Initiative framework

A closed loop toward revenue.

Each initiative feeds the next. The cycle is self-reinforcing. Implementation enables operations, operations feeds customers, customers fund everything.

Implementation

~20% cap

Tooling, infra, build speed. Names what it protects.

Tyler · Gibby

Operations

Capacity

Capacity planning, workflows, and delivery operations.

Gibby · Wes + Tyler

Customers

Most direct

Sales and delivery as one continuum. The client pays.

Wes · Gibby

Attribution Rule

Work attributes to the initiative whose revenue it serves, not the function that does it.

A client feature built by Tyler files under Customers. Site work files under Operations. The build is just how they get done.

Engineering is a capability all three draw on, not a bucket.

Revenue Gate

Every ticket carries a hypothesis and a directness rank.

If nobody can articulate any revenue hypothesis, that silence is the answer and the work stops at hour zero.

How Ownership Works

Each initiative has a DRI, one directly responsible individual. A secondary provides backup and continuity.

Customers

Wes

Gibby

Operations

Gibby

Wes + Tyler

Implementation

Tyler

Gibby

Operating principle

Transparency by default.

Make transparency the path of least resistance. The goal is for staying visible to be easier than going dark, not for us to track our work because we're told to.

The problem

Our work is invisible. We don't know who is working on what, or how far along it is, until it lands in a done state.

Today we have no ability to forecast capacity. We can't see what's in flight, so we can't say what we'll finish or when, or whether two of us are solving the same thing.

We also have no way to track the importance of what's already on the board. The backlog grows, but nothing tells us what actually matters, so everything competes for attention equally and the signal gets lost.

The principle in one example

If someone wants to reduce duplicative effort, they can come to each of us and ask what we're working on, then look for overlap. That works, but it only works when they ask, and you have to stop and answer.

Or you can tell the system what you're working on before they ask. The effort to you is the same. Only one of those can be automated. We are building the second one.

Done looks like

We can answer "what is everyone working on" without asking anyone.

  • Every piece of in-flight work is visible early enough for the team to weigh in before it ships.
  • The effort to stay visible is close to zero, because the agents and the digest do the bookkeeping.
  • Nothing surfaces for the first time as a failed deploy.
Why this matters

We sell governance and operational excellence. Our own internal workings need to be an example of what we can provide. If we can't run ourselves this way, we can't credibly sell it.

What this is not

This only gets as far as we take it. The system can make visibility cheap, but it can't make us choose it. The ask is small, a one line update the system mostly drafts for you, but it is still an ask.

Engineering process

Branching strategy.

How work flows from an idea to main. Three levels, mirroring the work hierarchy, initiative to epic to ticket. Make the visible path the easy path.

main

Always releasable. Nobody pushes directly. Only changes through merged pull requests.

epic/<name>

Rollup for one epic. Feature branches merge here, so the epic lands on main as one reviewable unit.

feat/<name>

Does one thing. Branches off its epic branch and PRs back into it, not into main.

Branch topology
main
 └── epic/pm-restructure
      ├── feat/steps-from-the-dollar   → PR into epic
      ├── feat/revenue-gate-guardrail  → PR into epic
      └── docs/branching-strategy      → PR into epic
 (when the epic is done) epic/pm-restructure → PR into main
The flow
  1. Cut the epic branch off main.
  2. For each piece of work, cut a feature branch off the epic and open a PR into the epic branch.
  3. When the epic is complete and reviewed, open one PR from the epic branch into main.

Small standalone fixes that don't belong to an epic can branch off main directly, but see the revenue gate.

Revenue gate for PRs

Every PR into main must trace to an epic that carries a revenue hypothesis with a steps-from-the-dollar rank (0 to 3).

  • Put a line in the PR description, Epic: #<number>.
  • The epic must be real, created from the Epic issue template with owner, initiative, hypothesis, and rank.
  • No epic fits? Create one, or question whether the work should be in flight.
  • Infra PRs with genuinely no epic carry the no-epic label. Use sparingly and visibly.
Branch prefixes

Name the branch for the one thing it does. Epic branches roll up work, feature branches use a prefix that says what kind of change it is.

epic/<short-name> feat/ fix/ docs/ refactor/ chore/

Delete branches after they merge.