Project management has been a staple of business for decades. It has undergone significant changes, particularly when it was formally adopted for Agile development. It wasn’t always that way, though. Let me take you back three decades, to a time when Waterfall was still the king of software development processes.

Asking questions is how we all learn and grow in our careers. It is how we gain understanding, gather necessary information, and ensure relevance and accuracy towards what we are tasked with doing. Asking questions bridges the gap between intent and ability to generate a valid and accurate response. There are times when asking questions will cause problems at work, though. Sometimes, your questions may not be welcome, and there may be several reasons for that.

Many teams today have specific “go-to” people on a team. There is often a person who is the only one who has dealt with a specific feature or issue, and they are always the one that the team turns to when work needs to be done. What happens if that person is unavailable or busy with something else? Is the team sharing knowledge, or are they using the specialist’s capability as a crutch? Should someone be allowed to continue as the single point of failure?