On Tue, Dec 29, 2015 at 12:23 PM, Steve Fink <sf...@mozilla.com> wrote:
> On 12/29/2015 11:49 AM, Bobby Holley wrote: > > > > On Tue, Dec 29, 2015 at 11:41 AM, Steve Fink <sf...@mozilla.com> wrote: > >> On 12/22/2015 10:06 AM, L. David Baron wrote: >> >>> But I don't think having mozilla-inbound/mozilla-central be closed >>> more than it already is is going to help anything. It will just >>> make people frustrated that they can't land what they've been >>> working on. >>> >> >> Amen. Trying to artificially force this stuff is going in the wrong >> direction. After all, you'd be reducing productivity from the top-down in >> order to improve productivity. It might work, it might not, it might help >> for a while but have long-term negative consequences. >> >> Personally, I feel like getting farther away from our volunteer-driven >> roots is dangerous. Sure, we have lots of paid staff now, but you really >> don't want any more selection pressure to push the overall contributor base >> towards people who are involved for the money and away from people who are >> motivated by the mission. > > > I don't follow the concerns in this last part. Can you clarify which > proposal you're concerned will take us farther from our volunteer-driven > roots? The part about ordering paid staff to do unpleasant-but-necessary > things, or something else? > > > Yes, the part about ordering paid staff to do unpleasant things, or at > least some proposed mechanisms to do so. > > We're getting paid, and so obviously it's within the organization's > *right* to order us to do stuff that furthers the organization's goals at > the expense of the individual's. > Very much so. > (Which is the suggestion, in the case of mandatory tree closures for > oranges that a particular developer has no hope of addressing personally.) > I think this proposal is flawed enough that it's more or less orthogonal to concept of ordering a subset of our paid staff to fix oranges. > 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. 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. > > 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. 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. bholley _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
