Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-21 Thread Quim Gil

Thanks Erik for the extensive response.

Ultimately what counts is ongoing progress. If the model proposed is an 
improvement from the current, solving specific problems we currently 
have, then fine and I'm all or it.


I'm still stuck in one point:

On 11/19/2012 07:54 PM, Erik Moeller wrote:

3) Why not have an even flatter structure?

My prediction with a structure like the one you propose would be the following:

If you increase the number of direct engineering-related reports to
Sue from 1 to 5, her ability to meet and seriously interact with any
one of them will drop to close to zero, with no time for goal-setting
conversations, career pathing, or serious conflict resolution.


One could ask why so many things need to be reported to or pass through 
a single person? This is the factor defining the angle of verticality of 
an organization.


Why not having more decentralized reporting (broadcasting), 
goal-setting, career path, or serious conflict resolution?


Why not betting on a more brave contemporary model being a non-profit 
foundation, with hundred-something employees, an open source culture, an 
Internet culture, a wiki culture, a remote work culture, a contributors 
culture, an online community culture, a San Francisco Bay tech startup 
inspiration?


I understand what you are explaining about the board being the first 
body defining this kind of game. As for today the board is an entity too 
unilateral and abstract for me, but I'm willing to help bringing this 
type of message to them if these opinions are shared by others.


BUT

Well, at least your proposal doesn't go against this scenario. Perhaps 
is one step in that direction. Good enough here and now, I guess. Thank 
you for trying!  And for opening this discussion. Just please consider 
further steps flattening and decentralizing the WMF.


There is a blog post  video circulating these days, about how GitHub 
Inc is organized as a company. They also manage a version control system 
promoting decentralized collaboration, plus other tools supporting this 
core goal and the big community around it. They are also 
hundred-something. They have also offices in San Francisco. They are 
also a young organization growing fast. Etc.


The video is interesting and entertaining. The slides are simple and 
fun. I'm not a person for watching 40min YouTube videos, even less about 
HR  business management topics - but this one was very interesting to 
watch. Even if only as a documentary of how certain company running 
certain product I like happens to work:


Your team should work like an open source project
http://tomayko.com/writings/adopt-an-open-source-process-constraints
http://youtu.be/mrONxcyQo4E

--
Quim

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-21 Thread Erik Moeller
On Wed, Nov 21, 2012 at 6:02 PM, Quim Gil q...@wikimedia.org wrote:
 There is a blog post  video circulating these days, about how GitHub Inc is
 organized as a company. They also manage a version control system promoting
 decentralized collaboration, plus other tools supporting this core goal and
 the big community around it. They are also hundred-something. They have also
 offices in San Francisco. They are also a young organization growing fast.
 Etc.

Yeah, I'm familiar with it. There's also a similarly interesting
description of the organizational culture at Valve (makers of
Half-Life, Portal, etc.) in the form of their employee handbook:

http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf

I like a lot about the picture these presentations and documents
paint, and I think there's a ton we can learn from them. There are of
course also crucial differences between Wikimedia and a Git hosting
company or a game developer, and less obvious ways that power is
exercised in both organizations (e.g. the role of the founders).

 Well, at least your proposal doesn't go against this scenario. Perhaps is one 
 step in that direction.

[Fair warning, below is really starting to drift away from being
on-topic for wikitech-l and going into general OD stuff.]

I believe so. I do think we should have bigger conversations about
what kind of organization we want to be, and what tradeoffs we'd need
to accept if we wanted to move away from what's stilll in many ways a
fairly hierarchical model. Like I said, I don't think you can make
major structural changes in isolation, or you'll just end up with
mismatched expectations and broken hearts. ;-)

I do think flat structures are pretty enticing, though. I encourage
you (and anyone) to look a bit more into the way things currently work
if you want to help be part of continued evolutionary change. I've had
conversations with Sue about this and she's pretty open to supporting
well-justified structural changes (hence this discussion). The Board,
too, is generally open-minded and responsive.

An example where I think change is badly needed is the Annual Planning
process. There are few aspects of WMF that follow as conventional a
hierarchical model as this one. You see the output: a 71 page document
[1] describing the organization's planned financials, key activities
and targets, etc. To get to that point, we went through a multi-month
process driven primarily by managers, sending drafts and submissions
up and down and up the organizational ladder, with final review by Sue
and ultimate approval by the Board. This was followed by the Narrowing
Focus resolution, the Narrowing Focus process (with again lots of
leadership involvement), the Narrowing Focus document and its
approval, the Wikimedia Foundation FDC submission and its approval,
etc.

That's a lot of time spent on meta-level work. I'm not arguing it's
time and effort wasted, but I do think there's a lot of room for
streamlining and consolidating processes. I also think it's predicated
on the assumption that creating a more comprehensive plan will lead to
a better outcome, and I would challenge that belief -- there's a
threshold at which point the opposite is true, and I think in a lot of
our work that threshold is very low because the unknowns are pretty
large and new ideas and opportunities may emerge all the time.

Moreover, to get back to the point you were making, I think this is
the kind of thing that creates a lot of dependency on conventional
management approaches -- time that could be spent, by those same
people, on doing the actual work the plan talks about, while creating
a less rigid harness for the organization as a whole, in turn allowing
for structures to be simplified and enabling greater autonomy across
the board.

So, I'm not arguing against deeper structural changes -- just for
change that's harmoniously managed in concert with the various other
factors at play.

Cheers,
Erik

[1] 
https://upload.wikimedia.org/wikipedia/foundation/4/4f/2012-13_Wikimedia_Foundation_Plan_FINAL_FOR_WEBSITE.pdf

-- 
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


Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-10 Thread Sue Gardner
Quim, thanks for writing that. I am happy about the conversations that are
happening about this, and I'm finding people's thoughts and input useful.
There have been (and are being) lots of face-to-face conversations as well
as the ones on the lists and in other venues: it's all good.

There is of course no perfect ideal solution --it's a balancing-act among
multiple considerations-- and there is zero likelihood that we'll come up
with a result that is understandable for everyone, and fits their ideal
version of how the org should work. That's okay: we don't need to be
perfect (and there is no perfect) --- we just need to be always
evolving-towards-better, as the org grows and changes. I'm glad Erik kicked
this off with a request for input: the input is useful :-)

Thanks,
Sue
On Nov 9, 2012 11:05 AM, Quim Gil quim...@gmail.com wrote:

 Thank you for the explanations.


 On 11/07/2012 11:47 AM, Terry Chay wrote:

 It turns out we use a lot of industry
 terminology, without realizing that we are poorly communicating what
 that means to most people.


 Actually I'm familiar with industry terminology, and also with the wrong
 assumptions and prejudices it carries many times. I know *you* get it right
 but a basic goal of any reorg is that *everybody* gets it right now and in
 the future.

 While it makes total sense to organize Product Management, Design and
 Analytics under Product Development, it feels old school and odd to leave
 out the software engineers fully dedicated to product development. It
 enforces the old vision that software development is something that comes
 apart and after the product definition. But being Erik (a software
 developer himself) the proposed VP in that area I don't need to insist in
 this point.

 The current proposal of having software developers working on products
 (Language, Mobile, Platform...) together with Operations (sysadmins, not
 directly involved in product development) feels just as old school and odd.
 The common denominator seems to be teams that know to code, the command
 line dudes, etc. I might be mistaken, but it feels as consistent as a VP
 of Presentations overseeing Marketing, Analytics, Design and other teams
 with high communications skills and able to produce great slides.  :)

 And whoever leads the proposed Engineering team still would need to deal
 at a high level with two very different agendas: those from teams actually
 developing software features and those from the operations teams, the
 latter probably still complaining that they don't get as much attention at
 the top level.

 So...

 If the goals are narrowing focus + scale the dept, and take seriously
 our identity as a tech org (as stated by Sue) (Erik says) then why not
 flattening more all this tech structure?

 Something like

 - Product Management.
 - Design.
 - Software development.
 -- Features
 -- MediaWiki.
 -- Language.
 -- Mobile.
 - Operations.
 - Analytics.

 This would mean 5 tech managers (already leading their teams) where now
 you have Erik alone, 4 of them focused on product development + Operations.
 Erik himself could act as EVP overseeing the product development
 activities, since this is the narrowed focus now. He should focus on
 vision, strategy and glue between the tech teams and with the rest of WMF.
 The reporting and leadership of each team would be done by those 5
 managers, now interacting with Sue  non-tech managers more often.

 Doesn't this sound like a more flat and scalable org, with a clearer tech
 org identity?

 PS: yes, it's easy for an outsider to shuffle proposals without much
 background and knowledge of the day to day.  :)  But since you asked for
 feedback... I hope it's useful, regardless of what you decide at the end.
 Thank you for listening!

 --
 Quim

 __**_
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org
 Unsubscribe: 
 https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-09 Thread Quim Gil

Thank you for the explanations.


On 11/07/2012 11:47 AM, Terry Chay wrote:

It turns out we use a lot of industry
terminology, without realizing that we are poorly communicating what
that means to most people.


Actually I'm familiar with industry terminology, and also with the wrong 
assumptions and prejudices it carries many times. I know *you* get it 
right but a basic goal of any reorg is that *everybody* gets it right 
now and in the future.


While it makes total sense to organize Product Management, Design and 
Analytics under Product Development, it feels old school and odd to 
leave out the software engineers fully dedicated to product development. 
It enforces the old vision that software development is something that 
comes apart and after the product definition. But being Erik (a software 
developer himself) the proposed VP in that area I don't need to insist 
in this point.


The current proposal of having software developers working on products 
(Language, Mobile, Platform...) together with Operations (sysadmins, not 
directly involved in product development) feels just as old school and 
odd. The common denominator seems to be teams that know to code, the 
command line dudes, etc. I might be mistaken, but it feels as 
consistent as a VP of Presentations overseeing Marketing, Analytics, 
Design and other teams with high communications skills and able to 
produce great slides.  :)


And whoever leads the proposed Engineering team still would need to 
deal at a high level with two very different agendas: those from teams 
actually developing software features and those from the operations 
teams, the latter probably still complaining that they don't get as much 
attention at the top level.


So...

If the goals are narrowing focus + scale the dept, and take seriously 
our identity as a tech org (as stated by Sue) (Erik says) then why not 
flattening more all this tech structure?


Something like

- Product Management.
- Design.
- Software development.
-- Features
-- MediaWiki.
-- Language.
-- Mobile.
- Operations.
- Analytics.

This would mean 5 tech managers (already leading their teams) where now 
you have Erik alone, 4 of them focused on product development + 
Operations. Erik himself could act as EVP overseeing the product 
development activities, since this is the narrowed focus now. He should 
focus on vision, strategy and glue between the tech teams and with the 
rest of WMF. The reporting and leadership of each team would be done by 
those 5 managers, now interacting with Sue  non-tech managers more often.


Doesn't this sound like a more flat and scalable org, with a clearer 
tech org identity?


PS: yes, it's easy for an outsider to shuffle proposals without much 
background and knowledge of the day to day.  :)  But since you asked for 
feedback... I hope it's useful, regardless of what you decide at the 
end. Thank you for listening!


--
Quim

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-08 Thread Federico Leva (Nemo)

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 platoni...@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 mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-07 Thread Sue Gardner
On 7 November 2012 08:40, Federico Leva (Nemo) nemow...@gmail.com wrote:
 Crossposting is tricky – Sue's answer didn't reach wikimedia-l as far as I
 can see. From
 http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064281.html :

Oh thanks, Nemo. I don't know what went wrong there, but I appreciate
you catching it :-)
Sue

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-07 Thread Quim Gil
Hi, am I the only one having difficulties understanding the proposal and 
what it implies?


On 11/05/2012 07:03 PM, Erik Moeller wrote:

we need to split the current department into an engineering dept
and a product dept in about 6-8 months.


It is strange to see engineering and product side by side, since (as 
i understand them) these words belong to different categories.  :)


Do you mean a platform team and product team, both filled with 
engineers and other profiles but each one focusing on different things? 
The MediaWiki (platform) team and the Wikimedia (product) teams, so to say?


Or are you indeed referring to the classical separation between product 
managers + designers and developers + testers? The first ones 
defining requirements and the second ones implementing them?


Or something else? Reading your email + 
http://wikimediafoundation.org/wiki/Staff_and_contractors + 
http://www.mediawiki.org/wiki/Wikimedia_Engineering wasn't enough for me 
to understand.


What is clear from your email is that the current Engineering team is 
underrepresented at a high level and you Erik have too much in your 
bucket. A split and flattening getting more people in the high decision 
levels makes total sense.


What also seems to be clear is that such reorganization should solve the 
slightly schizophrenic tension of priorities between Wikimedia/product 
and MediaWiki/platform, right?


Whatever the result, I hope we end up with teams where software 
developers, sysadmins, product managers, designers etc are well mixed in 
focused teams going after clear common goals.


--
Quim


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. I’ll make myself personally available to
anyone who wants to talk more about it. (I'm traveling a bit starting
tomorrow, but will be available via email during that time.) We can
also discuss it at coming tech lunches and such.

There’s also nothing private here, so I’m forwarding this note to
wikitech-l@ and wikimedia-l@ as well. That said, there’s no urgency in
this note, so feel free to set it aside for later.

Here’s why I’m recommending to Sue that we create distinct engineering
and product departments:

- It’ll give product development and the user experience more
visibility at the senior mgmt level, which means we’ll have more
conversations at that level about the work that most of the
organization actually does. Right now, a single dept of ~70 people is
represented by 1 person across both engineering and product functions
- me. That was fine when it was half the size. Right now it’s out of
whack.

- It’ll give us the ability to add Director-level leadership functions
as appropriate without making my head explode.

- I believe that separating the two functions is consistent with Sue’s
recommendation to narrow our focus and develop our identity as an
engineering organization. It will allow for more sustained effort in
managing product priorities and greater advocacy for core platform
issues (APIs, site performance, search, ops improvements, etc.) that
are less visible than our feature priorities.

A split dept structure wouldn’t affect the way we assemble teams --
we’d still pull from required functions (devs, product, UI/UX, etc.),
and teams would continue to pursue their objectives fairly
autonomously.

It’s not all roses -- we might see more conflict between the two
functions, more us vs. them thinking, and more communications
breakdowns or forum shopping. But net I think the positives would
outweigh the negatives, and there are ways to mitigate against the
negatives.

The way we’d get there:

I’m prepared to resign from my engineering management responsibilities
and to focus solely on my remaining role as VP of Product, as soon as
a successor for VP of Engineering has been identified. We would start
that hiring process probably in early 2013. I’m recommending to Sue
that we seriously consider internal candidates for the VP of
Engineering role, as we have a strong engineering management team in
place today.

So realistically we'd probably identify that person towards the end of
the fiscal year.

Obviously I can’t make any promises to you that in that brave new
world, you’ll love whoever gets hired into the VP of Engineering role,
so there’s some unavoidable uncertainty there. I’ll support Sue in the
search, though, and I’m sure she’d appreciate feedback from you on the
kind of person who you think would be ideal for the job.

The VP of Product role would encompass a combination of functions.
Howie and I would work with the department to figure out what makes
sense as an internal structure. My opening view is that Analytics and
User Experience are potential areas that may benefit from dedicated
Director-level support roles. (Analytics is tricky because it includes
a strong engineering piece, 

Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-07 Thread Erik Moeller
On Wed, Nov 7, 2012 at 10:00 AM, Quim Gil quim...@gmail.com wrote:

 Whatever the result, I hope we end up with teams where software developers,
 sysadmins, product managers, designers etc are well mixed in focused teams
 going after clear common goals.

Absolutely. Teams are assembled cross-functionally to ensure that all
required skills are present in a team. This will not change in the new
structure. Indeed there are ways in which we need to do better (e.g.
involving ops/architects earlier in the development process on major
feature initiatives). The departments represent functional groupings,
while teams are inherently cross-functional, which is a pretty
conventional structural approach.

I've asked Howie to weigh in a bit on the definition and role of
Product Managers, User Experience Designers, Visual Designers,
Interaction Designers, Research Analysts, Community Liaisons and other
functions grouped in Product. I'll write a bit more in this thread in
a few days as well (about to head to Bangalore for the hackathon
there).

All best,
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


Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-07 Thread Tilman Bayer
On Wed, Nov 7, 2012 at 2:16 PM, Platonides platoni...@gmail.com wrote:
 On 07/11/12 22:21, Federico Leva (Nemo) wrote:
 Terry Chay, 07/11/2012 21:04:
 You aren't the only one. It turns out we use a lot of industry
 terminology, without realizing that we are poorly communicating what
 that means to most people. [...]
 First of all, this will help greatly to the others (you already
 read it): http://wikimediafoundation.org/wiki/Staff_and_contractors.

 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.


 So, to keep it simple, that page has:

 2 Engineering and Product Development
 2.1 Platform
 2.2 Features
 2.3 Technical Operations
 2.4 Mobile and Special Projects
 2.5 Language
 2.6 Product

 and as first approximation Product would be something like 2.2+2.6 and
 Engineering something like 2.1+2.3, with 2.4 and 2.5 aside?

 I thought that 2.4 (Mobile) would also be Product.



 [...] On the Engineering side, there exists an amalgam of
 specific focused groups with their own directors. The focused groups
 are: Language (formerly i18n and Experimentation,
 internationalization/localization/globalization is a cross-cutting
 concern), and Mobile (formerly, Mobile and Special Projects: the
 mobile web, the mobile app, also including Wikipedia Zero). The
 area focused ones are: Operations (keeping the lights on), Platform
 (keeping the code working) and Features (ostensibly new features). [...]

 What you call the Engineering side here, at a first glance, could seem
 product development, and in fact those two focused groups currently
 have some members which are under 2.6 (Product). Surely the same happens
 for the other areas you mentioned.


 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.


 After staring for a while to [[Staff and contractors]] and trying to
 match people with its work, my only conclusion is that I don't know what
 most employees do.

It often (not always) helps to click through to the employee's user
page and read the My work section there. Earlier this year, Gayle
harassed us all a lot to put something informative there ;)

-- 
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-07 Thread Erik Moeller
On Wed, Nov 7, 2012 at 2:16 PM, Platonides platoni...@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


Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-07 Thread Howie Fung
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.,

Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-07 Thread Sue Gardner
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!

https://donate.wikimedia.org/

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

2012-11-06 Thread K. Peachey
(Double Post, Since this was crossposted in the first place, and to
make sure I hit both lists, Sorry Wikitech)

On Tue, Nov 6, 2012 at 1:03 PM, Erik Moeller e...@wikimedia.org wrote:
 The way we’d get there:

 I’m prepared to resign from my engineering management responsibilities
 and to focus solely on my remaining role as VP of Product, as soon as
 a successor for VP of Engineering has been identified. We would start
 that hiring process probably in early 2013. I’m recommending to Sue
 that we seriously consider internal candidates for the VP of
 Engineering role, as we have a strong engineering management team in
 place today.

 So realistically we'd probably identify that person towards the end of
 the fiscal year.

Due to the nature of the foundation and to ensure continued growth and
prosperity I would be hoping that the foundation ensured both
positions became vacant and the person/s are chosen on the merits of
their applications to ensure the continued and best growth.

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l