How leader should answer a (technical) question

Posted on December 03, 2012 · 1 min read · tagged with: #leading #team

Being a leader of a team means questions. Sometimes too many to answer. Questions means interruptions in your work, hence one can think about minimizing the time spent on answering. You can think of an easy solution: lets put a time limit, which exhausted one day, disallows any further questions. Yep it will limit the time spent on answering but will it help your team as a whole? So many unanswered questions which should have been answered yesterday… It’s wrong. One can come up with an idea of limiting answer time, for instance you have no more than 5 minutes for a chat about your question. What if the meeting is ended just before the enlightenment moment? It’s wrong. My preferred way of answering one’s question is t o bring even-more-than-needed insight, to not simply answer how to do it, but why it should be done this way. It’s profitable to spend even ten minutes more allowing one to think about reasoning and follow the same path. After all, when the general knowledge about the ‘how-to’ solve the problem is passed, you will have two people in your team why can answer the same question in the future. It’s a lot of better to say ‘he knows how it works and can give you some information. You can analyze this together’ than ‘this was done before. Ask this copier-of-ideas, he will show you how to paste a snippet of code’. This will reduce the chance of you being the bottleneck in your team and increase chances of self-organization.