- Zen IT Technologies
- Why Zen IT
You have four options. Three of them are sometimes right.
Most companies at your stage are choosing between a managed service provider, an internal hire, a consultancy, and continuing to absorb IT into engineering. Each of those works in specific circumstances, and each fails in predictable ones.
Here is what we think the honest comparison looks like, including where we are the wrong answer.
Comparison matrix
-
A managed service provider
Where it wins Coverage and headcount
Where it fails Tickets are not architecture
-
An internal hire
Where it wins Presence and full context
Where it fails One salary, five disciplines
-
A consultancy
Where it wins Depth on a defined problem
Where it fails The engagement ends at handover
-
Absorbing it into engineering
Where it wins Free, for a while
Where it fails Your best engineers, spent on IT
The alternatives
-
A managed service provider
Where it wins: breadth of coverage and headcount. A help desk that answers at 8am regardless of who is on holiday, and a contract that scales to hundreds of endpoints without renegotiation.
Where it fails: the model is built around ticket resolution, and ticket resolution is not architecture. Whoever picks up your ticket has no memory of why your firewall is configured the way it is, so the fix is local and the design decays. Over three years the estate accumulates a hundred locally correct decisions that nobody made together.
For a company running standard infrastructure with commodity requirements, this trade is fine. For a technology company with an identity model, a compliance obligation, and a security posture that has to survive customer scrutiny, it compounds badly.
-
An internal hire
Where it wins: full-time presence and total context. At sufficient scale it is unambiguously the right answer, and part of our job is telling you when you have reached it.
Where it fails: below that scale, you cannot hire the person you actually need. One salary buys one skill set, and your requirements span identity, endpoint security, networking, cloud, and compliance. The generalist you can afford will be strong in two of those and improvising in the rest, usually the ones where improvisation shows up in an audit.
There is also the failure mode nobody plans for: a single internal person is a single point of failure with a notice period, and everything they knew leaves with them.
Which is why this is not either/or. Where an internal team already exists, we work alongside it rather than against it, bringing senior depth to migrations, integrations, and security work that is expensive to hire for and rarely needed full time. The internal team keeps ownership.
-
A consultancy
Where it wins: depth on a defined problem, and a name that satisfies a board.
Where it fails: the engagement ends. You get a design and a document, and then the implementation lands on whoever is left, usually your engineering team, who did not ask for it. Consultancies are also, structurally, not the people who run what they designed, which means the design is rarely shaped by having to live with it.
To be fair to them: consultancies clear vendor onboarding and security review without difficulty. That is not where they fail. They fail at the handover.
-
Absorbing it into engineering
Where it wins: it is free, and it works for a while.
Where it fails: it stops working quietly. Your engineers are competent enough to keep things running, which is exactly why the erosion is invisible. Access reviews that never happen, an identity model that drifts, a firewall rule added at 11pm and never revisited. The cost is not the hours. It is that your best engineers are spending attention on infrastructure instead of product, and the security posture is being maintained by people whose actual job is something else.
What we do instead
-
One architect, embedded
You get a named person who holds the whole estate: identity, endpoints, network, security operations. The same person is still there in year three. Not a queue, not a rotation, not a different engineer each time. For companies with an internal IT team, this is our fractional IT architecture model: senior technical ownership and continuity without adding another full-time senior role.
The advantage is not responsiveness. It is that decisions get made against a design that someone remembers, so the estate improves over time instead of accumulating.
-
Architecture-led, not ticket-led
Work starts from how the environment should be built, not from what broke this morning. Incidents get resolved, but they are treated as evidence about the design rather than as the unit of work.
-
Thirty years of estates, applied to yours
The value of having run many environments is knowing which decisions are load-bearing and which are reversible. Most infrastructure judgment is pattern recognition, and patterns need volume to recognize.
-
Depth across the whole surface, not one part of it
Identity, endpoint security, networking, email infrastructure, and cloud platforms. These are the areas that a single internal hire cannot cover and that an MSP covers at surface level. These are also the areas that interact: an identity decision changes your endpoint posture, and an email decision depends on DNS you also use for authentication.
-
We verify outcomes, not configuration
A control existing in an admin console does not mean it works. We verify the result: devices actually enroll, policies reach the endpoints they are meant to protect, access follows the intended model, offboarding removes it, and certificates and integrations remain healthy.
Configured is not the same as working.
-
IT doesn't operate in isolation
Identity starts with People & HR. Equipment touches Operations and Finance. Security affects R&D. SaaS decisions cross almost every department. We work with the people behind those processes, not just the systems underneath them.
When we are the wrong choice
-
Under about twenty people, for ongoing work.
Ongoing work is more than you need. Use a small local provider or absorb it into engineering, and revisit when headcount or a compliance obligation forces the issue. A defined project can still be worth doing at that size: an access review, a deliverability audit, a Wi-Fi deployment.
-
When you only want to maintain the status quo.
If you want an MSP to reset passwords, manually provision laptops, and keep the environment running exactly as it does today, we are probably not the right fit.
We provide help desk and user support, but with a purpose: every ticket is feedback. Repeated problems should be engineered out, manual provisioning should become zero-touch, and the user experience should get better over time.
The goal isn't to run a busier help desk. It's to build an environment that needs it less.
-
When you need someone on site every day.
The work is remote by design. Identity, endpoints, and cloud infrastructure are managed the same way regardless of where the office is, and on-site time is arranged where a deployment requires it. If your requirement is a physical presence in the building daily, that is a different job.
-
During an active incident, if you are not already a client.
You need a dedicated response firm that can mobilize today. We would rather say that than take the engagement.
When we are the right choice
Technology companies. Technical staff, opinions about their own infrastructure, a SaaS estate that has outgrown informal management. Usually the trigger is growth: an environment that has not kept pace with the company running on it. A compliance obligation (SOC 2, ISO/IEC 27001, a customer security questionnaire) often sets the deadline, but the work is the environment, not the certificate.
Some have no internal IT and want the function run. Some have a team and want senior depth alongside it. Some have one problem and want it solved properly. All three are normal.
Companies that want infrastructure designed deliberately rather than allowed to accumulate, and that would rather have one person who knows everything than a contract that covers everything.
Why we work this way
-
IT starts with people.
IT is ultimately about people and how they interact with technology. A well-designed environment starts with understanding how the company is structured, how its people actually work, where friction appears, and what ongoing support and operational feedback reveal.
That means working with Operations, People & HR, Finance, R&D and other teams to understand the processes behind the systems, not just the systems themselves. Onboarding, access, equipment, approvals, collaboration and day-to-day support all show us how the environment is really being used.
We use that understanding to shape the systems, infrastructure and processes around the business, then keep improving them as the company evolves.
The goal is not simply to manage technology well. It is to create an IT environment that feels natural to use, supports the way the company operates, and gives people the best possible experience while remaining secure, reliable and manageable.
-
Use what you have. Spend where it matters.
Better IT doesn't always mean buying more technology. We start by understanding the tools you already have, what they can do, and whether you're actually getting the value you're already paying for.
We are vendor-independent. We don't sell licenses, receive commissions, or have a financial interest in recommending one platform over another. Recommendations are based on what we believe is the most practical, secure and commercially sensible solution for the company at its current stage.
Sometimes the right answer is a new platform. Sometimes it's using an existing one properly, consolidating overlapping tools, or deciding that a capability simply isn't worth paying for yet.
The goal is to spend where it makes a difference, save where it doesn't, and keep the environment as simple as it can reasonably be.
-
Everything is documented and yours.
Designs, runbooks, findings, and administrative access are yours throughout, not held as leverage. Documentation is part of the work rather than an extra, and handover is part of the engagement rather than a favor. We would rather leave an estate someone else can run than one that traps you.
Find out whether this is the right fit.
A 30-minute call with Jonny. If a different model suits you better, we will tell you which one and why.