Support buries the team.

How it happens

With customer number one, the developers sit with the user and watch the server logs. A problem is a text message, and the fix ships the same afternoon.

Then someone says "uncle" and support gets its own process. It gets better, because someone owns it, and worse, because the developers are now building for customer number five. Hundreds of tickets wait to be triaged, combed for duplicates, or closed for a fix that shipped weeks ago in another release.

So a support sub-team forms. Then it needs more horsepower, and support tickets start clouding the main team’s sprints. Deadlines slip, the executives stop believing the dates, and support would rather have less broken software than the two new features, which bring their own support load.

“In addition to the development team’s technical debt you also have support debt. And everyone was and is always doing the best they could.”

What it costs

• Time keeping the lights on grows from about 20% of development hours to 65%, in Peter’s experience, and that’s if anyone measures it.
• Missed sprint targets and release dates, and an executive team that stops believing engineering’s estimates.
• Fixed bugs that stay open as tickets, and duplicates nobody has time to merge.

What does keeping the lights on cost your team? Run your numbers →

What the bench does

• V1Watches exceptions, failed and slow requests and silent failures, in the server and the browser.
• V1Triages each problem with the stack, what the user did, and the server log lines of that request.
• V1Files problems as GitHub issues with who was affected, grouping repeats of the same error. A fixed problem that comes back reopens its issue.
• V2Drafts the fix with tests as a pull request, for your team to review and merge.

V1 watches, triages and files the issues. V2 also drafts the fixes and features as pull requests. Compare the editions →