# A fractional COO for SaaS fixes delivery chaos > See when a fractional COO for SaaS should own delivery, how the role differs from the CTO, and how both leaders can reset execution. A SaaS company can have sound architecture, capable engineers, and enough runway, yet still miss every meaningful date. The usual reaction is to push the CTO harder. That works only when engineering judgment or technical execution caused the delay. When priorities change by the day, sales promises bypass planning, nobody owns cross-team dependencies, and executives reopen settled decisions, the bottleneck is operations. A fractional COO for SaaS can fix that system while the CTO fixes the product and engineering system. I have watched founders spend a quarter on cloud migrations, team reshuffles, and new planning software because delivery felt chaotic. The code got cleaner while customers kept hearing different dates. The company had treated an operating failure as an architecture problem. A turnaround starts when the CEO assigns one executive to company execution and another to technical execution, then gives both a shared set of facts. This split matters before a company reaches executive scale. A founder may still hold the COO authority while a fractional operator builds the controls. The title matters less than the decision design: somebody must be able to stop an unsupported promise, and somebody must be able to stop an unsafe technical plan. Asking one CTO to carry both vetoes creates a conflict whenever revenue pressure rises. ## Delivery chaos leaves a different trail than technical debt Operations is the bottleneck when work waits longer for decisions, handoffs, or commercial clarity than it spends in engineering. You do not need a time study to see the pattern. Pull five recently delayed commitments and trace each one from promise to release. If the delay began before engineers could make a stable plan, the CTO inherited the mess rather than created it. A technical bottleneck leaves evidence such as slow builds, brittle deployments, recurring incidents, unclear service boundaries, or a codebase that makes small changes risky. An operating bottleneck leaves a different trail: two teams believe they own the same decision, a customer commitment has no named approver, a launch waits on legal or support, or a founder changes scope in a private message. Both kinds of failure can exist together. Calling all of it engineering hides the part that only the CEO or COO can correct. Look at waiting states, not meeting volume. A busy calendar may be a symptom, but canceling meetings does not resolve missing authority. Ask where a decision sat, who had the right to make it, what evidence they lacked, and which commitment depended on it. That produces a useful delay record: Commitment record A: Enterprise export. First blocked on 6 May, waiting on contract scope. The COO owns the decision, and a renewal is at risk. Commitment record B: Billing change. First blocked on 9 May, waiting on the migration method. The CTO owns the decision, and support load is growing. Commitment record C: Partner launch. First blocked on 12 May, waiting on final packaging. The CEO owns the decision because the campaign slot is at risk. The table forces a distinction that status reports blur. Work can be incomplete because a team is still doing it, or blocked because the company has not made a decision. The first needs execution. The second needs an owner with authority. Compare three clocks for the same initiative: elapsed time since the company accepted it, active time spent producing it, and blocked time waiting for a decision or dependency. Exact measurement is unnecessary at first. Calendar evidence from approval records, planning notes, and release history will show whether ten days of engineering sat inside ten weeks of organizational delay. If active work dominates, the CTO should inspect the engineering system. If waiting dominates across several functions, an operations executive has work to do. Do not confuse product discovery with operating drift. Learning may change scope because evidence changed. Drift changes scope because authority was unclear or a stakeholder arrived late. A good control preserves room to learn while requiring someone to record why the commitment changed, who accepted the consequence, and what work moved. That distinction stops leaders from defending avoidable reversals as agility. ## The COO owns the promise system and the CTO owns technical reality The clean split is simple: the COO owns how the company makes and keeps delivery commitments, while the CTO owns whether the technical plan is safe, feasible, and properly staffed. Neither executive owns the other. They meet at the boundary where a commercial promise becomes a technical commitment. The COO should own portfolio priority, cross-functional sequencing, operating cadence, escalation paths, and the definition of ready for a company commitment. That includes asking sales what the customer actually bought, ensuring finance understands the margin consequence, and confirming support can absorb a rollout. The COO does not decide the database design or tell an engineering manager how many days a task should take. The CTO should own architecture, engineering capacity, technical risk, security, reliability, and the delivery method inside product development. The CTO must give the business an honest range, name technical dependencies, and refuse unsafe shortcuts in plain language. The CTO should not arbitrate which strategic account matters more, chase legal approvals, or reconcile four executives' competing roadmaps. Those jobs consume attention without using the CTO's judgment well. A useful decision-rights table removes most ambiguity: - The COO recommends which company outcome comes first and runs the choice. The CTO advises on cost and risk. The CEO decides ties or strategy shifts. - The CTO decides whether a technical approach is acceptable. The COO advises, and the team informs the CEO. - The COO decides whether to promise a date after checks. The CTO supplies the range and conditions. The CEO approves exceptional exposure. - The CTO may stop a risky release for technical safety. The COO handles the customer response, and the team informs the CEO. - The CEO decides whether to add or remove a major initiative after the COO models operating impact and the CTO models capacity. This split does not reduce the CEO's authority. It prevents the CEO from becoming the routing layer for routine conflicts. If every disagreement returns to the founder, the company has executive titles but no operating design. ## Dates become credible only after scope, capacity, and authority meet A date is credible when the company can name the scope, reserve the required capacity, expose the major dependencies, and identify who may trade one constraint for another. A date copied from a sales call or investor deck is an aspiration until those conditions exist. The COO should introduce a commitment gate that is light enough to use and strict enough to matter. Before any date reaches a customer, board update, or coordinated campaign, the owner supplies five fields: - Outcome and explicit exclusions - Accountable business owner and technical owner - Capacity source, including what gets displaced - External and internal dependencies - Confidence range plus the next review date The CTO validates feasibility and the engineering range. Product confirms that the scope describes an outcome rather than a bag of features. The COO decides whether the full company should accept the commitment. When information is missing, the correct answer is not no. It is not yet, followed by the exact evidence needed for a decision. Do not turn the gate into a business case that takes two weeks. A one-page commitment record is enough for most SaaS work. Its value comes from forcing the trade in public: this enterprise request will use two engineers for a month, so onboarding improvements move. Once the displaced work is visible, executives stop treating capacity as an unlimited shared resource. I argue against the popular rule that engineers should never discuss dates. The rule became popular because leaders often turn an estimate into a promise and punish any change. Silence creates a worse system. Engineers should describe ranges, assumptions, and technical uncertainty; the COO should control how that evidence becomes an external commitment. Ranges need expiration conditions. A six-to-eight-week range may assume one team, settled access rules, and no migration of existing tenants. Put those assumptions beside the range. If sales adds a second customer workflow or a security review reveals a migration, the old range expires and the commitment returns to the gate. That is not engineering changing its mind. The input changed. The COO makes that change legible to the customer and to the executives whose work the company will displace. Confidence also needs a common vocabulary. High can mean that the team has settled scope and dependencies and completed comparable work. Medium can mean one known decision remains. Low can mean discovery is still changing the shape of the solution. These labels should never replace the written reason. Their purpose is to help the operating review find changes quickly, not to manufacture certainty. ## A turnaround needs one queue before it needs a new plan The first turnaround move is to put every active company initiative into one queue, including work hiding in departmental plans and executive messages. Most troubled SaaS companies do not have a prioritization problem yet. They have an inventory problem because nobody can see all the promises competing for the same people. The COO and CTO can build the queue in a working session, but they must not compromise by preserving everything. Use this sequence: 1. List every initiative that consumes product, engineering, data, security, support, or executive capacity. Give each one an accountable outcome owner. 2. Mark hard obligations such as signed contracts, regulatory deadlines, and reliability remediation. Record the evidence rather than accepting the loudest person's label. 3. Estimate capacity in coarse bands. Precision is false when scope is unstable; small, medium, and large can expose overcommitment. 4. Rank outcomes, then cap active work at the capacity the teams can actually support. Move the rest to a visible holding queue with no implied start date. 5. Publish the decisions, displaced work, and next review point. Private prioritization does not change company behavior. This is where the two roles must resist each other's bad habits. A COO may compress technical uncertainty into a convenient date. A CTO may respond by adding so much technical caution that no business decision feels possible. The shared record should carry both: an operating commitment and the technical conditions that can change it. The Theory of Constraints makes a useful point here: improving work away from the constraint does not improve overall throughput. In a SaaS turnaround, the constraint may be executive decisions, customer clarification, test capacity, or one overloaded platform team. Optimizing every department equally spreads attention and preserves the bottleneck. Find where commitments accumulate, subordinate other work to that constraint, then check again because the constraint will move. A new annual roadmap will not rescue an overloaded queue. Neither will a planning offsite. Once leaders see that the company has capacity for four serious outcomes and has opened eleven, the turnaround becomes a choice rather than a motivation campaign. ## The operating system must expose drift every week A weekly operating system should reveal commitment drift early enough to act, not collect polished updates after the damage is fixed or hidden. The COO designs the cadence; the CTO supplies technical evidence and owns corrective work inside engineering. Use one control page for the whole company. It can live in any tool, provided every executive reads the same version. A practical control page contains current outcomes, confidence, changes since last review, blocked decisions, capacity exceptions, and customer exposure. Each line needs an owner and a decision date. Color alone is weak evidence because teams learn to keep work green until the week it fails. Require a short reason whenever confidence changes. The weekly review should make decisions, not receive narrated status. Owners submit updates beforehand. During the meeting, the group handles only changes, conflicts, and requests for authority. A 45-minute agenda can work: - Minutes 0-10: identify changes in company commitments and accept or reject each change. - Minutes 10-25: resolve decisions that block delivery, with an owner and deadline for any open item. - Minutes 25-35: identify where capacity moved and state the work it displaced. - Minutes 35-45: decide what customers or staff must hear and name the communicator. Keep a decision log beside the control page. Record the decision, owner, date, evidence, dissent, and condition for reopening it. Dissent matters because a technical objection should not disappear when the company accepts commercial risk. The condition for reopening prevents the opposite failure, where anyone relitigates a decision because they remain unhappy. The Kanban Guide defines work in progress as started work that has not finished and treats controlling it as part of managing flow. Companies often apply that idea only to engineering tickets. The costly work in progress sits one level higher: launches, integrations, migrations, market experiments, and enterprise promises. A COO should limit that portfolio inventory. The CTO should limit engineering work within the outcomes that remain. Do not measure the turnaround by story points, tickets closed, or hours worked. Those measures can rise while commitments keep slipping. Track promise reliability, age of blocked decisions, active outcome count, unplanned capacity use, and how often leaders change priority after work starts. The direction matters more than a decorative score. ## One failed launch shows where authority broke A failed launch often looks technical in the final week even when an operating error started it months earlier. Consider a SaaS company that promises a custom permission model to win a large account. Sales records the feature name but not the customer's approval workflow. Product assumes a small extension to existing roles. Engineering discovers late that the customer expects delegated administration, audit history, and different rules across business units. The CTO now has three bad options: ship a narrow version that disappoints the customer, expand scope and miss the announced date, or patch the design and accept security risk. Replacing the framework will not resolve the ambiguity. Adding engineers may increase coordination cost because the team still lacks a settled requirement. The visible crisis sits in engineering, but the first failure occurred when the company converted an undefined request into a dated promise. The COO's correction starts outside the codebase. The account owner must document the contractual outcome and exclusions. Product translates the customer's operating workflow into acceptance examples. The CTO chooses a safe design and returns a range. The COO then negotiates the company trade: phase the rollout, move another initiative, change the commercial expectation, or decline the work. The CEO enters only if the account exposure crosses an agreed threshold or the options change strategy. After the incident, do not write an action item that says improve communication. Change the control that failed. Require commitment review for custom account work, name who can approve exceptions, and add customer acceptance to the release condition. A useful postmortem assigns each cause to an operating control or a technical control. If every action belongs to engineering, the organization has learned nothing from the sequence. The distinction also protects the CTO. Technical leaders should answer for ignored risk, poor engineering execution, and unreliable systems. They should not become the universal owner of any promise that contains software. Accountability works only when authority arrived before the commitment. ## A fractional COO needs a narrow mandate and real authority A fractional COO is worth hiring when the operating failure spans functions, the company needs executive judgment now, and a full-time operations executive would be premature or too slow to recruit. The role is a poor fit when the founder wants a senior project manager, a meeting facilitator, or a buffer who will deliver unpopular messages without changing founder behavior. Part time does not mean advisory only. The executive needs authority over the commitment process, operating cadence, portfolio record, and cross-functional escalation. Put that mandate in writing. State which decisions the COO can make, which require the CTO, which remain with the CEO, and what information each leader must provide. Tell the company, because private authority evaporates at the first conflict. Write the engagement around outputs and decision access, not a bundle of meeting hours. The fractional COO needs a fixed session with the CEO and CTO, direct access to portfolio owners, the right to inspect customer commitments, and a response path for urgent decisions. Name who maintains each control between the COO's working days. Without that continuity, blockers wait for the consultant's calendar and the role creates a new queue. Compensation and schedule do not create authority. The CEO does. When a revenue leader bypasses the commitment gate, the CEO must send the request back through it. When the CTO withholds capacity evidence because the estimate feels uncertain, the CEO must require conditions and a range rather than accept silence. A mandate becomes credible after leaders see the founder enforce it against a commercially attractive exception. Ask candidates for evidence from comparable failure modes rather than broad operating claims. A useful interview request is: describe a commitment you canceled, who resisted, what evidence changed the decision, and what control prevented a repeat. Ask how they disagree with a CTO and how they protect technical uncertainty from commercial pressure. Listen for specific decision design. People who answer only with alignment workshops and dashboards will probably add ceremony. The engagement needs an exit condition. Suitable outcomes include one trusted portfolio, defined decision rights, a stable weekly cadence, fewer priority reversals, shorter waits for executive decisions, and internal leaders able to run the controls. Avoid promising that a fractional executive will fix culture in a fixed number of days. The person can change mechanisms quickly; repeated leadership behavior determines whether they stick. A fractional COO cannot compensate for a CEO who keeps making private promises, exempts favored initiatives from review, or reverses decisions without recording the trade. The founder must accept the same system imposed on everyone else. If that condition is absent, the engagement becomes expensive status administration. Do not confuse the role with a chief of staff. A chief of staff may improve executive preparation, follow through on decisions, and connect information across the company. A COO carries line authority for the operating system and owns whether it works. A strong chief of staff can support the turnaround, but giving that person executive-sized conflicts without explicit decision rights leaves the original gap in place. Nor is the role a substitute for a product leader. Product decides which customer problem and product outcome deserve investment. Operations decides how that choice competes for company capacity and what must happen before the business promises delivery. If the fractional COO starts writing every requirement, product accountability has moved by accident. ## The first 30 days should remove ambiguity, not add ceremony The first month should produce fewer active commitments, faster decisions, and a visible split of authority. It should not produce a thick operating manual. The COO and CTO need to work on the live portfolio, because a clean process designed away from current pressure usually fails on contact with the company. During the first week, the COO interviews the CEO, CTO, product lead, revenue owner, finance lead, and support owner. The output is not an opinion survey. It is a map of promises, decision rights, recurring handoffs, and recent delays. Meanwhile, the CTO supplies the engineering capacity picture, technical risk register, incident load, and work that cannot safely pause. The two compare records and investigate every disagreement. In the second week, they create the single queue, stop or hold excess work, and assign outcome owners. This is the first test of authority. If leaders can only add priorities and cannot remove one, the CEO must make the trade in the room. The COO records the choice and communicates it to affected teams. In the third week, they run the commitment gate and weekly review against real decisions. They keep the artifacts small and revise fields that fail to produce a decision. The CTO establishes the technical stop conditions for releases and major changes. The COO establishes who handles customer, staffing, and commercial consequences when a stop condition triggers. By the fourth week, the CEO should be able to inspect a compact evidence set: - One ranked portfolio with a stated active-work limit - Decision rights for promises, technical safety, and priority changes - A commitment record for every material external date - A decision log with owners and reopening conditions - Trend evidence for blockers, priority changes, and capacity exceptions Do not declare victory because the meetings now run on time. Test the system with an uncomfortable request: a strategic customer wants an unplanned feature, an incident consumes planned capacity, or the CEO wants to insert a new initiative. If the company can expose the displacement, assign the decision, and communicate the change without routing everything through the CTO, the operating design has started to work. ## The boundary holds only when both executives can say no The COO and CTO split succeeds when each can reject a different kind of unsafe promise. The CTO can stop a release or refuse a technical plan that creates unacceptable security, reliability, or maintenance risk. The COO can refuse a company commitment that lacks scope, capacity, ownership, or cross-functional readiness. Each must explain the evidence and the condition that would change the answer. Conflict between the roles is normal. Concealed conflict is dangerous. When the COO accepts a commercial risk against the CTO's advice, record the objection, mitigation, owner, and review point. When the CTO requests more time, state which technical uncertainty or control requires it. The CEO resolves only true executive ties, using a decision record rather than whoever presents last. Do not hire a fractional COO to cure weak architecture, and do not hire a fractional CTO to police sales promises. If engineering cost and output are also part of the problem, the Team & AI Audit at oleg.is is a fixed $5,000, five-business-day engagement that identifies at least $50,000 a year in savings or it is free. That offer can expose capacity and engineering-system issues, but the CEO still needs to assign operating authority for cross-company commitments. The test for the turnaround is concrete: a promise enters through one gate, draws from visible capacity, carries technical conditions, and has one business owner. When reality changes, the company records the trade before it announces a new date. That discipline may feel slower during the first week. It is much faster than spending another quarter asking a CTO to repair decisions the company never made.