‘You can’t tell someone something if they aren’t ready to listen’ is something I picked up from my kayak coaching training. When coaching on placid water the major concerns can be considering the position of the sun and the group, background noise and any potential distractions. But in more challenging conditions or teaching over a longer period you might need to be thinking more about the students’ state of mind, how alert they are, and their energy and stress levels.
What really got me was how well this advice applies to the office/team environment.
The more important or difficult the message you are delivering the more you need to focus on the receiver’s ability to listen. For a really critical conversation they may really need to be in a space to consider what you say without many distractions, and time before and after to think about the conversation.
For any conversation where the result counts, I try to take a second to consider the environment the conversation is taking place and where the other person is at. Sometime I get it wrong and have to back out and try again later but I try to keep it at the back of my mind.
You can’t tell someone something if they aren’t ready to listen
Monday, 11 August 2008
Labels:
personal development
A Moral Hazard: is your team insulated from the project risks?
Monday, 4 August 2008
Ever been frustrated when a workmate or a member of your team made such stupid choice that you had to go in there and fix things, distracting you from the stuff you should be doing? Perhaps they weren’t able to make the right choices because they didn’t know what they were risking.
There is a term in the Insurance business: Moral Hazard. Summed up it means people insulated from a risk behave differently that if they are exposed to it. For example a driver worries less about a well insured car than an under-insured one; or an extreme example: un-insured owners are less likely to torch their factory
I think this applies to software development teams also. The team’s behaviour and choices differ depending on the risks they are exposed to. If you want the team to make wise choices and have good behaviours they need to feel the risks. If the push is just for delivered functionality above everything else, the team may choose to work on stories when there are bugs to be fixed as they have not exposed fully to the project risk of a buggy application’s release being delayed. You or someone might be concerned about it but unless the team understands the risk they are taking with continual story development, they don’t make the wisest choice.
I feel that its important that the team isn’t isolated from the risks associated with the project and I see that as ensuring the information about the critical aspects of the project are shared with them – as a team leader it can be tempted to shield them, but that leads frustration when they make choices that make no sense to the people with all the information.
There is a term in the Insurance business: Moral Hazard. Summed up it means people insulated from a risk behave differently that if they are exposed to it. For example a driver worries less about a well insured car than an under-insured one; or an extreme example: un-insured owners are less likely to torch their factory
I think this applies to software development teams also. The team’s behaviour and choices differ depending on the risks they are exposed to. If you want the team to make wise choices and have good behaviours they need to feel the risks. If the push is just for delivered functionality above everything else, the team may choose to work on stories when there are bugs to be fixed as they have not exposed fully to the project risk of a buggy application’s release being delayed. You or someone might be concerned about it but unless the team understands the risk they are taking with continual story development, they don’t make the wisest choice.
I feel that its important that the team isn’t isolated from the risks associated with the project and I see that as ensuring the information about the critical aspects of the project are shared with them – as a team leader it can be tempted to shield them, but that leads frustration when they make choices that make no sense to the people with all the information.
Subscribe to:
Posts
(
Atom
)