Use Case · Team Resilience
Bus factor and overload risk surfaced early: how agencies stop discovering their single points of failure in a resignation letter.
Monday, 8:52 AM. Before the coffee machine has warmed up, a direct message lands: short, polite, and instantly recognizable to anyone who has ever run a delivery team.
By 9:15, Olivia has opened the repo analytics, and the numbers are clear. Mark wrote 71% of last year’s commits on the payments core. He is the only maintainer of the deployment pipeline. Three active contracts depend on modules only he knows well. If Mark leaves, that knowledge leaves with him.
This was not a decision anyone made. Mark was the best at hard work, so it kept going to him. Pairing another engineer with him stayed on the plan but never happened. Now the team has four weeks to move two years of his knowledge to someone else.
Key-person risk and overload are the same pattern seen at two depths. The critical work concentrates on the strongest person because that is the easy choice in every single sprint, and the same concentration that makes them indispensable is what wears them down. Both build silently, and both get discovered at the worst possible moment.
Read correctly, they describe how work is distributed, not how any individual performs.
Critical modules drift toward whoever handles them best, one reasonable handoff at a time. Nobody ever decides that a single person should own the payments core, yet a year later that is exactly where the agency stands: its most valuable code has one safe pair of hands, and no backup.
The most loaded engineer is usually the most productive one, right up until they are not. The late-night commits and skipped breaks that precede burnout look like dedication on every dashboard the team has, so the warning signs read as good news until the resignation makes them obvious.
The dependency stays invisible until the person is on their way out: a notice period, a sudden sick leave, a long-booked vacation. Only then does the team see how much rested on one pair of hands, and by then the calendar sets the terms, turning fixes that were routine in Q1 into a crisis squeezed into the weeks that are left.
The Hidden Cost of Manual Reporting
Early
Bus-factor and overload patterns can surface well before a resignation, while mitigation is still routine
Tolmete customer baseline4-6 wk
Typical recovery time when a key engineer leaves mid-project unmitigated
Tolmete customer baseline1
Typical bus factor on the most critical module of an agency codebase
Tolmete customer baselineHow Tolmete Approaches This
Ownership concentration and sustained overload leave traces months ahead: commit distribution narrowing onto one person, reviews flowing through a single gate, after-hours activity turning from exception into pattern. The team cannot see it because they are inside it. Tolmete surfaces it from the already-connected delivery evidence, on the same read-only stream.
Two signals cover the pattern at both depths. Bus Factor maps who can maintain each critical module and flags when the map collapses to a single name. Overload Risk looks for sustained-pressure patterns in the work rhythm and can surface them early, before they affect output, quality, or the person carrying the load.
Here is what this signal is not: a productivity score. It never ranks people and never feeds into a performance review. The overload pattern is framed as load to redistribute, not as a mark against the person carrying it. The evidence points to the structure that overloaded one engineer, because it is what management can actually fix.
Tolmete does not add a new process for the team. It reads the delivery evidence the agency already produces and turns it into a plan the manager can act on before the risk becomes a crisis.
Tolmete works from commits, reviews, tickets, and work rhythm in the tools already connected, with the historical record scanned at onboarding, so the ownership map exists on day one.
Input: commits, reviews, tickets, time patterns · Read-only access
For every module the client projects depend on, Tolmete determines who could realistically maintain it tomorrow and flags where the answer has narrowed to a single name.
Output: bus-factor map, weighted by project dependency · Context-checked
Spikes are normal; trends are the signal. Tolmete tells a crunch week apart from a six-week pattern of after-hours work and shrinking rest, and the Clarification Loop checks context before anything surfaces.
Surfaces on: sustained patterns, not single weeks
Pairing rotations, load balancing, documentation targets: named actions with owners and timelines, delivered while there is still runway, when fixing the structure costs two sprints instead of two quarters.
Output: Briefing + Owner + Timeline · While mitigation is still routine
How Tolmete Approaches This
Rewind 70 days. The Bus Factor signal surfaces in March, and Olivia’s response is unglamorous: Bob pairs into the payments core, the reporting module moves off Mark’s plate, and the deployment pipeline finally gets written down. Nobody calls it a crisis, because it is not one. It is two sprints of routine work.
Mark’s offer still arrives in June. People leave, and that’s never a variable anyone can control. What is different is everything around the departure.
No stalled projects, no emergency consultant, no client ever finding out. And there is a version of this story where the June offer never lands at all, because the overload signal in March was the reason the after-hours pattern stopped, and the reason Mark was not job-hunting by May.
A bus factor of one is not a strength to celebrate; it is a debt the project has not paid down yet.
The old way
The dependency took two years to build and left four weeks to undo.
The automated way
People still leave. Crises do not have to.
For agency leaders, the bus-factor map turns a vague anxiety, “how exposed are we, really?”, into a portfolio view: which client commitments rest on a single person, and where two sprints of pairing buys real insurance. It changes hiring and staffing conversations too, because “we need redundancy on payments” finally comes with evidence instead of instinct.
For the team, the overload signal is the part that builds trust, if it is used right. It exists to take load off people, not to measure them. The engineer carrying too much usually knows it and says nothing, because raising your hand feels like weakness. When the system flags the structure instead, asking for help no longer feels like a confession.
Portfolio margin visibility before risk reaches the client.
A live burn picture instead of a month-old spreadsheet.
Clear change requests mid-project, without an end-of-project standoff.
Tolmete is designed to fit the tools your team already uses. The ownership history is already in your repos and trackers, so Tolmete scans it at onboarding, read-only, and the resilience picture appears before the first new commit.
Signals point at structure, not people: never a productivity score, never a leaderboard.
Connect
Jira, GitHub, Slack · ~3 min per tool
Ownership Scan
12+ months of contribution history
Resilience Watch
Bus factor and overload, continuous
No tool prevents resignations, and none should try. What is preventable is the version where one departure stalls three projects, burns a quarter, and reaches the client, because the dependency was visible in the data for months and nobody was looking. Make the concentration visible at day −70, and a resignation goes back to being what it should be: a career event for one person, not a delivery event for the whole agency.
Map the dependency. Rebalance the load. Let departures be handovers.
Self-Serve
Connect Jira and GitHub, tuned to your projects within days.
No credit card, no demo call required.
Talk to Us
For teams 25+ or with enterprise needs: dedicated SLA, SSO, custom integrations, and onboarding support.
Tolmete helps IT service agencies connect project activity, approved time, scope movement, and billing context, so teams can protect the margin they have already earned.
