What Does an IT Person Do? A Role-by-Role Breakdown for Business Leaders
The question sounds simple. It almost never is.
Most people outside IT have a working theory: the IT person fixes computers, resets passwords, and occasionally does something mysterious with servers. That mental model isn’t entirely wrong—but it accounts for maybe 15% of what IT work actually involves at a functioning organization.
The gap between perception and reality matters more than it used to. When leadership doesn’t understand what IT people actually do, they underinvest in the wrong areas, overinvest in others, and consistently miscommunicate what they need from technology partners. The result tends to be IT departments that spend most of their time on reactive support while strategic technology work either doesn’t happen or gets outsourced without clear direction.
This piece breaks down what an IT person actually does—organized by function rather than job title, because titles vary wildly while the underlying work tends to follow recognizable patterns.
The Problem With Job Titles in IT
A “Systems Administrator” at a 20-person professional services firm might do everything: manage email, maintain the network, handle endpoint security, onboard new employees, and advise leadership on software purchases. At a 500-person company, a Systems Administrator might do exclusively one of those things.
The same title. Completely different scope.
This is why answering “what does an IT person do” by listing job titles doesn’t work. What works better is mapping IT work by function—the categories of work that need to happen regardless of how many people are doing it or what they’re called. You can explore the specific title-to-responsibility mapping in more detail in our breakdown of IT job duties and responsibilities, but here we’re focused on function over form.
The Six Core Functions IT Work Actually Covers
1. Infrastructure and Environment Management
This is the work that keeps the lights on. Servers, networks, storage, cloud environments, email systems, identity management—someone has to configure them, monitor them, patch them, and fix them when they break.
In practice, this means an IT person in this function might spend their morning reviewing overnight monitoring alerts, their midday patching a vulnerability in a server operating system, and their afternoon troubleshooting a switch that’s causing intermittent connectivity issues for a specific floor of an office building.
None of that shows up on a business dashboard. None of it generates revenue directly. But when it fails, everything else stops.
The invisible nature of good infrastructure work is one reason this function is chronically underfunded. When IT infrastructure works, leadership often concludes it doesn’t require much attention. The organizations that have avoided major outages for years tend to have invested consistently in the people doing this work—not the ones who got lucky.
2. End-User Support
This is the function most people actually see. A helpdesk technician, IT support specialist, or desktop support engineer fields requests from employees who can’t access a file, whose printer isn’t working, whose laptop is running slow, or who got locked out of an account.
At surface level, this looks like reactive service delivery. And at many organizations, that’s all it is. But well-run IT support functions do something more useful: they use support ticket data to identify patterns.
If eight people in the same department submitted tickets about the same application crashing in the same two-week window, that’s a signal—maybe a configuration issue, maybe a software update that broke something, maybe inadequate training on a new tool. The IT person who only resolves tickets misses this. The IT person who analyzes ticket trends surfaces a problem before it becomes a crisis.
This distinction between reactive and pattern-aware support is one of the clearest indicators of IT department maturity.
3. Security
Security work in IT spans a wide range—from configuring firewall rules and managing endpoint protection software, to reviewing access permissions, monitoring for suspicious activity, responding to incidents, and training employees on how to recognize threats like phishing.
For a deeper look at one of the most common and underappreciated threat vectors, see our breakdown of signs of phishing by channel—the way phishing attempts present differently in email versus Teams versus SMS versus QR codes is something most security training misses entirely.
The challenge in security work is that the threat landscape shifts faster than most organizations’ security postures do. An IT person doing security work is, in part, doing research continuously—staying current on new attack methods, reviewing advisories from software vendors, and evaluating whether the organization’s current controls are still adequate.
At smaller organizations, security work often gets absorbed by whoever manages infrastructure. That’s workable up to a point, but it creates a prioritization problem: infrastructure incidents are immediate and visible; security risks are latent and invisible until they’re not. The infrastructure work wins the attention battle almost every time.
4. Project Delivery and Systems Implementation
Not all IT work is operational. A significant portion involves implementing something new—migrating from on-premises file storage to SharePoint, deploying a new ERP system, integrating two applications that don’t currently talk to each other, or building an internal tool that automates a manual process.
This work looks different from day-to-day operations. It requires scoping, planning, stakeholder communication, vendor coordination, testing, and change management. An IT person doing project work might spend their week in planning meetings, writing technical specifications, coordinating with a software vendor’s implementation team, and building out a test environment to validate configurations before they go live.
Project delivery is also where IT work intersects most visibly with business outcomes. When a systems migration goes badly—data lost, integrations broken, employees unable to work during cutover—it’s a business problem, not just a technology problem. Organizations that treat IT project delivery as a purely technical exercise tend to learn this the hard way.
5. Governance, Compliance, and Documentation
This function is often the most neglected and least understood.
Governance in IT means establishing and enforcing policies about how technology is used, accessed, configured, and decommissioned. Who can access what data? What happens to a former employee’s accounts when they leave? What software is approved for business use, and what process exists for requesting new tools?
Compliance means ensuring the organization’s IT practices meet applicable regulatory requirements—HIPAA for healthcare data, SOC 2 for service organizations that handle customer data, state privacy laws, and others depending on the industry and geography.
Documentation means maintaining accurate records of the IT environment: network diagrams, configuration baselines, software inventories, procedure runbooks. Organizations without good documentation are entirely dependent on individual IT people who carry the environment in their heads. When those people leave, the knowledge leaves with them.
An IT person focused on governance work might spend their week auditing user access to a file share to verify that only active employees with a business need have access, reviewing a vendor’s security questionnaire, and updating the organization’s IT policy documentation to reflect a recent change in tooling.
This work is procedurally tedious and strategically critical. The organizations that discover they’ve been out of compliance during an audit—rather than before one—often find that someone was supposed to be doing governance work and wasn’t.
6. Strategic Planning and Advisory
At more senior levels, IT work shifts toward planning, evaluation, and alignment. A Director of IT or CTO isn’t typically fixing laptops—they’re evaluating whether the current technology stack supports where the organization is going, identifying technology risks that leadership should be aware of, and translating business requirements into technical decisions.
This is the function that gets called “IT strategy,” and it requires a different skill set than the operational functions above. Technical depth matters, but so does business fluency—the ability to understand what the organization is actually trying to accomplish and map technology decisions to those objectives.
For organizations that don’t have this capability internally, IT advisory services fill this role—external experts who provide strategic guidance without being embedded full-time.
What IT Work Actually Looks Like Day-to-Day
Here’s what’s worth understanding: most IT people work across multiple functions simultaneously, and the distribution of time across those functions shifts constantly.
An infrastructure engineer might spend 70% of their week on operational tasks and 30% on a migration project. The following week, an unexpected network issue might flip that ratio entirely. A security incident might consume three consecutive days.
The unpredictability is structural, not personal. IT environments are complex interdependent systems. Changes in one place create ripple effects in others. Vendor software updates introduce bugs. Hardware fails outside of its predicted lifecycle. Users do things with technology that no one anticipated.
This is why IT capacity planning is genuinely difficult. You can staff for the expected workload, but the unexpected workload is often larger—and it arrives without warning.
Where the Lines Blur (And Why That Matters)
At many organizations, particularly smaller ones, individual IT people cover ground across multiple functions because there simply aren’t enough people to specialize. One person might own infrastructure, handle support tickets, manage security tools, and participate in vendor evaluations—all in the same week.
This is workable, but it creates predictable failure modes:
The strategic gets crowded out by the urgent. When the same person is responsible for both patching servers and evaluating a new collaboration platform, the servers get patched and the evaluation gets deferred. Infrastructure emergencies reliably beat strategic work in the prioritization battle.
Depth suffers across the board. Security is a domain where staying current requires real time investment. An IT person carrying four functional responsibilities probably isn’t spending enough time on security research to keep pace with the threat environment.
Single points of failure accumulate. When one person holds the institutional knowledge for an entire IT environment, that person’s absence—planned or unplanned—creates operational risk.
This is the structural argument for managed services, additional IT staff, or more deliberate role definition as organizations grow. It’s not that the IT people are underperforming. It’s that the math of one person covering six functions doesn’t work beyond a certain scale.
For context on how this plays out in specific markets, our piece on managed services in Raleigh covers how the Triangle’s growth dynamics are reshaping how local organizations think about IT capacity.
The Skill Sets That Cut Across All of It
What makes IT work genuinely hard isn’t the technical knowledge alone—it’s the combination of technical knowledge with the communication and problem-solving skills needed to apply it in organizational contexts.
An IT person who can configure a complex network but can’t explain to a business leader why a proposed shortcut creates a security risk isn’t fully effective. Neither is one who communicates well but lacks the technical depth to make sound configuration decisions.
The most effective IT people tend to be good at:
- Translating between technical and business language. Explaining what a vulnerability actually means for operations, not just that it has a CVSS score of 8.9.
- Managing competing priorities under uncertainty. Deciding what to address first when three things break simultaneously.
- Maintaining systems thinking. Understanding that a change to one system has implications for others, and mapping those implications before acting.
- Knowing what they don’t know. Recognizing when a problem exceeds their expertise and sourcing external support rather than improvising.
These aren’t soft skills in the dismissive sense—they’re functional requirements for the work.
Frequently Asked Questions
What does an IT person do on a typical day? There’s no single answer because it depends heavily on their function and organization size. An IT support technician might spend most of their day resolving helpdesk tickets and troubleshooting user issues. A systems administrator might spend their day on infrastructure maintenance, patching, and monitoring. A senior IT leader might spend most of their day in meetings, planning conversations, and vendor evaluations. The only consistent element is that unplanned work routinely disrupts planned work.
Is IT just about fixing computers? No, though that’s the most visible part. IT work spans infrastructure management, security, compliance, project delivery, strategic planning, and governance. End-user support—which includes fixing computers—is one function among many.
What’s the difference between an IT department and an IT person? An IT department is a team organized to cover all IT functions. A single IT person, particularly at a small organization, tries to cover those same functions alone. The coverage gaps that result from one person doing the work of a team are real and consequential—they don’t disappear because no one acknowledges them.
When should a business hire an IT person versus use managed services? This depends on the volume and nature of IT work, not just cost. Organizations with consistent operational IT needs—infrastructure, support, security monitoring—often benefit from internal staff who develop institutional knowledge. Organizations with episodic or highly specialized needs often get better outcomes from managed services or advisory relationships that can flex with demand. Many organizations use both.
What does an IT person need to know about the business they support? More than most organizations give them credit for needing. Effective IT work requires understanding the organization’s workflows, risk tolerance, regulatory environment, and strategic direction. An IT person who only understands the technology and not the business context makes worse decisions—not because of technical deficiency, but because they’re missing the information needed to prioritize correctly.
How do you know if your IT person is doing a good job? This is harder than it sounds because good IT work is often invisible. Useful signals: How quickly do issues get resolved? Are the same problems recurring? Are there documented systems and procedures, or does knowledge live only in one person’s head? Is IT proactively flagging risks, or only responding after problems surface? Is the organization experiencing security incidents at a rate that suggests something isn’t working?
A Specific, Actionable Takeaway
If you’re a business leader trying to evaluate whether your IT function is structured correctly, start by mapping the six functions above against who in your organization actually owns each one—not who’s supposed to own it in theory, but who’s realistically doing the work.
You’ll typically find one of three situations: the functions are spread across more people than you realized (which is fine, if they’re coordinated), they’re concentrated in one or two people who are necessarily cutting corners somewhere (which is a risk, not an indictment), or some functions aren’t owned by anyone and are just not getting done (which is the situation worth acting on).
The unmapped gaps—governance no one is doing, documentation that doesn’t exist, security reviews that happen only when something goes wrong—are usually where the organizational exposure is. Finding them is the first step to addressing them.
