Fractional CTO & Virtual IT Director

There's a gap in most mid-market organizations that nobody talks about directly. The company has grown past the point where IT can be managed by committee. The office manager can't evaluate a firewall vendor. The finance director can't assess whether the ERP migration proposal makes sense. But it hasn't grown to the point where a full-time CTO or IT director is justifiable on the payroll.

This gap is expensive. It's where vendors sell products nobody needed. Where carrier contracts auto-renew for years because nobody reviewed them. Where the board hears "our IT is fine" from whoever drew the short straw, and assumes that silence means stability. It rarely does.

A fractional CTO fills that gap. Not a consultant who writes a report and disappears, but a technology leader who operates as part of your executive team. We attend board meetings. We manage your vendor relationships. We govern your IT budget. We make the decisions a permanent CTO would make, with the advantage of having done it across multiple organizations and multiple sectors.

What that looks like in practice

The engagement typically runs one to four days per month, depending on the complexity of the organization's technology estate. We start with an assessment of where things stand: what's running, what's exposed, what's costing more than it should, and what decisions have been deferred. Within the first ninety days, we deliver a technology roadmap that the board can actually use. Not a fifty-page strategy document that gets filed, but a prioritized list of what to fix, what to invest in, and what to leave alone.

From there, the work becomes operational. Vendor reviews happen on a cycle. Budget is governed against the roadmap. Security posture is assessed and improved. Contract negotiations happen with someone who knows what the market rate actually is and what concessions are worth fighting for. When the organization needs to make a major technology decision (a new ERP, a cloud migration, an office move that requires a full network redesign), there's someone at the table who has done it before and can separate the vendor's marketing from the engineering reality.

What we typically deliver

Board-level technology leadership and reporting: translating technical reality into business language
Technology strategy and multi-year roadmaps tied to business outcomes, not vendor timelines
Vendor evaluation, selection, and contract negotiation: because the sales engineer is not your friend
IT due diligence for M&A transactions, assessing what's really running underneath the target company
IT budget governance and spend rationalization (finding the contracts nobody reads and the licenses nobody uses)
Security posture assessment and remediation planning
IT team development, hiring, and restructuring
Multi-country IT governance for organizations expanding internationally

Who this is for

Organizations between fifty and five hundred employees where IT has become a boardroom concern but a full-time executive hire isn't the answer. Companies navigating M&A, international expansion, rapid growth, or the realization that the patchwork of systems accumulated over the years is becoming a liability. Private equity portfolio companies that need technology governance across the investment period. Family businesses that have scaled beyond the founder's ability to oversee IT alongside everything else.

Day-to-day IT support and managed services are delivered through The Tech Factory, our managed services operation. The two work in tandem: strategic leadership from Quimera Technology, operational delivery from The Tech Factory. But the consultancy and the managed service are independent. You can engage one without the other.

Critical Connectivity

Some networks are allowed to go down. An office loses its internet connection, people grumble, someone tethers to a phone, and the day continues. That's not the world we work in. The networks we design underpin operations where downtime has immediate, visible, and sometimes irreversible consequences: a live broadcast that doesn't make air, a vessel that loses contact, a defense operation that goes dark, or a stadium event that falls apart in front of sixty thousand people.

Critical connectivity is not about buying expensive hardware. It's about understanding failure modes: where circuits physically route, how failover actually behaves under load (not in the lab), what happens when a cell tower gets congested during a major event, and whether your "diverse" paths really are diverse or just diverse on the carrier's diagram. We've seen organizations spend significant sums on "resilient" connectivity where both circuits entered the building through the same duct. That's not resilience. That's a single point of failure with two invoices.

What we design

Every critical connectivity engagement starts with a failure mode analysis. What has to keep working? What's the recovery time objective? What's the environment. Fixed site, temporary deployment, mobile, maritime? From there, we design the architecture, specify the hardware, write the technical requirements for procurement, and oversee the implementation to make sure what gets deployed matches what was designed.

Resilient network architecture for zero-downtime environments: genuine path diversity, not just dual connections
Bonded cellular for broadcast contribution: SRT, RIST, and reliable transport over unstable bearers
Satellite connectivity design: GEO VSAT, MEO, and LEO architectures including Starlink and OneWeb integration
Hybrid WAN for remote and hostile environments: combining whatever bearers are available into something usable
Event and temporary infrastructure networking: deploy Friday, live Saturday, strike Sunday
Maritime and offshore connectivity: VSAT, cellular-at-sea, and the operational constraints of vessel environments
Field-deployable systems designed for operation by non-specialists: because the person pressing the button shouldn't need a CCNP

The vendors worth knowing

The critical connectivity market is full of vendors selling solutions that work brilliantly in controlled conditions and struggle in the field. We've evaluated and deployed hardware from Peplink, Cradlepoint, Mushroom Networks, Dejero, LiveU, TVU, Ceragon, and others. We know which products hold up under sustained load and which start dropping sessions after forty-five minutes. We know which vendors actually support their equipment in remote deployments and which ones point you to a knowledge base article. That experience shapes every specification we write.

Who this is for

Broadcasters, live event producers, maritime operators, defense contractors, and any organization whose core operation depends on connectivity that cannot fail. If your network going down means the show doesn't happen, the vessel can't communicate, or people are at risk. This is what we do.

Enterprise Network Architecture

Multi-site networking has a presentation problem. Every vendor has a clean slide showing boxes at branch offices connecting through a cloud with green lines to headquarters and data centers. The demo works. The proof of concept works. Then you deploy it across thirty-seven sites in twelve countries and discover that the underlay performance in Romania is nothing like the underlay performance in the UK, that the branch in Dubai routes through Mumbai, and that the application your logistics team depends on was never tested with the overlay's TCP optimization turned on.

We design enterprise networks for the real world. That means understanding not just the technology, but the commercial and operational constraints: carrier availability per site, local regulatory requirements, lease obligations on existing circuits, application behavior under latency, and the fact that "site B" is actually three buildings separated by a car park with no fiber between them.

SD-WAN done properly

SD-WAN is a category, not a solution. Cisco Viptela, Fortinet, VMware VeloCloud, HPE Aruba, Versa, and Cato all call themselves SD-WAN, and they all work differently. The choice depends on your application mix, your security model, your existing infrastructure, and whether you need the overlay to handle security or whether you're running a separate SASE stack. We've designed and deployed networks on most of the major platforms and we know where each one excels and where each one falls over.

More importantly, we know that the SD-WAN project is rarely just an SD-WAN project. It's usually the trigger for a broader network redesign that should include a review of your carrier contracts, your firewall estate, your DNS and DHCP infrastructure, your monitoring stack, and your disaster recovery assumptions. We scope the project to match the actual requirement, not the vendor's definition of what SD-WAN covers.

What we deliver

SD-WAN vendor evaluation and selection: structured comparison based on your actual application requirements, not the vendor's feature matrix
WAN architecture design for multi-site and multi-country organizations
MPLS migration planning: because ripping out MPLS without a plan is how you discover which applications can't tolerate jitter
Network resilience engineering: genuine path diversity analysis, not just ordering two circuits
Cloud connectivity architecture: Azure ExpressRoute, AWS Direct Connect, and the hybrid reality most organizations actually live in
SASE and zero-trust network design: integrating security into the network architecture instead of bolting it on afterward
Network monitoring and observability: because you can't manage what you can't measure, and SNMP traps aren't management
Carrier contract review and consolidation: finding the circuits nobody uses and the contracts nobody renegotiates

Who this is for

Multi-site enterprises that need their network to work consistently everywhere. Not just at headquarters. Organizations migrating from MPLS, expanding internationally, consolidating after acquisition, or discovering that their "SD-WAN project" is actually a full network transformation wearing a vendor's hat. IT leaders who are tired of being sold a product when they need an architecture.

How every engagement works

We don't do open-ended retainers with ambiguous scopes. Every engagement has a defined structure, clear deliverables, and an exit condition. We want you to know exactly what you're getting, when you're getting it, and how you'll know when it's done.

We also don't compete with your existing IT team or your managed service provider. We operate at the strategic layer. The decisions, the architecture, the vendor relationships, the roadmap. If you have an IT manager handling day-to-day operations, we work alongside them. If you don't, we help you figure out what support model you actually need and help you procure it, without taking a margin on the introduction.

Fractional CTO / vITD

Ongoing technology leadership, typically one to four days per month. Board attendance, vendor management, budget governance, team oversight. The engagement continues until your organization has scaled enough to justify a permanent hire. Or until you decide that the fractional model is the permanent model. Both outcomes are fine.

Strategic Advisory

Defined-scope engagements for specific decisions. Technology due diligence for M&A, network architecture reviews, vendor selection, security assessments. Typically two to twelve weeks. You get a written deliverable, a clear recommendation, and a handover that your team can execute against. Not an invoice for "ongoing consultation."

Design & Deployment

End-to-end network architecture for critical environments. We design the topology, specify the hardware, write the technical requirements for procurement, evaluate the bids, and oversee the implementation through commissioning. We don't sell the kit and we don't pull the cable. We make sure the people who do are held to the spec.

Start with a conversation.

Every engagement begins the same way: you tell us what you're dealing with, we tell you honestly whether we can help. No pitch deck, no committee, no obligation. If we're not the right fit, we'll say so.

Get in touch