Helia HR

Guide

A time-off policy for IT companies that people actually understand

Updated 2026-07-23 · For founders and HR running teams across UA · PL · RO · EE

A policy nobody understands is the same as no policy

Every growing IT company hits the same moment: someone asks "how many vacation days do I actually have left?" and the answer requires an HR person, a spreadsheet and ten minutes of archaeology. Multiply by every person, every quarter. Then add the conflicts a vague policy seeds: the December rush when nobody knows whether days expire, two seniors from one project approved for the same week, the engineer who learns at exit that "we'll sort out carryover later" meant "no".

A time-off policy isn't a legal document first. It's an interface. If a person can't answer "how much do I have, who approves it, when does it expire" in ten seconds, the policy has failed — whatever the PDF says.

What the policy must define

Write these down explicitly. Every undefined item becomes a DM to HR — or a precedent set by accident:

  • Vacation quota per year — and whether it lands upfront on January 1 or accrues monthly, plus proration for people who join mid-year.
  • Sick-day rules — separate from vacation (a merged budget makes people work sick to protect their holiday), when documentation is required, plus the other types: unpaid, parental, bereavement.
  • Carryover and expiry — how many unused days move into the new year and when carried days expire. "Use it or lose it" without a written deadline is a morale grenade.
  • Negative balances — can someone borrow against next year's days, how much, and what happens if they leave while negative.
  • Who approves what — by relationship, not just role: the manager for their team, HR for anyone, and never yourself.
  • Public holidays per country — which calendar applies to whom, and the rule that holidays never consume vacation days.
  • How days are counted — working days, not calendar days, and what happens when a public holiday falls inside a request.

Sensible defaults for a 5–50-person IT company

Defaults you can adopt tomorrow and defend later:

  • 20–24 working days of vacation. Competitive in the region's IT market and simple to administer. Where the local statutory minimum is higher, the law wins — a floor is a floor.
  • Sick days separate from vacation, with light documentation for short absences. People who feel punished for being sick come to the standup sick.
  • Carryover capped, with a spring expiry. A small cap (say, five days) expiring in spring balances flexibility against a year-end liability pile-up — and kills the December stampede.
  • Negative balances: small or none. If you allow borrowing, cap it at a few days and write down how it settles when someone leaves — verified against local employment law.
  • Relationship-aware approvals. Managers approve their team; HR approves anyone; nobody approves their own request — a manager's leave goes up the chain or to HR.
  • A fast answer. Decide requests within a couple of working days — a pending request blocks flight bookings, and slow approvals train people to ask in Slack instead.

Keep the whole thing to one page. If the policy doesn't fit on a page, people won't read it — and you're back to DMs.

UA · PL · RO · EE: what actually differs

Teams in this region routinely employ across several countries — employees here, contractors there, sometimes an employer-of-record. The trap is assuming home-country intuitions transfer. They don't. The differences cluster in predictable categories:

  • Statutory minimum vacation — the legal floor differs by country, in places by seniority or category of work. Your policy may exceed the floor anywhere; it may not undercut it for that country's employees.
  • Carryover windows — how long unused statutory days survive into the new year, and by when they must be used or settled, is regulated differently in each country. Your internal expiry must never be stricter than the local rule for statutory days.
  • Payout on termination — how unused days are settled at exit is a legal obligation whose mechanics and math differ by jurisdiction. It's the difference people discover angriest and latest — know it before the first exit, not during.
  • Sick-leave mechanics — who pays which days (employer vs. state), documentation thresholds and caps vary widely. Don't copy one country's sick rules onto a team in another.
  • Public holidays — different lists, different counts, dates that move yearly, and in some countries substitute-day rules when a holiday lands on a weekend.

We're deliberately not quoting statutory numbers: they change, and stale figures are worse than none. Treat this as the checklist to verify with your accountant or local counsel per country — your written policy is the layer on top of those floors.

Approved leave must feed capacity — or your plan lies

In a services company, a time-off policy that ends at "request approved" is half-built. Approved leave is capacity data:

  • Utilization must be net of PTO. Someone on leave for two weeks isn't "80% allocated" — they're unavailable. Counting them as available keeps the utilization number looking healthy while the delivery week quietly has fewer hands than the plan assumes.
  • Coverage is a question for approval time. Two seniors from the same project out the same sprint is sometimes fine and sometimes a client escalation. The approver should see the overlap at the moment of deciding — not discover it at standup.
  • The delivery calendar should already know. Approved leave belongs where staffing decisions happen — in the capacity plan and on the calendar people actually check — without anyone copying dates between tools.

If leave lives in one tool and staffing in another, the link is copy-paste. It's one of the strongest reasons to move HR out of spreadsheets: the record that grants the day off can update the capacity math.

How Helia HR does this

Time off ships in Helia's base pack (see pricing) — it's core, not an add-on:

  • Balances per type — vacation, sick, unpaid and more, with quotas, proration and a live "how much is left" per person. The ten-second answer is a page, not an HR ticket.
  • Carryover policies per type — cap the carried days, set an expiry date or none; year-end rollover runs automatically and every carried day stays traceable.
  • Public-holiday calendars for UA · PL · RO · EE built in — your workspace country selects the calendar, and custom company days can be added on top. Working-day math skips weekends and holidays automatically, so a request spanning a holiday charges the right number of days — nobody counts squares on a wall calendar.
  • Relationship-aware approvals — managers approve their own team (or through explicit delegation), HR approves anyone, and self-approval is blocked by design.
  • Coverage visibility — the approver sees who else on the team is already out for the requested dates, at approval time.
  • A calendar feed (iCal) — approved leave, subscribable from Google Calendar or Outlook. It shows who's out without exposing why: names and dates, never leave types.
  • Capacity that respects leave — utilization math excludes people on approved leave, so the dashboard reports the capacity you actually have.

And HR keeps an escape hatch: manual balance adjustments for the edge cases every real company has — audit-logged, of course.

Time-off balances, approvals queue and per-country public holidays in Helia

FAQ

Working days or calendar days?

Working days, almost always — calendar-day counting silently punishes anyone whose leave spans a weekend or a holiday. Whatever you pick, the system's math must match the written policy, or every request becomes a negotiation.

Can a manager approve their own vacation?

No — self-approval undermines the whole record. A manager's request goes up the chain or to HR like anyone else's. (In Helia the workspace owner is the one pragmatic exception: someone has to be the top of the chain.)

Whose public holidays apply in a distributed team?

As a policy matter, the calendar of each person's employment country — not headquarters'. Write that down explicitly, and verify the employment-vs-contractor nuances per country with your accountant.

Do we need a separate written policy per country?

Usually one policy with per-country annexes beats four documents: shared defaults (quota, approvals, counting rules) in the core, statutory specifics (minimums, carryover windows, termination payout) in a short annex per country — each verified against current local law.

Run HR and delivery ops in one system

Helia HR combines the HR basics with the capacity matrix, bench view, timesheets and client invoicing IT services teams actually run on. Start free, no card. GDPR-grade security, role-gated PII, audit-logged access.