New CTO operating rules to write before teams drift

Why this needs a written rule now

Teams do not wait for a perfect process. They copy whatever happened last time.

If one customer gets a rushed feature, the next sales call treats that as normal. If one engineer fixes production without asking, other people assume they can do the same. That is how chaos stops feeling like chaos and starts feeling like "how we work here."

Small exceptions spread fast because they solve a short-term problem. They also create a hidden rule. Nobody votes on that rule. Nobody writes it down. People just remember the last escape hatch and use it again.

The problem gets worse when sales, product, and engineering fill the same gap in different ways. Sales wants to close the deal. Product wants to protect focus. Engineering wants to reduce risk and avoid late surprises. All three goals make sense. Without written rules, each team makes a different call under pressure.

A new CTO usually sees the symptoms before the cause. You hear the same lines again and again:

• "We already did this once for another customer."
• "I thought approval was implied."
• "Nobody said I could not do it."
• "We needed to move fast."

These are not edge cases. They show that the company already has rules, but those rules live in memory instead of writing.

Written rules do not slow good teams down. They remove the daily debate. People stop arguing about who gets to decide and start working inside clear boundaries. That matters most in three areas: scope changes, production access, and custom deal work. Each one creates risk quickly, and each one can train the company into bad habits without anyone noticing.

That is why a new CTO should put operating rules in place early, while the team is still small enough to change course. Once people build habits around exceptions, every cleanup feels personal. A short written rule avoids that fight and gives everyone the same answer before the next urgent request lands.

The three decisions to define first

Three choices create more rework than almost anything else in a young team. Start there: changing what the team is building, touching live systems, and promising work that only one customer wants.

Each one needs a single owner. Not a group. Not "whoever is around." One person makes the call, and one backup steps in when that person is away.

For scope changes, pick the person who can balance delivery, cost, and customer impact. In many startups, that is the CTO for technical scope or the product lead for feature scope. Write down what needs approval, such as new features, deadline changes, and work that adds more than a small amount of engineering time. Then write down what does not need approval, like bug fixes, copy edits, or small UI changes that do not change behavior.

For production access, keep the rule tighter. A named owner should approve who can enter production, under what conditions, and for how long. The backup approver should be another senior person, not a broad admin group. Be plain about exceptions. Emergency access might be allowed, but the person who uses it should log what they changed the same day.

Custom deal work creates a different kind of mess. Sales wants to close the deal, but delivery has to live with the promise. Put one owner in charge of approving any request that is not part of the normal product plan. That owner might be the CTO, founder, or head of product, but the team should never have to guess. The rule should say when custom work is allowed, who prices the effort, and when the answer is simply no.

A small example makes this concrete. If a salesperson promises a one-off dashboard to close a customer this week, nobody should start building it from a chat message. The owner reviews effort, support cost, and product fit first. If the owner is away, the backup decides. That one habit prevents a lot of avoidable chaos.

Who can approve scope changes

A scope change is any decision that changes what the team will deliver, when they will deliver it, or what it will cost to do. If a request adds a new feature, expands an integration, increases testing needs, or forces rework, treat it as a scope change.

Do not lump every small question into that bucket. A clarification keeps the original promise intact. It explains details the team already planned to deliver. New work changes effort or risk. That line needs to be written down, or people will argue about it every week.

A simple threshold works better than a clever one. If a request fits inside the current plan with no date change and no extra budget, the product owner or engineering manager can approve it as a clarification. If it adds days of work, changes dependencies, or pushes another task out, it needs formal approval.

A practical approval rule might look like this:

• Product or project leads approve small clarifications inside the current sprint.
• The CTO approves changes that affect delivery dates, architecture, or technical risk.
• The CEO, founder, or business owner approves any change that affects budget, pricing, or headcount.

This protects the team from casual promises. A salesperson should not promise "one small addition" to a customer if that addition pulls an engineer off a planned release. A founder should not move a launch date during a call without checking what slips behind it.

Require a short written reason before anyone commits. Keep it simple:

• What changed
• Why it changed now
• What it does to timing, cost, or staffing
• Who approved it

That note can live in a ticket, shared document, or chat thread. The format matters less than the habit. When teams skip this step, memory turns into process, and memory is a bad system.

Who can touch production

Production is where small mistakes turn into customer pain fast. A new CTO should name the few roles that can get in, what each role can do, and who says yes when access changes.

Most teams only need a handful of access levels:

• On-call engineer with read access by default and temporary write access during an incident
• Senior engineer or tech lead with limited write access for the systems they own
• CTO or head of engineering with full access for emergencies and final approval
• DevOps or platform engineer with infrastructure access for the parts they run
• Support or product staff with read-only dashboards, logs, and admin tools when their job requires it

Read access and write access should never mean the same thing. Reading logs, metrics, and traces helps people investigate problems. Writing to databases, changing configs, or deploying code can break live systems. Split those permissions early. Most engineers can do their job with read access, staging access, and a clear path to ask for more when a real issue appears.

For urgent incidents, write down one approval path that still works at 2 a.m. A simple rule is enough: the on-call engineer can ask the incident lead or CTO for temporary write access, use it to fix the issue, and lose it when the incident ends. If nobody removes temporary access, it becomes permanent by accident.

Monthly cleanup matters more than teams expect. People change projects, contractors leave, and old accounts stay behind. Put one person in charge of a short monthly access review. That person should check every account, remove unused access, and confirm that each person still has the lowest level they need.

This is especially important on lean teams. Oleg Sotnikov often works with small, AI-augmented teams that run serious production systems, and the same rule applies there too: clear production access rules keep a tiny team fast without letting speed turn into chaos.

How to handle custom deal work

Custom deal work can wreck a small team faster than almost anything else. A salesperson says yes on a call, the customer feels promised a feature, and engineering inherits a side project with no owner, no budget, and no end date.

Start with one simple rule: nobody promises one-off work during a sales call. Sales can listen, ask questions, and log the request. They cannot commit the team on the spot.

That pause matters because custom work rarely ends with the first build. Someone has to maintain it, answer support questions, test every future release against it, and explain it to new team members six months later. If you do not name that owner before you agree, the work lands on whoever is already overloaded.

A good decision usually starts with four questions:

• Who will build it?
• Who will support it after launch?
• Who owns the customer relationship if it breaks?
• Does this help more than one customer, or only this deal?

Build time is the number teams notice first, but support cost is what keeps hurting. A feature that takes three days to ship can create months of small interruptions. Those interruptions are expensive because they pull engineers away from planned work and make delivery less predictable.

That is why custom deal work needs a real price. Sometimes the answer is a separate paid project. Sometimes it is a premium contract with clear limits. Sometimes the right answer is no. Saying no early is much cheaper than saying yes and regretting it later.

This is another place where shared rules matter. Sales, product, and engineering should use the same rule before any custom promise goes out. A tiny team can handle a lot, but it cannot survive a growing pile of private features for different customers.

Keep the final decision in one shared place. A simple record is enough: request, customer name, price, owner, support plan, and final yes or no. When the next request appears, the team can check the rule instead of reopening the same argument every week.

How to put the rules in writing

Do not start from a blank page. Start with the last three arguments your team already had in email or chat. Pick one scope fight, one production access issue, and one custom deal request that slowed people down.

Each conflict gets one rule. Keep the wording plain enough that a tired team lead can read it once and act on it. If people need a long meeting to explain the rule, the rule is still too vague.

A good rule usually fits in four parts:

• Who owns the decision
• Who steps in when that person is away
• How fast they need to respond
• Who breaks the tie when people disagree

That turns a policy into something people can actually use on a busy Tuesday.

Use real examples, not theory

After you write the draft, test every rule against something that happened last month. Ask a simple question: if this rule had existed then, would the team have moved faster and argued less? If the answer is no, rewrite it.

Say sales promised a custom integration near the end of the quarter. Product said it would pull two engineers off roadmap work. Engineering said no one had approval to commit that effort. A usable rule might say that only the product owner and engineering owner can approve custom deal work above a set effort limit, and they must reply within one business day. If they disagree, the CTO decides.

That level of detail matters. Clear names beat broad principles.

Review with the people who feel the pain

Before you publish anything, sit down with sales, product, and engineering. Keep the review short. You are not asking for perfect wording. You are checking whether the rule matches how work actually moves through the company.

Then publish the rules where people already work every day. Put them in the team handbook, the shared workspace, or the internal document hub your company already uses. Do not hide them in a slide deck or meeting notes.

If someone can find the rule in under 30 seconds, they will use it. If they cannot, the old arguments come back by Friday.

A simple startup example

A salesperson is close to closing a new customer. On the final call, the buyer asks for one extra thing: a custom export with fields the product does not support today. The salesperson wants to say yes right away because the deal looks important.

A good CTO slows that moment down. The first question is not whether the team can code the export. The first question is what the request changes.

Does it add product scope for every customer, or is it special work for one account? Will the team need to support this export every time the customer changes a field, adds a new report, or finds a bug six months later?

Product makes the next decision. If the request matches a need that keeps coming up, it may belong on the roadmap. If it only fits one customer's internal process, product should keep it out of the main product and say so clearly.

Engineering then estimates the real cost before anyone gives a date. A custom export sounds small, but it can touch permissions, data mapping, testing, and support. A request that looks like two days of work can quietly turn into a permanent maintenance job.

One simple rule set keeps everyone honest:

• Sales records the request and explains why the customer wants it.
• Product decides whether it fits the roadmap.
• Engineering estimates effort, risk, and support work.
• The CTO approves any exception that adds scope or ongoing maintenance.
• Sales offers either a paid custom project or the closest standard option.

That last part matters. The team should not treat every deal request as a product promise. Sometimes the right answer is a paid custom build. Sometimes the right answer is, "We do not support that, but this standard export may solve most of the problem."

Small startups drift when people make nice-sounding promises in private. One custom deal can create a second product the team never planned to own. Written operating rules stop that drift early, while the company is still small enough to fix it.

Mistakes that create daily confusion

Most operating rules break in boring ways. Teams do not ignore them because people are careless. The rules fail because they are vague, split across chats, or owned by the wrong people.

The worst mistake is giving two people the same final say. If sales and product can both approve scope changes, engineers end up waiting, guessing, or choosing the answer they like more. The same thing happens in production access when a founder says "yes" and the engineering lead says "not yet."

Another common problem starts with rules that read like legal terms. Nobody opens a stiff two-page policy during a release problem. People use short rules they can remember, and they ignore the rest.

A few warning signs show up fast:

• Team members ask the same approval question every week.
• People use private messages to get around the stated process.
• Urgent requests have no expected response time.
• Deal exceptions reach engineering after a promise was already made.
• New managers join, but the approval map stays the same.

Private exceptions do more damage than most teams expect. One founder message saying "please do this just for this customer" can wipe out a rule in a day. After that, people stop trusting the written process and start watching who has direct access to leadership.

Urgent work also needs a time limit. If nobody says who answers a production access request in 15 minutes, one hour, or by the next business day, people invent their own rule under stress. That is when access spreads, hotfixes skip review, and blame starts later.

Team changes make old rules rot quietly. A startup hires a new engineering manager, brings in a Fractional CTO, or moves account ownership to a new sales lead. If nobody updates the approval rules, people keep following the version stored in memory.

Short, plain rules win. Name one final approver for each decision, say where exceptions must be recorded, and set a response time for urgent cases. If the team cannot repeat the rule from memory, it is probably too messy to use.

A quick weekly check

A rule that nobody can find or explain will fail the first time the team feels pressure. Spend 10 minutes each week checking whether your written rules still match what people actually do.

This works best as a short meeting with one lead from product, engineering, and sales. If you are a new CTO, this habit catches drift before it becomes normal.

Use the same five checks every week:

• Ask a few people who approves scope changes. Do not ask only managers. If two people give different names, the rule is already weak.
• Ask a new team member where the production access rules live. If they cannot find the answer in one minute, the rule is too buried or too vague.
• Check whether sales approved any custom deal work outside the written process. One off-process promise often creates days of rework later.
• Review role changes from the past week. If someone moved teams or left a hands-on role, make sure they did not keep production access by accident.
• Look for repeat confusion. If the same rule caused the same question twice in one week, rewrite it. The team is telling you the wording is bad.

Do not turn this into a big audit. You are not measuring perfection. You are checking whether the rules are easy to name, easy to find, and easy to follow.

A simple standard helps: if a person can answer in one sentence and point to the written rule in under a minute, the rule is working. If they need a long story, a private message, or a memory from last month, it is not a real rule yet.

These weekly checks keep the rules alive. They also show where chaos is starting: fuzzy approvals, hidden production access, and sales exceptions that quietly become policy.

What to do next

Put 60 minutes on the calendar this week and get sales, product, and engineering in the same room. Do not turn it into a strategy meeting. Make three decisions and write them down before anyone leaves.

A short page beats a polished handbook. Most teams do better with one page they can read in two minutes than a long document nobody opens when pressure hits.

• Name the person or role that approves scope changes after work starts.
• Name the person or role that can grant production access, and state when that access expires.
• Name the person or role that approves custom deal work before sales promises it.

Keep the wording plain. If a sentence needs a paragraph to explain it, rewrite it. Rules like this work best when a tired engineer can read them at 11 p.m. and still know what to do.

After your next release, outage, or ugly customer request, review the page again. Teams usually find the weak spot fast. Maybe sales still slips in custom promises, or maybe production access stays open longer than it should. Fix the line that failed, then use the new version right away.

A small habit helps: store the page where everyone already works, and bring it up in the next weekly leadership meeting. If someone broke the rule for a good reason, update the rule. If they broke it because nobody remembered it, the page is too vague.

If the team keeps circling the same argument, outside help can save time. Oleg Sotnikov at oleg.is does this kind of Fractional CTO work with startups and small teams, helping them set clear approval lines without adding process for its own sake.

You do not need a perfect system. You need a written rule people can use on a busy day.