ITIL without the bureaucracy: service management for a ten-person IT team

ITIL has an image problem in small and mid-size IT departments. Managers picture binders of process documentation, change advisory boards that meet weekly, and a bureaucracy designed for banks with thousand-person IT divisions. So they skip “all that process,” and the team runs on heroics — everything urgent, nothing measured, knowledge in people's heads, and every outage a surprise.

Having run IT departments from a handful of people to enterprise scale, my conviction is that ITIL's value for a lean team lies in exactly five disciplines. Adopt them properly, ignore the rest, and you get most of the benefit at a fraction of the ceremony.

1. One front door for every request

The corridor request, the WhatsApp message to a technician, the call to whoever answered last time — each is a small theft from the team's capacity, because unrecorded work cannot be prioritized, assigned or measured. The rule is absolute: everything enters through the ticketing system, even if a technician logs it on the user's behalf. This is less a tooling decision than a management stance, and it takes about three months of gentle consistency (“of course — I've logged it, you'll get updates by email”) before the organization accepts it. Every discipline below depends on this one.

2. Separate the fix from the cure

ITIL's most useful distinction is incident versus problem. The incident is restoring the user's service now; the problem is the underlying cause that keeps generating incidents. A lean team cannot investigate everything, and doesn't need to: a monthly hour reviewing the ticket data for the top recurring issues, picking two, and assigning root-cause actions will visibly bend the ticket curve within a quarter. Teams that skip this stay busy forever — fixing the same printer, the same sync failure, the same access request, in perpetuity.

3. Make change boring

Ask where your last three self-inflicted outages came from, and the answer is almost always an unmanaged change — the quick firewall rule, the patch applied at noon, the “small” ERP configuration edit. Change management for a lean team is one form and one rule. The form: what is changing, why, when, the rollback plan, and who approved it. The rule: production changes happen in an agreed window, never on Thursday afternoon before the weekend. Pre-approve genuinely routine changes as “standard” so the process stays light. The point is not paperwork; it is that someone thought about rollback before, not after.

4. Write down what only Ahmed knows

Every small team has its Ahmed — the one person who knows the backup schedule, the ERP job sequence, the story behind VLAN 40. That knowledge is a single point of failure with an annual-leave problem. The lean version of knowledge management: every problem investigation and every non-trivial ticket resolution ends with ten minutes of documentation in a shared knowledge base, and new joiners are pointed there first. Measure it simply — tickets resolved by article vs. escalated to the senior engineer.

5. Publish three numbers

Service levels for a lean team are not a 30-page SLA. Pick three numbers, publish them to management monthly, and let them drive the improvement conversation: system availability for the two or three services the business actually depends on; ticket resolution within target by priority; and the recurring-incident count from discipline #2. The day IT reports its own numbers before anyone asks is the day the department's credibility changes.

Introducing the disciplines without a revolt

Sequence matters. Start with the single front door and nothing else, because it generates the data that justifies everything after. After two or three months of tickets, the recurring-problem review practically writes itself — the top ten list is sitting in the queue statistics. Change management comes third, introduced after (ideally, immediately after) a self-inflicted outage, when the case argues itself. Knowledge and the three published numbers follow once the rhythm is stable. Attempting all five disciplines in one announcement produces a month of enthusiasm and a quiet reversion; layering them over two or three quarters produces habits.

And resist the tooling trap. Every discipline here runs adequately on a modest ticketing system and shared documents. Teams that begin by evaluating platforms for six months have chosen the most comfortable possible way to change nothing. The tool can always be upgraded later — imported into whatever the process has already made routine.

This is ITIL reduced to its load-bearing walls. A ten-person team that holds these five disciplines will outperform a fifty-person team that has certified everyone and institutionalized nothing.