Sprint planning Monday. The team commits to two weeks of work. Halfway through the meeting somebody mentions that two backend engineers are out next week. Nobody had checked, because the source of truth was a Google calendar that does not show approved leave by team. The scope gets cut, but it should have been scoped lower from the start. The same thing happens every six to eight weeks at most tech companies.
BreezeLeave fixes the visibility part. The team calendar, the workload view, and the daily Slack digest are the three screens an engineering lead actually opens. The leave product line covers the request flow, balances, approvals, and reports. For tech companies that also run client delivery work, the Project Operations module adds capacity planning, project budgets, and ClickUp time; engineering-only orgs usually only need leave.
The work patterns an engineering team brings
Sprint cycles, not weekly capacity
Engineering does not plan in weeks; it plans in sprints. A two-week sprint where one engineer is out for three days is a different capacity number than a sprint where the same engineer is fully in. The workload view aggregates planned engineering days per sprint and subtracts approved leave and public holidays. The sprint lead opens it before scoping, not after.
On-call rotation that nobody wants to overlap with PTO
If an SRE is on-call this week and books a vacation that starts in the middle of it, somebody has to swap. The cleanest version: the engineer sees the conflict when they submit the request, picks a swap target, and the approver gets both the leave request and the on-call swap in one message. BreezeLeave shows the on-call shift on the engineer's calendar and warns on overlap. The shift itself can stay in PagerDuty, Opsgenie, or whatever rotation tool the team already uses; the leave product just needs the dates.
Release windows and blackout dates
The week of a major release is not a great week for the entire platform team to be out. Most engineering orgs have an informal freeze, which inevitably means somebody books that week off without realizing. Set the release window as a blackout in BreezeLeave and requests inside it get held for manual review with the freeze reason shown. The platform team and product engineering can have different blackouts on the same calendar.
Slack-native approval, not Slack notification
The difference matters. A tool that pings the approver in Slack but routes them to a web form to actually approve adds friction that is enough to make the approver wait. BreezeLeave keeps the approval button in the Slack message. The engineer's response, the manager's decision, the team digest all happen inside the channel. The web dashboard is mostly for the engineering lead pulling per-team reports.
A Friday production incident, with proper visibility
Picture a Friday afternoon incident. The only engineer who knows the affected service is on PTO that started Thursday. With proper visibility the incident commander knows this in five seconds, not after twenty minutes of Slack searching. The team calendar shows the engineer is out. The cover person field on the leave request shows who is the backup. The Slack daily digest from Thursday morning already named the leave; the on-call rotation channel already flagged it.
A common pattern in engineering orgs: this scenario plays out once, the team switches to a real leave tracker the following week. The motivation is usually an incident, rarely a planning meeting.
Distributed engineers and time zones
An engineering team that spans Berlin, New York, and Lisbon does not share a single calendar. The German engineer is off for Tag der Deutschen Einheit on a date the New York team is fully in. The US engineers are off for Independence Day on a date the European team is still building. BreezeLeave attaches each engineer to a country with the right public-holiday calendar, then rolls availability up at the team level so the sprint lead sees the combined picture in one screen.
The same logic helps with on-call coverage. A rotation that follows the sun relies on knowing which engineer in which time zone is available. The team calendar shows the absence with the originating country, so a US-based incident commander on a Saturday call does not assume the European engineer is reachable.
Per-team policy, because platform is not product
Engineering teams inside the same company often need different rules. Three common patterns:
- The platform and SRE teams need a higher minimum coverage threshold during business hours.
- The mobile team wants a blackout around app store submission week.
- Product engineering allows two-week PTO blocks during the quiet weeks of the quarter and disallows them in the launch month.
BreezeLeave runs per-team policies for entitlement, accrual, approval chain, conflict threshold, and blackouts. The engineering lead can set them once and adjust per quarter.
Tech work pattern matched to product
Sprint planning with two engineers on PTO
Workload view, planned days minus approved leave per sprint
On-call shift overlapping vacation
Conflict warning on the request, visible to approver
Release window with no PTO allowed
Per-team blackout dates, manual review on conflicts
Friday production incident, owner unreachable
Cover person field, team calendar, daily Slack digest
Engineers in three time zones
Per-country public holiday calendars
Engineering lead pulling utilization
Reports export by team, by quarter, by type
Founder still approving every request
Auto-approval for low-risk requests, human review on the rest
Frequently asked questions
Everything you might want to know before getting started. Still have questions? Reach out anytime.
Yes. You can set blackout dates per team for release windows or freeze periods. Leave requests inside the blackout get held for manual review with the reason shown to the requester. Outside the window the same team falls back to standard auto-approval.
On-call is a separate calendar overlay. BreezeLeave can warn the engineer when they request leave that overlaps an on-call shift, and the manager sees the conflict in the approval flow. The on-call schedule itself can be imported or kept in your existing rotation tool.
Yes. The engineer submits the request from Slack with a slash command. The approver gets a Slack message with approve and decline buttons. The decision posts back to the requester and to the team channel. The web dashboard is the same data, used mostly for reports.
Yes. Each team can have its own PTO entitlement, accrual schedule, approval chain, conflict threshold, and blackout dates. The platform team and the SRE team often want different rules than product engineering, and that is supported.
The workload view shows planned engineering days per person for the sprint window, minus approved leave, minus public holidays. The sprint lead can scope work against actual capacity rather than guessing from the calendar.
Yes. Each engineer is attached to a country with the correct public holiday calendar. A team split across Berlin, New York, and Lisbon sees the right holidays for each location, and the workload view rolls up across all of them.
Setup for an engineering org
- Create the account and connect Slack first. The flow is built around Slack-native approvals.
- Define teams: platform, SRE, product engineering, mobile, data. Each team is its own policy unit.
- Import the engineer roster from Slack or via CSV. Assign each engineer to their team and country.
- Load the public-holiday calendar for each country.
- Set blackout dates per team for known release or freeze windows.
- Turn on conflict checking with a minimum coverage threshold per team.
- Enable auto-approval for single-day requests outside the blackout windows.
The first week is for getting the request flow into Slack. The second week is for setting blackouts around the next release. The first sprint after that runs with capacity numbers that everyone trusts.
Where to read next
- Capacity planning for engineering teams: how the workload view treats sprints and approved leave.
- Sprint planning around PTO: the operational pattern for scoping a sprint when engineers are on leave.
- All industries: how BreezeLeave runs for agencies, consulting firms, startups, nonprofits, and law firms.
- Pricing: free for teams up to 10 engineers, Pro at $2 per person per month above that.
For most engineering teams the leave module is enough. Tech companies that also bill client delivery work usually layer Project Operations on top once the leave side has a quarter of clean data.