If you're a team lead then being open is part of your job description, if you're not a team lead but want to be one then being open will help you get there. Sharing knowledge isn't just for team leads and senior developers, it is for everyone and should be part of the team mind-set. Sharing your knowledge with other people makes your team and organisation more successful, it makes you more successful and helps you build relationships with others. I cannot recommend more highly sharing your knowledge openly with others.
But as with everything there are good ways and bad ways to do it. Being open isn't just about sharing the solution with a colleague, it is about sharing the background to what drew you to that solution, the benefits and trade-offs and any other contenders. If there is a thought process that can lead to good solutions then share that too. In the short term it takes more of your time, but in the long run you'll have more effective team mates and you'll be more highly valued.
Let's take an example, a junior colleague comes to you because they know you're the database guy in the development team and as a good junior developer they realise they have a performance problem and because they care about the quality of their work they come to you for help. They think an index would help but they really don't know about indexing and they need some help. So they come to you they give you a brief description of the problem, they show you the table and a query and ask what index should they put on the table. Let's say an index is required and this is the only query. One response would be to tell them what index to add and send them on their way but what will they have really learned if that is all the information you give them. They will be back again with a similar question in the future, as clueless as before about indexes and how to design a good one.
In 15 to 20 minutes I can give a decent introduction to indexes, clustered and non-clustered, explaining what the physical structure of an index is and why it speeds up read queries, why it penalises writes and how to see the usage of an index in a query execution plan. It is enough for many developers to get started into understanding indexing strategies.
In 10 to 15 minutes I can explain why using ToLower() when performing a string comparison is inefficient, by creating a quick console application with a large loop with an if statement inside that performs a string comparison using ToLower() on both sides. I run a memory profiler and show the large memory allocation for strings. Then I replace the ToLower() approach with a case insensitive string comparison and show the difference in memory allocation. The junior is usually pretty shocked but it is a lesson they remember.
I could have told my colleague the exact index to create and that's it. I could have told my other colleague never to use ToLower() when doing case insensitive string comparisons and left it at that. But all I would have done is solved one instance of one problem, the impact would be insignificant and so I would have wasted my time and their time.
Explain the why, convince them with reasoning and it is more likely to stick and they’ll be a better coder for it.