There is a phrase that we use to describe a particular phenomenon of work and that is “dev-t” or “developed traffic.”
Develop = to make or to create or to promote the growth of.
Traffic = work or communications or transportation of items or messages.
Developed traffic (dev-t) is not your usual and necessary work. Dev-t is “unusual and unnecessary work” or “created unnecessary work.”
Though it may seem unreal to you, it has been observed that up to 66% of the work a company does is dev-t. It seemed unreal to me until I started looking for it and I found it everywhere in the world. We are pretty efficient here and still at least 20% of the work we do every day is dev-t. Much of what we do in life is dev-t as well. Dev-t is a waste of everyone’s time, and prevents us from having time to do the really important actions that lead to more sales and more success. That is why it is VERY important that you learn what dev-t is and how to prevent it.
It is part of your job to eliminate dev-t.
Anytime you have to go back to someone for more information, it is dev-t. Anytime you receive something that is not complete: an invoice, a note, an e-mail, a request, a piece of merchandise that appears on your desk with no note, it is dev-t.
If someone takes something and doesn’t return it, or puts something in the wrong place, or leaves something on your desk, that causes unneeded work and it is dev-t.
A very common form of dev-t is interruptions. We call it “bringing a body” when you walk over to someone’s desk to ask or tell something that could have been communicated in an email. If a question can be answered by an e-mail but the person interrupts you instead, then it is dev-t. It is dev-t even if the question is part of your job. If a note or e-mail will handle it, then use the e-mail and don’t interrupt someone else’s work. ANYTHING that slows down or interrupts our work is dev-t.
Especially don’t burden your busy supervisor with unnecessary “traffic.” If it is important to immediate production, then tell them verbally. If not, e-mail.
Similarly don’t stop people as they walk by your desk to ask a question if it can be asked and answered in email. Even though they are “just walking” it’s still an interruption, and it’s a broadcast.
If you have some piece of news (good or bad) that needs to go to only one person, yet you “announce” it across the room, then six people will hear you. This stops them all and they all have to comment here and there and work is not getting done. Direct your communications to the one(s) who need to know, not the whole room. Again, using e-mail or notes lessens this type of dev-t. Very good news that will cheer up the group and raise morale (like a big sale) would be an exception to this rule.
When you involve more people than are necessary in any task, such as looking for something or even trying to get something done, it’s inefficient. Always ensure that the fewest people possible are involved in any one task. If you end up assigning or turning over the task to someone else, go back to what you were doing rather than continue to tag along.
Although all of our employees are very helpful, taking time away from multiple people slows down efficiency. Also be sure that everyone who was involved in the task is notified when the task is completed; for example, when the person finds the thing that was being looked for, and doesn’t tell the others still looking for it.
Similarly, do not involve yourself in what someone else is doing if your help wasn’t asked for, unless you actually have the answer or solution to the situation. Don’t be a buttinski!
Someone stops you to tell you that a watch company is raising prices in a month. They should have e-mailed you because you don’t need to know that at this very moment. A few hours later would have been fine.
When you start something but don’t finish it, you end up doing it twice. You start again but don’t finish. Example: preparing to call a problem customer, but delaying and then having to redo the preparation wastes time and may cause further loss of materials or information.
Keep things in their natural and logical sequence. Do things in the order that they should be done. Don’t try to do B first if B can’t happen without A being in place.
Leaving someone in charge of an area when they are not properly trained causes dev-t, because they have to run around interrupting people and asking how to do things. Incomplete, incorrect or no training causes dev-t every time.
Only copy those who really need to know. Sending anything by email to someone who didn’t need to know it is dev-t. Employees who copy their supervisors on everything will only bring down the efficiency of that supervisor and their group.
If you get an email sent to ALL and have a comment that does not need to be read by ALL, then just reply to the person who sent it. Don’t automatically Reply to All.
And lastly, but very common dev-t is interrupting someone to ask verbally, “Hey, did you get my e-mail?”
Work: Being asked to do work that is part of your job is not dev-t.
Information needed to do the job at hand: If you need information right now to finish what you’re doing, get it in person; if it could have waited for an email, then it would have been dev-t.
Salespeople asking for help: A salesperson interrupting you to ask you to gift-wrap, invoice, or otherwise help with a sale is not dev-t.
Customers: A customer calling or coming in the store is never dev-t.
Orders from your Supervisor: Instructions necessary for production are not dev-t, though non-essential information could be handled by email. Example: urgent production-impacting news should be given verbally.
Meetings to discuss issues or plans: When complex discussion requires more than one person, a meeting is appropriate and not dev-t.
ANYTIME you get work that is dev-t, you must write what happened and email it to his or her supervisor and copy HR. The supervisor will help the person who caused the dev-t learn to avoid causing dev-t to others. If it is a supervisor who is causing the dev-t, then email Leo so he can get it corrected. HR will save the report in the employee files for future reference.
If you don’t report it, you become part of the dev-t and can be written up. By NOT reporting dev-t, you allow that person to continue wasting everyone’s time. By writing it up you encourage them to stop. Reporting dev-t helps correct behavior and improves overall efficiency.
If the same type of dev-t continues after you’ve reported it to the person’s supervisor, then report that to HR.
The elimination of dev-t is important because it is pure waste; we need efficiency and completed cycles of action.