On 6 November 2012 11:23, K. Peachey <p858snake(a)gmail.com> wrote: Hi K. Peachey, Generally speaking, the WMF posts and boards for every vacancy. (I think there's a policy document somewhere to that effect -- regardless, it's been our practice for years.) Sometimes we skip the posting & boarding process if there's a sufficiently compelling reason, but mostly we post and board every position. And so yes, indeed, we will post and board the head of Engineering vacancy, because it's a newly-created position, and it's vacant. We won't be posting and boarding the head of Product, though, because it is not a newly-created position and it's not a vacancy. Even though the responsibilities and scope of the role are shifting, it is an existing position, and it has an incumbent (Erik). Thanks, Sue

Le 07/11/12 13:07, Dmitriy Sintsov a écrit : Hello Dimitriy, Please repost your original message as a NEW message. You did reply to an unrelated message named "Engineering/Product org strucuture" which means lot of people will not notice your message since it is hidden in that thread. Your message copy: http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/65… Thanks! -- Antoine "hashar" Musso

Quim, On Nov 7, 2012, at 10:00 AM, Quim Gil &lt;quimgil(a)gmail.com&gt; wrote: 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. For instance, I once introduced our Director of "Product" to someone and Howie got inundated with a request for help in getting them a Wikimedia T-shirt. :-D First of all, this will help greatly to the others (you already read it): <http://wikimediafoundation.org/wiki/Staff_and_contractors>. In this case, the current structure has three separate concepts under the banner of "Product": they are product design (i.e. new software features <http://en.wikipedia.org/wiki/Product_design>), project management (getting those features out on a schedule), and user-interface/user experience/design (in this case, the pixels as the actual coding of the UX/UI is in "Features"). 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). (In reality, taking my division, Features, as an example, I have teams working on the Visual Editor (actually three challenges: the visual editor, the parser, and integrating the two), FR-tech (engineering support for the Fundraiser), Editor Engagement (this year: Notifications and Messaging), and Editor Engagement Experimentation (i.e. post-edit feedback, account creation, new user flows, and analytics to support it), and normally Multimedia (Commons, video, UploadWizard). Plus there is stuff I haven't counted but take resources here and there: maintenance of existing stuff, being available for UI/UX for platform, ResourceLoader/ResourceLoader2, the Agora project for standardized UI/UX, previous and current Editor engagement projects (ArticleFeedbackTool, PageCuration, MoodBar), and MicroDesign.) I believe what is being talked about is more the latter, less the former: a separation of "Product" into distinct teams. Initially that will probably be splitting the product and project managers from the UI/UX piece. Already, Product works closely with Features (projects), Mobile, and Language providing the product management support and design. On doing this, it elevates Product Development as a whole to a higher level (along with Global Dev, Fundraising, Legal and Community, Finanace and Administration and HR, and distinct from Engineering). This does not mean that they are separate. For example, currently, Mobile (in engineering) works closely with mobile partnerships in Global Development on Wikipedia Zero, FR-tech in Features works closely with Fundraising (obviously), and none of us can do anything without Finance and Administration, HR, and Legal counsel. Right now, Erik wears three hats: deputy director, VP of engineering, VP of product development. As you have noticed from the staff and contractors page, "Engineering and Product Development" is an umbrella that encompasses nearly half the WMF. While groups like Mobile and Language are focused, Features, Platform, and Ops have become "catch-all" areas and lack focus. As the groups have grown, fragmentation has increased. I showed what Features really looks like above, but I'm sure Rob and CT can share similar examples of that in Platform and Ops. I think it is believed that splitting off a dedicated VPE distinct from the demands of new feature release will create someone with the wherewithal to focus these groups into a more effective engineering staff as a whole. Right now, deducation where directors have more focused responsibilities like Mobile and Language, and less fragmented isn't possible because Erik has competing things demanding his attention. Hence, following a "narrowing focus" mandate. :-) I hope this explains the decision (or at least, my interpretation of the decision :-D). You nailed it on the head. :-) Take care, terry terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tchay(a)wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay

Thank you for the explanations. On 11/07/2012 11:47 AM, Terry Chay wrote: 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

On Sat, Nov 10, 2012 at 12:35 AM, Quim Gil &lt;quimgil(a)gmail.com&gt; wrote: Hi Quim, your post touches on quite a few different points, so let me try to articulate my views on what I see as some key themes and give my take on those, and I hope others jump in as well. 1) Do Product Managers hand down requirements from up high and software development comes after product definition? Fortunately, generally not. We were much more guilty of this in the days before WMF had Product Managers. The 2009 usability initiative (AKA Vector) had functional requirements defined in a grant proposal before developers had been hired, and the development process was very waterfall-style, with limited (perceived and therefore actual) flexibility to change course on the part of the team. We started seriously ramping up Product in 2011-12, and also gave some teams training in agile methodology to move away from either ad hoc or waterfall-style development. Teams that have dedicated PMs typically pull from multiple functions (design, development, product management) working together at peer-level and negotiating requirements on a day-to-day basis. PMs sometimes play more of a servant leadership role, sometimes are more directive, depending on what's required in a given context. However, there are at least two major issues with this model: - So far, some teams have benefited significantly more than others from access to scarce staffing in areas like UI/UX. Top feature priorities like Visual Editor and Editor Engagement get lots of UI/UX love, while behind-the-scenes changes which can also have major user-facing implications (e.g. Scribunto) have received relatively little. More bridges have been built recently, thanks to the intrepid efforts of notorious bridgebuilders like James Forrester and Steven Walling, but there's still work to do. This (i.e., developer and platform improvements not receiving UX love) is a common problem in the industry and explains why Gerrit's UI is a clusterf^Wbit challenging while other more user-facing Google products have good-to-great UIs. We can't resource everything perfectly, but I'd like to ramp up our UI/UX staffing a bit in part to mitigate these types of resourcing issues. - We've not pulled in ops, senior engineers and site architects sufficiently in feature teams throughout a product's lifecycle, which has sometimes led to miscommunications and frustrations. (A single email or RT ticket isn't sufficient to establish a shared understanding of what needs to happen.) This does _not_ mean developers getting grouped together with ops people but being walled away from product. A Product Manager needs to be just as aware of a major site architectural issue related to a feature as the developers working on the same team, even if the PM's understanding is more abstract. 2) What's the common denominator for a functional separation, and does it mean people start thinking in silos? I've written a bit more about the difference between functional and team-level organization here: http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064298.html Even so, I acknowledge that there's a risk of the Product Department seeing itself as solely responsible for the long term product roadmap, and insufficiently creating venues either for other developers or for the community at large to influence that thinking. After all, who decides that a new "Editor Engagement" team is created, as opposed to - say - a "Multimedia" or "Content Curation" or "API" team? If we go forward with the proposed approach, much of the responsibility for creating better venues for collaborative thinking about product priorities will fall onto me and my team, and I would certainly appreciate the freed up time to help organize such discussions across the organization and the movement. But there's also a role for leadership here that, I think, needs to be explicitly acknowledged: for example, it was ultimately the Board's decision to make editor engagement the organization's top priority, upon the recommendation of the Executive Director. That's why I think it's crucial that more brains influence her thinking directly. 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. An "EVP" role, held by me or someone else, focused on "Product" would quickly gravitate to taking on most of those responsibilities, leading to the common frustrations that you have when you have a "boss" and a boss (feelings of inequity and unfairly limited access to the ED). IMO you'd essentially end up with a structure similar to the current one, except for a higher drama factor. This prediction is based in part on some broader observations about the role of hierarchy in WMF. Whether you like or dislike hierarchy (I'd personally prefer a far less hierarchical organization), we can't deny the current reality or the forces that have created it. The same forces that create a desire for clearly laid out plans (an Annual Plan with targets, goals, quarterly milestones, etc.), are also the ones that tend to reinforce traditional hierarchical thinking. That begins at the Board-level and continues through new organs like the FDC, through relationships with funders, etc. As noted above, the organization's top priorities today have ultimately been decided by the Board on recommendations from the ED through instruments such as the annual planning process, individual Board resolutions, etc. That's a pretty traditional, hierarchical way of setting the agenda for an organization like Wikimedia. Upsides or downsides of that approach notwithstanding, my main point here is what it means for the rest of the organization. If you have a pretty high expectation to be a "plan and execute" organization with ever-improving standards of accountability, and that expectation comes from the top, a structure that exhibits a high degree of conflict or tension with those objectives will tend to shift, by formal or informal means, to accommodate that objective (or, which is worse, you'll end up with a massive disconnect between leadership and the rest of the org). I do think, though, that regardless of whether we do the split as originally described, and regardless of whether we do it sooner or later, we need to bring more senior folks into the conversation w/ Sue and her direct reports. As long as we embrace a fairly conventional hierarchy, we should definitely strive to at least make it as porous as possible. We've done a bit more recently (such as a leadership retreat pulling together at least all the managers), but there's a lot more to do. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

On Wed, Nov 21, 2012 at 6:02 PM, Quim Gil &lt;qgil(a)wikimedia.org&gt; wrote: 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). [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_Fo… -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate