Thanks for sharing that data and perspective. One aspect of that I hadnāt had in mind before was that the value of explicit ToCs, ToC diagrams, and similar might depend in part on the extent to which theyāre:
used by people who themselves believe these things are a good idea, and only when those people believe these things are a good idea.
Also, I was only really thinking about an organisation making one, organisation-wide ToC diagram; I hadnāt considered the idea of making ToC diagrams for each particular project, program, etc.
Having read your comment, I thought itād be interesting to consider what organisation leaders should do if it would be useful for employees to make ToC diagrams for a substantial portion of individual projects, programs, etc.
I think that, if employees arenāt already in the habit and itās not already common in the organisation, employees would by default hardly ever make ToC diagrams. If so, and if we assume that making ToC diagrams often would be good, then there should probably be some sort of push from the leadership.
But maybe this push should take the form of explicitly highlighting the option of making ToC diagrams, providing some good examples, and encouraging people to try it a few times. And then hopefully, if the employees were chosen well, theyāll naturally come to use them about as often as they should.
Whereas perhaps it would be badto have a strong push from above, e.g. mandating the use of ToC in every case, or being so persistent in encouraging their āoptionalā use that employees feel compelled. Maybe that would lead to employees making such diagrams even when itās not valuable, or making such diagrams in a crappy way when a good diagram would be valuable.
But maybe this push should take the form of explicitly highlighting the option of making ToC diagrams, providing some good examples, and encouraging people to try it a few times. And then hopefully, if the employees were chosen well, theyāll naturally come to use them about as often as they should.
This is probably the right course of action. Before the project I just finished, it was never really clear to me the settings in which flow chart-type diagrams made sense. As a more or less mathy type, I think I didnāt give them their due. Now that Iāve seen them in practice, Iāve started making them here and there.
I think just giving employees the allowance to make diagrams instead of slideshows or reports, and cluing them into best practices (see e.g. this guide from the CDC) can go a long way. It seems like lots of staffers go down the report/āslideshow rabbit hole because they want to be seen to be doing something. This results in long, unread memos, etc.
Thereās another benefit, too: staffers have sometimes dramatically different writing and design skills, and simple diagrams can lower the barriers to communicating ideas for employees who may not be confident in these skills. If staff members are held to a strict standard for the clarity and coherence of logic models, they can be a way of rapidly iterating ideas that would otherwise remain unheard.
Thanks for sharing that data and perspective. One aspect of that I hadnāt had in mind before was that the value of explicit ToCs, ToC diagrams, and similar might depend in part on the extent to which theyāre:
mandated from above and then Goodharted on, or
used by people who themselves believe these things are a good idea, and only when those people believe these things are a good idea.
Also, I was only really thinking about an organisation making one, organisation-wide ToC diagram; I hadnāt considered the idea of making ToC diagrams for each particular project, program, etc.
Having read your comment, I thought itād be interesting to consider what organisation leaders should do if it would be useful for employees to make ToC diagrams for a substantial portion of individual projects, programs, etc.
I think that, if employees arenāt already in the habit and itās not already common in the organisation, employees would by default hardly ever make ToC diagrams. If so, and if we assume that making ToC diagrams often would be good, then there should probably be some sort of push from the leadership.
But maybe this push should take the form of explicitly highlighting the option of making ToC diagrams, providing some good examples, and encouraging people to try it a few times. And then hopefully, if the employees were chosen well, theyāll naturally come to use them about as often as they should.
Whereas perhaps it would be bad to have a strong push from above, e.g. mandating the use of ToC in every case, or being so persistent in encouraging their āoptionalā use that employees feel compelled. Maybe that would lead to employees making such diagrams even when itās not valuable, or making such diagrams in a crappy way when a good diagram would be valuable.
This is probably the right course of action. Before the project I just finished, it was never really clear to me the settings in which flow chart-type diagrams made sense. As a more or less mathy type, I think I didnāt give them their due. Now that Iāve seen them in practice, Iāve started making them here and there.
I think just giving employees the allowance to make diagrams instead of slideshows or reports, and cluing them into best practices (see e.g. this guide from the CDC) can go a long way. It seems like lots of staffers go down the report/āslideshow rabbit hole because they want to be seen to be doing something. This results in long, unread memos, etc.
Thereās another benefit, too: staffers have sometimes dramatically different writing and design skills, and simple diagrams can lower the barriers to communicating ideas for employees who may not be confident in these skills. If staff members are held to a strict standard for the clarity and coherence of logic models, they can be a way of rapidly iterating ideas that would otherwise remain unheard.