As one of our teams was restructured completely (6 our of 8 new people in the last two months) and their knowledge base is now very weak, I notice constant daily interruptions from them. We share the office space and since most of the knowledge on their project is held by one of my team members, they always pop-over with questions.

We did a technical presentation for their team and planned one task battery-type, so we can offer some support during the sprint. We also suggested to them to build a knowledge database with the info they gather, but lately the questions keep on coming even after talking to them.

I can't just forbid people to talk, also since they like to be very helpful. How would you handle this?

  • 3
    How about having your team member assigned to that team as team leader for a transition period until the team matures enough to replace him (to return him to your team)? Commented Sep 6, 2012 at 12:30
  • How long have they been on the project? Did the presentation to them cover very deep technical details? How long had the previous team been working on the project to gain the technical depth that they had? What do you think is a reasonable expectation for how long it will take these guys to get past the initial newbie phase that they seem to be in?
    – Kent
    Commented Sep 6, 2012 at 15:52
  • There was a high level presentation to give an overview of the project, also a handover from the last team member that left and afterwards another very low level and detailed presentation from my senior developer. Unfortunately the new people are quite junior, not just new in the company, so i expect this situation to last a while given that the pool of knowledge and skills cannot be found anywhere else in the company.
    – elena
    Commented Sep 6, 2012 at 16:19

8 Answers 8


First, notice that you are taking ownership of a problem that is not entirely yours. The PM PM in charge of the project should be asking this question. Also note that you are specially punished because you share office space with the team, while other former team members don't have this issue.

This is important to keep in mind because you must involve the PM2 in your solution and he should lead any kind of agreement that you decide together and any effort from your side you should split it with the rest of the team also if too big for your project to absorb it, and even if it is not because I am sure your senior is not the best developer to solve all the questions he is being addressed (the project must be big enough with 8 developers so that he doesn't master all the code). You may require then to escalate the issue to your management so that they support and track progress of your transfer initiatives.

Next point is to have an RCA, root cause analysis, of the questions so that you see the kind of doubts that still remain and even who the questions come from. You may discover that the training required is not only related to the project domain but to the technologies used, specially if as you say the new members are quite junior. Maybe the questions where addressed in the technical sessions and trainings that you had, then: Were they clear enough? Were they correct? Were they addressed?

Ask your senior developer to write down and classify the questions, I would even track the questions as issues or bugs. This will help you in your RCA effort and later on will help you to distribute the questions to different people to answer them even if they are not in the same office. Also, once you force people to write the questions the number will get reduced. The effect is the same as asking in public, most people don't dare but they don't mind asking later to the person privately. Also it can be a good way to introduce the Duck technique that has been suggested in the thread. Last but not least, it can be a base for your knowledge base or FAQ.

And if you need support for all this, just make visible the impact foreseen on your project, on your developer productivity and motivation. Don't wait for delays to be visible, because they will be and then nobody will listen that it was not your fault.



First, introduce the equivalent of a stuffed duck in the office. Questions should always be asked to it first. This one depends on the level of trust you have from that other team, and their own technical level. Make sure they don't take it as poking fun at them for not being able to work on their own.

Question ticket board

Then, introduce a question ticket board. I used this to manage interruptions from team members when I was doing Pomodoro and still had to be available to others.

Basically, that was simply having yet another post-its board, on which people with questions would write down one or two key words for them to remember their question, and then put the post-it on some reserved space next to my desk. Then, when I was available, I would take the top post-it, FIFO style, and went to answer it with the asker.

This has the following advantages:

  • Transforming interruptions into managed time off the project. Not as good as being rid of them, but probably the best tradeoff.
  • Answering only one (or n, depending on the actual amount) question at a time forces askers to cooperate and self-organize to decide which question should be asked first. This adds a bit to the cost for asking too many questions, while not making asking few questions costly at all.
  • Making the quantity of questions visible for everyone, calling for responsibility from askers, especially if you are in the same room.


Have askers document the given answers. It seems you already asked them to do so, but all the usefulness of a knowledge base depends on its implementation.

Make sure they don't simply write down “question: answer” in a file, no one will ever read it. Have them document or refactor the parts that gave them problems, boyscout-style (I'm assuming a programming project here, but hopefully you can find an equivalent in your domain if it is different).

Basically, have them understand that they should bend the material to their understanding, in order to foster a sense of possession and responsibility. This will also have the side effect of increasing the cost of questions to them, which seems to be something you might desire if it has already been some time since the transition started, and you noticed a rise in questions (based on “ lately the questions keep on coming even after talking to them”).

  • 1
    Quite interesting this 'question ticket board'!
    – Tiago Cardoso
    Commented Sep 10, 2012 at 13:28

I think pair programming could really help you out. Pair your team members up for the day, and switch the pairs everyday. It will do two things to specifically address your needs:

First it will help get your team used to asking questions of someone other than the resident expert. There may be someone that knows almost as much as he does, but no one knows it (this is usually the case, teams seem to become fixated on a single individual as a 'guru' even when it isn't the case). Pair programming can get your team asking questions of each other, and it will answer questions they didn't know they had.

Second, it will level the knowledge playing field much quicker than training sessions alone. I really don't know of a better way for an experienced programmer to impart knowledge to less experienced ones than pair programming.

Even if you don't go this route, I think there is only one major thing to watch out for: your team members asking questions that they could have easily found the answer to with 30 seconds of googling. This is a bad habit for everyone to get into, and its also a difficult one to break without doing something invasive. Talk to the resident expert and see if he thinks this is happening, and if he is willing to help you. A few responses of, "didn't you google that?" from him will be worth more than a policy from you.


Somehow in all my wisdom I missed that it was the other team's members coming to your team to ask questions. In this case pair programming wouldn't fix that particular issue (although that doesn't make it any less awesome). You could however, suggest to the other PM that he/she try instituting it of his/her team.


With patience. Performance goes up and down. Motivation goes up and down. Teaming goes up and down. Op tempo goes up and down. The point is, everything is variable and in a very random way. Trying to control it is futile.

This is where planning and risk management come to play. This variability should have been part of your planning and risk assessments so your targets were set to accommodate some of the variability and your contigent reserves were adequate.


You have a couple of alternatives:

  1. Improve the training. It doesn't seem like what you've done to bring the team up to speed has worked, which isn't necessarily surprising. Think back to your school days and how many concepts/ideas were really understood after one presentation. Step back and look at the questions they have. Is there a pattern that will let you figure out where the shortfalls are, what additional training/materials you could provide, etc?
  2. Control the conversations. Have your key team member set aside blocks of time when s/he is NOT available for answering questions. This will increase productivity by concentrating interruptions into a fixed part of the day.
  3. Carry on as-is. If you are still meeting the goals of your sprints and the schedule/budget/scope of the project aren't being impacted you may want to put this issue lower down on your priority list.
  4. Order a stop to the questions. IMO this is the worst alternative. The only benefit is helping make your most experienced person more productive, but this will be more than offset by the likely loss of productivity of everyone else, added work around quality assurance, rework to address incorrect assumptions on the part of the less experienced team members, etc.
  • Thanks Doug, I think i will start with identifying the topics that bring the most questions and plan a few tutorial/workshop sessions.
    – elena
    Commented Sep 6, 2012 at 13:17

Some good answers so far. I think the solution is a combination of all of them. It all comes down to people management, dealing with human beings.

Since you said 'my team' I'm assuming that you have sort or leadership role. I also assume the other team has someone in this role as well. I suggest the two of you meet, along with the team member with the knowledge, and simply say "Here's the situation, and here's how it's impacting my project. How do we resolve it so that your team gets what it needs, with as little impact to mine as possible? And how do ensure that the information being transfered is done so that the questions only have to be asked once"

It will take the three of you to figure out what to do. The two team leads can discuss ideas or options that work within the project context (schedule, etc.), but the team member has to agree as well. He has to be comfortable with how things are going to be handled after all it's HIS time and concentration being impacted.


Indeed a lot of good answers here, so I'll summarize what I'll do based on other answers:


Move the ownership of this issue away from the team. First, would be to get one appointed person from their team that will be responsible for the communication with the senior developer (this will be the speaking duck everybody will ask their questions to), so the classification and documentation of the Q&A becomes their responsibility.

Second, speak to the senior dev that will be managing the time for answering these final questions by setting aside some blocks of time during the week, so it can be included in the initial sprint planning.

Third, involve both PM in setting up and, since the other team is not using scrum, try a joint retrospective after 1 week to see how the situation can be improved and track the progress.

  • 2
    Hi Elena! Thanks for your kind words and feedback. However, please note that StackExchange does not work like a forum :) You should add these details by editing your question: here, they look like an answer to your own question, which it is currently not so much. If you find your solution to be applicable for everyone, you could consider making it look more like a precise, actionable answer, and then accepting it. If you need some more hints, please have a look at the FAQ :)
    – MattiSG
    Commented Sep 7, 2012 at 20:58
  • Hi elena, SE doesn't work like a forum. We don't use answers to talk to other answerers. However, it is okay to answer your own question, but you should pretend like you're on Jeopardy and answer it as if you're answering the original question that you asked, just as if you were another PM providing an answer to this question. I'll leave this here for a day or two for you (and others) to edit and improve; otherwise, we'll remove it later. Good luck, and glad to hear we were able to help! :)
    – jmort253
    Commented Sep 8, 2012 at 0:28
  • 1
    I made an edit. Hope this helps! :)
    – jmort253
    Commented Sep 8, 2012 at 1:16

With a team that young, consider temporarily moving one of your senior people on the "good" team to the new team. This person can then help mentor the young team and deflect most of the support issues until they can become self-sustaining. Losing one developer full time is better than the whole team being distracted several times a day.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.