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

[Erik Moeller]

On Sat, Nov 10, 2012 at 12:35 AM, Quim Gil <quimgil at 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
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate