Once more, I find myself in the post-alpha run to the finish line. And once again, I find myself getting busier and busier as the completion date looms.
One of the most challenging issues at this time is managing the stream of traffic to your desk. Other people are very busy too. People have questions. People need answers. And answering those questions takes time away from handling your own workload, allowing it to multiply like bacteria. I find programmers tend to employ several archetypal techniques to handle those interruptions:
1. Just help them. Indulge them. Offer them as much help as you can. Get their problem fixed, as it helps the team move forward. Really, this is the ideal strategy for the whole project. Someone has come to you with a problem, they may be at their wits end, you should help them fix it.
The problem is that it's a win-win-lose proposition. It's a win for the individual, it's a win for the team, but it's a lose for you.
2. Say you don't know. Strangely, this is a rare tactic. People often feel it's preferable to have a stab, and speculate as to the cause or the solution, even without any useful knowledge or data. Email is rife with this kind of thing. This isn't actually useful. The individual with the problem is likely to have conducted much the same process and reached similar conclusions. It's nice that you're trying, but this just consumes time and doesn't advance a solution. Better to say you don't know, and refer them to someone else who may be able to help.
3. Pretend you don't know. You may know the answer, but since fully helping is a time sink for you, you may judge it more profitable to deny all knowledge and continue work.
Until someone rats you out.
Not a great plan. Not professional. Instead, it's better to admit knowledge where you have it, but if you have a more pressing matter, explain yourself and offer help when you're done. If it's urgent, they can find help elsewhere, if not they can wait. Chances are they'll solve it anyway in the meantime, increasing their own knowledge and learning.
4. Measured help. Give them just enough help to get them moving forward again, but stop short of full disclosure. The advantages to this technique are that you're offering help, the individual is employing their own initiative and learning and everyone gets to move forward. The downside is that they may return to your desk a further 38 times before the problem is solved.
5. Be brusque. Make people not want to ask. This is a win for you, in the short term, but a lose for the team and a lose for yourself in the long term as people will not offer help in return. It can be difficult to resist this strategy when you're stressed!
6. Refer them to a subordinate. The joys of seniority! Pass the problem down the line to the next guy. It's a win for you, but it has mixed results. It may result in a win for the delegate, as they learn something and increase their standing within the team. It may be a win for the individual. It's a win for you, as it frees your time up. The problem is if the delegate cannot solve that problem. The delegate burns a lot of time, the individual with the problem loses time, and ultimately you end up having to help out anyway. Choose carefully.
7. Dazzle them with science. This is a strange one. When faced with a non-technical user, they blaze them with incredible technical knowledge and prowess. A scintillating analysis, definition and solution to the problem is offered; the individual looks back, blankly. No solution is made. The individual retreats, and contacts your line manager to request that you implement the solution instead. You clearly know what you're talking about.
8. Debate them on it. One for the orators. Any problem can be negated with a gallant argument, excellent critical analysis and undeniable logic. Your inquirer retreats, defeated. No more problem you think! No. Instead, the inquirer learns to cut you out of the loop, and ratify and implement a solution elsewhere, elsehow.
9. Blame the build server / Visual Studio / Perforce / Whatever. Clearly the programmer doesn't honestly believe this is the case. It's just a play to buy some time, or to momentarily offload the stress.
10. Counter-problem! You come to me with a problem? You're gonna leave with a bigger one! Thats the Chicago way.
Ask them if they tried to rebuild the resource cache. Bam! 3 hours gained... (and in some cases it might actually help)
ReplyDeleteAnother approach I've seen and used is what I'd call "Office Hours." I don't mean literally posting hours and keeping the door shut otherwise - but rather having a bit of a informal schedule for being most receptive to questions that can interrupt your own tasks.
ReplyDeleteFor example, it seems to me the majority of the questions-that-get-asked-before-doing-proper-research seem to come up most often (a) first thing in the morning before people are "ready" to dive fully into the day, and (b) shortly after lunch when people aren't quite ready to re-dive into the work load. By contrast, a question asked later in the evening usually is a good one - or else the person won't still be in the office working on it :)
I usually use the first fraction of the day to sort through my own e-mail and schedule for the day, so if I'm asked a question then, I'll ask people to come back later when I'm through with those tasks. I like this approach since it's both truthful and usually leads to a more productive conversation later (usually because later we're both more engaged in the project by then). As for the post-lunch "hotspot" - I take a late lunch. This gives me more productive time to myself while most others are eating and blocks me out as busy during the normal post-lunch lull. This one is a bit more selfish, but is a polite way of allocating a bit more uninterrupted time for one's own tasks. Working from home once a week certainly can also really boost personal productivity on those heads-down tasks you don't want to be interrupted on. Other times are usually fair game.
Long story short though, the best policy is just being truthful. Tell people when you're busy and when you have time. Usually works out fine.
Interesting post, though. Thanks!
...oh and one more: headphones plugged into thin air is another good technique to block out time as busy :)
You can understand developing process and implement it on current application to get proper direction.
ReplyDelete