Founder and tech lead working agreement that cuts rework

Why work keeps circling back to the founder

Teams do not send work back to the founder because they are lazy or afraid. They do it because nobody has clearly said who decides what, how much they can spend, and when a problem needs to move up.

The pattern is easy to spot. A developer asks whether a feature can ship without one edge case. The tech lead is not sure whether that tradeoff needs founder approval. The founder is on sales calls, replies hours later, and adds two more requests. Work stops, starts again, and stops again.

The same thing happens in smaller choices. A designer wants to simplify onboarding. A product person wants to delay a minor integration. A tech lead wants to pay for a tool that saves two days of setup. None of these calls are huge on their own. But when the approval line is fuzzy, all of them drift back to the founder.

That creates rework fast. The team builds version one, then hears that the feature should target a different customer. Engineers rewrite the flow. QA tests it again. Release notes change. The calendar moves, but the product barely does.

After a few rounds, people adjust in the worst way. They stop making small calls. They wait for cover. Meetings get longer because nobody wants to act first. Releases slow down, deadlines slip, and the founder gets dragged into details that should never have reached their inbox.

The cost is not only time. Teams get annoyed when they do solid work and then hear, "We need to redo this because I thought you'd check with me first." Founders get annoyed too. They feel trapped in every decision, even after hiring good people to own delivery.

Without a clear working agreement between the founder and the tech lead, the company runs on memory, mood, and whoever spoke last. Product work keeps circling back because the team has no shared rulebook for everyday decisions.

What the one-page agreement should include

A good one-page agreement answers three questions fast: who decides, who can spend, and when the founder steps back in. If people need a meeting to understand it, it is already too long.

The page should have three simple blocks: decisions, budgets, and escalation. That structure prevents repeat arguments because each issue has an obvious place.

In the decisions block, name the owner for each area and name a backup. Use real names, not only job titles. Startups change too quickly for vague labels. The tech lead might own architecture choices. The founder might own roadmap changes that affect revenue. A product manager might own scope tradeoffs inside a sprint.

In the budget block, write approval limits as plain numbers. Boring is good here. "The tech lead can approve tools up to $300 a month" is much better than "reasonable software spend."

In the escalation block, spell out what must come back to the founder and how fast that should happen. Keep this short. Most teams only need a few triggers:

• delays that move a launch date
• spend above the agreed limit
• security or legal risk
• hiring or vendor commitments
• customer requests that change product direction

Use plain language throughout. Write it the way two busy people talk at work, not the way a policy memo sounds. Short lines help. Specific examples help more. "If support asks for a small dashboard tweak, the tech lead decides" removes more friction than three abstract rules.

If someone can scan the page in under a minute and point to an owner for most likely problems, it will hold up when the week gets messy.

How to split decisions without confusion

This only works when decisions are split by area, not by vague labels like "business" and "tech." Those labels sound clean, but they leave too much room for overlap. It is better to define a few decision lanes and assign one owner to each.

Most startup teams can start with four lanes: product scope, technical design, hiring, and vendor choice.

For product scope, the founder usually sets goals, priorities, and what ships first. The tech lead gives effort, risk, and tradeoff input before that call. For technical design, the tech lead decides architecture, tools, code standards, and delivery approach. The founder stays out unless the choice changes budget, timing, or customer promises.

Hiring needs a split too. The founder approves headcount and pay range. The tech lead defines the role, runs the technical screen, and recommends who can do the work. Vendor choice is similar. The tech lead can pick tools that fit the team if they stay inside the agreed spend and security rules. The founder steps in when a contract is long, expensive, or painful to unwind.

After that, add one of two labels to each lane: "decides alone" or "ask first." Keep it that simple. Teams get stuck when every line says "joint decision." In practice, that usually means nobody knows who breaks the tie.

Founder-only calls should fit on a short list. Think roadmap direction, bigger spending, senior hires, and commitments that affect cash or customer terms. If that list keeps growing, the founder is still acting like the default project manager.

The tech lead needs real day-to-day ownership. That includes task sequencing, bug triage, small tool purchases, and normal engineering tradeoffs. If the founder can reopen those calls every week, the split is fake.

How to set budget rules people will follow

Money rules fail when they depend on mood, memory, or whoever replies first in chat. The tech lead should know what they can approve alone, what needs a quick founder check, and what always waits for a final yes.

Budget rules should fit on one page too. If people still have to ask, "Does this count?" every time, the rule is too vague.

Use fixed approval bands

Most teams do well with three spending bands:

• Small purchases: the tech lead approves routine spend up to a set limit.
• Mid-size spend: the tech lead recommends it, but the founder approves it.
• Large or long-term commitments: the founder signs off before anyone starts.

Use the same logic for tools, contractors, and cloud costs. A bug tracker, a freelance designer, and a bigger database plan are different purchases, but they still need clear approval rules.

Still, each type of spend behaves differently. Software tools are often fixed. Contractor costs can quietly expand if nobody sets an end date. Cloud spend can jump in a week if traffic rises or someone leaves a service running. Put each type in the agreement with plain limits, such as a monthly ceiling for cloud, a contract cap for outside help, and a per-tool cap for software.

A small startup might use rules like this: the tech lead can approve up to $1,000 per month in routine software, up to $3,000 for a one-time engineering need, and temporary contractor work up to two weeks. The founder still approves new long-term contracts, any unplanned cloud increase above 15% of the monthly target, and anything that adds ongoing cost.

Exceptions will happen. Launch week might force a rushed infrastructure upgrade. A security issue might require outside help the same day. Do not leave those cases to memory.

Record every exception in one shared place with four fields: date, amount, who approved it, and the reason. That simple log stops repeat arguments later. It also shows patterns. If the team keeps making "one-off" cloud exceptions, the budget is wrong or the system needs work.

Good budget rules do not slow the team down. They remove small approvals from the founder's plate and make surprise spending rare.

How escalation rights should work

Escalation rights stop small issues from turning into week-long loops. An escalation is not every disagreement. It is a change or risk that crosses a clear line and needs a wider decision.

Most teams only need a few triggers:

• scope grows beyond the agreed sprint or release
• cost moves past the approved budget limit
• launch dates slip enough to affect sales, marketing, or customers
• security, legal, or reliability risks appear that the tech lead should not own alone

The point is not to pull the founder into daily work. The point is to bring the right people in when the team leaves the space it can decide on its own.

When scope changes, the founder and tech lead should join the call, along with the product owner if there is one. When cash changes, include whoever controls spending, often the founder, finance lead, or operations lead. When launch dates move, include the person responsible for sales or customer communication so nobody promises a date the team cannot hit. If the company uses a fractional CTO, that person can help with architecture, hiring, or delivery tradeoffs that need senior judgment.

Reply windows matter. Without them, every message feels like a fire alarm or nobody answers in time. A simple rule works well:

• urgent: reply within 1 hour during working hours, decision the same day
• high impact but not urgent: reply within 4 business hours, decision within 24 hours
• normal escalation: reply within 1 business day, decision within 2 business days

Keep "urgent" rare. A broken checkout is urgent. A nice-to-have feature idea is not.

After each escalation, someone should write down the final call in plain language: what changed, who decided, what happens next, and what deadline or budget now applies. Put that note where everyone can find it. If nobody records the decision, the same issue comes back next week and starts the argument again.

How to draft it in one working session

Put the founder, the tech lead, and the person who owns delivery in the same room for one focused session. If one person comes late or leaves early, the draft usually turns vague and nobody trusts it later.

Start with real friction, not theory. List the last ten decisions that got stuck, bounced back to the founder, or created rework. Small examples are best: approving a paid API, changing scope after design started, delaying a release for one more feature, or choosing between a quick fix and a proper rebuild.

Then turn each example into a plain rule. Keep the wording short enough that someone can use it under pressure. A useful rule says who decides, what budget limit applies, and when someone must escalate.

For example: "The tech lead can approve tools up to $500 a month if they affect delivery speed." Or: "The founder approves any scope change that moves the launch date." If a sentence needs a paragraph to explain it, rewrite it.

Before you lock the draft, test it against one live project. Walk through the next few likely decisions and ask three questions: Who decides without waiting? What budget limit applies? When does this go back to the founder?

This test exposes weak spots fast. Teams usually find missing rules around contractors, deadline changes, or quality versus speed tradeoffs.

Keep version one small. Ten clear rules beat twenty-five fuzzy ones. Review the page after two weeks and fix the decisions that still felt messy. Most first drafts do not fail in dramatic ways. They fail in small, annoying moments that waste half a day at a time.

If you already have a fractional CTO advisor, that person can moderate the session and keep the language clear. The document still has to reflect how the founder and tech lead actually work, not how they wish the company worked.

A simple example from a startup team

A five-person SaaS team kept missing launch dates for one plain reason: every hard call drifted back to the founder. The founder approved pricing changes, jumped into architecture debates, and got pulled into outage chats at night. Work moved for a day, paused for a day, and then started over.

They fixed it with one page and a few blunt rules. The founder kept the calls that changed company risk: pricing, the hiring plan for the next quarter, and fundraising conversations. The tech lead owned system design, sprint tradeoffs, and incident response when something broke.

That split removed a lot of noise. Engineers stopped waiting for founder approval on technical choices that did not change budget or company direction. The founder stopped reviewing tickets that never needed founder input.

One problem still caused trouble: scope creep. Their product manager could not approve those changes alone. If a request would move the launch date, the product manager had to flag it that day and ask for a decision before the team added work to the sprint.

They also set one clear spending rule. The team used contractors for design and data cleanup, but only within a cap that everyone knew. If someone wanted to go above that cap, the request went to the founder that day with three facts: cost, reason, and what would slip if they waited.

The change showed up quickly. Weekly planning got shorter. The founder stopped rewriting technical tasks. The tech lead stopped asking permission for every architecture choice.

One Friday, their payment flow failed after a release. The tech lead handled the incident first, rolled back the change, and updated the founder after service recovered. Two days later, sales asked for a custom pricing exception for a large prospect. The founder made that call without dragging the whole product team into it.

That is the point of the agreement. It does not remove debate. It makes sure the right person makes the call before work circles back again.

Mistakes that break the agreement

A one-page agreement fails when people keep working the old way under a new document. The page says one thing, but the founder still approves tiny choices in chat, the tech lead still waits for a green light, and the team treats budget rules like rough guesses.

The most common failure starts with informal veto power. A founder says, "Do whatever you think is best," then jumps in later to change a naming choice, a small tool purchase, or a sprint detail. After that happens twice, nobody trusts the agreement. People learn that every decision can still bounce back upstairs.

Habit causes the next problem. Many tech leads ask for approval even when they already own the call. They do it to stay safe, avoid conflict, or because that was the old pattern. This slows work more than most founders expect. If the agreement gives ownership to the tech lead, both people need to act like it does.

Budget rules break just as fast when they stay vague or stale. "Small expenses are fine" is not a rule. Neither is a limit that made sense six months ago but no longer fits your tools, contractors, or cloud bill. Pick numbers, write them down, and review them on a schedule.

A few simple fixes help:

• write the exact spending limit for each owner
• record every escalated decision in one shared place
• name a backup owner for both founder and tech lead
• review the page when team size, product scope, or costs change

Missing records after escalation cause quiet damage. People leave a call with different interpretations. A week later, the same issue comes back because nobody wrote down the final call, who made it, and whether it applies next time.

Time off creates another gap. If the founder is away and no backup owner is named, work stalls. If the tech lead is out and nobody can approve a release, the agreement is useless when the team needs it most.

Keep the page boring and current. If a decision depends on memory or guesswork, people will ignore it when the week gets busy.

Quick check before you start using it

The agreement only works if people can use it under pressure. If someone needs five minutes to explain who decides what, the page is still too vague.

Ask the founder and the tech lead to explain their decision rights out loud without reading. Each person should be able to do it in about a minute. If they give different answers, the team will drift back into repeat debates and quiet approvals.

A short page should also cover the three areas that create most rework: money, scope, and urgent issues. Money means who can approve spending and up to what amount. Scope means who can cut, delay, or swap work once a sprint or milestone starts. Urgent issues means who can stop planned work when production breaks, a customer is at risk, or a legal problem shows up.

Use this quick test:

• both the founder and the tech lead can explain their own decision rights in one minute
• the page names budget limits, scope changes, and what counts as urgent
• the team can list the decisions that stay with the founder alone
• the rules match how the team actually works this month
• the page includes the date of the next review

That third point matters more than it seems. Founder-only decisions should be easy to name. Pricing changes, fundraising, hiring or firing leaders, and major shifts in product direction often stay with the founder. If the list is fuzzy, people will keep pulling the founder into routine calls just to feel safe.

One more reality check helps: does this page match current behavior? If the team already solves small issues in chat and ignores heavy approval flows, write rules that fit that pace. A rule nobody follows is dead on arrival.

Add a review date before you start using the page. Two to four weeks is enough for the first pass.

What to do next

Use the agreement for 30 days. Do not spend weeks polishing it. A working draft will teach you more than a perfect document nobody opens.

During that month, track only friction you can point to: blocked decisions, delayed approvals, and cases where two people thought they owned the same call. Skip vague feedback. "This feels off" is less useful than "we lost three days because nobody knew who could approve the spend."

At the end of the month, spend 30 minutes reviewing it and trim hard. Cut any rule nobody used. Rewrite any line people had to read twice. If a decision still bounced back to the founder, name the reason and fix that line. Most teams do not need more process. They need cleaner boundaries.

That review should answer four questions:

• which decisions moved faster
• which budget caps worked in real cases
• which issues still needed escalation
• which rules nobody used

Update the page when the company changes shape. New funding, a larger team, a new product line, or a bigger customer can all change who should decide what. A budget rule that worked for five people can slow twelve.

If the split still feels messy after one revision, an outside review can help. Advisors who work as Fractional CTOs often spot overlap quickly because they have seen the same pattern in many teams. Oleg Sotnikov at oleg.is does this kind of startup advisory work, and a short review can help tighten decision lines without turning a simple page into process theater.