First three CTO meetings with founders that set clear rules

Why this goes wrong in week one

Week one usually fails for a simple reason: founders want speed, and the new CTO does not yet know the hidden rules of the company. They have not seen the missed promises, the workarounds people use to hit deadlines, or the habits that shape how the team actually works.

That gap creates bad fixes. A founder feels pain, so the CTO changes process first. More meetings appear. Ticket rules get tighter. Approval steps multiply. A sprint routine changes before anyone names the real problem. One issue shrinks, then another grows. Engineers spend more time explaining their work, product decisions slow down, and the cause stays untouched.

Small startups hit this fast. A team keeps missing release dates, so the founder asks for stricter planning. Two weeks later, dates still slip. The real problem was simpler: sales kept promising custom work before product and engineering agreed on scope.

Authority causes just as much trouble. Everyone assumes decision rights are obvious until a hard choice shows up. Who can stop a launch over quality? Who can reject a rushed feature for a big customer? Who makes a hiring call when cash is tight? If nobody has named the rule, people wait, argue, or run back to the founder.

The same confusion shows up during incidents. Something breaks, the founders jump in, the CTO tries to organize the response, and the team watches to see whose call will hold. Even a short delay hurts when customers are waiting.

Old habits make this worse. People do not change behavior because a new CTO joined. They change when someone states the new rules in plain language and the founders back them in public.

That is why the first three meetings matter. They are not about process theater. They are where founders and the CTO replace assumptions with clear goals, clear authority, and named owners before any real change begins.

Meeting 1: agree on business goals

Start with time horizons, not tools. Ask the founders what must improve in the next 30, 90, and 180 days. Push for plain answers such as "close 10 more customers," "cut churn," or "ship the enterprise plan." Do not accept vague targets like "clean up the stack" or "modernize the platform" unless someone can tie them to a business result.

Founders often mix business goals and technical pain in the same sentence. Separate them. If a founder says the team needs to rewrite a service, ask what result that change should produce and when they expect to feel it.

That keeps the discussion honest. Revenue goals, hiring plans, retention, and launch dates belong in one bucket. Technical cleanup belongs in another. It only moves up when it clearly protects revenue, delivery, or product quality.

Then ask each founder for the single metric they watch most. One may care about monthly revenue. Another may watch churn or sales cycle length. If those metrics pull in different directions, you have found a real tension early. That is much better than discovering it in the middle of a sprint.

Tradeoffs matter as much as goals. Write down what the company will accept for the next few months. Maybe the founders will accept slower internal tooling if customer work keeps moving. Maybe they will accept a small rise in cloud spend to cut outages. If nobody says these tradeoffs out loud, the team will fight about them later under pressure.

A small example helps. A SaaS startup might say it wants "better engineering discipline." That sounds sensible, but it does not guide work. A better version is this: grow qualified demos by 20 percent in 90 days, keep production incidents below two per month, and delay a full test rewrite until after the sales push.

Before the meeting ends, turn the discussion into a short list that everyone can read the same way:

• 30 days: fix onboarding drop off and ship the pricing test
• 90 days: support the sales push with the two promised product changes
• 180 days: reduce incident load and pay down the worst reliability debt
• Main metrics: qualified demos, conversion rate, monthly churn
• Accepted tradeoffs: delay lower impact cleanup unless it protects delivery or revenue

If this list feels too simple, that is usually a good sign. The team needs a few clear targets, not a strategy deck.

Meeting 2: set decision rights

A new CTO does not need more opinions in week one. They need boundaries. If founders and the CTO make the same calls in parallel, the team gets mixed signals almost immediately.

This meeting should end with a short decision map, not a policy document. One page is enough if it answers three questions: who decides, who gets asked first, and when approval is required.

A clean split often looks like this:

• Founders decide what the company is trying to achieve, which customer problems matter now, and how much risk the business can take.
• The CTO decides how the team ships, which technical tradeoffs make sense, and how engineering work gets sequenced to hit the goal.
• Founders approve headcount and pay limits.
• The CTO defines technical roles, runs interviews, and makes the final call on engineering fit.
• Founders set the total budget.
• The CTO spends within that limit without asking every time.

Write down which calls founders keep and which calls the CTO makes alone. If you skip that step, people will guess, and they usually guess in their own favor.

Approval rules matter too. A CTO should ask before adding headcount, signing a new vendor, moving a date tied to revenue, or changing scope that affects customer promises. They should not need approval for every backlog change, interview step, or infrastructure fix.

Tie breaks need one rule. Pick it now. A common version is simple: the founder breaks ties on market, budget, and company risk. The CTO breaks ties on architecture and execution. If both sides still disagree, the CEO makes the final call that day.

Record decisions in one place. A shared doc, board, or meeting note is enough. Keep each entry short: decision, owner, date, and reason. That little record saves hours later.

This meeting often prevents more friction than any other. When everyone knows who decides what, later process changes land with far less drama.

Meeting 3: name problem owners

A new CTO usually walks into a messy pile of problems. The founders see outages, slow releases, bugs, missed deadlines, and open roles that stay open too long. Put those problems on the table in plain language before anyone changes process.

Keep the list short enough to discuss. Five to eight problems is usually enough. If everything feels urgent, the team has not ranked the pain yet.

A useful list might include:

• production outages that damage customer trust
• delays on the next release
• too many bugs reaching users
• hiring gaps on the engineering team
• rising cloud or tooling costs

Then give each problem one owner. One person can ask for help, but one person must own the result. Shared ownership sounds fair and usually creates drift.

This is also the moment to separate symptoms from causes. "We keep missing deadlines" is a symptom. The cause might be constant scope changes, weak specs, poor release discipline, or too few engineers for the plan. "Quality is bad" is also a symptom. The cause might be missing tests, rushed reviews, or weak ownership after incidents.

Write both down. If you only name the symptom, the team keeps treating pain instead of fixing the source.

Be direct about what the CTO owns now and what stays with founders. The CTO can own incident response, engineering delivery, code quality, vendor cleanup, and hiring for technical roles. Founders usually keep budget approval, product bets, pay ranges, and any decision that changes company strategy.

Some issues need split responsibility, but even then the split should stay clean. For example, the CTO can own how the team interviews engineers, while founders decide whether the company can afford three hires or one.

If this meeting works, you should leave with one first target. Pick a problem that is painful, visible, and small enough to move in two to four weeks. For many startups, that is not the biggest problem. It is the one that proves the team can fix something quickly.

A better first target is often "reduce release delays by fixing scope control and review rules" instead of "rebuild the whole platform." That gives the CTO a real test case, shows founders what change looks like, and makes the next conversation easier.

How to run the meetings in one week

Move quickly, but do not force all three conversations into one long session. Founders get tired, side topics take over, and people leave with different memories. Three separate meetings in one week work better. They give people enough time to think and still create pressure to decide.

Book 60 to 90 minutes for each meeting. An hour is enough when the founders already agree on most things. Use the full 90 minutes when there is tension, more than two founders, or a messy handoff.

A simple cadence works well:

• Monday: business goals
• Wednesday: decision rights
• Friday: problem owners

Send a short agenda the day before each session. Keep it brief. Three to five lines is enough if the questions are sharp. That gives founders time to react before they enter the room and cuts down on surprise debates.

Use the same note taker in every meeting. That person does not need to lead. They need to write down decisions, open questions, names, and dates in plain language. If you switch note takers, the record often shifts in tone and detail, and that creates confusion you do not need.

Close every meeting the same way. Read back what the group decided, name what is still open, and put a deadline next to each unresolved point. If nobody owns a deadline, the issue returns next week dressed up as a new problem.

After each session, turn the notes into one shared page. Keep it plain. Use the same structure every time: decision, owner, deadline, open question. By the end of the week, that page becomes the working record everyone can check instead of arguing from memory.

If a founder misses a session, do not patch it over in chat. Schedule a short catch up and update the shared page right after. Week one should leave the team with clear records, not loose promises.

A simple example from a small startup

A small SaaS company has two founders, six engineers, and one product designer. Both founders want the same two outcomes: faster releases and fewer outages. They hire a new CTO because the team keeps getting stuck between urgent bug fixes and sudden product changes.

At first, the problem looks technical. Releases slip, and production issues take too long to sort out. After two meetings, the new CTO sees the real issue. One founder still approves technical choices that should sit with engineering, so developers wait for sign off on service changes, database decisions, and release timing.

That slows everything down. Engineers hesitate. The CTO cannot fully own delivery. The founders get pulled into details they should not handle every day.

The team fixes this with a simple split. The CTO takes architecture decisions, release decisions, and incident response. The CEO keeps budget limits, hiring limits, and final approval for spending above the agreed cap. The founders still own pricing, sales promises, and market direction.

They also name problem owners. When the app goes down, engineering owns the outage, the rollback, and the follow up work. When customers push back on pricing, the founders own that discussion. It sounds obvious, but small startups often mix these jobs together and create noise for everyone.

Only after those rules are clear does the CTO change the release flow. The team moves to smaller releases twice a week instead of one big release that always slips. Engineers know who decides. Founders stop jumping into technical debates unless budget or business risk changes.

The result is not magic. It is just cleaner behavior. One founder stops approving every technical choice. The CTO starts acting like an owner. The team spends less time waiting in chat and more time shipping.

Mistakes that create friction

Most week one tension starts with speed in the wrong place. A new CTO wants to show momentum quickly, but fast changes in the wrong area usually make trust worse.

The first trap is changing tools before you know the bottleneck. A team can switch ticket systems, rewrite standup rules, or add new dashboards and still miss the real problem. Sometimes the delay is much simpler: founders change priorities every two days, one person approves every release, or nobody owns customer bugs after launch.

Another mistake is promising a reorg in the first week. Founders may like it because it sounds decisive. The team usually hears something else: more uncertainty is coming. If the CTO has not yet seen how people work together, a reorg is often a guess presented as action.

Founder input also needs a filter. Every founder opinion should not become a standing rule. In early meetings, founders often think out loud. One says engineering should ship daily. Another wants every change reviewed by product. If the CTO treats each comment as policy, the team ends Friday with conflicting rules.

Budget causes a quieter kind of friction. If limits stay vague, the CTO cannot make clean calls on hiring, contractors, cloud spend, or AI tools. Then every decision turns into a small debate. A simple number or range works much better than "be careful with cost."

Written notes matter more than most teams expect. Trusting memory feels fine when the room is small and everyone gets along. A week later, people remember different versions of the same agreement. One founder thinks the CTO owns delivery. Another thinks the CTO only advises. That gap creates tension fast.

A short check helps during these meetings:

• Ask what problem hurts revenue, delivery, or customers right now.
• Ask who decides, who advises, and who only needs notice.
• Ask what budget the CTO can use without extra approval.
• Write the answer down in plain language.
• Send the notes the same day.

This does not slow the company down. It stops small misunderstandings from turning into weekly arguments.

Quick checks before process changes

A process change fails when people answer basic questions in different ways. New meeting rules, ticket workflows, or approval steps do not fix that. They usually make the confusion harder to spot.

These early meetings only help if founders and the CTO leave with the same picture of the business. Before you add a sprint ritual or change how the team ships code, stop and test that picture.

Use a short yes or no check:

• Can each founder name the top three goals without looking at notes?
• Does everyone know which decisions the CTO can make alone and which still need founder approval?
• Does every major problem have one owner?
• Has the team written down the tradeoffs behind each process change and the deadline for reviewing it?
• Can someone explain in one or two plain sentences why this change matters now?

A startup can test this in 15 minutes. One founder says the goal is growth. The other says the goal is shipping a stable enterprise feature. The CTO thinks the goal is cutting cloud spend. All three sound reasonable. Together, they create daily conflict.

The same thing happens with decision rights. A CTO may think they can change the deployment process immediately, then find out every release rule still needs founder approval. That is not a tooling problem. It is a rules problem.

Write the answers on one page, not ten. People should be able to read it before a meeting and repeat it back. If they cannot, wait before adding more process.

This is often where a fractional CTO earns trust. Good process helps after people agree on goals, authority, owners, deadlines, and timing. Before that, more process is just more noise.

What to do after the meetings

These meetings only matter if the rules survive the next two weeks. Write a one page summary within 24 hours and send it to the founders and team leads. Keep it short enough that people will actually read it.

Include four things:

• the business goals for the next 90 days
• who makes which decisions
• who owns each current problem
• the first change the team will test

Do not roll out five changes at once. Pick one process change, and pick the one that removes the most daily confusion. In many startups, that is enough. A simple rule for product requests or bug priority often does more than a full rewrite of meetings, tools, and reporting.

Small teams feel every change quickly. If founders, engineers, and product people all adjust at the same time, they usually fall back to old habits by Friday. One clear change is easier to notice, easier to judge, and much easier to keep.

Put a review on the calendar for two weeks later. That meeting should answer a few plain questions. Did people follow the new rule? Did it save time? Did it reduce back and forth? If the answer is no, change the rule or drop it.

Watch founder behavior closely during those two weeks. If a founder still steps into daily calls, reassigns work in chat, or overrides priorities outside the agreed path, the ownership map is still off. Fix that fast. It is usually a role problem, not a personality problem.

A simple example makes this concrete. If the CTO owns sprint scope but a founder keeps adding tasks midweek, move feature requests into a weekly review and name one person who can approve urgent exceptions. That gives the team a real rule instead of a vague hope.

Some teams want outside help at this stage because the meetings were clear but the follow through gets messy. Oleg Sotnikov at oleg.is offers fractional CTO advisory for startups and small businesses that need help setting goals, decision rules, and early operating changes without hiring a full time CTO.