Re: [teampractices] Kahneman, loss aversion, and achieving 75% of your goals

2018-03-14 Thread Jeroen De Dauw
Hey,

Interesting points. And a memorable section from Thinking Fast and Slow.

I too think it is important to get feedback early and not invest tons and
tons of effort into trying to never publish/deploy something that turns out
to need further iteration or does not make sense altogether. When a lot of
effort is invested into something and signs show up that it does not make a
lot of sense, it can be tempting to ignore those sings or to continue
because otherwise the effort would have been wasted (Sunken Cost Fallacy).
In my view there is room for improving this not just at WMF but also at
WMDE.

It is my impression that some people at WMF and WMDE are so afraid of the
community that they avoid cutting their losses when they should. Cutting
losses by ending a certain effort is visible to the community and is
something that is easy to direct criticism at. On the other hand if you
just throw tons and tons of resources at this effort you eventually end up
with an output that is not a failure if we ignore the cost in resources.
That cost is less visible to the community and can be justified with
"software development takes time and this project to add a button took the
same amount of years as that other one that adds a checkbox, so what are
you complaining about". This fear also leads to blocking risky projects
even if the cost of failure (ignoring community apocalypse) is much lower
than the possible upside. This kind of reasoning leads to subtle systemic
failure with a huge cost, leaves the community worse off and makes me
personally rather sad. I'd like to see less fear and more courage. If
delivered value goes up, feedback is used more often and mistakes are
corrected quicker, won't the community be more happy and more trusting?

> - Management based on *outcomes* rather than *outputs *for people whose
roles are strategically oriented (PMs, for example)

I do not understand this point. Could you reword or elaborate?

Cheers

--
Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw
Software Crafter | Speaker | Student | Strategist | Contributor to Wikimedia
and Open Source
~=[,,_,,]:3
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices


Re: [teampractices] No questions allowed!

2017-10-12 Thread Jeroen De Dauw
Hey,

Thanks for sharing.

It seems like for such a policy to not result in disaster, everyone needs a
good amount of empathy and willingness to cooperate. If you have an opinion
and person B has another opinion, person B cannot rely on you asking them
why they have this differing opinion in case where you want to know.
Instead they have to figure it out for themselves. At least assuming you
can't say something like "I wonder why you think that" or "Tell me why",
which while strictly are not questions, result in the "same" interaction
(different tone though).

Cheers

--
Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw
Software craftsmanship advocate | Developer at Wikimedia Germany
~=[,,_,,]:3

On 12 October 2017 at 22:13, Marti Johnson <mjohn...@wikimedia.org> wrote:

> This is such an awesome list.  I love getting a colleague's dream
> description in my work inbox!  Thank you, Kevin!
>
>
>
>
> *Marti JohnsonProgram Officer*
> *Individual Grants*
> *Wikimedia Foundation <http://wikimediafoundation.org/wiki/Home>*
> +1 415-839-6885
> Skype: Mjohnson_WMF
>
> Imagine a world in which every single human being can freely share
> <http://youtu.be/ci0Pihl2zXY> in the sum of all knowledge.  Help us make
> it a reality!
> Support Wikimedia <https://donate.wikimedia.org/>
>
> On Thu, Oct 12, 2017 at 1:01 PM, Kevin Smith <ksm...@wikimedia.org> wrote:
>
>> Last weekend, I had a dream, and this email is about that dream.
>>
>> I had just started working at an organization, as an Agile Coach (or
>> similar). I was surprised to learn that one of their important rules was
>> that everyone was prohibited from asking questions.
>>
>> Since a HUGE part of being an agile coach is asking questions, this
>> seemed insane to me. While trying to do my work, I kept starting to ask a
>> question, and then thinking through how to convey my point in a different
>> way.
>>
>> I pushed back, and asked why this rule was in place. The explanation
>> (remember this was a dream, so it doesn't have to be entirely coherent) was
>> something along the lines of: It's unfair for you to expect someone to
>> answer YOUR questions, because it makes assumptions about their goals and
>> interests. It puts them in a position of "answering to" you.
>>
>> As I continued to work within this odd framework, it became less
>> uncomfortable. There were cases where it was actually helpful, especially
>> since I sometimes have difficulty expressing my own preferences. Instead of
>> "What should we do next?", I might say "I think we should do X next". It
>> prevented people from using questions in a passive-aggressive way (which
>> can happen). And some people who were used to *only* speaking up when asked
>> a question found themselves force to speak up without prompting.
>>
>> For the rest of the night, even as I was in other, unrelated dreams, this
>> idea of "no questions" kept returning. By the end of the night, I felt
>> mostly at peace with it.
>>
>> I'm not advocating that we adopt this policy. But I encourage you to take
>> a few minutes and reflect how different your work life would be if you
>> weren't allowed to ask questions. For me at least, it was an interesting
>> thought experiment.
>>
>>
>> Kevin Smith
>> Engineering Program Manager, Wikimedia Foundation
>>
>>
>> ___
>> teampractices mailing list
>> teampractices@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices


Re: [teampractices] The Costs of Accountability

2015-09-11 Thread Jeroen De Dauw
Hey,

Nice article, I found the parts at the end about why this happens so often
most interesting. The "suspicion of authority based on class, expertise,
and background" line is making me scratch my head a bit though. Does the
author mean to say "authority of any form", or is there some commonality
between those sources of authority that I'm missing? Those based on class
and those based on expertise are as far apart as one can get no?

It does seem that "The Cost of Using Metrics Like an Idiot" would be a
better title, since one can have accountability without using metrics
poorly.

Cheers

--
Jeroen De Dauw - http://www.bn2vs.com
Software craftsmanship advocate
Developer at Wikimedia Germany
~=[,,_,,]:3
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices


Re: [teampractices] Agile coaching and the drama triangle

2015-05-07 Thread Jeroen De Dauw
Hey,

 Great stuff, Kevin - thank you for sharing this :)

I'd like to second that.

Cheers

--
Jeroen De Dauw - http://www.bn2vs.com
Software craftsmanship advocate
Developer at Wikimedia Germany
~=[,,_,,]:3
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices