Part of the series: The Post-Startup C-Suite

This is the final article in The Post-Startup C-Suite series. I've written about the CEO who must transition from founder to executive. The CRO who must be an operator, not a strategist. The CFO who must say no. The CPO who must follow a framework. The COO who must connect all the pieces. Each of those articles describes a role that depends on technology working correctly — plans rating properly in the BSS, CDRs flowing for reconciliation, provisioning completing on activation, payments processing, taxes calculating, dealer portals loading.

All of that is the CTO's world. And in most MVNOs, the CTO is either the wrong person for the job or is doing the wrong version of the job.

The Role That Gets Misdefined

Here's the hiring mistake I see most often: the MVNO recruits a CTO from a software development background. Someone who has built applications, managed engineering teams, shipped code. They're technically excellent. They understand architecture, APIs, databases, and deployment pipelines.

And they have no idea how a wireless BSS works, how MNO provisioning flows operate, how CDR feeds are structured, how a tax engine integrates with a billing platform, or why the dealer portal crashing on a Saturday morning is a revenue emergency and not a Monday-morning ticket.

The MVNO CTO is not a software engineering leader. They are a technology operations leader in a telecom context. The distinction matters because the MVNO doesn't build most of its technology stack — it assembles, integrates, configures, and operates a collection of third-party platforms. The BSS comes from a vendor. The tax engine comes from a vendor. The payment processor comes from a vendor. The MNO's provisioning system is the MNO's. The CTO's job is to make all of these platforms work together reliably, and to ensure that when any of them fails, the impact on the business is contained and the recovery is fast.

That's a fundamentally different skill set than building software.

What the CTO Actually Owns

The BSS: The Beating Heart

The BSS is the central nervous system of the MVNO. Subscriber lifecycle management — activation, provisioning, plan changes, suspension, deactivation. Real-time charging — rating every voice call, data session, and SMS against the subscriber's plan and balance. Billing — generating invoices (postpaid) or managing balances (prepaid). Reporting — subscriber counts, usage summaries, revenue recognition, CDR export.

The CTO owns this platform. Not in the sense that they personally configure rate plans (that's the CPO with billing ops validation) or reconcile invoices (that's billing operations). They own it in the sense that they are accountable for the platform's availability, performance, configuration integrity, upgrade management, and vendor relationship at the technical level.

When the BSS goes down, activations stop, existing subscribers can't recharge or make plan changes, the dealer portal shows errors, and customer care gets flooded with calls. Every minute of BSS downtime is a revenue event. The CTO who treats BSS uptime as an IT metric rather than a business metric doesn't understand the MVNO model.

The Integration Layer

The BSS doesn't operate in isolation. It connects to:

The MNO/MVNA provisioning system. When a subscriber activates, the BSS must trigger provisioning on the MNO's network — SIM activation, IMSI registration, plan assignment, number porting. This integration is the most fragile and most consequential in the stack. A provisioning failure means the subscriber paid for service and can't use it.

The CDR feed. Usage records flow from the MNO to the MVNO — typically via SFTP or API — for billing, reconciliation, and analytics. The CTO owns the reliability and timeliness of this pipeline. CDRs that arrive 72 hours late or in an unexpected format create reconciliation nightmares for billing operations.

The tax engine. SureTax, Avalara, or equivalent. Every subscriber transaction must be taxed correctly by jurisdiction. The integration must calculate taxes in real time at the point of transaction and produce filing-ready reports for remittance. A misconfigured tax integration creates financial liability that compounds across every subscriber, every month.

The payment processor. Credit card, debit, ACH, and potentially cash payment integrations. The payment system must handle auto-pay, manual top-up, failed payment retries, refunds, and chargebacks. Payment processing failures directly impact revenue — a subscriber who can't recharge is a subscriber who churns.

The dealer portal. Dealers activate subscribers, process plan changes, and check commissions through a web-based portal that connects to the BSS. If the portal is slow, buggy, or down, dealers can't sell. A dealer who can't activate a customer standing in their store will activate them on a competitor's service instead.

Customer self-service. The subscriber-facing app and website for account management, usage monitoring, payment, and plan changes. This is the digital storefront. If it doesn't work, the subscriber calls customer care — or switches carriers.

The CTO owns every one of these integrations. Not the business logic (that belongs to the CPO, CFO, CRO, and billing ops respectively) but the technical reliability. When any integration breaks, the CTO owns the incident response and the root cause resolution.

Platform Change Management

BSS vendors release updates. MNOs change their provisioning APIs. Tax engines update rate tables. Payment processors modify their SDKs. Each of these changes has the potential to break something that's currently working.

The CTO owns the change management process — the discipline of testing every platform update in a staging environment, validating that existing plan configurations still rate correctly, confirming that integrations still function, and deploying to production with a rollback plan if something goes wrong.

The MVNO that pushes a BSS update to production on a Friday afternoon without testing is the MVNO whose billing operations team spends Monday discovering that three plan tiers are rating incorrectly and 2,000 subscribers were overcharged over the weekend. The CTO who allows this to happen has failed at the most basic element of their role.

Vendor Performance Management

The MVNO's technology stack is only as strong as its weakest vendor. The CTO manages vendor performance against SLAs — uptime, response time, support quality, update cadence. When a vendor underperforms, the CTO escalates, documents, and if necessary, builds the case for migration to an alternative.

This is unglamorous work. It's not building cool technology. It's reviewing uptime reports, filing support tickets, attending vendor QBRs, and maintaining the kind of persistent, detail-oriented pressure that keeps vendors accountable. The CTO who finds this work beneath them will preside over a technology stack that gradually degrades.

The Good CTO

The good MVNO CTO has a specific orientation that distinguishes them from a generic technology leader:

They think in terms of business outcomes, not technology. When the CPO wants to launch a new plan, the good CTO doesn't ask "what's the architecture?" — they ask "what's the BSS configuration required, what's the testing plan, and when can billing ops validate it?" When the CRO reports that dealer activations are slow, the good CTO doesn't say "the system is performing within spec" — they investigate whether the provisioning integration has latency, the dealer portal has UX friction, or the activation API has a bottleneck.

They maintain an integration map that everyone can read. A living document that shows every system, every connection between systems, every data flow, and every dependency. When something breaks, the integration map tells the COO which functions are affected and the CTO which components to investigate. Without this map, incident response is guesswork.

They build for resilience, not elegance. The MVNO technology stack doesn't need to be architecturally beautiful. It needs to work — every day, every hour, under load, through vendor updates, through MNO provisioning changes, through tax rate updates. The good CTO prioritizes monitoring, alerting, redundancy, and failover over optimization and modernization. A slightly outdated system that never goes down is infinitely more valuable than a cutting-edge system that fails twice a month.

They own incident response personally. When the BSS goes down at 11 PM, the good CTO is on the bridge call. Not because they're micromanaging — because BSS downtime is a revenue emergency that requires executive-level vendor escalation, cross-functional communication, and real-time decision-making. The CTO who delegates incident response to a support engineer and reads the post-mortem the next morning has abdicated their primary accountability.

They say "that update isn't ready for production" and mean it. Just as the COO says "that launch isn't ready" and the CFO says "that plan doesn't work financially," the CTO must be willing to block a production deployment that hasn't been adequately tested. The pressure to deploy quickly — from the CPO who wants the new plan live, from the CRO who wants the dealer portal feature shipped, from the CEO who wants the board to see progress — is constant. The CTO who folds under that pressure is the CTO whose production environment breaks.

They translate technology into business language. The CEO doesn't need to understand API latency. They need to understand "dealer activations are taking 4 minutes instead of 30 seconds because the MNO's provisioning system is degraded, we've escalated, and here's the ETA for resolution." The CFO doesn't need to understand database schema. They need to understand "the CDR pipeline was delayed by 6 hours, which means billing ops is behind on this month's reconciliation, and here's the impact on the dispute filing timeline." The good CTO is a translator between the technology reality and the business impact.

The Bad CTO

Three failure modes:

The Builder

This CTO wants to build things. Custom BSS modules. Proprietary analytics platforms. In-house dealer portals. Home-grown payment integrations. They came from a software development background and they believe the MVNO's competitive advantage lies in proprietary technology.

It doesn't. The MVNO's competitive advantage lies in distribution, pricing, customer experience, and operational execution — not in having a custom-built BSS. Every dollar and every engineering hour spent building what could be bought from a vendor is a dollar and an hour not spent on the operational integration that actually matters.

The builder CTO's legacy is a collection of half-finished custom systems, a team of developers maintaining code that could have been a vendor feature, and a technology budget that is 2-3x what it should be. The classic tell: the builder CTO has a roadmap full of features. The good CTO has a roadmap full of integrations and stability improvements.

The Invisible

This CTO manages the technology from behind a screen. They respond to tickets. They attend vendor calls. They maintain the systems. But they never appear in the operating rhythm of the business — they're not in the weekly operating review, they don't participate in plan launch readiness discussions, they don't engage with billing operations on CDR quality, and they don't connect with the CRO on dealer portal performance.

The invisible CTO runs technology as a service desk rather than a business function. The result: technology decisions are made without business context, business decisions are made without technology input, and the gaps between the two produce the integration failures that the COO spends their week managing.

The tell: ask the COO how often the CTO raises issues proactively versus reactively. If the CTO only surfaces problems after they've broken something, they're invisible until they're firefighting.

The Perfectionist

This CTO won't deploy anything that isn't perfectly tested, perfectly documented, and perfectly architected. They block releases for weeks while they refine the configuration. They refuse to push a BSS update because one edge case hasn't been validated, even though the update fixes a critical billing defect affecting thousands of subscribers.

Perfectionism sounds like quality. In practice, it's a bottleneck that delays plan launches, slows feature delivery, and frustrates every function that depends on technology to execute. The MVNO doesn't need a perfect technology stack. It needs one that's good enough to work reliably, deployed fast enough to support the business, and maintained well enough to improve over time.

The tell: what's the average time from "ready to deploy" to "deployed in production"? If it's measured in weeks rather than days, the CTO is optimizing for perfection at the cost of velocity.

The CTO's Relationship with the C-Suite

With the CPO: The CTO and CPO must operate in lockstep on plan launches. The CPO defines the plan. The CTO configures it in the BSS, tests it, and confirms it's ready for production. Neither role has unilateral authority to launch — the CPO can't launch a plan the CTO hasn't validated, and the CTO can't block a plan the CPO has designed and the CFO has approved without a documented technical reason.

With the CFO: The CTO owns the technology budget. The CFO validates it against the financial plan. The CTO must be able to justify every vendor contract, every platform cost, and every engineering headcount in terms of business value — not technical necessity. "We need this because the architecture requires it" is not a business justification. "We need this because without it, CDR reconciliation takes 15 business days instead of 3, which means we miss dispute filing deadlines and lose $X in recoverable credits" is.

With the CRO: The CTO owns dealer portal performance and digital activation flow reliability. When the CRO says "dealers are complaining the portal is slow" or "digital conversion dropped 20% this week," the CTO investigates and resolves — not in a week, not after a sprint planning session, now. The dealer who can't activate a customer doesn't wait for the next release cycle.

With the COO: The CTO and COO are the closest partnership in the C-suite. The COO owns cross-functional handoffs. The CTO owns the technology that enables them. Together, they manage the plan launch sequence, the change management process, and incident response. When they're aligned, the operation runs smoothly. When they're not, every cross-functional process breaks at the technology seam.

With the CEO: The CEO should evaluate the CTO by one metric above all others: does the technology stack enable the business or constrain it? If the CRO, CPO, CFO, and COO are all spending time working around technology limitations, the CTO is constraining the business. If those roles can execute their functions without thinking about the technology underneath, the CTO is doing their job.

Consequences of Getting It Wrong

The wrong CTO in an MVNO produces a specific pattern of damage:

BSS instability becomes normalized. The organization learns to work around system issues rather than expecting them to be resolved. "The BSS does that sometimes" becomes an acceptable answer. Billing operations builds manual workarounds for CDR issues that should be fixed in the pipeline. Customer care develops scripts for known system errors instead of escalating them for resolution.

Integration debt accumulates. Each new vendor integration is bolted on rather than properly engineered. The CDR pipeline has three manual steps because the automated feed was never finished. The tax engine integration was configured at launch and never updated for rate changes. The dealer portal runs on an older version of the BSS API because upgrading would require regression testing that the CTO hasn't prioritized.

Technology cost creeps upward. The builder CTO's custom projects consume budget. The invisible CTO's lack of vendor management means contracts auto-renew at higher rates without negotiation. The perfectionist CTO's over-engineering means every project takes twice as long and costs twice as much.

And the ultimate consequence: the CEO becomes the de facto CTO, just as they became the de facto COO when that role was missing. The CEO is reviewing BSS vendor proposals, attending incident calls, and mediating between the technology function and every other function. The company now has a CEO who is doing three jobs and doing none of them well.

What to Look For

Telecom platform experience, not software development experience. The CTO must have worked with BSS/OCS platforms, MNO provisioning systems, CDR pipelines, and telecom-specific integrations. A software engineer who has never touched a BSS will spend their first 6-12 months learning the domain — time the MVNO doesn't have.

Vendor management as a core skill. The MVNO CTO manages vendors more than they manage engineers. They need to hold vendors accountable to SLAs, escalate effectively, negotiate technical requirements, and maintain productive relationships without being captive.

Integration thinking, not build thinking. Ask them how they'd approach a new requirement. If the answer starts with "we'd build..." instead of "we'd evaluate vendor options and integrate the best fit," they're a builder, not an MVNO CTO.

Incident response credibility. Ask about the worst production incident they've managed. How did they find out? How long to resolve? What was the root cause? What changed to prevent recurrence? The CTO who can walk through this with operational detail is the CTO who owns their production environment. The one who gives a vague answer delegated the incident to someone else.

Business language fluency. Can they explain a technology decision in terms the CFO would understand? If every answer is technical, they'll operate in a silo. The MVNO CTO must translate between technology reality and business impact in every conversation.

Recommendations

Hire for telecom operations, not software engineering. The MVNO CTO manages a third-party technology stack, not a development team. The skills that matter are platform configuration, integration management, vendor accountability, and incident response — not code review, architecture design, or sprint planning.

Require the CTO in the weekly operating review. Technology is not a support function — it's the platform every other function operates on. The CTO must be in the room, hearing the CRO's dealer portal complaints, the CPO's launch timeline requirements, and the billing ops team's CDR quality issues. A CTO who only hears about business needs through a ticket queue is an invisible CTO.

Maintain a live integration map. Every system, every connection, every data flow, every dependency — documented, current, and accessible to the COO and CEO. This is the CTO's equivalent of the CFO's financial model: the document that tells you how the operation actually works.

Set uptime and incident response SLAs for the CTO, not just the vendors. The CTO should commit to specific standards: BSS uptime target, incident response time by severity, maximum CDR pipeline delay, dealer portal availability. Measure them weekly alongside every other function's KPIs.

Make the decision at six months. If the CTO has not stabilized the platform environment, established a change management process, built the integration map, and integrated into the operating rhythm of the business within six months, the role isn't working. Technology problems that persist after six months of CTO leadership are CTO problems.