Since my last post about leaving Python, my career has shifted further.

Earlier this year Mozilla shut down its Labs group. It’s a little hard to tell – I guess we didn’t actually shutter anything, and though it was announced internally it is entirely unclear externally. But Mozilla Labs is definitely shut down. Most of those who were still part of Labs at the end moved to the Mozilla Foundation (the non-profit foundation that owns Mozilla Corporation – taxes are complicated). Aaron, my partner in building TogetherJS and Hotdish, was left in a reorganization limbo, and in the process we lost him to Google. With the closing of Labs I was also left in a limbo, but with a baby on the way (Willa Blue Murphy Bicking, born April 23rd 2014) I wasn’t looking forward to any big changes.

On The Closing Of Mozilla Labs

As inopportune as the timing of this was, I understand the reason for closing Mozilla Labs. I don’t believe Labs was effective. And I was not effective in it.

Note that Mozilla Labs is distinct from Mozilla Research – Research is the home of projects like Rust and ASM.js. Mozilla Research is still going strong. To make a broad distinction between the two groups: Research has worked on foundational technologies for the web, especially related to programming languages, while Labs was product-focused. Also Research has been led by Brendan Eich and now David Herman, with what appears to be a fairly clear vision and succession. Labs was led by a number of people with different interests and different visions – some people with an eye to external validation, some looking to spur disruptive (also uncomfortable) changes in Mozilla, some hoping to enable and include external contribution.

When I first started writing this I felt that a leadership misdirection was at the root of Labs’ missteps. But leadership fetish feels a lot like a Great Man theory, an expectation that we are doomed or blessed only by the wisdom and fortitude of our leaders. These shifting priorities from our leadership may have been disruptive to the degree our cultural priorities and understandings (that is, the understanding held collectively by the group) did not themselves provide an even enough keel.

That said, management is a group’s conduit to the larger organization. Individuals can reach out, but it’s harder, and the information they acquire doesn’t necessarily percolate well through the group. Advocacy by individual contributors is also often misdirected, chasing after support where there is no real potential. For any identified problem you can picture an imaginary perfect leader who will fix it, but imagining heroes isn’t the same thing as planning for a strong organization.

Launching a project from Labs did not seem particularly successful. Firefox Sync came out early, as did Jetpack (now the Addon-SDK). Open Web Apps ultimately subsumed Labs. Tab Candy/Panorama/Tab Groups got into Firefox but that was the end of it. Persona became an independent group and team, but didn’t really succeed. Social API is not gone, but it also hasn’t found a real home in Mozilla. Many things people worked on in Labs now exist, but not because of Labs – often a project only took off when someone else in Mozilla committed to it. Other projects still suffer from how they were birthed in Labs.

“Labs” groups are often criticized for being too separate from the companies they belong to. In Mozilla this was a problem because we had a hard time getting things done – for instance, if the success of a project depended on changes to Firefox, then it was hard to get those prioritized. By working separately we also would often use patterns that weren’t liked by other people. People in Labs would often come from the perspective of web developers, where much of Mozilla is focused on user agents, and this is a much bigger divide than I initially appreciated. But the technical problems were perhaps a symptom: integration with the rest of Mozilla was viewed as a problem, a late-stage effort, not part of the exploration and experiment itself.

Another criticism of “Labs” is that innovation comes from everywhere, and having some kind of Innovation Group is exclusionary and misses the opportunity that the larger company and community represents. At times Labs tried to be inclusionary – collecting ideas from the community, trying to guide some more inclusive design processes, played around with internal sabbaticals. I fear these mostly led people on, it did not lead to creative engagement with the community.

Still I’m not entirely pessimistic about the idea of a Labs-like group. Maybe I’d want to call it a new product incubation group (using a wide definition of “product”). Having a separate group does present challenges. But established groups tend not to be conservative about their scope, there’s always more core priorities to be addressed. Establishing a separate group creates an investment that won’t be redirected. But as I write this down this seems like an inferior way to keep investment balanced, it would be better to protect innovation within existing product groups. I see some groups accomplish that protection and I see many groups that do not, but I don’t yet know what creates that difference.

TogetherJS and Hotdish

While unexpectedly abrupt, it was not a surprise to us that Labs shut down. We certainly had every expectation that TogetherJS as a project would be shut down. It may have only gotten by as long as it did because no one was clear who had responsibility for shutting it down.

And again, we didn’t disagree with the motivations that would have it shut down. TogetherJS didn’t have a strategic tie-in to Mozilla. It neither built on Mozilla’s strengths nor did it strengthen Mozilla.

There’s this “failure is okay” meme among the Innovation Crowd. Certainly we talked about it in Labs as well. Fail fast; try another experiment; repeat. I think this is bullshit. Failure isn’t okay, we don’t achieve things through Brownian motion and a selection function. There are many kinds returns on an investment, and if you focus on only one kind of return, only one definition of success, then most experiments will appear to fail. If you want to encourage innovation you have to create a more inclusive definition of “success”. Success can mean that you learn something. It can mean getting rid of a biased preconception about a solution. It can mean learning about and understanding a domain or approach. It can mean adapting processes for future improvement. If something looks like an abject failure, I still believe if you look more closely and thoughtfully you can learn from it and come up with another approach, another experiment or if necessary a meta-experiment. You should be ready to pivot at any time, but thoughtfully.

To innovate we need to learn from every experiment. We need to actively learn during experiments. We need to learn about the projects – but we also need to learn about the environment the innovation is embedded in. Understanding the tensions, fears, needs, and excitement of the larger Mozilla needs to be part of that learning process.

I think the inability to pivot didn’t just keep us from succeeding a projects, but also kept the successes from their full potential. For instance “Apps” was a going concern in Labs when I started, and ultimately would become the group that would contain and then close Labs. But to me it always felt like a project built on willfulness rather than inspiration. It’s only in the context of Firefox OS — where the OS makes demands on apps — that I think Apps are becoming something meaningful, and iterating towards something more than a trivial imitation of native apps. But when you treat success as a binary then you are forced to push through your plan even if it could be improved by rethinking the approach, because rethinking feels like failure.

We knew TogetherJS wasn’t a success for Mozilla (at least the Mozilla Corporation). But we did learn things. Hotdish was our pivot – our attempt to rethink the concepts in a form that was strategically meaningful to Mozilla. Specifically adding collaboration to the User Agent (i.e., Firefox), not to a web page. But the pivot was hopeless at that point, events overtook us. Or maybe not – I’ve been caught up in success through execution for too long, and missing out on opportunities, so I don’t trust those assessments of opportunities. But I think Hotdish as a concept was a bad match for Mozilla at that moment – Mozilla is currently under stress, it’s looking for near-term wins, and Hotdish is a long-term concept.

Still I’m frustrated. I feel like the kind of approach to experimentation that we were developing, through both TogetherJS and Hotdish, was what Labs should have been doing all along, like I’d finally started figuring it out. We were critically engaged with a product-oriented view, something I really learned with TogetherJS, from working with Aaron, and also from Simon and Gregg. We were starting to engage (on our end) with Mozilla’s strengths and specific opportunities (we had not yet started to engage outwardly in this respect). We still needed to engage more aggressively on a technical level with the larger organization. But it really felt like we were developing patterns by which a small team could effectively explore new areas, where with a conservative investment we could really push in new directions.

But now, with respect to these specific projects, I don’t know — I am still excited about their potential, but also feel like I need to establish emotional distance. TogetherJS has been in a bit of a limbo as a result, but Mozilla Foundation is planning to use TogetherJS more extensively in 2015, hopefully spurring another stage of development and use. And a helpful contributor has emerged lately, but I know it’s a hard slog to take on a project in this state.

Some of what I’ve learned

I learned a couple things about myself from my last experiences in Labs:

1. Being on a good team is great. Good people alone don’t make a good team. I hadn’t been on a good team at Mozilla before, or I hadn’t been a good team member, I’m not sure which. Either way I want to take that on myself, not blame others, as my real goal is to find my own positive path.

2. Working with people with a variety of skills and perspectives is great, if they are critically and positively engaged. They must be critically engaged because happy shallow input doesn’t have much value, and often covers up high-value input. They must be positively engaged because negative input is cheap and unhelpful. A scattershot of perspectives and motivations isn’t good, people talk across each other, discussions are drawn to problem collecting instead of solution finding. Getting really smart people together doesn’t inevitably lead to positive searching.

3. I shouldn’t expect success or impact through only my own abilities. I’ve had a lone coder approach for a long long time now. I’m a pretty good lone coder. I’ve had this notion in my mind of the Ultimate Product, some great thing I’m going to come up with and then make in some series of late-night coding frenzies, and it’ll be amazing. It’s a self-acknowledged fantasy, I don’t really believe I’ll do this, but it’s still a real motivation and thwarts my realistic ambitions. This perspective might seem conceited, but in practice it’s an incredible drain on my self-esteem. I would have to withdraw to create software of my own invention just to maintain some modicum of self-respect.

4. I should stop making assumptions about other people’s intentions, interests, or disinterests. It’s entirely unnecessary. All I have to do is ask.

5. Success (or effectiveness or impact) happens in a context, it’s not an independent thing. It happens within the team, the company, the community, and the larger world. But I shouldn’t just avoid being a loner: skipping all the most nearby contexts and paying attention only to the zeitgeist also isn’t effective. This was a chronic problem in Labs. I also sometimes wonder if it’s in the nature of The Valley.

Then what…?

So now I’m in a new position, Engineering Manager. I’m working in the Cloud Services group, and my team is focused on providing services for Firefox OS. I have not touched code since I started. In the parlance of management, I am a “people manager”.

This is not a move I expected to make. Like many a developer (especially open source developers) I have always eschewed these formal lines of authority. I might have imagined myself in a tech lead position, but not management. More so the authority I now have was granted to me by Mozilla, not exactly earned — this was a lateral move, not a promotion within a team. And the role I play is not implementor but facilitator. But here I am.

I’ve spent a lot of time exploring how to do things, and now I’m looking forward to spending some time exploring how to get things done. This is itself not an easy bridge to cross when holding on to open source attitudes — we’ve created this incredible set of tools, but very few products. (Even Firefox was in some sense really created by Netscape.) And so I find myself looking more to traditional methods, to the processes and perspectives of the commercial world.

I’m also just trying to learn to be a manager, a craft of its own, and a role I do not take lightly. The pacing of my day is now much different. Large chunks of free time are not my most productive, instead I find momentum through appointments and my to-do list. I’m not even sure “flow” means something to a manager. I’m practicing a discipline that before I had always seen as overhead — I saw the clerical work, the communication work, the reponsiveness as distractions that keep me away from my “real work”. That attitude was hubris on my part, but there it was.

How long I’m in this, I don’t know. I have a lot more to learn, I won’t run out of important lessons anytime soon. And I have commitments to follow through on, things I set in motion take time to resolve, it take time to even know how well I’m doing. And I don’t dislike the work. I’m surprisingly relaxed, more so than I’ve been for a long time in my professional life (though it’s had its ups and downs). And while I do think fondly to times when I was less responsible, the reality is in my life I am now responsible for many things, the most important of them aren’t part of work, and I can never be carefree in the way I was when I was younger.

I do worry my technical experience will atrophy. I actually feel confident understanding things in theory, not always through direct experience. I don’t exactly need skills to contribute to my team. I think what I really need is intuition. It is my role to infer things about a project, so that I can ask questions, suggest improvements, detect risks, suggest alternatives. But even as I write this down it makes me worry less; if I was to waterfall all my insights upon the organization or team then my knowledge would atrophy, but each suggestion is also a chance to learn so long as I listen.

It may, or may not, be obvious at this point why I haven’t coded since I started. Programming is comfortable, it satisfies something in me — and that thing is not what I need to grow in myself right now. What I’m choosing to do is uncomfortable for me, and I feel a need to withhold a comfort I do not trust.

I am feeling a certain fatigue. I spend more time now worrying about what I don’t know I should worry about. Mozilla is not huge, but it is not small, and I struggle trying to understand where in the organization there is flexibility, tension, what parts are locked down, what parts already want to change. I see the appeal to greenfield organizational development (aka the startup).

A growing set of principles

In my time so far I’ve thought about what kind of manager I try to be. Maybe sometimes I live up to these principles, but I’m also comfortable thinking of these as aspirational.

1. My primary concern is to help the members of my team do their most impactful work. This is not the same as their best work. Over time I am seeing that these are greatly different, and I think the open source world is almost built on “best” over “impactful”, so this prioritization is important and somewhat contrary.

2. I always want there to be space. Space to discover, space to learn, space to make mistakes, and space to learn from those mistakes (the space to learn is so often forgotten). Also space in conversations, and space in meetings. I enjoy long pauses in conversations or meetings, I think they can be a good sign.

3. It’s hard to think hard, especially on demand. It’s hard for me too. Intuition or convention is much easier. But at some points it is essential that we think hard. I’ve yet to figure out how to ensure that happens at those critical times.

4. I may be called on to judge the members of my team, but that is not my job. Though the article is about teaching, I found myself quite affected by The Lesson of Grace in Teaching. I fear when I have the opportunity to offer my team grace that I will forget this, miss the opportunity amid my own stress. But that is why I must remind myself like this.

5. It’s always a good time to do the right thing. But we should do the right thing for right now, not for the past or for an imagined present. The Sunk Cost Falacy has two sides.

6. I do not shield my team from the confusions or stresses of the larger organization. When I have asked people what their favorite experience with a manager was, I have often heard that they liked a manager that shields them from the larger stresses of the organization, a manager who gave them a singular clear vision. That management style creates a more comfortable environment, and one that feels safer. But as I said, I prioritize impact, and impact exists in the organizational context. I hope that my team can creatively respond and react to the organizational context. I don’t want to pass down my own stress, but insulating my team through a false confidence isn’t fair to them, even if it seems nice at the moment.

7. Small decisions are important. And each person is making many small, important decisions throughout their work. That’s why I don’t want to insulate: I believe that those decisions, well made, have important impact. And I can’t predict, on behalf of my team, when those decisions will come up.

8. I always want my team to understand why. Why are we doing this? People can execute instructions without understanding why. I can simply assign work. They can close bugs (then the bug tracker assigns work). But there’s an opportunity lost if you don’t understand motivations.

There’s a lot missing from this list that I have yet to learn. And probably some items that represent an incorrect perspective on my role. But I will keep making provisional theories, these form my next set of experiments.

I hope I can muster the will to write more about what I learn along the way.