On Wed, Nov 7, 2012 at 2:16 PM, Platonides Platonides@gmail.com wrote:
You can see several teams in that page, with members from multiple "sections". Which leads to the (naive?) question on what's the purpose of being splitted in those sections if then the work is done in teams with a completely different organization.
The purpose of functional groupings is to ensure that there is coordination and communication among people who share a function (e.g. all designers), and that they have management support, ideally from someone who understands their function and purpose in the organization, and is able to help them grow in their career and as an individual contributor. It creates escalation points in case of conflicts, and can help to remove blockers.
The purpose of team groupings is to ensure that a team is assembled cross-functionally, from all the required skills, and fully focused on delivering its objectives.
The two organizational models are complementary; the singular focus on one or the other tends to lead to silos. Achieving a healthy balance between intra-functional team development and growth and cross-functional delivery is one of the key challenges of management.
Erik
Picking up this thread as Erik asked me to explain the different functions that fall under "Product". To do that, it's worth describing in a bit more detail how our project teams work.
This may be a bit reductive (apologies in advance), but there are a basic set of things that need to happen when building a product. These things happen regardless of what the product actually is (e.g., t-shirts count):
1. Decide what to build 2. Design it 3. Build it 4. Measure how it's used (if you want to improve the product)
Roughly speaking, that's how we organize our teams when it comes to building features. Product Managers decide what features to build, Designers design the feature, Developers build the feature, and Analysts measure how the features perform. (features = things on our websites or mobile that readers or editors would use).
Let's take PageCuration as an example of a feature that WMF developed. In this case, the feature development team consisted of a Product Manager, Designers, Developers, and Analysts, all working together. Here's how the various roles worked:
1. Product Manager [1]: Represents the user's point of view. Works with the rest of the team to identify and solve a user problem. For example, we knew that the backlog for Special:NewPages on the English Wikipedia was consistently too large and that existing page patrollers felt overworked. To solve the problem, we needed to make page patrolling more efficient [2]. Product Manager worked with the rest of the team to develop potential solutions to this problem. The outcome of this was the decision to build two separate features for the end user (i.e., page patrollers): Special:NewPagesFeed [3] (redesign of Special:NewPages) and the Curation Toolbar.
The Product Manager worked with the rest of the WMF and volunteers in the community to identify specific features by asking question such as "If we were to redesign Special:NewPages, what kind of information would page patrollers want to see that would make their jobs more efficient. Out of this inquiry came ideas like surfacing the # of categories, # of citations, whether an article is an orphan, a snippet of the content, etc. as these pieces of information would help the patroller determine which articles warranted attention. Fabrice Florin was the Product Manager.
We also have a Community Liaison (Oliver Keyes) who is responsible for reaching out to the editor community to make sure the feature we're building actually meets the needs of our editors. The Community Liaison creates the space where community members can give input into the feature by holding IRC chats, on-wiki discussions, reaching out to editors, etc.
2. Designer: The designer then takes this input and designs the user interface for Special:NewPagesFeed. Part of this is Interaction Design [4] e.g., how are the elements of the page laid out so that page patrollers can easily parse the information? How does a page patroller actually accomplish the task of selecting an article to review (e.g., should there be a "Review" button associated with each article, or should the article link be sufficient?). Does this action open up a separate tab? How should filtering of this list work? Etc.
There's also Visual Design: How do we use color to help identify the different states of an article? How can icons be used to reduce the cognitive load associated with parsing information? How can we create a look & feel that's visually engaging?
Brandon Harris and Vibha Bamba were the designers for Page Curation.
3. Developer: The developers then take these functional and design ideas and code the feature. On this project, the developers were Ryan Kaldari and Benny Situ.
4. Analyst: The data analyst works with the developers to determine what types of stats would give the team a handle on whether/how the feature is being used. For example, here is the dashboard that Dario Taraborelli: http://toolserver.org/~dartar/pc/
These roles aren't rigidly defined. For example, ideas for features can come from anywhere, not just the Product Manager. In my view, a well-functioning team is one where everyone is engaged in coming up with ideas. But there should be someone responsible for ensuring that the various ideas come together into a coherent whole, ones that addresses the problem at hand. That responsibility lies with the Product Manager.
Also, Product Managers and Designers don't spec out stuff which they then hand over to developers to build. Teams work collaboratively to come up with solutions.
That's how our project teams are structured. When it comes to the proposed organizational structure, "Product" consists of Product Managers, Designers, and Analysts (1, 2 and 4) and "Engineering" consists engineers across the different areas Terry describes. One way to view it is that "Product" involves everything outside of writing code for a feature and developers in "Engineering" write the code. It's oversimplification (e.g., analysts write code for analytics work, designers may prototype), but I think it's directionally useful.
The individuals in Product and Engineering are then matrixed into project teams like the one described above for Page Curation so project team structure != organizational structure.
Howie
[1] http://www.quora.com/How-can-I-learn-to-be-a-good-Product-Manager [2] This is a slight oversimplification [3] https://en.wikipedia.org/wiki/Special:NewPagesFeed [4] http://en.wikipedia.org/wiki/Interaction_design
On Wed, Nov 7, 2012 at 2:49 PM, Erik Moeller erik@wikimedia.org wrote:
On Wed, Nov 7, 2012 at 2:16 PM, Platonides Platonides@gmail.com wrote:
You can see several teams in that page, with members from multiple "sections". Which leads to the (naive?) question on what's the purpose of being splitted in those sections if then the work is done in teams with a completely different organization.
The purpose of functional groupings is to ensure that there is coordination and communication among people who share a function (e.g. all designers), and that they have management support, ideally from someone who understands their function and purpose in the organization, and is able to help them grow in their career and as an individual contributor. It creates escalation points in case of conflicts, and can help to remove blockers.
The purpose of team groupings is to ensure that a team is assembled cross-functionally, from all the required skills, and fully focused on delivering its objectives.
The two organizational models are complementary; the singular focus on one or the other tends to lead to silos. Achieving a healthy balance between intra-functional team development and growth and cross-functional delivery is one of the key challenges of management.
Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Hey folks,
I think all the conversation about this is really helpful, and it's been particularly useful thus far to hear from community members about what's confusing about the current and proposed structures. ("Not being confusing" isn't the primary motivation for a restructure, but it's obviously worth consideration.)
I do want to underline though, from Erik's original note, this: "To avoid fear and anxiety, and to make sure the plan makes sense, I want to start an open conversation now. If you think any of the below is a terrible idea, or have suggestions on how to improve the plan, I’d love to hear from you," and "I look forward to hearing your thoughts & discussing this further in coming weeks."
I kind of have the sense that people are considering this a done deal. I understand why people might assume that -- in an ordinary organization, a note like Erik's doesn't go out until things are pretty much locked down. But it's important that you realize that's not what's happening here: your input is wanted. Particularly for staff who'd be directly affected by these changes --- this is your window to shape what happens. If you think there are likely to be downstream effects of these proposed changes that are worth considering, or additional improvements that could be folded into this, or an aspect that warrants being revisited: this is your window. You can talk with Erik (by e-mail because he's travelling), me, Gayle, or whoever else seems relevant. That was the whole point of Erik's note :-)
So to be super-clear: None of this is a done deal at this moment. Lots of conversations are happening in various places, and it's all good. That's why Erik made the pre-announcement --- to create a window for discussion & iteration and further thinking :-)
Thanks, Sue
-- Sue Gardner Executive Director Wikimedia Foundation
415 839 6885 office 415 816 9967 cell
Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us make it a reality!
Sue Gardner, 08/11/2012 07:03:
I kind of have the sense that people are considering this a done
deal. [...]
So to be super-clear: None of this is a done deal at this moment. Lots of conversations are happening in various places, and it's all good. That's why Erik made the pre-announcement --- to create a window for discussion & iteration and further thinking :-)
Thank you for clarifying this. Another thing I found confusing in Terry's email is that he called it a "decision" (another terminology inconsistency problem? ;-) ).
Howie Fung, 08/11/2012 05:53:
[...] That's how our project teams are structured. When it comes to the proposed organizational structure, "Product" consists of Product Managers, Designers, and Analysts (1, 2 and 4) and "Engineering" consists engineers across the different areas Terry describes. One way to view it is that "Product" involves everything outside of writing code for a feature and developers in "Engineering" write the code. It's oversimplification (e.g., analysts write code for analytics work, designers may prototype), but I think it's directionally useful.
The individuals in Product and Engineering are then matrixed into project teams like the one described above for Page Curation so project team structure != organizational structure.
Thank you for this short explanation and its long (useful) premise. It would seem that the tentative answer to my question, pending more insight from Erik when he has time, is "more scattered rather than less".
A thing your answer doesn't cover is that not only «project team structure != organizational structure» (with Erik's words, «functional groupings» != «team groupings»), but also (it seems) "project team structure != team structure", i.e. not all teams are the same. By browsing the wonderful https://www.mediawiki.org/wiki/Category:WMF_Projects , one can see that each project has different ad-hoc teams (specified in the infobox), but some teams are more consistent/frequent than others, with the tightest groupings being the permanent teams mentioned also on the staff page, who mostly move together from one project to another. On the opposite side of the spectrum we have "electrons" who are not in any team (and don't have any "day-to-day management"?) but move across many projects ("serving" many teams). It would seem to me that you can't treat everything in the same way?
Steven Walling, 07/11/2012 23:46:
On Wed, Nov 7, 2012 at 2:16 PM, Platonides Platonides@gmail.com wrote:
Thanks for your explanation but personally I'm more confused than
before
about the difference between Engineering and Product, also because the terminology didn't appear internally consistent. :-)
I feel like you, Nemo. I am glad by Terry explanation, but as I went on reading it, the less I felt I understood it. It would benefit from a more layman explanation. Maybe it's just complex to everybody.
Simplest possible explanation of what Erik is proposing: we need to
split a
large department in to two, and add more managers. It's too big ad too critical for one person to manage.
This is very clear and it's not hard to see that it's needed, but it doesn't actually explain the need for a split. If, for instance, one "only" needs to make more equal «functional groupings» so that "each C-level has to sign an equal amount of holiday permissions"[1], instead of inventing boundaries between "Engineering" and "Product" or other names for almost-fake separations, one could as well just keep the two together, call it an "area" or "super-department" with its VP[2] and then Chief 1 and Chief 2 under it... or whatever. But the further explanations will help us understand what are the aims and how it's expected to achieve them.
Nemo
[1] Simplifying at most; fake example with probably wrong terminology even. [2] Speaking of terminology bikeshedding, I never understood that "VP of Engineering and Product Development" were actually /two/ VP roles. Previous discussion: http://thread.gmane.org/gmane.org.wikimedia.foundation/59115/focus=59147
wikimedia-l@lists.wikimedia.org