How we work
Fractional leadership
Fractional CTO / VP direction to set architecture, process, and hiring while you scale your team.
Sometimes the need is not another pair of hands. It is somebody senior deciding what the system is, what good enough means, and which of the four things everyone is arguing about actually matters — and then being around long enough to be held to it.
This is the mode for a team that is scaling faster than its process, a founder who is the de facto CTO and has stopped having time to be one, or an organisation facing a migration or re-platform where the cost of getting the architecture wrong is measured in years. Part-time, without the full-time hire, and with the explicit intention of not being needed indefinitely.
We have done the full-time version of this job — CTO and director of software development at A2 Hosting, engineering leadership at Site5 and Pressed before that — which is the only real qualification for doing the part-time version well.
What senior direction buys.
Four things, and only the first one usually makes it into the job description.
Architecture and technical direction
Somebody has to decide what the system is, hold that decision while it is unpopular, and revisit it when it turns out to be wrong. Done badly it produces a codebase where every subsystem reflects whoever was on call the week it was written.
TurboHub is the clearest example: a Laravel control plane built alongside the vendor billing product it was architected to outlive, with one rule underneath every decision in it — never query WHMCS's database, only its API. That single constraint is what bought A2 the option to replace the vendor later, and it held across five thousand servers and four datacenters because it was set at the start and defended.
The process that lets people ship confidently
Coding standards, review that means something, sprint planning that survives contact with a support queue, and reporting that tells you where the work actually went. Process is not overhead — it is the thing that lets a developer merge on a Friday without checking who else is around.
On TurboHub we set the standards, the review workflow, and the sprint cadence for the team that built it. A sprint reporting tool we wrote for ourselves took Jira reporting from fifteen or twenty minutes of manual assembly down to seconds, which is the difference between a metric that gets reported and one that quietly stops being.
A new developer shipping on their first day
The most useful measure of an engineering organisation is how long it takes a new hire to put something in production. It is a proxy for everything else: environment setup, documentation, test coverage, deploy safety, and whether anyone has written down how the thing works.
At A2 we got that to the first day, which took onboarding automation that pulled environment setup down from multiple days to same-day, and standards written where people would actually meet them. It is the achievement from those years we would both point to first — see about.
Hiring and mentoring the team you keep
The point of fractional leadership is that it ends. What has to be true by then is that the people who stay can make the decisions we were making, which means interviewing, levelling, and mentoring are part of the engagement rather than adjacent to it.
Helix was started by the two of us and then handed to a team we hired around it; it ran for eight years across three companies. Career arc, for what it is worth as evidence: solo developer to director of software development to co-founder, on both sides of the table for a lot of those hires.
What twelve engineers looked like.
On TurboHub we set the architecture and led the twelve engineers who built it, from MVP to a control plane serving 385,000 sites for 110,000 customers. The work that made that possible was not architectural heroics. It was deciding the one rule the system was not allowed to break, writing the standards down, making review non-optional, and running a sprint cadence that people could actually plan against — then holding all four of those in place for two years while the requirements moved.
Part-time, that looks less dramatic and mostly the same: a standing slot in planning, design review on anything structural, pull request review as a matter of course, hiring loops when they come up, and being the person your engineers can escalate a technical argument to. We still write code while we do it — direction that has not compiled in three years is a liability.
Two of them, written up in full.
TurboHub
A2 Hosting's customer control panel, built alongside the vendor product it was architected to outlive — a Laravel application with no users of its own, a PHAR daemon on every hosting server, and one rule underneath both: never query WHMCS's database, only its API. Two years, twenty-five people, four datacenters.
Read case studyWormhole
Roughly ten thousand customers moved off three separate WHMCS installations and into Helix — one JSON file per record, one brand per maintenance window, and no billing incident anyone had to apologize for. Two and a half years, a team of ten. The interesting part is everything we decided not to carry.
Read case studyWhen this is the wrong choice.
If what you are short of is throughput rather than direction — the priorities are clear, the architecture is settled, and the problem is that the list is longer than the team — this is the expensive way to buy it. You would be paying for judgement you already have and not getting the hands you need.
It is also the wrong choice if the intention is for someone else to own the decisions permanently. Fractional leadership works when there is a team to leave behind, or a full-time hire it is bridging to. If neither is true, it becomes an outsourced CTO nobody can escalate past, which is worse than the gap it was filling.
If you are the person currently making every technical decision by default, that is the conversation to start with.