Something in Oliver's departure email caught my eye:
* "Because we are scared and in pain and hindered by structural biases and hierarchy, we are worse at our jobs." (quoted with Oliver's permission)*
And that got me thinking. WMF, an organization that was built with the open and community-driven principles - why have we became the classic example of a corporate multi-level hierarchy? Should we mimic a living organism rather than a human-built pyramid?
This may sound naive and wishful, but could we have a more flat and flexible team structure, where instead of having large teams with sub-teams, we would have small self-forming teams "by interest". For example, someone decides to dedicate their 20% to building support for storing 3D models in wiki. Their efforts are noticed, the community shows its support, and WMF reacts by increasing project resourcing. Or the opposite - the community questions the need of a project, and neither the team nor WMF can convincingly justify it - the project resources are gradually reduced.
An organism reacts to the change of its environment by redistributing resources to the more problematic areas. Would small, flexible, and more focused teams achieve that better?
If I remember correctly, I think that's how the Content Translation project started -- it was someone's personal project, which got more people and attention because it's a great idea and showed real success.
It's hard to know what the mechanism would be for how to gauge community support at meaningful intervals. Most people aren't paying a lot of attention to what the WMF is working on from one day to the next, and there's only so many big surveys you can do before people get tired of them. It's a tough problem.
On Tue, Feb 23, 2016 at 4:53 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
Something in Oliver's departure email caught my eye:
- "Because we are scared and in pain and hindered by structural biases and
hierarchy, we are worse at our jobs." (quoted with Oliver's permission)*
And that got me thinking. WMF, an organization that was built with the open and community-driven principles - why have we became the classic example of a corporate multi-level hierarchy? Should we mimic a living organism rather than a human-built pyramid?
This may sound naive and wishful, but could we have a more flat and flexible team structure, where instead of having large teams with sub-teams, we would have small self-forming teams "by interest". For example, someone decides to dedicate their 20% to building support for storing 3D models in wiki. Their efforts are noticed, the community shows its support, and WMF reacts by increasing project resourcing. Or the opposite - the community questions the need of a project, and neither the team nor WMF can convincingly justify it - the project resources are gradually reduced.
An organism reacts to the change of its environment by redistributing resources to the more problematic areas. Would small, flexible, and more focused teams achieve that better? _______________________________________________ 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
If I remember correctly, I think that's how the Content Translation project started -- it was someone's personal project, which got more people and attention because it's a great idea and showed real success.
and Event Logging, and the Graph extension, and Mediawiki Vagrant , and ... and ... Wikipedia!!
but also, some projects that were not so useful, sure. But we learn, move on, we're not the first group of people to make mistakes : )
On Feb 23, 2016 5:52 PM, "Dan Andreescu" dandreescu@wikimedia.org wrote:
but also, some projects that were not so useful, sure. But we learn, move on, we're not the first group of people to make mistakes : )
Yep... High-tech organizations call it "failing fast".
-- Brion
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
Does it make sense to have an "Incubator team" ("Bell Labs" if you will), whose core competency is to nurture small projects? When projects are mature and need to switch into maintenance mode, they move under the umbrella of a different team.
On Wed, Feb 24, 2016 at 5:06 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Feb 23, 2016 5:52 PM, "Dan Andreescu" dandreescu@wikimedia.org wrote:
but also, some projects that were not so useful, sure. But we learn,
move
on, we're not the first group of people to make mistakes : )
Yep... High-tech organizations call it "failing fast".
-- Brion
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
Brion,
there was a very constructive, heartfelt session on models of bottom-up open innovation at this year's WMF All Hands. You can find extensive notes from this session on the Office Wiki ("Embracing skunkworks") which I encourage you to read and that I'd love to share publicly in a more readable format at some point.
There are obvious tradeoffs between allowing more flexibility on the one hand and making sure we have a reasonable budget plan, accountability to donors and stakeholders and appropriate resource allocation on the other hand, but I believe this model would work much better than the current one, at least for projects that are not core initiatives.
Skunkworks is what got us revision scoring, EventLogging, countless initiatives by TechOps and innovative MediaWiki extensions.
Dario
On Tue, Feb 23, 2016 at 6:14 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
Does it make sense to have an "Incubator team" ("Bell Labs" if you will), whose core competency is to nurture small projects? When projects are mature and need to switch into maintenance mode, they move under the umbrella of a different team.
On Wed, Feb 24, 2016 at 5:06 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Feb 23, 2016 5:52 PM, "Dan Andreescu" dandreescu@wikimedia.org
wrote:
but also, some projects that were not so useful, sure. But we learn,
move
on, we're not the first group of people to make mistakes : )
Yep... High-tech organizations call it "failing fast".
-- Brion
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
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
That's funny, there's also an active reading group looking into flatter organizational structures. I think we're maybe ready for a more official lack of hierarchy, or at least a more solid acknowledgement that it's flexibility that makes us strong and it should be cherished.
On Tue, Feb 23, 2016 at 10:01 PM, Dario Taraborelli < dtaraborelli@wikimedia.org> wrote:
Brion,
there was a very constructive, heartfelt session on models of bottom-up open innovation at this year's WMF All Hands. You can find extensive notes from this session on the Office Wiki ("Embracing skunkworks") which I encourage you to read and that I'd love to share publicly in a more readable format at some point.
There are obvious tradeoffs between allowing more flexibility on the one hand and making sure we have a reasonable budget plan, accountability to donors and stakeholders and appropriate resource allocation on the other hand, but I believe this model would work much better than the current one, at least for projects that are not core initiatives.
Skunkworks is what got us revision scoring, EventLogging, countless initiatives by TechOps and innovative MediaWiki extensions.
Dario
On Tue, Feb 23, 2016 at 6:14 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
Does it make sense to have an "Incubator team" ("Bell Labs" if you will), whose core competency is to nurture small projects? When projects are mature and need to switch into maintenance mode, they move under the umbrella of a different team.
On Wed, Feb 24, 2016 at 5:06 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Feb 23, 2016 5:52 PM, "Dan Andreescu" dandreescu@wikimedia.org
wrote:
but also, some projects that were not so useful, sure. But we learn,
move
on, we're not the first group of people to make mistakes : )
Yep... High-tech organizations call it "failing fast".
-- Brion
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
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
--
*Dario Taraborelli *Head of Research, Wikimedia Foundation wikimediafoundation.org • nitens.org • @readermeter http://twitter.com/readermeter _______________________________________________ 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
On Feb 23, 2016 7:01 PM, "Dario Taraborelli" dtaraborelli@wikimedia.org wrote:
Brion,
there was a very constructive, heartfelt session on models of bottom-up open innovation at this year's WMF All Hands. You can find extensive notes from this session on the Office Wiki ("Embracing skunkworks") which I encourage you to read and that I'd love to share publicly in a more readable format at some point.
Awesome, I'll check it out and read up on the prior art. :) Looking forward to further discussion on these ideas once we have a chance to clean it up.
There are obvious tradeoffs between allowing more flexibility on the one hand and making sure we have a reasonable budget plan, accountability to donors and stakeholders and appropriate resource allocation on the other hand, but I believe this model would work much better than the current
one,
at least for projects that are not core initiatives.
*nod* I like the idea of an internal small grants-like system to provide some documentation, a little oversight, and help coordinate needed additional people/equipment/contracting budget on small projects with a shorter turnaround time than waiting for next year's annual budget.
-- brion
Skunkworks is what got us revision scoring, EventLogging, countless initiatives by TechOps and innovative MediaWiki extensions.
Dario
On Tue, Feb 23, 2016 at 6:14 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
Does it make sense to have an "Incubator team" ("Bell Labs" if you
will),
whose core competency is to nurture small projects? When projects are mature and need to switch into maintenance mode, they move under the umbrella of a different team.
On Wed, Feb 24, 2016 at 5:06 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Feb 23, 2016 5:52 PM, "Dan Andreescu" dandreescu@wikimedia.org
wrote:
but also, some projects that were not so useful, sure. But we
learn,
move
on, we're not the first group of people to make mistakes : )
Yep... High-tech organizations call it "failing fast".
-- Brion
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
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
--
*Dario Taraborelli *Head of Research, Wikimedia Foundation wikimediafoundation.org • nitens.org • @readermeter http://twitter.com/readermeter _______________________________________________ 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
I've advocated for flexible/ad-hoc/cross-functional teams before, and I would advocate for that again.
Many of our successful projects -- both software and social -- start as initiatives from individual staff members, often in concert with volunteers providing research, testing, feedback, usage, and even patches. This is something I think we should embrace in how we structure new projects.
Central budgeting and a standing team are great for maintenance and for ongoing work on large projects, but I think we need to be more flexible in spinning up new projects.
Communication should be handled by people close to the planning and implementation; we've seen startling failures of centralized communication in the Knowledge Engine project, and the difficulty for the *actual* Discovery team to control and communicate their own narrative and be judged on their own merits has been very painful for that team.
Anyway, I think there's plenty of place for planning and big teams and predefined KPIs, but I think we can be more... dare I say "agile"... than we have been. (Little "a".)
I hope once the current troubles pass, that we will all be able to talk more openly and safely about how we can all help ourselves, our org and our movement succeed.
-- brion On Feb 23, 2016 4:53 PM, "Yuri Astrakhan" yastrakhan@wikimedia.org wrote:
Something in Oliver's departure email caught my eye:
- "Because we are scared and in pain and hindered by structural biases and
hierarchy, we are worse at our jobs." (quoted with Oliver's permission)*
And that got me thinking. WMF, an organization that was built with the open and community-driven principles - why have we became the classic example of a corporate multi-level hierarchy? Should we mimic a living organism rather than a human-built pyramid?
This may sound naive and wishful, but could we have a more flat and flexible team structure, where instead of having large teams with sub-teams, we would have small self-forming teams "by interest". For example, someone decides to dedicate their 20% to building support for storing 3D models in wiki. Their efforts are noticed, the community shows its support, and WMF reacts by increasing project resourcing. Or the opposite - the community questions the need of a project, and neither the team nor WMF can convincingly justify it - the project resources are gradually reduced.
An organism reacts to the change of its environment by redistributing resources to the more problematic areas. Would small, flexible, and more focused teams achieve that better? _______________________________________________ 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
Well, I see nothing in the rule-book [1] that says we have to be rigid. Sure a lot of our work aligns with Reading, Editing, Discovery, and Infrastructure. But some of our work needs bits and pieces from each vertical, and even if managers and "hierarchists" [2] moan and groan, it doesn't make the need for that work go away.
I'll give you one example. This graph that Yuri shared earlier [3] has a dark secret if you click Edit twice. The data for that graph is copy-pasted into the graph in a most unsightly way. So now it lives in both wikitext format in the table below and eye-piercing JSON format inside the graph. Obviously, this data should live somewhere as a first class citizen, and be used from both the table and the graph. Yuri, me, Dario, and a *bunch* of community members have been talking about the fact that we need this for at least 2 years.
So why hasn't it happened? Well, it's because people moaned and groaned and it didn't fit into our structure.
So let's do it. Starting now, I am no longer going to be rigidly defined by my title [4]. I will dedicate some (not all) of my time to helping make this structured data a first class citizen so we can use it on wikis and stop turning people's eyeballs to mush with our weird JSON. I know there's community desire and support for this, it makes sense, and we're all trying to work on it in our spare time and at 3am on Sunday the last day of the hackathon. Not a great way for a complicated feature to make it out to our dear community!
Much love, and hopefully inspiration for others to find and do useful projects not necessarily defined by their title.
Dan
p.s. this email was written with a smile and light-hearted attitude
[1] There is no rule-book :) [2] hierarchists: people who love hierarchy [3] https://en.wikipedia.org/wiki/List_of_most_expensive_paintings#Interactive_g... [4] I am a "Front End Javascript UX/UI Engineer, Analytics" *whatever* that means... : )
On Tue, Feb 23, 2016 at 7:53 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
Something in Oliver's departure email caught my eye:
- "Because we are scared and in pain and hindered by structural biases and
hierarchy, we are worse at our jobs." (quoted with Oliver's permission)*
And that got me thinking. WMF, an organization that was built with the open and community-driven principles - why have we became the classic example of a corporate multi-level hierarchy? Should we mimic a living organism rather than a human-built pyramid?
This may sound naive and wishful, but could we have a more flat and flexible team structure, where instead of having large teams with sub-teams, we would have small self-forming teams "by interest". For example, someone decides to dedicate their 20% to building support for storing 3D models in wiki. Their efforts are noticed, the community shows its support, and WMF reacts by increasing project resourcing. Or the opposite - the community questions the need of a project, and neither the team nor WMF can convincingly justify it - the project resources are gradually reduced.
An organism reacts to the change of its environment by redistributing resources to the more problematic areas. Would small, flexible, and more focused teams achieve that better? _______________________________________________ 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
On Tue, Feb 23, 2016 at 7:53 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
And that got me thinking. WMF, an organization that was built with the open and community-driven principles - why have we became the classic example of a corporate multi-level hierarchy? Should we mimic a living organism rather than a human-built pyramid?
This may sound naive and wishful, but could we have a more flat and flexible team structure, where instead of having large teams with sub-teams, we would have small self-forming teams "by interest". For example, someone decides to dedicate their 20% to building support for storing 3D models in wiki.
So glad to see this being discussed in the open with smart folks like Brion, Dario, et al.
3D support would be most welcome – we’re in a holding pattern with Smithsonian 3D GLAM projects in DC because of that shortcoming in Commons. It was never known whether anyone was paying attention or going to put 3D on the radar screen. (https://phabricator.wikimedia.org/T3790)
At my keynote talk at Wikiconference USA, I said one of the things WMF “must do” is multimedia and interactivity. Your work on the interactive graph is a great step. Brion, myself and others have been working on collaborative video. Brion’s ogv.js work is a great example of skunkworks type projects having a huge impact.
And if 3D is given a priority, the three areas would be a great collective step towards Wikipedia continuing its revolutionary work. Best of all, they would be technologies developed in service of content and community needs, and not simply created for tech’s sake.
An organism reacts to the change of its environment by redistributing
resources to the more problematic areas. Would small, flexible, and more focused teams achieve that better?
Yes, and in a recent meeting you mentioned Bell Labs as a model. As someone who worked there, it’s a very good ideal to shoot for.
https://www.mediawiki.org/wiki/Discovery/2016-02-16_Discussing_Knowledge_Eng...
Thanks for opening up this discussion. -Andrew
If I remember correctly, I think that's how the Content Translation project started -- it was someone's personal project, which got more people and attention because it's a great idea and showed real success.
That is not accurate. I think Content Translation is a good example of bottom-up and design-driven project, though.
The Language team identified that users frequently were asking for better support for translating Wikipedia articles, and decided to learn from existing translators (and their heavily manual efforts) without a predefined idea of how the solution would look like. After many iterations of design, prototyping and research the team started building the tool iteratively and driven by user behaviour (based on metrics and more user research). I wrote a more detailed piece about this some time ago if anyone is interested in more details: http://pauginer.com/post/116536135010/the-design-of-content-translation
So while this project didn't came from top-down roadmap, it was also not a solo "cowboy-style" personal project. I definitely think it followed a good pattern for more projects to consider.
Pau
On Wed, Feb 24, 2016 at 4:40 AM, Andrew Lih andrew.lih@gmail.com wrote:
On Tue, Feb 23, 2016 at 7:53 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
And that got me thinking. WMF, an organization that was built with the
open
and community-driven principles - why have we became the classic example
of
a corporate multi-level hierarchy? Should we mimic a living organism
rather
than a human-built pyramid?
This may sound naive and wishful, but could we have a more flat and flexible team structure, where instead of having large teams with sub-teams, we would have small self-forming teams "by interest". For example, someone decides to dedicate their 20% to building support for storing 3D models in wiki.
So glad to see this being discussed in the open with smart folks like Brion, Dario, et al.
3D support would be most welcome – we’re in a holding pattern with Smithsonian 3D GLAM projects in DC because of that shortcoming in Commons. It was never known whether anyone was paying attention or going to put 3D on the radar screen. (https://phabricator.wikimedia.org/T3790)
At my keynote talk at Wikiconference USA, I said one of the things WMF “must do” is multimedia and interactivity. Your work on the interactive graph is a great step. Brion, myself and others have been working on collaborative video. Brion’s ogv.js work is a great example of skunkworks type projects having a huge impact.
And if 3D is given a priority, the three areas would be a great collective step towards Wikipedia continuing its revolutionary work. Best of all, they would be technologies developed in service of content and community needs, and not simply created for tech’s sake.
An organism reacts to the change of its environment by redistributing
resources to the more problematic areas. Would small, flexible, and more focused teams achieve that better?
Yes, and in a recent meeting you mentioned Bell Labs as a model. As someone who worked there, it’s a very good ideal to shoot for.
https://www.mediawiki.org/wiki/Discovery/2016-02-16_Discussing_Knowledge_Eng...
Thanks for opening up this discussion. -Andrew _______________________________________________ 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
I would like to clarify a fairly major premise of this conversation: namely, the comment I made that Yuri quoted in the very first message.
When I say that the hierarchical organisation of the Foundation is something that is preventing us from doing better, I was not thinking of how we develop software. Indeed, I suspect that peoples' tendency to bring things constantly back to "does it improve the measurable speed at which we right code" is symptomatic of the problematic dynamics here. What I was thinking about was how we pay attention to organisational hiring, to how we promote, to how we treat people, what empathy we have and how we value empathy.
I have consistently found the Foundation to lag in all of these regards. It is not good at making sure that the recognition of employees is fair and treated equitably (be that who gets called out in presentations, who gets given opportunities, or who gets raises). It is not good at making sure that how we hire is fair. It is not good at making sure that concerns of employees are given weight. All too often the people marginalised by our approaches are the people marginalised outside the Foundation, as well; women, people in "non-technical" roles, people in roles that we code as "support work" (and guess what tends to correlate with a role being coded as support work?) All too often the work marginalised by our approaches is the work that Doesn't Product Code (again: guess who tends to do the heavy lifting on things like organisational health and process and structure?)
As an organisation I have found the Foundation overly rigid and resistant to the most conservative change around these problems; particularly I think of efforts to improve unintentional bias in our job descriptions. Basically, unless you as an employee go out and do the damn work yourself, for free, with 0 recognition of the emotional and temporal cost of that work, it doesn't get done. The organisation as a whole is not interested.
Switching to a flat organisational structure does not, in any way, solve for this problem. In fact, in some way it makes it worse, because it makes us *think* that we have solved for the systemic and hierarchical power dynamics that make it difficult for low-level or marginalised people to get things done, or people doing marginalised work to get things done, when we have only shifted them.
To pick on someone, I pick Trevor (sorry Trevor. For reference this is an entirely hypothetical example and Trevor is lovely): Trevor's voice is given a lot more weight in the organisation than mine. Trevor has a lot more influence than I do. Trevor has a lot more influence than most WMFers do!
Crucially: this *isn't because he's management*. This was the case even *before* he was management. Because:
1. He's been here a really really long time and so knows everyone. 2. He's an Engineer, and we give engineers more weight and cachet than we do, say, administrative staff or people in "support" roles, even though those people are both as-smart and have an equal interest in the organisation's success; 3. His background matches what we strongly correlate with Authority Voices.
If we switch to a flat organisational structure where nobody has a title, or..whatever, all of these things will still be true. We will switch pronounce systemic biases or uneven power dynamics Done, and we will have achieved something that's actually worse than not doing anything at all. Because now, we still *have* all those problems, we just think we're done and don't have to put any work in and can't talk about it, and nobody has the responsibility for continuing to fix things.
The Foundation I would return to is not an organisation with a flat structure. In fact, it could be an organisation that looks a lot like this one, because I don't believe reporting lines or titles have as much of an impact on dynamics as we think they do. What *does* have an impact is how we recognise the value of emotional labour, how we recognise our implicit biases and advantages, and how honest we are with each other: not just in terms of what we *say* but in terms of how we *listen*. In other words, the litmus test for me is: what happens when the socially and politically weakest person in the organisation has an idea?
Anyway; I don't particularly want to go into a long drawn-out conversation, just correct the initial, fundamental misunderstanding. Hopefully I've provided a bit of food for thought along with that.
On Wed, Feb 24, 2016 at 3:50 AM, Pau Giner pginer@wikimedia.org wrote:
If I remember correctly, I think that's how the Content Translation project started -- it was someone's personal project, which got more people and attention because it's a great idea and showed real success.
That is not accurate. I think Content Translation is a good example of bottom-up and design-driven project, though.
The Language team identified that users frequently were asking for better support for translating Wikipedia articles, and decided to learn from existing translators (and their heavily manual efforts) without a predefined idea of how the solution would look like. After many iterations of design, prototyping and research the team started building the tool iteratively and driven by user behaviour (based on metrics and more user research). I wrote a more detailed piece about this some time ago if anyone is interested in more details: http://pauginer.com/post/116536135010/the-design-of-content-translation
So while this project didn't came from top-down roadmap, it was also not a solo "cowboy-style" personal project. I definitely think it followed a good pattern for more projects to consider.
Pau
On Wed, Feb 24, 2016 at 4:40 AM, Andrew Lih andrew.lih@gmail.com wrote:
On Tue, Feb 23, 2016 at 7:53 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
And that got me thinking. WMF, an organization that was built with the
open
and community-driven principles - why have we became the classic example
of
a corporate multi-level hierarchy? Should we mimic a living organism
rather
than a human-built pyramid?
This may sound naive and wishful, but could we have a more flat and flexible team structure, where instead of having large teams with sub-teams, we would have small self-forming teams "by interest". For example, someone decides to dedicate their 20% to building support for storing 3D models in wiki.
So glad to see this being discussed in the open with smart folks like Brion, Dario, et al.
3D support would be most welcome – we’re in a holding pattern with Smithsonian 3D GLAM projects in DC because of that shortcoming in Commons. It was never known whether anyone was paying attention or going to put 3D on the radar screen. (https://phabricator.wikimedia.org/T3790)
At my keynote talk at Wikiconference USA, I said one of the things WMF “must do” is multimedia and interactivity. Your work on the interactive graph is a great step. Brion, myself and others have been working on collaborative video. Brion’s ogv.js work is a great example of skunkworks type projects having a huge impact.
And if 3D is given a priority, the three areas would be a great collective step towards Wikipedia continuing its revolutionary work. Best of all, they would be technologies developed in service of content and community needs, and not simply created for tech’s sake.
An organism reacts to the change of its environment by redistributing
resources to the more problematic areas. Would small, flexible, and more focused teams achieve that better?
Yes, and in a recent meeting you mentioned Bell Labs as a model. As someone who worked there, it’s a very good ideal to shoot for.
https://www.mediawiki.org/wiki/Discovery/2016-02-16_Discussing_Knowledge_Eng...
Thanks for opening up this discussion. -Andrew _______________________________________________ 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
-- Pau Giner Senior User Experience Designer Wikimedia Foundation _______________________________________________ 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
I just want to call out Oliver's post here as extremely valuable, and this bears repeating:
A "flat" org structure is not a panacea when you don't have a level playing field, and the playing field's never as level as we like to think it is.
Google up some discussions on the subject of 'meritocracy' and you'll find talk about all kinds of inequalities in the power dynamics in free/open-source software and similar online cultures, as well as many engineering/"high-tech" organizations in general. I won't go into more here now, but I think it's something we need to seriously think more about, especially since we're at the intersection of many different cultures.
-- brion
On Wed, Feb 24, 2016 at 10:34 AM, Oliver Keyes ironholds@gmail.com wrote:
I would like to clarify a fairly major premise of this conversation: namely, the comment I made that Yuri quoted in the very first message.
When I say that the hierarchical organisation of the Foundation is something that is preventing us from doing better, I was not thinking of how we develop software. Indeed, I suspect that peoples' tendency to bring things constantly back to "does it improve the measurable speed at which we right code" is symptomatic of the problematic dynamics here. What I was thinking about was how we pay attention to organisational hiring, to how we promote, to how we treat people, what empathy we have and how we value empathy.
I have consistently found the Foundation to lag in all of these regards. It is not good at making sure that the recognition of employees is fair and treated equitably (be that who gets called out in presentations, who gets given opportunities, or who gets raises). It is not good at making sure that how we hire is fair. It is not good at making sure that concerns of employees are given weight. All too often the people marginalised by our approaches are the people marginalised outside the Foundation, as well; women, people in "non-technical" roles, people in roles that we code as "support work" (and guess what tends to correlate with a role being coded as support work?) All too often the work marginalised by our approaches is the work that Doesn't Product Code (again: guess who tends to do the heavy lifting on things like organisational health and process and structure?)
As an organisation I have found the Foundation overly rigid and resistant to the most conservative change around these problems; particularly I think of efforts to improve unintentional bias in our job descriptions. Basically, unless you as an employee go out and do the damn work yourself, for free, with 0 recognition of the emotional and temporal cost of that work, it doesn't get done. The organisation as a whole is not interested.
Switching to a flat organisational structure does not, in any way, solve for this problem. In fact, in some way it makes it worse, because it makes us *think* that we have solved for the systemic and hierarchical power dynamics that make it difficult for low-level or marginalised people to get things done, or people doing marginalised work to get things done, when we have only shifted them.
To pick on someone, I pick Trevor (sorry Trevor. For reference this is an entirely hypothetical example and Trevor is lovely): Trevor's voice is given a lot more weight in the organisation than mine. Trevor has a lot more influence than I do. Trevor has a lot more influence than most WMFers do!
Crucially: this *isn't because he's management*. This was the case even *before* he was management. Because:
- He's been here a really really long time and so knows everyone.
- He's an Engineer, and we give engineers more weight and cachet than
we do, say, administrative staff or people in "support" roles, even though those people are both as-smart and have an equal interest in the organisation's success; 3. His background matches what we strongly correlate with Authority Voices.
If we switch to a flat organisational structure where nobody has a title, or..whatever, all of these things will still be true. We will switch pronounce systemic biases or uneven power dynamics Done, and we will have achieved something that's actually worse than not doing anything at all. Because now, we still *have* all those problems, we just think we're done and don't have to put any work in and can't talk about it, and nobody has the responsibility for continuing to fix things.
The Foundation I would return to is not an organisation with a flat structure. In fact, it could be an organisation that looks a lot like this one, because I don't believe reporting lines or titles have as much of an impact on dynamics as we think they do. What *does* have an impact is how we recognise the value of emotional labour, how we recognise our implicit biases and advantages, and how honest we are with each other: not just in terms of what we *say* but in terms of how we *listen*. In other words, the litmus test for me is: what happens when the socially and politically weakest person in the organisation has an idea?
Anyway; I don't particularly want to go into a long drawn-out conversation, just correct the initial, fundamental misunderstanding. Hopefully I've provided a bit of food for thought along with that.
On Wed, Feb 24, 2016 at 3:50 AM, Pau Giner pginer@wikimedia.org wrote:
If I remember correctly, I think that's how the Content Translation
project
started -- it was someone's personal project, which got more people and attention because it's a great idea and showed real success.
That is not accurate. I think Content Translation is a good example of bottom-up and design-driven project, though.
The Language team identified that users frequently were asking for better support for translating Wikipedia articles, and decided to learn from existing translators (and their heavily manual efforts) without a predefined idea of how the solution would look like. After many
iterations
of design, prototyping and research the team started building the tool iteratively and driven by user behaviour (based on metrics and more user research). I wrote a more detailed piece about this some time ago if
anyone
is interested in more details: http://pauginer.com/post/116536135010/the-design-of-content-translation
So while this project didn't came from top-down roadmap, it was also not
a
solo "cowboy-style" personal project. I definitely think it followed a good pattern for more projects to
consider.
Pau
On Wed, Feb 24, 2016 at 4:40 AM, Andrew Lih andrew.lih@gmail.com
wrote:
On Tue, Feb 23, 2016 at 7:53 PM, Yuri Astrakhan <
yastrakhan@wikimedia.org>
wrote:
And that got me thinking. WMF, an organization that was built with the
open
and community-driven principles - why have we became the classic
example
of
a corporate multi-level hierarchy? Should we mimic a living organism
rather
than a human-built pyramid?
This may sound naive and wishful, but could we have a more flat and flexible team structure, where instead of having large teams with sub-teams, we would have small self-forming teams "by interest". For example, someone decides to dedicate their 20% to building support for storing 3D models in wiki.
So glad to see this being discussed in the open with smart folks like Brion, Dario, et al.
3D support would be most welcome – we’re in a holding pattern with Smithsonian 3D GLAM projects in DC because of that shortcoming in
Commons.
It was never known whether anyone was paying attention or going to put
3D
on the radar screen. (https://phabricator.wikimedia.org/T3790)
At my keynote talk at Wikiconference USA, I said one of the things WMF “must do” is multimedia and interactivity. Your work on the interactive graph is a great step. Brion, myself and others have been working on collaborative video. Brion’s ogv.js work is a great example of
skunkworks
type projects having a huge impact.
And if 3D is given a priority, the three areas would be a great
collective
step towards Wikipedia continuing its revolutionary work. Best of all,
they
would be technologies developed in service of content and community
needs,
and not simply created for tech’s sake.
An organism reacts to the change of its environment by redistributing
resources to the more problematic areas. Would small, flexible, and
more
focused teams achieve that better?
Yes, and in a recent meeting you mentioned Bell Labs as a model. As
someone
who worked there, it’s a very good ideal to shoot for.
https://www.mediawiki.org/wiki/Discovery/2016-02-16_Discussing_Knowledge_Eng...
Thanks for opening up this discussion. -Andrew _______________________________________________ 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
-- Pau Giner Senior User Experience Designer Wikimedia Foundation _______________________________________________ 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
On Wed, Feb 24, 2016 at 1:34 PM, Oliver Keyes ironholds@gmail.com wrote: ....
. What I was thinking about was how we pay attention to
organisational hiring, to how we promote, to how we treat people, what empathy we have and how we value empathy.
I have consistently found the Foundation to lag in all of these regards. It is not good at making sure that the recognition of employees is fair and treated equitably (be that who gets called out in presentations, who gets given opportunities, or who gets raises). It is not good at making sure that how we hire is fair. It is not good at making sure that concerns of employees are given weight. All too often the people marginalised by our approaches are the people marginalised outside the Foundation, as well; women, people in "non-technical" roles, people in roles that we code as "support work" (and guess what tends to correlate with a role being coded as support work?) All too often the work marginalised by our approaches is the work that Doesn't Product Code (again: guess who tends to do the heavy lifting on things like organisational health and process and structure?)
This is an important thing to say and an important lens to look at the organization through; thank you for saying it, and thank you for being specific.
How can an organization turn itself around? Many of you know I changed jobs last year, to be at MIT Libraries. There's a lot of good things about this, but one good thing is that the head of the library is remarkable, and thinks a lot about how to make equity and diversity an actionable part of our daily work.
One of the first things she did was to add a section to our performance review forms (which also include sections for goals, etc) to include a section called: "Demonstration of organizational values of diversity and inclusivity– Note participation in formal and informal activities and demonstrated behaviors that enhance these values (past year, ongoing and planned)."
She also added a similar category to our staff awards process. She invited two line staff on a semi-annual rotation to join the leadership group (our equivalent of the C-levels). Then she did the same thing for a big formal strategy process. Then we sponsored an outside organization that supports underrepresented librarians. Now, because she's set a tone, rhetoric in meetings and among all levels of staff is similar.
None of this is perfect or earthshaking, and I suspect there are a lot of ideas yet to come. But what she's taught me, in the few months that I've been here, is that an organization can address systemic and societal problems through concrete actions without a lot of drama.
In other words, the litmus test for me is: what
happens when the socially and politically weakest person in the organisation has an idea?
A question that we sometimes talk about for the community, too (and is sometimes framed as what ways can a person develop a positive reputation sufficient enough to make a change); not unrelated to the question of how we treat smaller projects too.
best, Phoebe
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.
Hey Yuri,
[Responding offlist because I'm linking to officewiki]
Le jeudi 25 février 2016, 01:38:31 Yuri Astrakhan a écrit :
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?
One possible mechanism is the Business case: https://office.wikimedia.org/wiki/Business_case
And also from https://office.wikimedia.org/wiki/Rebuilding#Agency : "If we want to start a new project or make a big change, we can make a case for it and argue its merits to the group."
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
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
Guillaume, the idea may come from anywhere, shouldn't we post the process on meta? Or is this WMF specific, e.g. "I want my favorite cereal in the cafeteria" proposal? :)
Hello,
Le jeudi 25 février 2016, 02:06:38 Yuri Astrakhan a écrit :
Guillaume, the idea may come from anywhere, shouldn't we post the process on meta? Or is this WMF specific, e.g. "I want my favorite cereal in the cafeteria" proposal? :)
This is what I wrote in the introduction of the Business case page:
----------------------------------------- A business case is a document that provides the rationale for making a change or starting a project. It defines an observed problem and argues the merits of a proposed solution.
A case may be created for a small change ("Every WMF employee must wear green clothes on the third Friday of the month") or a large project ("The WMF should create a freely-licensed YouTube"). They provide a useful framework for organizing one's thinking and convincing others. -----------------------------------------
Putting the Business case documents on the private staff wiki was the first step in my effort to rescue the process from the walled Google Docs abyss, where the documents got lost after senior staff (who initiated the process) left the WMF. I like the framework and was hoping to make it used more widely at the Foundation over time.
I agree that Meta-Wiki would be a better place in principle. I am slightly worried that moving the process there might lead some employees to revert to Google Docs for their ideas and drafts*, whereas they could be convinced to use the process if it was on the staff wiki (which would still be an improvement).
On the other hand, if the upside is that the tool is useful to, and used by, volunteers, that may be a good enough reason to move the pages to Meta. It could set an example for staff to follow. I'm happy to move the pages if people think it's a good idea.
[*] I refuse to use the word "ideation".
On Thu, Feb 25, 2016 at 11:04 PM, Guillaume Paumier gpaumier@wikimedia.org wrote:
Putting the Business case documents on the private staff wiki was the first step in my effort to rescue the process from the walled Google Docs abyss, where the documents got lost after senior staff (who initiated the process) left the WMF. I like the framework and was hoping to make it used more widely at the Foundation over time.
I also like that framework. At least for software projects, it could be plugged in the Product development process, see https://www.mediawiki.org/wiki/WMF_product_development_process#Plan & https://phabricator.wikimedia.org/T125809
Also related with this and other discussions held these days in this list:
Proposal: any WMF software project willing to be prioritized requires a concept publicly available https://phabricator.wikimedia.org/T118231
and its counterpart
Define good practices to start working on project concepts privately https://phabricator.wikimedia.org/T123611
Thanks for this email, Oliver, it's fantastic! Since I'm one of the people who says 'flat' and 'flatter' a lot, I feel compelled to respond, though I run the risk of painting an already-perfect lily.
One of the first essays we read in the Flat Org group was 'The Tyranny of Structurelessness'[1] which makes a similar point to Oliver's, and I think it's one that everyone is wise to remember. The question that I seek an answer to is not "How can we smash hierarchy?" It is, rather, "How can an institution be less reliant on the competence and benevolence of a small number of people, and less vulnerable to malice or incompetence on the part of a small number of people?" In my experience, traditional top-down management systems are highly vulnerable because they're great at magnifying whims and mistakes.
I'm pretty sure that it's possible to have structure without having a rigid power-based hierarchy. To some extent, that's what democracy is, or at least what it seeks to be. It's definitely what Wikipedia seeks to be. I hope that someday the WMF joins Wikipedia and the other projects in their weird adventure of anarchist/collectivist/self-organizing weirdness. Not because I want the Foundation to be governed more like Wikipedia, but because I want Wikipedia _and_ the Foundation to be governed better, and I think there are lessons we can learn together.
-Andrew (Top-posting to prevent scroll-wheel-related RSI)
[1] http://www.jofreeman.com/joreen/tyranny.htm
On 2/24/16 12:34 PM, Oliver Keyes wrote:
I would like to clarify a fairly major premise of this conversation: namely, the comment I made that Yuri quoted in the very first message.
When I say that the hierarchical organisation of the Foundation is something that is preventing us from doing better, I was not thinking of how we develop software. Indeed, I suspect that peoples' tendency to bring things constantly back to "does it improve the measurable speed at which we right code" is symptomatic of the problematic dynamics here. What I was thinking about was how we pay attention to organisational hiring, to how we promote, to how we treat people, what empathy we have and how we value empathy.
I have consistently found the Foundation to lag in all of these regards. It is not good at making sure that the recognition of employees is fair and treated equitably (be that who gets called out in presentations, who gets given opportunities, or who gets raises). It is not good at making sure that how we hire is fair. It is not good at making sure that concerns of employees are given weight. All too often the people marginalised by our approaches are the people marginalised outside the Foundation, as well; women, people in "non-technical" roles, people in roles that we code as "support work" (and guess what tends to correlate with a role being coded as support work?) All too often the work marginalised by our approaches is the work that Doesn't Product Code (again: guess who tends to do the heavy lifting on things like organisational health and process and structure?)
As an organisation I have found the Foundation overly rigid and resistant to the most conservative change around these problems; particularly I think of efforts to improve unintentional bias in our job descriptions. Basically, unless you as an employee go out and do the damn work yourself, for free, with 0 recognition of the emotional and temporal cost of that work, it doesn't get done. The organisation as a whole is not interested.
Switching to a flat organisational structure does not, in any way, solve for this problem. In fact, in some way it makes it worse, because it makes us *think* that we have solved for the systemic and hierarchical power dynamics that make it difficult for low-level or marginalised people to get things done, or people doing marginalised work to get things done, when we have only shifted them.
To pick on someone, I pick Trevor (sorry Trevor. For reference this is an entirely hypothetical example and Trevor is lovely): Trevor's voice is given a lot more weight in the organisation than mine. Trevor has a lot more influence than I do. Trevor has a lot more influence than most WMFers do!
Crucially: this *isn't because he's management*. This was the case even *before* he was management. Because:
- He's been here a really really long time and so knows everyone.
- He's an Engineer, and we give engineers more weight and cachet than
we do, say, administrative staff or people in "support" roles, even though those people are both as-smart and have an equal interest in the organisation's success; 3. His background matches what we strongly correlate with Authority Voices.
If we switch to a flat organisational structure where nobody has a title, or..whatever, all of these things will still be true. We will switch pronounce systemic biases or uneven power dynamics Done, and we will have achieved something that's actually worse than not doing anything at all. Because now, we still *have* all those problems, we just think we're done and don't have to put any work in and can't talk about it, and nobody has the responsibility for continuing to fix things.
The Foundation I would return to is not an organisation with a flat structure. In fact, it could be an organisation that looks a lot like this one, because I don't believe reporting lines or titles have as much of an impact on dynamics as we think they do. What *does* have an impact is how we recognise the value of emotional labour, how we recognise our implicit biases and advantages, and how honest we are with each other: not just in terms of what we *say* but in terms of how we *listen*. In other words, the litmus test for me is: what happens when the socially and politically weakest person in the organisation has an idea?
Anyway; I don't particularly want to go into a long drawn-out conversation, just correct the initial, fundamental misunderstanding. Hopefully I've provided a bit of food for thought along with that.
On Wed, Feb 24, 2016 at 3:50 AM, Pau Giner pginer@wikimedia.org wrote:
If I remember correctly, I think that's how the Content Translation project started -- it was someone's personal project, which got more people and attention because it's a great idea and showed real success.
That is not accurate. I think Content Translation is a good example of bottom-up and design-driven project, though.
The Language team identified that users frequently were asking for better support for translating Wikipedia articles, and decided to learn from existing translators (and their heavily manual efforts) without a predefined idea of how the solution would look like. After many iterations of design, prototyping and research the team started building the tool iteratively and driven by user behaviour (based on metrics and more user research). I wrote a more detailed piece about this some time ago if anyone is interested in more details: http://pauginer.com/post/116536135010/the-design-of-content-translation
So while this project didn't came from top-down roadmap, it was also not a solo "cowboy-style" personal project. I definitely think it followed a good pattern for more projects to consider.
Pau
On Wed, Feb 24, 2016 at 4:40 AM, Andrew Lih andrew.lih@gmail.com wrote:
On Tue, Feb 23, 2016 at 7:53 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
And that got me thinking. WMF, an organization that was built with the
open
and community-driven principles - why have we became the classic example
of
a corporate multi-level hierarchy? Should we mimic a living organism
rather
than a human-built pyramid?
This may sound naive and wishful, but could we have a more flat and flexible team structure, where instead of having large teams with sub-teams, we would have small self-forming teams "by interest". For example, someone decides to dedicate their 20% to building support for storing 3D models in wiki.
So glad to see this being discussed in the open with smart folks like Brion, Dario, et al.
3D support would be most welcome – we’re in a holding pattern with Smithsonian 3D GLAM projects in DC because of that shortcoming in Commons. It was never known whether anyone was paying attention or going to put 3D on the radar screen. (https://phabricator.wikimedia.org/T3790)
At my keynote talk at Wikiconference USA, I said one of the things WMF “must do” is multimedia and interactivity. Your work on the interactive graph is a great step. Brion, myself and others have been working on collaborative video. Brion’s ogv.js work is a great example of skunkworks type projects having a huge impact.
And if 3D is given a priority, the three areas would be a great collective step towards Wikipedia continuing its revolutionary work. Best of all, they would be technologies developed in service of content and community needs, and not simply created for tech’s sake.
An organism reacts to the change of its environment by redistributing
resources to the more problematic areas. Would small, flexible, and more focused teams achieve that better?
Yes, and in a recent meeting you mentioned Bell Labs as a model. As someone who worked there, it’s a very good ideal to shoot for.
https://www.mediawiki.org/wiki/Discovery/2016-02-16_Discussing_Knowledge_Eng...
Thanks for opening up this discussion. -Andrew _______________________________________________ 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
-- Pau Giner Senior User Experience Designer Wikimedia Foundation _______________________________________________ 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
Now, I agree with Oliver's points but I disagree they apply to the entire organization, and I have proof. I also objectively think there's much more reason for optimism than pessimism. I'm open to being proven wrong or told that I have an Authority Voice and I just don't understand, I really am, I think if someone like me who's thought about this extensively doesn't get it we have a real problem and my optimism should check its privilege.
*how we treat people, **what empathy we have, and* *how we value empathy*. Disclosure: I was treated very poorly in my past work life. I was forced to work an average of 70 hours per week for 32 months, without overtime for most of it, and was denied any vacation during that time (a superior punched me in the chest at one particular low point). In a different situation I had to organize a strike to obtain overtime payment for my 30+ hours and my friend's 50+ hours of *continuous* work with *no sleep*. My point is, when I got this opportunity to work at WMF, I was extremely clear that I was looking for a place where I was treated decently. My first few months here were rocky, I got unknowingly tangled up in some political struggles. But over time, I'm really proud of what my team has accomplished and the fun, empathetic, distributed, and fair way we run things. We take turns presenting at quarterly reviews, try to achieve consensus, consider each others' welfare, it's really great. So I'm trying to say that we're proof it's possible to have this kind of environment at WMF. I admit I've never thought about this beyond the now comfortable walls of my team, but I am really deeply sad now that I have poked my head outside. The fact that so many people I feel really close to are leaving... it just feels like a big opportunity lost. We could have made this place amazing to work at, together. Instead we seem to be conquered individually by enemies that some of us have defeated.
how we pay attention to *organisational hiring*. We're bad at this. We get lucky sometimes, and sometimes we get lucky to hire *amazing* people like Nuria who really know what they're doing and help us hire well. So we need to get better, and we do that by paying really close attention to those who obviously know better.
*how we promote*. I'm against promotions personally, I don't want or need the recognition, power, or change in work type. But some people do, and I don't for the *life* of me understand why this is such a taboo touchy scary topic full of drama and elevated emotion. My 2c: if you want a promotion - make a case for it. Say, I've been here for this and this time, I feel like I add this and this value, if I was promoted, I feel like this would align better with my opinion of myself and the value I provide while also benefiting the organization in such and such way. You'll get public support if the argument makes sense, and you'll get private hopefully sensitive messages if not. And, if you get something else, like intimidation, pain, reprimand, etc. then I *personally* have your back. And I'll call on the many friends I have that share my feelings on this. There's a way to be appropriate, transparent, and fair here. And a way to drown out biased voices through the wisdom of our especially wise crowd. Use that, don't fight your battles in silence and complain about the results of problems that the rest of us don't even have a chance to help with.
Full disclosure, Oliver, I spoke up on your behalf several times, and I thought you received fairer treatment as a result, but I now consider myself an idiot because we should have had this conversation in the open. It's sad to lose you, but I'm very happy for you and your next adventures, and thankful for this last gift you give us, the opportunity to have this conversation.
On Wed, Feb 24, 2016 at 3:27 PM, Andrew Bogott abogott@wikimedia.org wrote:
Thanks for this email, Oliver, it's fantastic! Since I'm one of the people who says 'flat' and 'flatter' a lot, I feel compelled to respond, though I run the risk of painting an already-perfect lily.
One of the first essays we read in the Flat Org group was 'The Tyranny of Structurelessness'[1] which makes a similar point to Oliver's, and I think it's one that everyone is wise to remember. The question that I seek an answer to is not "How can we smash hierarchy?" It is, rather, "How can an institution be less reliant on the competence and benevolence of a small number of people, and less vulnerable to malice or incompetence on the part of a small number of people?" In my experience, traditional top-down management systems are highly vulnerable because they're great at magnifying whims and mistakes.
I'm pretty sure that it's possible to have structure without having a rigid power-based hierarchy. To some extent, that's what democracy is, or at least what it seeks to be. It's definitely what Wikipedia seeks to be. I hope that someday the WMF joins Wikipedia and the other projects in their weird adventure of anarchist/collectivist/self-organizing weirdness. Not because I want the Foundation to be governed more like Wikipedia, but because I want Wikipedia _and_ the Foundation to be governed better, and I think there are lessons we can learn together.
-Andrew (Top-posting to prevent scroll-wheel-related RSI)
[1] http://www.jofreeman.com/joreen/tyranny.htm
On 2/24/16 12:34 PM, Oliver Keyes wrote:
I would like to clarify a fairly major premise of this conversation: namely, the comment I made that Yuri quoted in the very first message.
When I say that the hierarchical organisation of the Foundation is something that is preventing us from doing better, I was not thinking of how we develop software. Indeed, I suspect that peoples' tendency to bring things constantly back to "does it improve the measurable speed at which we right code" is symptomatic of the problematic dynamics here. What I was thinking about was how we pay attention to organisational hiring, to how we promote, to how we treat people, what empathy we have and how we value empathy.
I have consistently found the Foundation to lag in all of these regards. It is not good at making sure that the recognition of employees is fair and treated equitably (be that who gets called out in presentations, who gets given opportunities, or who gets raises). It is not good at making sure that how we hire is fair. It is not good at making sure that concerns of employees are given weight. All too often the people marginalised by our approaches are the people marginalised outside the Foundation, as well; women, people in "non-technical" roles, people in roles that we code as "support work" (and guess what tends to correlate with a role being coded as support work?) All too often the work marginalised by our approaches is the work that Doesn't Product Code (again: guess who tends to do the heavy lifting on things like organisational health and process and structure?)
As an organisation I have found the Foundation overly rigid and resistant to the most conservative change around these problems; particularly I think of efforts to improve unintentional bias in our job descriptions. Basically, unless you as an employee go out and do the damn work yourself, for free, with 0 recognition of the emotional and temporal cost of that work, it doesn't get done. The organisation as a whole is not interested.
Switching to a flat organisational structure does not, in any way, solve for this problem. In fact, in some way it makes it worse, because it makes us *think* that we have solved for the systemic and hierarchical power dynamics that make it difficult for low-level or marginalised people to get things done, or people doing marginalised work to get things done, when we have only shifted them.
To pick on someone, I pick Trevor (sorry Trevor. For reference this is an entirely hypothetical example and Trevor is lovely): Trevor's voice is given a lot more weight in the organisation than mine. Trevor has a lot more influence than I do. Trevor has a lot more influence than most WMFers do!
Crucially: this *isn't because he's management*. This was the case even *before* he was management. Because:
- He's been here a really really long time and so knows everyone.
- He's an Engineer, and we give engineers more weight and cachet than
we do, say, administrative staff or people in "support" roles, even though those people are both as-smart and have an equal interest in the organisation's success; 3. His background matches what we strongly correlate with Authority Voices.
If we switch to a flat organisational structure where nobody has a title, or..whatever, all of these things will still be true. We will switch pronounce systemic biases or uneven power dynamics Done, and we will have achieved something that's actually worse than not doing anything at all. Because now, we still *have* all those problems, we just think we're done and don't have to put any work in and can't talk about it, and nobody has the responsibility for continuing to fix things.
The Foundation I would return to is not an organisation with a flat structure. In fact, it could be an organisation that looks a lot like this one, because I don't believe reporting lines or titles have as much of an impact on dynamics as we think they do. What *does* have an impact is how we recognise the value of emotional labour, how we recognise our implicit biases and advantages, and how honest we are with each other: not just in terms of what we *say* but in terms of how we *listen*. In other words, the litmus test for me is: what happens when the socially and politically weakest person in the organisation has an idea?
Anyway; I don't particularly want to go into a long drawn-out conversation, just correct the initial, fundamental misunderstanding. Hopefully I've provided a bit of food for thought along with that.
On Wed, Feb 24, 2016 at 3:50 AM, Pau Giner pginer@wikimedia.org wrote:
If I remember correctly, I think that's how the Content Translation
project started -- it was someone's personal project, which got more people and attention because it's a great idea and showed real success.
That is not accurate. I think Content Translation is a good example of bottom-up and design-driven project, though.
The Language team identified that users frequently were asking for better support for translating Wikipedia articles, and decided to learn from existing translators (and their heavily manual efforts) without a predefined idea of how the solution would look like. After many iterations of design, prototyping and research the team started building the tool iteratively and driven by user behaviour (based on metrics and more user research). I wrote a more detailed piece about this some time ago if anyone is interested in more details: http://pauginer.com/post/116536135010/the-design-of-content-translation
So while this project didn't came from top-down roadmap, it was also not a solo "cowboy-style" personal project. I definitely think it followed a good pattern for more projects to consider.
Pau
On Wed, Feb 24, 2016 at 4:40 AM, Andrew Lih andrew.lih@gmail.com wrote:
On Tue, Feb 23, 2016 at 7:53 PM, Yuri Astrakhan <
yastrakhan@wikimedia.org> wrote:
And that got me thinking. WMF, an organization that was built with the
open
and community-driven principles - why have we became the classic example
of
a corporate multi-level hierarchy? Should we mimic a living organism
rather
than a human-built pyramid?
This may sound naive and wishful, but could we have a more flat and flexible team structure, where instead of having large teams with sub-teams, we would have small self-forming teams "by interest". For example, someone decides to dedicate their 20% to building support for storing 3D models in wiki.
So glad to see this being discussed in the open with smart folks like Brion, Dario, et al.
3D support would be most welcome – we’re in a holding pattern with Smithsonian 3D GLAM projects in DC because of that shortcoming in Commons. It was never known whether anyone was paying attention or going to put 3D on the radar screen. (https://phabricator.wikimedia.org/T3790)
At my keynote talk at Wikiconference USA, I said one of the things WMF “must do” is multimedia and interactivity. Your work on the interactive graph is a great step. Brion, myself and others have been working on collaborative video. Brion’s ogv.js work is a great example of skunkworks type projects having a huge impact.
And if 3D is given a priority, the three areas would be a great collective step towards Wikipedia continuing its revolutionary work. Best of all, they would be technologies developed in service of content and community needs, and not simply created for tech’s sake.
An organism reacts to the change of its environment by redistributing
resources to the more problematic areas. Would small, flexible, and more focused teams achieve that better?
Yes, and in a recent meeting you mentioned Bell Labs as a model. As
someone who worked there, it’s a very good ideal to shoot for.
https://www.mediawiki.org/wiki/Discovery/2016-02-16_Discussing_Knowledge_Eng...
Thanks for opening up this discussion. -Andrew _______________________________________________ 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
-- Pau Giner Senior User Experience Designer Wikimedia Foundation _______________________________________________ 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
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@lists.wikimedia.org