On Sat, Nov 10, 2012 at 12:35 AM, Quim Gil quimgil@gmail.com wrote:

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.

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