01 layer
governance
the limits it cannot cross without a human
03 playbooks
—
stands on its own
Every team runs on practices it picked up somewhere. Agile, Scrum, Lean, whatever the last place did. The practices aim at real problems: productivity, risk, alignment, communication.
The sheer number of them is the tell. Roughly 90% of startups fail, which is enough to establish that no practice guarantees anything.
Working through why, we kept landing on the same thing: any given best practice covers one aspect of software delivery, sometimes 2. There are 3: Team, approach, and process. They only produce an outcome together.
That is the TAP system.
Why all three
Take a team with clear requirements where everyone is experienced enough to know their job. Deadlines still slip and progress still crawls. There was a team and an approach; nobody defined the process.
The more common version: a great team, everyone committed, no usable output. The team and the process were fine. Nobody set a strategic approach to a business outcome.
And however good your approach is and however tight your process, neither survives a team that is not assembled and aligned.
We pick different practices for every engagement depending on size, goals and available resources. What does not change is that all 3 aspects get covered.
T for team
Team management starts at hiring, and hiring is the part most engineering leaders inherit rather than design. The practices here run from how a job post is written through to continuous hiring, so that experts of the right caliber are available before you need them and burn and attrition stay predictable.
Once there is more than one team, organizing them becomes its own problem. That needs role definitions that say what each person is responsible for, and a clear read on who the subject matter experts and the T-shaped generalists are, so a team can be reshaped quickly when priorities move.
A for approach
The approach starts with the documents an organization aligns on: product briefs, architecture decision records, customer journey maps, user stories, acceptance criteria. Then the techniques that decide how fast a team can move and how early it sees a problem, like CI/CD and architecture review. Then the tactical ones, like feature flags, error tracking and dynamic environments, which look minor individually and compound.
It also covers how the team sequences work. Taking the riskiest thing first and working in small batches is what makes a delivery date mean anything.
P for process
Process is what makes up the day. Distributed teams work asynchronously, which puts weight on the small mechanics: how Slack is used, how a calendar invite is written, how the backlog gets groomed. Skip those and progress stops being visible until it is late.
The rest depends on where the product is. Preparation, execution, launch. Each stage has practices that fit it and practices that do not.
Choosing practices
More is not better. The practices in TAP do not promise an outcome. They address risks, and a project only has some of them.
Launching a major version of a popular app means a go-live plan and a phased rollout, because the cost of getting it wrong is high and public. A small new website does not need that, and the effort spent automating it is effort not spent on the roadmap that will actually change.
So the selection is the work. Which is why we packaged it.
Where TAP lives now
TAP became tap-os, the same 3 concerns as installable Claude Code skills. The practices that were a reading list are now workflows an agent runs, and the Atlas is the reference behind them.
The rest of the library is here. Start with whichever of the 3 you are weakest on.