Wednesday, April 23, 2014

Tools for the Distributed Team: ETGB Queue

Teamwork is a difficult problem to solve. And I'm not talking about conflicting personalities or whatever; just the bare practicalities of it. For instance, interrupting each other, or not. Waiting on somebody who's forgot to get back to you.

It's very much like multithreading: interrupt(ion)s and context switches often incur a non-trivial cost.

So I often end up thinking about how better adapted tools could help. Imagining tools carefully designed for cooperatively multitasking humans, or perhaps better, 'mostly cooperatively', the nodes are humans, that we're imagining kind of realistically.

And I am thinking about so-called distributed teams.

So, one problem out of many: you've send a question about work ongoing via Skype chat. No reply. You wait. Should you prod your peer again? In 15 minutes? It's hard to miss notifications in Skype, so it's probably not that the message wasn't seen. The coworker might simply be swamped in things to do.

So, that's a common scenario; now how could tools help here? And/or changed practices.

How about ACK support? "I hear you, sorry, later. "

Plus an ETA, or let's make an acronym: Estimated Time When I Can Get Back To You. ETWICGBTY. Estimated time of getting back to you. ETGB?

The awaitee end will of course often get multiple requests. That'd be a Queue; and the tool would of course update the ETGBs for everyone. Requestors should probably only be allowed one spot in the queue each. They should probably only ask for the most important or pressing thing to be done.

The poor overworked awaitee might feel stressed by seeing a row of ETGB promises, but I think that'd be at least one better than getting Skype-pinged every half hour.

No comments:

Post a Comment