IT Systems Administrator (Remote)

About Techvestor
Techvestor is a US-based holding company with businesses in short-term rentals, property management, construction and renovation, and design. We run four business units and we are doubling headcount this year.

Why this role exists
We have never had a dedicated IT function. Today it is split between a Finance Lead, a People Lead who is moving to a full-time talent role, and an engineering lead. None of them should be doing it.

Concretely, this is what happens now:

• Someone forgets a password on a Saturday and calls our engineering lead directly
• An offboarding request arrives while that person is driving, so a leaver keeps their access until someone is free to revoke it
• When our virtual phone system goes down, the engineering lead calls the account manager, raises the ticket and chases the fix
• There is no record of what any individual has access to, across roughly 21 integrations, 29 running services, 12 domains and 8 databases
• Nobody audits what we are paying for or who is actually using it

You are hiring into a blank page. The first thing you build is the system that should already exist.

We are hiring two
One person cannot cover four business units across business hours and carry a rota. Two gives us a staffed desk and a sustainable alternating on-call. You will be hired as a pair, you will split brand coverage between you, and you will cover for each other.

What you will do
** Build the foundation — first 90 days

• Build the access register. Every person, every system, every permission level. This does not exist today and everything else depends on it.
• Write the joiner-mover-leaver runbook. What gets provisioned on day one by role, what changes on a move, and what gets revoked on exit — verified against the register, not from memory.
• Scope and stand up ticketing. We are building our own. You define the requirements, the priorities, the response targets and the categories; our engineers build it with you. Requests stop arriving as direct messages.
• Scope the request and approvals tool. Access requests, tool provisioning and license approvals routed to the right approver and logged against the person.

** Run it — ongoing

• First-line support across every business unit. Accounts, access, devices, software, the lot.
• Identity and access management. Google Workspace, Slack, 1Password, Atlassian, GitHub, Supabase, Render, Cloudflare, plus every operational platform — Hospitable, Breezeway, Turno, Quo, CompanyCam.
• Vendor management and escalation. When a platform breaks, you are the one who raises the ticket, chases the account manager, and keeps the business informed. Not an engineer.
• Subscription audit. A recurring review of every paid tool across the group: what we pay for, who actually uses it, what gets cancelled. This has never been done.
• Device fleet. Laptops and accounts for a doubling headcount, on-call phones, and field devices for market managers working across states.
• Security hygiene. MFA coverage, password policy, shared-credential elimination, and finding the vendors that still only offer SMS two-factor.
• 24/7 and weekend cover, alternating between the two of you.
• Documentation. Runbooks for everything, so the second person can cover the first.

** What you bring

• 3+ years in IT support, systems administration or IT operations, ideally in a company that was growing fast and under-tooled
• Google Workspace administration at admin level — users, groups, org units, security settings, device management
• Identity and access management. SSO, MFA, provisioning and deprovisioning, least-privilege. 1Password or a comparable enterprise password manager
• SaaS administration across a wide estate. Slack, Atlassian (Jira and Confluence), GitHub. Comfort learning a platform you have never seen because the business just bought it
• Ticketing systems. You have run a queue with published response targets and reported on it
• Vendor escalation. You have held a vendor to an SLA and chased an outage to resolution
• Asset and license management. You know what the company owns, who has it, and what it costs
• Clear written communication. Async-first, distributed, and you will be writing the documentation that does not exist yet
• Comfort with ambiguity. There is no runbook here. You are writing it

** Nice to have

• Scripting — Google Apps Script, Python or PowerShell — to automate provisioning rather than doing it by hand
• Experience selecting or specifying a ticketing system, not just using one
• Exposure to developer tooling: GitHub, Render, Supabase, Cloudflare
• Mobile device management, Apple device management
• Security or compliance work — access reviews, audit evidence
• Multi-entity or holding-company environments
• Experience as the first IT hire somewhere

** Where this role stops

• You own access, identity, devices, vendors and licenses. You do not build product features or own application code.
• You scope and specify the ticketing and request tools; engineers build them. You define the requirements, the priorities, the response targets and the categories. They write the code.
• You own SaaS and license spend. Hosting belongs to engineering, AI token spend belongs to the AI and Automation Specialist.
• You are the first responder for access, devices, accounts and third-party outages. Application failures, broken integrations and failed automations go to engineering — your job is to route them there fast, not to fix them.

** What success looks like
30 days - The access register exists and is complete for at least two business units. Both of you know every system we run.
60 days - Ticketing is live with published response targets. Requests stop going to engineers as direct messages.
90 days - Joiner-mover-leaver runbook in use. Every leaver verified against the register. First subscription audit delivered.
6 months - 24/7 and weekend cover running sustainably between you. Time-to-revoke on a leaver is a number we measure. No engineer has been pulled into an IT issue in a month.

** What we are not asking for
You are not a help desk ticket-closer. You are standing up a function, choosing the tooling, and writing the process. If you want to be handed a runbook, this is the wrong role. If you want to write the one that was never written, it is a good one.