More to the point, I don't think that doing this is "a big hammer
[that] should be used sparingly." Getting paid to work on Mozilla
stuff is a huge privilege, and that privilege comes with the duty to
work on what the organization thinks is most important. The fact that
it's often most practical to delegate that prioritization to the
employee makes working at Mozilla (and in the tech industry in
general) a lot of fun, but employees generally do not have the right
(morally or legally) to refuse to work on something because it's _not_
fun.
While perhaps more difficult to get immediate traction from, it
applies equally well to unpaid volunteers.
I disagree - volunteers are generally free to work on exactly what
they want. The only leverage that the org has over them is (a)
accepting or rejecting their contributions and (b) the extent to which
it expresses appreciation for their work. We should certainly _try_ to
steer volunteers towards useful things using (a) and (b) above, but we
cannot order them to do un-fun stuff (like fixing oranges) the way we
can with employees.
Note that my suggestion isn't really any better; it's just a stick
in place of a carrot. I only suggested it because it feels to me
like it is more likely to produce net positive results. But PTO is
obviously irrelevant to unpaid contributors. Tree closures *are*
globally relevant, but are more likely to drive away unpaid
volunteers than to incent them to help out with unfamiliar
intermittent oranges. The two weeks of enforced quality-related
work at the end of each cycle are better, in that they only
penalize paid staff, but that still feels to me like a top-down
imposition to work in a particular way, one that changes the
flavor of the organization into one that people are less likely to
want to volunteer for.
As noted previously, "ordering everyone to work on X" is very
different than "ordering some people to work on X". The former is
clearly flawed, and I think the latter is very sensible.
That makes me think that we're not disagreeing very much. Still some, I
think, but sure -- if assigning a handful of people to work on
intermittent oranges makes the problem go away, then that seems like a
reasonable thing to do. Though if you're taking existing developers, and
I think you'd have to in order to get anywhere, then you'd want to be
sure that stalling off what they're currently working on is not going to
strike them as a ridiculously bad idea.
And even then, I'm not sure of the "tiger team" approach here. We have
that now, and his name is Ehsan. He has good evidence to show that it
doesn't work. Admittedly, if you're grabbing one person from each of a
large set of teams, then you're likely to get better "priority
diffusion" than you get with one guy working on weekends. Certainly, I'd
expect that actually fixing the problems is going to require a lot more
than the small group, so the awareness of the importance is likely to
spread somewhat.
But this sort of problem seems like it's something we have an
institutional disregard for. And any attempt to spot-fix it without
addressing that systemic issue seems less likely to succeed. *That* is
what I understood the true motivation for things like enforced tree
closures was -- not to directly solve the issue, but to force everyone
to care more about it, so that we don't have to do crappy things like
that. But I still don't like it, because it feels like a "you must write
at least 100 lines of code a day" type of thing: it doesn't necessarily
put the pressure at the right place, and it causes a lot of collateral
damage.
I didn't really want to get into this (hey, I just wanted to throw out a
suggestion to get people thinking), but to me the problem is that we're
at all ok with allowing the current situation to develop. The sheriffs
have been warning about impending orangopocalypse for as long as I can
remember, and we've all (myself included) largely ignored them. Ehsan
has also brought this up several times, with real data as to how
addressable this is with focused effort, and from what I can tell the
response has basically been a collective "boy, that Ehsan guy is smart
and nice to have around" followed by a continuation of the current way
of doing things.
To be fair, we *are* doing some important work in the right direction. I
don't know what all of it is, but the treeherder improvements for
identifying and categorizing oranges is really important, as are rr,
chaos mode, web replay, and related work. To me at least, that still
feels like more of the "let's throw a few smart people at the systemic
problem" approach, though. I could be wrong. Maybe we're close enough to
being able to recognize failures and direct them to the appropriate
people, who will then jump up and fix them, that this whole problem will
go away soon.
/me holds breath
/me turns blue
On 12/29/2015 01:02 PM, Bobby Holley wrote:
On Tue, Dec 29, 2015 at 12:23 PM, Steve Fink <sf...@mozilla.com
<mailto:sf...@mozilla.com>> wrote:
But that's a big hammer, and should be used sparingly.
The alternative is to motivate staff by aligning their goals with
the organization's.
I don't think these differ at all. Saying "your goal for this quarter
is X" is precisely how the organization orders employees to work on X.
I agree. But I assert that saying "your goal for this quarter is X" only
has the effect of making that developer's true goal to be X to the
extent that the developer is convinced the X is a worthwhile goal (eg
that it aligns with high-level objectives, and those high-level
objectives are useful and deserve a higher priority than everything
else.) If you tie the bonus to accomplishing an X that the developer
doesn't truly agree with, then the developer will indeed work on X (or
quit), but then run away from it or punt it off to somebody else at the
first available opportunity. Which is exactly what you don't want to
happen if your goal is to improve long-term quality.
In short, I agree that that's how to order someone to work on X, but I
disagree that it will result in goals being aligned.
Don't get me wrong, I can also argue that it would be suboptimal
to only have a pile of developers all working on what they feel
like, when they feel like it, and in the way they feel like it.
But the right place is a balance between authoritarian and
free-for-all, and right now I feel a couple of pushes towards
excessively authoritarian that bother me.
Managers order their reports to do unpleasant things all the time. The
trick to being a good manager is finding the right balance of workload
and incentives to keep everyone happy (enough) so that they're
productive, keeping growing, and don't quit. We have a mixed track
record in that area, but it's fundamentally an implementation detail.
That feels somewhat orthogonal to me. I agree with all of that, and I
think that you can accomplish all of that in the short term with or
without aligning personal goals with institutional ones. But in the long
term, Mozilla won't survive if it's just another corporation that knows
how to push around its employees effectively.
Even though we often end up serving Mozilla's mission best when we're
having fun, that fun is a means to an end, and is by no means sacrosanct.
Well said. But the point is not the fun, it's about people freely
believing that what they're working on is the best way to further the
mission.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
