Oliver, that's a fair point, but my idea can be expanded to non-products. The only difference here is that everyone becomes group #2 - having to convince others via social means. If the idea is not very visual, it has to be painted with words, so maybe our amazing community liaisons or other writers might be able to help with their writing prowess.
My main point is that we should have a well understood "idea path" - from inception to getting feedback, and well known resources to rely on.
On Thu, Feb 25, 2016 at 1:53 AM, Oliver Keyes ironholds@gmail.com wrote:
On Wed, Feb 24, 2016 at 5:38 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
Oliver, thanks!
In other words, the litmus test for me is: what happens when the
socially
and politically weakest person in the organisation has an idea?
If we speak of a "product" idea, we have two groups of people - those who can implement the idea, and those who would need to convince others to do it. They use fundamentally different, scarcely overlapping skill-sets.
An
engineer might go via the "hackathon + demo" route, implementing
something
simple and showing it to gain traction. A non-engineer would start with
the
social aspect first - talking to others if the idea is worth pursuing,
how
hard is it to do, and eventually - convincing others to allocate their time/resources to do it. Sometimes an engineer may go the social route instead, but it would be very hard for a non-engineer to engage in development. Lastly, the "designer" group has an amazing skill-set to visually present their full vision rather than the demo, thus often
having
easier time of conveying their thoughts.
In a sense, the barrier of entry for the person in the "weakest position" would not be as high for the "doer" as for the "inspirer". So I think the real challenge is how do we capture and evaluate those ideas from the second group? Also, no matter how hard we try, it would be either very hard, or very expensive (and not just financially) to force the implementers to do an idea they do not believe in. So in a sense, doers need to be persuaded first and foremost.
As with any explanation, a picture == 1000 words, so we could promote
"idea
visualizers" - designers who are easily approachable and could help to
draw
up a few sketches of the idea.
My email opened with "I think reducing things to engineering terms are sort of indicative of the problem here". I'm not talking about code. I'm not talking about designs. I'm not talking about software products. And thinking about it in terms of engineering projects, which is what we do as an organisation a lot, will not be helpful. If it did, then after several years of insisting that we are primarily a tech shop, we would hopefully not still be having conversations about structure and direction!
What I am talking about is ideas generally. They might be about software products. They might be about social products, a la the teahouse. They might be about how to tweak our process by which we interact with the community. They might be that our hiring process is kinda weird and here's this one cool way we could look at improving it. They might be that the break room snacks _suck_ (again, hypothetical: they're fine. Sorry, Facilities).
In any case, the litmus test is just that; a litmus test. Our structure should be designed cognizant to these problems, and then pass the test, but not be designed *specifically* to pass the test. And the designer idea seems pretty hyper-optimised just for the test.
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe