Getting Software Onto a Managed Work Laptop

The first thing many developers do on a new work machine is try to install something. The second thing many of them do is discover they cannot.

This is a disorienting moment, especially if you have come from a smaller company or from freelancing, where the machine is yours and the only limit is what you are willing to download. On a managed device, installs can fail for several different reasons, and the error messages are rarely clear about which control blocked you.

It is worth understanding what is happening, because "the laptop is locked down" is not one thing. It is several separate mechanisms with different owners, and knowing which one is stopping you tells you who to ask and what to ask for.

What "managed" actually means

A work laptop is usually enrolled in a device management system. Microsoft Intune, Jamf for Macs, and older tools such as SCCM are the common ones. Enrolment means the machine checks in with a central service, receives policies, and reports its state back.

Those policies are what you are running into. They typically cover:

• Which applications may be installed, and by whom
• Whether you hold local administrator rights
• Disk encryption (so data remains unreadable if the device is lost or stolen), screen lock timeouts and password rules
• Which security agents run, and what they inspect
• What happens if the device is lost, which is usually a remote wipe

None of this is aimed at you personally, and none of it is negotiable by you individually. These controls exist so the company can meet security, compliance and audit requirements across every device.

So when an install fails, the first question is which mechanism refused it: the device policy, the endpoint agent, the browser download filter, or a missing local administrator right. Each has a different owner and a different request path, and the error message rarely names which one it was.

The self-service catalogue

Most managed environments provide a self-service software catalogue. On Windows this is often Company Portal or a Software Center. On Macs it is frequently Jamf Self Service. Some organisations build their own portal for the same purpose.

The catalogue holds packages that have already been approved, licensed and, importantly, packaged. That last word is doing more work than it looks. A packaged application has been configured for the environment: it may already trust the corporate certificate, already point at the internal package registry, already have the proxy configured, and already be licensed against the company's agreement.

This is why the advice is always to install from the catalogue rather than downloading the installer from the vendor's website, even when the download would work.

• It has been tested against device policy
• It will be updated when a security patch is required
• It is less likely to trigger avoidable security alerts
• It is often pre-configured for your network, which can save an entire afternoon of setup trouble

Open the catalogue on day one and read the whole list, before you need anything. It tells you a surprising amount about the organisation: which editor the developers use, which database tools are standard, whether containers are expected, which cloud provider you are on. It is a free map of the engineering culture and it takes ten minutes.

Administrator rights

Whether you get local administrator rights on your own machine varies enormously and it is worth finding out early rather than assuming.

You may hold them permanently, which is common in smaller and less regulated companies. You may hold none at all. Or, increasingly, you may be able to request temporary elevation: a short window of administrator access, sometimes requiring a reason, sometimes approved automatically, sometimes needing a manager.

If elevation exists, learn the process before you need it, because you will need it at an inconvenient moment. Find out how long the window lasts and whether anything you install during it survives afterwards.

If you have no route to administrator rights at all, it changes how you set up your environment rather than making it impossible. A large amount of developer tooling can be installed per user rather than per machine, into your home directory rather than into the system directories that need elevation. Language version managers, portable editions of tools, and user-scoped installs of runtimes will get you a long way. Containers help too, when they are permitted, because the container carries its own dependencies and the host machine does not need to.

What you should not do is spend your first week looking for a way around the policy. It is visible, it is logged, and the impression it creates in month one is not the one you want. If the supported route does not work for your role, that is a conversation to have openly with your lead, who may well agree with you and may already have the exception process on file.

Package managers on a managed machine

Developers arrive with habits. Homebrew on a Mac, Chocolatey, Scoop or winget on Windows, apt on Linux. These frequently work on a managed machine, and frequently work only partly.

The common friction points:

• Homebrew may need administrator rights for its initial install location, even if day-to-day use is fine afterwards.
• Package managers pull from the public internet, so proxy and certificate settings can block downloads.
• Device policy may block unsigned binaries or execution from user directories, even when install succeeds.
• Mixing centrally managed tools with package-managed tools can create duplicate versions and path confusion.

The pragmatic approach is to use the catalogue for anything it offers, and your package manager for the long tail it does not, while being aware that anything you install yourself is now yours to keep updated.

When what you need is not in the catalogue

This will happen. Some tool you consider basic will not be there.

There is usually a software request process, and it usually involves more than clicking a button, because approving new software means somebody assessing its licence, its security posture, its data handling and occasionally its country of origin. In a regulated environment this can take weeks, and the request may be refused for reasons that are entirely legitimate and nothing to do with the tool's quality.

To give a request the best chance:

• Ask first whether an approved equivalent already exists. Very often one does, and the answer arrives in a minute rather than a fortnight.
• Say what you need it for, not just what it is. "I need to inspect HTTP traffic while debugging the payment integration" gets a better response than "please install this tool".
• Name the specific edition and licence. Free for personal use is not the same as free for commercial use, and that distinction is often the entire decision.
• Ask what the usual turnaround is, so you can plan around it rather than wait on it.

Then, while it queues, find the interim workaround. There is nearly always one: a browser based version, something already approved that does eighty percent of the job, or a colleague who solved the same problem last year with a tool that is already on the list. Being blocked on a software request is not a reason to be idle.

Why builds can be slower on managed laptops

A common and rarely explained experience: the same project that built in ninety seconds on your old machine takes four minutes on the new one.

The usual cause is the security tooling. Endpoint detection and response agents, real time antivirus and data loss prevention software all inspect file activity as it happens. A build is close to a worst case for that kind of scanning. It creates, reads and deletes tens of thousands of small files quickly, and each one gets inspected.

Add full disk encryption (which protects data at rest by requiring authorised unlock), plus a corporate proxy in front of every dependency download, and the difference adds up.

You usually cannot remove any of that. What you can often do is ask whether exclusions exist for development directories. Many security teams already maintain a standard set of exclusions for build output folders, package caches and container storage, precisely because this problem is well known. It is a reasonable, specific and security-aware question to ask, and the worst answer is no.

If the answer is no, the remaining levers are the ordinary ones: build caching, incremental builds, and not putting your workspace on a network drive or a folder synced to cloud storage, where every file a build writes triggers an upload.

How much this differs between companies

The spectrum here is wider than in almost any other article in this series.

At one end, you get a machine with full administrator rights, no device management, and an expectation that you will install whatever you need and take responsibility for it. Fast, flexible, and entirely dependent on everyone being sensible.

In the middle sits the self-service catalogue described above, which is where most medium and large organisations land.

At the strict end, every install is a ticket, every ticket has a security review, and the review has a queue. Sometimes you do not get a laptop at all in the usual sense, and you work inside a virtual desktop: a remote machine you connect to, where the local device is little more than a screen. That brings its own experience, and it is worth knowing early because it changes how you think about everything from performance to where your files actually live.

There are also bring your own device arrangements, where the company has to protect its data on a machine it does not own. That usually means a managed work profile or a container on your own hardware, and a firm boundary about what lives inside it.

Which one you get follows from what the organisation stands to lose if a machine is compromised, which is why a startup and a hospital trust arrive at different answers.

Take away actions

• Open the self-service catalogue first, then install all approved essentials from there.
• Confirm your admin-rights model early: permanent admin, temporary elevation, or none.
• Use approved tooling by default; if something is missing, raise a software request with a clear business need.
• Plan for performance on managed devices: ask whether standard build-folder exclusions exist.
• Track setup blockers as you go and turn that list into onboarding notes for the next joiner.

Next in the series: the corporate proxy, and why every tool you own has a different opinion about where its network settings live.