Principles, patterns, and practices for execution.

Aim for clarity

Don’t invent terms. Projects should be called projects.

Bounded contexts

A boundary inside which a word means one thing, and outside which it is allowed to mean another.

Brook's law

An outrageous oversimplification that states "Adding manpower to a late software project makes it later"

Build for the creators

Keeping individuals productive is more important than generating perfect reports.

Connect daily work to larger goals with projects

All projects and work should directly correlate to strategic goals.

Decide and move on

There isn’t always a best answer. Sometimes the most important thing is to make a decision.

Goldratt's Theory of Constraints

A system's throughput is limited by its bottleneck. Improving anything else does not improve the system.

Goodhart's law

When a measure becomes a target, it ceases to be a good measure

Keep a manageable backlog

A focused backlog makes it easier to plan cycles and ensures work actually gets done.

Meaningful direction

Remind everyone of the purpose and long-term goals, even when the day is full of small tasks.

Measure progress with actual work

Show the diff. Small tasks make small, reviewable changes.

Mix feature and quality work

Include bugs and fixes in cycles. Tooling is a force multiplier if done right.

Parkinson's law

Administrative staff grow 5.17% to 6.56% a year, whatever the workload does.

Purpose-built

Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.

Reverse Conway Manouver

Run cross-functional teams

Designers and engineers push and pull together on the same projects.

Say no to busy work

A tool should work for you, not the other way around.

Scope issues to be as small as possible

Break work into small parts so progress is visible every week.

Set strategic product initiatives

Ambitious goals are the only way to make a significant impact.

Simple first, then powerful

Simple to start with, more powerful as you scale.

Specify project and issue owners

Every project and issue needs a single named owner.

Understand your users

Collect feedback as a research library and attach it to the work.

Write project specs

Short specs communicate why, what, and how—and force clear scope.