部下が期待を上回る時は, 部下が凄いのか, 自分の指示がタコだったのか

私には, (部下ではありませんが)私が指示を出す同僚がいます. 彼はニコニコ動画とアニメが好きな修士課程の 1年生です. 先日は着てるウィンブレを褒めたら, どうもエウレカセブンっていうアニメのキャラが着てたものと同じ意匠らしい. 変な所に凝っている. しかし何より, ひょうひょうとしています. ひょうひょうとしてるNE! って言うと, そうっすか. と言ってその会話は終わり, 口笛を ひゅる〜っと吹き出す. そして津軽三味線の大会に出てよく賞をとって帰ってくる.
本題. 昨日私は彼に, とある論文を読んでその文中で説明されてるモジュールが私達の想定用途に合うかどうか調べて下さい, とお願いしました. 私が求めた回答は yes or no のみでした. そして, (論文が最も力点を置いて説明している点である)このモジュールの動作原理等の説明は要らない, と. 私達の仕事に必要なのはそのモジュールが提供している機能を私達が使えるのかどうか であって, そのモジュールがどう作られててどう動くか, では無いと私は考えたからです. 論文を読みこなすことは有意義なことだけど, しっかり読むのは時間がかかる. それは情報収集あるいは勉強として実施すべきことであって仕事ではない. 週間11時間と決まっている彼の労働時間を効率的に使って欲しいので私は何度も"必要箇所のみ読んで下さい"と念押しした.
しかし翌日の会議で彼は, 私が求めた回答として no を答えた上, アルゴリズムの説明をしてきた. "やっぱりしっかり論文読んじゃったか..."と私は内心思ったのですが, なんとそのアルゴリズムは私達の仕事に有益かも知れないので実装して試用しよう, という結論が出た.
チームとして喜ばしい結果が出た反面, 私個人は反省しました. びっくりしたよ.
クイックな判断をしようとするあまり, 起承転結の起と結しか見ない癖が付いている. それが悪いことだとは正直今でも思わない. そうしないと仕事で入ってくる多量の情報はさばき切れないと思う. でも, 今回のケースでは承と転に使えるアイディアが含まれていた. もし起と結だけ見て終わっていたら, "うーんこのモジュールも使えないか...他に良いモジュールあるかなあ...探さなきゃ"とまた一からやり直しになっていた.
この問題, どうしたら良いのか答えが出ない.