Operating Principles
Definition of Done
Done does not mean "it works on my machine."
Done means:
-
The feature solves the intended problem.
-
Edge cases were considered.
-
It is deployed and usable.
-
It doesn't introduce regressions.
-
It is observable (logs, errors, monitoring).
-
It is documented enough that someone else can maintain it.
If you ship something, you own it.
Founders don't throw work over the wall. They close loops.
Before marking anything complete, ask:
-
Would I be comfortable demoing this live?
-
Would I put my name on this publicly?
-
If this breaks at 2am, would I understand it well enough to fix it?
If the answer is no, it's not done.
Communication Standards
Clarity creates speed.
We default to:
-
Written communication over verbal.
-
Decisions documented, not implied.
-
Directness over politeness theater.
-
Transparency over politics.
If something is unclear, clarify it.
If something is blocked, surface it early.
If you disagree, say so — with reasoning.
Founders don't wait to be asked.
They proactively reduce ambiguity.
Good communication:
-
Includes context.
-
States the desired outcome.
-
Proposes a solution.
-
Identifies risks or tradeoffs.
"Here's the problem and here's what I recommend" > "What should we do?"
Developer Performance Expectations
You are not evaluated on effort.
You are evaluated on impact.
High performers here:
-
Ship consistently.
-
Improve systems, not just tasks.
-
Identify problems before they escalate.
-
Increase clarity for others.
-
Take ownership beyond their ticket.
Low leverage behaviors:
-
Waiting for perfect specs.
-
Completing tasks without understanding why.
-
Creating dependency bottlenecks.
-
Needing constant direction.
We are building builders.
Operate as if:
-
The runway is yours.
-
The product reputation is yours.
-
The outcome reflects on you personally.
Because it does.
How to Propose a New Initiative
If you see an opportunity, don't ask for permission to think. Bring a case.
A strong proposal includes:
-
The problem.
-
Why it matters (user impact, revenue, risk reduction, leverage).
-
The proposed solution.
-
Tradeoffs.
-
Estimated effort.
-
What we would deprioritize to do this.
Founders understand tradeoffs.
Every "yes" is a "no" to something else.
If your proposal increases focus, leverage, or revenue — it will be taken seriously.
If it increases complexity without clear upside — expect pushback.
That's not rejection. That's discipline.
Ownership Model
If you touch it, you own it.
Ownership means:
-
Maintaining it.
-
Improving it.
-
Fixing it when it breaks.
-
Keeping it aligned with evolving priorities.
We do not operate on "that's not my job."
If something affects the product, it's everyone's job.
Founders don't protect their scope.
They protect the outcome.