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.

Comments

Tavis RuddTue, 16 Sep 2014

Good luck!

Marcel HekkingTue, 16 Sep 2014

From the way you write about management, i surely can say that being part of your team would not be bad at all. I think they are good thoughts and opinions.Greetings and good luck!

Andrey PetrovWed, 17 Sep 2014

Amazing post, thanks for sharing, Ian. Especially the "Some of what I’ve learned" section, I've had extremely similar realizations. I am also struggling with a similar self-acknowledged fantasy, but not sure how willing I am to give it up anymore (prior attempts were less than fruitful).

Also I very-agree to your assessment that it should not be the manager's role to hide stresses and confusion from the team. Noise, sure. But when "real life" doesn't make it to the core team, information is lost and incorrect decisions are made. Even if real life means politics and uncertainty.

Good luck on your new role, I'm sure you'll do an amazing job. :)

fredfnordWed, 17 Sep 2014

"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..."

Great management cannot guarantee success any more than enough money to pay the engineers can guarantee success. The lack of either one can, if it is bad enough, guarantee failure.

Les OrchardWed, 17 Sep 2014

Nice: "Failure isn’t okay, we don’t achieve things through Brownian motion and a selection function."

Also nice: "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."

I've long been there, having seen friends on the internets do the same thing to great effect. But, I think I'm starting to realize that spinning off one half-finished Ultimate Product after another is just how I learn all the new things. Maybe someday I'll have something that catches, but I'm becoming convinced that my serial enthusiasm won't let it happen.

XorlevWed, 17 Sep 2014

I identify so much with this that it's scary.

Russell LeggettFri, 19 Sep 2014

That makes three of us. "Serial enthusiasm". I love it.

Les OrchardFri, 19 Sep 2014

Yeah, FWIW, this was like a light-bulb-over-head phrase for me a few years ago. http://decafbad.com/blog/20...

Ian BickingFri, 19 Sep 2014

Oh darn, you fixed your Freudian typo of "a few tears ago"...

Asa DotzlerWed, 17 Sep 2014

"Even Firefox was in some sense really created by Netscape." As one of the people that created Firefox, I'm curious to hear more on what you mean by that.

Ian BickingWed, 17 Sep 2014

I mean that the product that is Firefox has a clear lineage going back to the commercial product produced by Netscape.

Asa DotzlerWed, 17 Sep 2014

OK. I'd replace "product" with "code" to make that more true. The product of Netscape, not so much.

One of the most important points about the creation of m/b (which became Phoenix which became Firefox) was that it wasn't chasing Netscape users like other Netscape/Mozilla efforts at the time, and it didn't try in any way to be a Netscape product or an upgrade or replacement for Netscape products. We were after IE users.

I'd say that Firefox, as a product, owes as much to IE and Netcaptor as it does to Netscape, perhaps more.

Alternatively, your statement could simply apply to all browsers released after Netscape. "Even IE was in some sense really created by Netscape" would be equally valid since IE was basically a Netscape clone. Heck as far as that goes, "Even Firefox was in some sense really created by Netscape" could be replaced by "Even Chrome was really created by Apple" since Chrome was built on much of Apple's tech just like we built Firefox on Mozilla/Netscape tech.

But a product is not code and Firefox was a product (and project) that had very little to do with Netscape.

Simply put, Firefox was not a Netscape product. It was the product of a small group of *independent* people, some Netscape employees (and later former employees) and some not, who wanted to take on and beat IE *despite* the existence of a Netscape that didn't care about it, didn't invest in it, and certainly didn't design it.

But yes, Firefox did use a lot of Mozilla/Netscape code.

Ian BickingWed, 17 Sep 2014

It was only an aside – Firefox is quite notable among a very very small list of successful consumer open source products. I'm not entirely sure why it's so hard for open source projects to produce a product. Some of it is the challenge of actually defining and executing on a product vision, when the work is done by volunteers with independent motivations, and often not a sufficiently diverse set of skills. Firefox notably got beyond that.

But I also suspect one of the challenges that open source projects have is organizations (or lack thereof) that support the product development – there is some wisdom in traditional corporate structures, and they support certain kinds of efforts that are hard to achieve without those structures. There was a lot of corporate effort that helped get early Firefox/Phoenix developers within shooting distance of a product.

Chrome is interesting as a kind of inverted example: the kind of code that Netscape provided to make Firefox possible is what WebKit/Konqueror provided to make Safari and Chrome possible, but it was Google and Apple that turned it into a successful product. Go figure.

Erik RoseThu, 18 Sep 2014

I think the reason open-source projects aren't great at churning out products (or "finishing" them, as you so astutely word it—in the sense of "polishing") is that the things that are interesting to work on are orthogonal to the things that make a good product.

The advantage a hierarchal organization brings to product creation is focus. It's what I enjoy about Apple: sometimes their products aren't for me, but they're always *coherent*. I can see what they were going for. The Apple suite of apps are clearly the best browser, calendar, and mailer for Steve Jobs.

Likewise, Safari has one focus. It is the browser most at home on the Mac.

Chrome has one focus. It is the best way to consume Google services.

Firefox is all over the place right now. Do we provide the best privacy? The best dev tools? The most ambitious web standards? The best integration with our phone? What? We're smart people, each in our area. But being an open source project at heart predisposes us to being a collection of each smart person's favorite features, duct-taped together and given a version number. It's what MS Word was around version 6 (and may still be for all I know): MS managed that project by having each developer come up with and be responsible for his or her own pet feature.

Don't get me wrong—I love and use a lot of FF features—but it seems like we're throwing things at the wall lately: a Hello button, Panorama, F1, a Social API. Now, I love Hello; I use it all the time. And I think better browser integration with Facebook is a motivating feature that could really net us some users. But I look at Firefox today, and I don't see focus. Who does Firefox want to be the Best Browser for? I have no idea. A Single Guiding Principle would both (1) prioritize our efforts so we can actually complete, polish, ship and support things rather than tossing them behind a toolbar button and forgetting about them and (2) unify our messaging so people know why, beyond a shadow of a doubt, to choose Firefox.

As for messaging, the "Doing good is part of our code" campaign made me proud to work for Mozilla, but it also took me back to Apple's darkest days, when they were putting up billboards saying "Give your dreams a chance." "Please, guys, don't leave us! Give us another chance!" Emotional appeals work for soft drinks where there is no product differentiation. But we're not there with browsers yet; there are important differences. In Apple's case, they brought Chiat/Day back onboard, started running some messaging that had teeth, started attacking their competitors directly, and sold themselves to Steve for -$400M, who promptly focused them by cancelling half their product line and doing ballsy things like eliminating floppy drives. The rest is history. They added good UI to music players. Maybe we add privacy to phones. I don't know. But we need to figure it out.

Catalin IacobFri, 19 Sep 2014

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

I hope so too, they're bound to be interesting, just like this one. Good luck

Diane MuellerSat, 20 Sep 2014

Powerful writings, thanks for sharing your 'grace'

Kas ThomasSat, 20 Sep 2014

This was such an awesome post that it deserves to be three or four posts, each one hitting a single concept hard, but I'm also grateful that you did decide to do it as one post, because I understand the need to pull all the various thoughts, feelings, concepts together in one place.

Agree the "fail fast" trope is overhyped and only makes sense when you can realize clear takeaways. OTOH, you can only "fail" when you have clear goals, some clear yardstick of success. So to the extent it helps concretize goals/yardsticks up front, failing often/fast can be valuable, but again only if the lessons of failure can be communicated and utilized.

KaerberTue, 23 Sep 2014

"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. "

Simple writing is really not your thing.

Peter BowyerTue, 30 Sep 2014

> "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"

Can you expand on this please Ian? I am not clear why the two would be different.

> and I think the open source world is almost built on “best” over “impactful”"

I agree with this - we build technologically superb pieces which are impossible to use and make little impact.

Howon SongSat, 22 Nov 2014

I came across this post only recently. Good luck with everything Ian, it was a great pleasure working with you!

This is the personal site of Ian Bicking. The opinions expressed here are my own.