In this post I will give a few pointers that will help you on how to be an effective technical lead or scrum master by sharing your ‘knowledge’.
1. Let team members decide on the details.
Altough the scrum master is the guiding person for the team, you should not be Mrs Knowall. The leader must be more concerned with broad essentials (mission, values, etc.) than with practical, detailed matters.
2. Share the communication and contact information.
As scrum master, architect or tech lead you are often the first one knowing who or where to go to for certain information. Suppose your team needs some information to continue their work, should they really have to go through you to get the necessay info, sometimes even wait till you are available again? Of course not, otherwise you are just a bottleneck for your team. So share contact information and ask team members to get in touch with people outside the team themselves.
3. Approval is with the team, not with the lead.
Guiding a team to higher quality is a good way to increase velocity. However when the lead is the sole judge on that quality you are again a throughput bottleneck for the team. So let members exchange the task of validating work. Let the QA role or architect role turn, in cycles, through the team. Remember that specialists are good but exchanging knowledge and widening the T-shape of all members is key. note: lead is not the team lead per se, can also be a tech lead, architect or QA lead. Prepare to share your role.
4. Be transparant, keep documenting.
It is cool when you found better or clearer ways of working. These can be in the process, in automation or in getting things done quicker. Do you like people coming to your desk how that module or setup worked again? Sure. But again you are being a knowledge bottleneck. Find ways to explain and document what you did. Organise a knowledge sharing and demo what you found and be open for suggestions from others for improving even further!
5. Do not sit on data or be an access obstacle.
When you are the sole person for getting certain data, the only one seeing a monitor or receiving alert e-mails. Maybe the sole person who can change some software configuration? You might be the sole authority to start or end a process? Or the only one with the access rights others do not have, or maybe you are the only one knowing the complexity of how changing the configuration of some key software application, or seeing certain data? You might be a chicken on golden eggs without anybody knowing. Stop it. Empower your colleagues and share.
In this post I have given you five examples how to stop being a knowledge bottleneck. It might take some courage to give up knowledge and will certainly be an effort to document and present, but you will be seen as the one who empowered the team.
Come back later for more posts!