Microspeak: DRI, the designated response individual


Someone sent a message to a peer-to-peer discussion group and remarked, "This is critical. I'm a DRI at the moment and have some issues to fix."

The term DRI was new to many people on the mailing list (including me), and while others on the mailing list helped to solve the person's problem, I also learned that DRI stands for designated response individual or designated responsible individual, depending on whom you ask. This is the person who is responsible for monitoring and replying to email messages sent to a hot issues mailing list. For online services, it's the person responsible for dealing with live site issues.

From what I can gather, teams that use this model rotate the job of being the DRI through the members of the team, so that each person on the schedule serves as DRI for a set period of time (typically a day or a week). The DRI may also be responsible for running various tools at specific times. Each team sets its own rules.

Other teams have come up with their own name for this job. Another term I've seen is Point Dev. On our team, we call it the Developer of the Day.

Bonus chatter: I bought this hat back in the day when the stitching was done by hand on a specially-designed sewing machine. Nowadays, it's computerized.

Comments (7)
  1. mc says:

    We call it  "on mailbox duty", shortened to "on mailbox"  obviously that means the designated person for the week, monitors the team mailbox for issues and solves / responds to them.   Generally that person gets very little other work done that week.  Sometimes after large upgrades more than one person will be assigned to cope with the volume of complaints / issues.    

    Our users (sorry, I mean Business Partners) love it because they get good support in a timely fashion,  our managers don't like it but have so far lost the arguments about abolishing the practice and sending everything through the organisation's helpdesk ticket system.

  2. Torkell says:

    That sounds a bit like a system at where I used to work, where some of the engineers would be designated "on support" – generally being on support lasted 3 weeks, and it was rotated through the entire team with 2 or 3 engineers on support. This didn't mean you were on the helpdesk, but rather that the actual customer support team would phone you up if they got stuck. If it was all quiet with customers then you often ended up doing maintenance releases or fixing reported bugs, but if something had gone pear-shaped then you might end up in the support offices SSH'd in to a customer site trying to work out why some piece of software was refusing to behave.

  3. David says:

    I think for some Google projects it's a 'sheriff': http://www.chromium.org/…/tree-sheriffs

  4. JM says:

    …wait, *rotating* the position? Huh. That's a novel idea. I might propose that at my work. It might give me, I don't know, more time to do other stuff. :-)

  5. cheong00 says:

    In one of my previous companies, we once had 2 support staffs rotate duty similar to this role.

    Whoever is on duty have to come to company office early and remote monitoring each stock trading servers to make sure they're up and running before the market is open.

    The practice didn't last long though… The staffs were not paid OT for it, and the company didn't gain more money for it. The practice slowing fade away.

  6. Francis Gagné says:

    In our team, a support round lasts from 3 to 5 *months* (we used to rotate weekly; we changed in 2011). There are a few reasons for this:

    – Some issues take a while to resolve (usually due to us waiting for more information), so having the same person on support for the whole time means that he's aware of all the details.

    – Some issues are more difficult to resolve (especially when you're new on the team!). When you rotate weekly, you might be tempted to let the issue sit there for the next guy to pick up.

    – It makes scheduling of long projects easier: you don't have to account for developers being on support duty once in a while. Also, it reduces the frequency of context-switching for developers.

    The server subteam has 3 (originally 4) developers and the client subteam has one developer on support duty, and we rotate at around the same time.

  7. RonO says:

    When I first started in the industry, the term was "on call" or "on call SE" (System Engineer) and it was a weekly rotating position (typically Monday AM to Monday AM) within each department/account. However, this was typically for after hours support only as issues during the day were handled by the sub-system SE(s). The size of a rotation group typically being 5-20 SEs. For the first few cycles of new SEs they were typically paired with a senior SE.

    On my last account with that company, I eventually became a senior level SE to such a degree I was never on call, but I was always the "last resort". And when that happened, I was often called because the SEs didn't want to do anything without checking up-the-chain. Most weeks it was 2-3 early morning calls (1-3AM). :(

Comments are closed.

Skip to main content