Introduction

When you step into an IT service management role at a new product or organization, many people think, “First, I need to understand the system.” But looking only at the system won’t reveal what truly matters.

That’s because incident response and ongoing operations aren’t simply about keeping a system running — they’re about protecting the value the business creates.

Take the same incident: priorities and the way you explain it to stakeholders change entirely depending on whether it hits a revenue-driving feature or only an internal one. And even with a firm grasp of the architecture, you can’t make sound calls during an incident if you don’t know the organization’s decision-making processes or the tacit operational knowledge held on the ground.

That’s why the principle of understand the business and the organization before you understand the system matters so much.

This article lays out the lens through which to assess a situation when you arrive at a new site. It should be especially useful for:

• Those newly responsible for an IT service or product
• Those looking to improve incident response and operations
• IT service managers who’ve just arrived and aren’t sure where to start

By the end, I hope you’ll feel that “understanding the system” isn’t just grasping the system and its configuration — it’s understanding the business, the organization, and the service in three dimensions. You’ll also see why collaboration with stakeholders and a service-oriented view matter so much in incident response.

IT service management can’t be done by staring at the system alone. It’s a role that connects business, organization, and system while continuously protecting service value.

So what should you actually look at? Broadly, three things: business, organization, and system.

1. Business

Customers

Above all: who is the customer? Understand how the IT service is actually used. This makes it far easier to see why the screens are laid out as they are, and why a particular user flow is prioritized.

Usage hours and access patterns reveal the nature of the service, too. A B2B service concentrated in weekday daytime hours behaves nothing like a B2C service with heavy night-and-weekend traffic — and that changes both the blast radius of an incident and the response speed required.

Without this, you can misjudge severity. A technically minor incident may halt a key customer’s operations, while a flood of alerts may carry only limited user impact. Incident response has to be viewed not just from a system angle but from the angle of what is happening to the people using the service. That’s why understanding the customer comes first.

How money is made

Next, understand the monetization points — how the product actually generates revenue.

The critical functions differ between an ad-supported service and one that charges on conversion. In one, a halt in ad display is fatal; in another, an outage of registration or payment is the serious incident. The quality of your judgment in a response depends on whether you understand where an outage creates the biggest business impact.

It also changes how you communicate with other departments. Understand the business model, and it becomes far easier to explain “why we’re prioritizing this now” — and decisions move faster.

Business processes

Understand what business processes exist to make that model work. You don’t need to dive into detailed process analysis right away; what matters is understanding enough to connect which system incident affects which business process. Even a rough grasp of the workflow makes impact investigation easier when something breaks.

Learn site-specific terminology early, too. Response meetings are full of business terms and abbreviations flying back and forth. If you can’t keep up with the vocabulary, you’ll spend all your energy just gathering information and never reach the essential judgments. When an unfamiliar term comes up, confirm it that same day if you can.

Priority themes

Every company and business has priority themes that shift over time — expansion, new product launches, cloud migration, cost reduction, security hardening. What matters here is not just what they’re doing but why. A performance push may be driven by a traffic surge; an automation drive may stem from chronic understaffing. Understanding that background lets you act during an incident with a feel for what the organization values right now.

2. Organization

Your own team and the development structure

Whether development is in-house, SIer-centered, or split across multiple vendors changes how response proceeds in a big way. What you especially want to see is who holds which role — detection, first response, escalation, permanent fixes, release decisions.

Another key point: are development and maintenance teams separated or run as one? An integrated model tends to be faster, but maintenance improvements slip when development gets busy. A separated model makes stable operation easier but raises the cost of passing information across. And as you build this picture, recognize what role you are expected to play.

Product structure

Grasp the planning and product management structure too. How are development items proposed, who sets priorities, who decides? Understand that, and you’ll see how to move fastest when “a problem that’s technically per-spec but causing service impact” needs an urgent fix. Incident response rarely ends as a purely technical matter — it’s tightly bound to organizational decision-making.

User departments

Get a rough grasp of how user departments are structured — by region, product, or industry. During an incident you need to sort out which department is affected, so the org chart is extremely useful.

Supporting functional organizations

Legal, security, risk management, SRE, infrastructure specialists — their scope varies widely by company. Knowing how far you can consult them and when to bring them in means less hesitation in the moment, and makes them easier to lean on.

Key people

Finally, identify the key people. Beyond formal titles, organizations have real information hubs and de facto decision-makers, and in a response their presence is enormous. Where to tread carefully so the ground moves smoothly; what kind of explanation earns buy-in from related organizations and customers — building relationships with people who hold these instincts makes response and improvement work far easier.

3. System

The overall system map

Grasp the system as a whole — but an ideal architecture diagram isn’t always in place. When it isn’t, gather the relevant people around a whiteboard for a “drawing session,” sketching systems and data integrations along the business flow. What’s especially important is connecting which system incident leads to which service impact. You need not a configuration diagram but a service-oriented understanding of the system.

Incident management

Check the process: where it’s detected, who receives it, how severity is judged, how it’s escalated — and how response begins at night or on weekends. It’s common for alerts to fire with no clear owner, for severity criteria to be missing, or for contact rules to live in one person’s head. In that state, the confusion comes less from the incident than from who decides what. So when you look at incident management, emphasize not just the technical mechanism but the communication design.

Operations and maintenance

Finally, the steady state — service desk, monitoring, capacity management, scheduled maintenance. Operations isn’t status-quo maintenance; it’s the work of sustaining the value an IT service creates over the long term. Sites with stable incident response usually have well-organized daily operations; where daily operations are in disarray, incident-time confusion gets amplified.

Conclusion

In terms of order, business and organization come before the system — because the system exists for the sake of the business and the organization.

In most sites, something is already a pain point: too many incidents, too many alerts, maintenance bottlenecked on one person, poor coordination, friction with user departments. So don’t just collect information — vary the order and depth of your assessment while staying conscious of where the problems are right now.

IT service management isn’t simply a role that responds to incidents. It protects service value, connects stakeholders, and keeps the business running. That’s exactly why you have to understand the business and the organization, not just the system.

Arriving somewhere new brings anxiety and pressure. But you don’t have to understand everything at once. First, try to understand the service. Then, working alongside stakeholders, understand the site one step at a time. That accumulation raises the quality of your incident response — and, in turn, protects the service value you deliver to end users.