The Contour Method

The art of running an effective FDE motion. From hundreds of conversations with high-performing delivery teams emerges the foundational ideas Contour is built on.

Principles and practices

Principles

• Centered around outcomes. Work can be endless given the number of stakeholders, external and internal. Not all work is weighted equally, so keeping individuals oriented toward outcomes over volume is important.
• Purpose-built. Deployment teams operate fundamentally differently than both product-led engineering teams and account management teams. An opinionated system can simplify their chaos.
• Maximum clarity. Collect every bit of data possible, but don't take everything at face value. Verify frequently and with minimal friction. Always trace back to the reasoning behind every decision. The goal is to create structure from ambiguity.
• Never repeat work. What lies within the system should never require heavy lifting to recreate. Resist the urge to let everyone use their own separate tools and invent their own workflows. Reusable patterns get lost instead of codified when individual work is disconnected.
• Stay current. Relying on people to maintain engagement state is faulty at best and slows teams down. A tool should see all the information available to a human, and make all the relevant updates in real time. What's surfaced to the humans should be concise, intentional, and up to date.

Practices

• Catalog the "why" behind requirements. No requirement should be accepted simply because someone asked for it. Similarly, no request should go undocumented or have an unclear owner. Every requirement is traced to its source, approver, and rationale.
• Connect tasks to requirements. Tasks should always stem from a requirement, so that when requirements change, tasks can be added, removed, altered, or reprioritized. Tasks should be small and tractable, with details on acceptance criteria and impact.
• Turn contractual deadlines into smaller milestones. Client-facing work has deadlines, whether contractual or implied. Juggling multiple deadlines across projects can be daunting. Breaking those timelines into more flexible milestones can reduce anxiety for individuals and demonstrate incremental progress for the client, keeping them engaged and preventing rework later.
• Assign tasks based on availability and skill. There should be a centralized view of team availability and capabilities so that incoming tasks get routed to the right individual with a reasonable deadline. This ensures tasks are completed properly, no team member is burned out unnecessarily, and overall utilization stays high.
• Observe work progress, avoid manual logging. An individual doing work should not have to report status to five different people and a tracker. Work is ongoing and projects are continuously changing. New information should make its way into the project's system of record with simple confirmation from the individual, not additional effort.
• Treat decisions, scope changes, and approvals as first-class citizens. A ticket is already downstream of all the artifacts that came before. Capture the evidence from transcripts or messages and store the structured intent: what we're trying to do, why the outcome is important, who wanted it, what success looks like, what edges exist, and what we won't do.
• Facilitate cross-functional communication. Most teams write a different status report for every audience: one for clients, one for leadership, one for sales, one for engineering. Each version takes the same underlying reality and re-narrates it for whoever's reading. Writing the response each time becomes a tax on the middle man when it should be derived straight from the source of truth.
• Reconstruct context in-line and across tools. The ability to instantly query the state of an engagement saves time for both the person asking and the person answering. The surface area for interacting with tools should be kept to a minimum. State should be as deterministic as possible, not a general model reasoning over corpuses of unstructured data each time.
• Keep a living project change log. Internally, this helps your team track what's actually been agreed to instead of relying on memory. Externally, it's how the client sees the engagement staying on track: every change is visible, attributed, and traceable back to the moment it was decided, instead of surfacing as a surprise on a status call.

Speed

Context is load-bearing

Every engagement runs on shared understanding. The question is whether that understanding lives in one person's head or somewhere that can be easily referenced.

When context is personal or undocumented, the engagement is fragile. One person leaving or sick, one missed call, or one Slack thread that got buried can cause the team to rebuild everything. When context is shared and current, anyone can step in, any stakeholder can get oriented, and decisions can be made without convening the one person who knows.

Good documentation exists for a reason. The people doing the implementation work, as well as the clients who depend on it, need to be clear onwhat was agreed to, what's been built, or what comes next. In the agent-native world, the impact of documentation compounds more, as more and more information is needed to make decisions and execute work with confidence.

Promises need receipts

A requirement that can't be traced back to where it came from isn't a requirement but a guess (and a potentially costly one).

If two parties remember a conversation differently, the answer should be easily referenced. The discipline of capturing what was said, who said it, and in what context used to be bureaucratic overhead. Now, it happens naturally in the flow of work, not as a separate burden or activity. This is how you protect individuals' time and the client relationship when things get complicated.

Requirements with provenance change the nature of scope conversations. Instead of relitigating what was meant, you're looking at what was said. This leads to either fewer, higher substance meetings.

Prioritization is an evolving point of view, not a list

Every engagement has more work than time. Unlike in other fields, tickets in our system don't get completed or deleted because they are subject to change.

The backlog should clear or update itself based on the current context: what matters now and why.

Prioritization means taking a position: this work unblocks something critical, this other work doesn't, and we're making that call explicitly rather than letting urgency decide for us. That position should be visible to the team, legible to the client, and revisited whenever the context changes, not just at the start of the engagement when everyone is optimistic.

Status shouldn't require effort

If someone has to compile a report to answer "where are we," the system is working against the team.

Clients should have answers available to them without anyone having to prepare it. Status updates that require an IC to stop doing the work and create a summary of the work are a tax on delivery. The information should flow naturally from observing how the work is done with intentional verification steps built in, not as a disconnected reporting layer on top of it.

The same is true internally. A manager who needs a weekly sync to know what's blocked isn't being kept in the loop. An IC being pinged by 5 different folks to re-explain the same thing is a gap in the system.

Communication should always be as simple and clear as possible. No one wants to read a long essay to get caught up, including agent explanations. Frequent, concise updates are better than one massive message. The level of detail should also be appropriate to the person receiving the update. No more, no less.

Scale

Speed gets you through the first few engagements or when teams are small. Scale is when the lack of systems starts to show. As teams grow, the things that worked informally, like context in one person's head, status passed verbally, requirements remembered from the kickoff call, stop working. What follows isn't chaos all at once but a slow erosion: quality becomes inconsistent, onboarding takes longer, renewals get harder to defend. The principles that govern speed don't change at scale, but the cost of ignoring them gets much higher.

Handoffs are a test

If the engagement can't be handed off cleanly at any moment, the knowledge is trapped, and trapped knowledge is a liability.

A new team member should be able to get oriented from a single source of truth. A client stakeholder who missed the last three months should be able to catch up without scheduling four calls. An engagement that's transitioning from implementation to support should transfer cleanly, with everything that was decided and built accounted for.

The handoff isn't a phase at the end. It's a constraint that should shape how the engagement is run from the beginning. If you're building context that only lives in people, you're building something that won't survive them leaving.

Delivery has to be measurable

The hardest conversation in a services engagement isn't individual scope debates. It's the renewal or end of pilot conversation where someone asks "what did we actually get?" and nobody has a clean answer.

Most teams can tell you what they shipped because tracking engineering work is straightforward. Few can link the business tracking layer to the technical work done: new revenue unlocked, hours saved, decisions unblocked, errors caught before they became incidents, risks avoided. You're asking the client to trust their memory of what happened in the engagement when they should have been visualizing and verifying the value delivered every step of the way.

That's a measurement problem. The engagement should produce two things in parallel: a record of what was built, and a record of what it impacted. Your client should be able to quantify the value delivered, not just the invoice. And your team should be able to see what it cost in time and resources to deliver that value: by engagement, by workstream, by outcome. The gap between cost and value isn't just useful for the finance team. It's the clearest signal you have for where to invest, where to automate, and how to scope the next engagement better than the last one.