What do you mean when you say “Write it down?”

July 2nd, 2012 in kids

I had this misunderstanding with my 5 year old about taking notes and looking them up.

“Mom, how old was I when I said my first word?”

“I don’t remember, but I wrote it down, so I can look it up.”

“Why?”

“Why did I write it down? Because I knew you might want to know some day.”

A few seconds later. “How old was I?”

“I don’t know. I’ll look it up.”

A pause. A pointed look at my phone. “How old was I when I said my first word?”

“I don’t know! I wrote it down. I’ll look it up for you when we get home.”

Another pause. Another look at the phone. “Is it stuck in the computer?”

Ah! “No, I wrote it down with a pen. On a piece of paper in a notebook. I have to find the notebook. I’ll find it when we get home.”

So what do you mean when you say you “wrote it down?” Five years ago, I meant I wrote it in a notebook with a pen. Today it means I noted it down some where in the cloud. Or perhaps I put just on my computer and it’s “stuck” there.

How to have hallway conversations when you can’t see the hallway

June 4th, 2012 in Business, Career, gnome, mozilla, PlanetGNOME

I recently listened to a talk by Michael Lopp about how to be a great manager.

During his talk, he stressed the importance of hallway conversations. Hallway conversations are informal conversations about projects, goals and status. As Shez says, they are great for bouncing ideas off people you might not normally interact with and just letting them know what you are up to.

Here’s how I do “hallway conversations” while working thousands of miles from my colleagues:

  • Chat informally. While most people will tell you it’s important to have an agenda for every meeting and to stick to it, I think that if you never see your colleagues at the water cooler, you need to build in some time for rambling. Maybe you’ll gripe about the latest project, maybe you’ll share the cool project you’ve been working on with your kids, maybe you’ll just talk about what you had for lunch. Or maybe you’ll have a great shared idea that inspires you to write that blog post that changes the whole project. It’s those relationships that enable you to informally share how you feel about the projects you are working on.
  • Send that trivial piece of feedback. Often I’ll send an irc message or an email that just says “I liked how you did this” or “here’s a piece of feedback I heard about your project”. Sometimes they seem too trivial for an email message. But if I don’t send the email, and I store them all up for the next time we talk in person, I might not send them at all. (I also keep a file where I keep track of things I want to talk to people about next time I interact with them. Things I think are easier to explain via interactive chats.)
  • Keep open channels. If at all possible, have some sort of real time channel where you can reach your colleagues. Best is a something like IRC where you can hang out and have informal chats. But if not a standing room, at least know how to find them via IM or txt messaging.
  • Be available. Be available in as many channels as possible. I’m regularly on irc, Skype, IM, email, txt messaging, Twitter and Yammer. And I try to respond in a timely fashion. Why? Because when someone thinks of something they want to tell you, you don’t want them to have to remember what they had to say until they get back to their desk. Right then, while they are standing in the hallway, you want them to be able to ask you “what do you think about …?” (You also need to make sure you aren’t letting your life be completely interrupt driven, but that’s for a different post.)
  • Get help. Ask others for help. I’ll regularly ask people I talk to what it feels like in the office or what they think about a paritcular project. What the mood is like, what people are talking about. Or I’ll say, “the next time you chat with so-and-so, can you ask him what he thinks about xyz?” I’ll also tell them I’m worried about a particular person or project and ask them to check in for me. After a meeting, I’ll check in with other folks that were at the meeting to share perceptions on how it went.
  • Meet regularly. If there are projects you care about, make sure you meet with the principal people on those projects regularly.
  • Meet in person. GNOME folks go out of their way to attend GUADEC – often taking vacation and time away from their families. It’s an important event because it’s the one time a year when much of the GNOME community gets together. Meeting people you work with in person is invaluable for community building. I love how humor in email makes much more sense after you’ve met someone in person.
  • Ask them. Ask how others are doing, how they are feeling, what’s top of mind, what keeps them up at night, what makes them feel so passionately that they are working at 3am, ask them … you never know what you’ll learn or what you’ll be able to do together.
  • Communicate effectively. I used to say “over communicate” but I now believe you have to communicate effectively. If you publish everything in the world on your blog and nobody reads it, or the important pieces get lost in the noise, you haven’t communicated. But it’s key to make sure people hear what you are worried about and the ideas you have for solving problems.

How do you effectively have hallway conversations when you don’t share a hallway with your colleagues?

Getting management feedback from your kids

April 18th, 2012 in mozilla, parenting, PlanetGNOME

Last night on our drive home from school I started asking my 11 year old about his science fair project. I asked him what it was going to be on, what supplies he needed, what was he going to do if his idea didn’t work, what was he going to draw on his poster board, … and he ended up yelling at me “I’M GOING TO DO IT, OK?!”

Then this morning I had a whole series of 1:1 meetings with folks on my team … and I caught myself asking them questions in much the same way. How many people are coming to the doc sprint? Where will it be? Do you have a theme? Did you email the developer teams?

Now Janet, the one planning the doc sprint, didn’t yell at me. But was she just being nice?

So I have some theories:

  • Maybe it’s ok to ask co-workers those questions and not your kid. (I do really want and need to know that information about the doc sprint …)
  • Maybe my way of asking questions is really abrasive (or giving feedback on what I think needs to be done via questions is abrasive) and my kid just feels more free to tell me so.
  • Maybe my kid feels like he’s behind on his science fair project and was just defensive. I expect my co-workers to have answers to those types of questions (and they do) but perhaps I haven’t taught my kid to think like that yet.

It made me think that I need to make sure I get more feedback from those I work with … especially since most of these conversations happen through a video camera.

Oh, and the science fair project is coming along quite nicely. So’s the doc sprint.

Global Community Champions Workshop

April 16th, 2012 in mozilla, PlanetGNOME

Mozilla is an amazingly global and diverse community. I like to think we got it from our open source heritage – open source projects know how to work globally.

Mozilla is committed to working globally – we hire all over the world, hold regular community meetups around the world and have community spaces in many cities.

But it’s not easy. Ensuring that a global team works effectively takes a lot of dedication by everyone.

Recently we had a Global Community Champions workshop to discuss what’s going well, how we can teach other best practices and what we want to improve on.

Amié Tyrrel organized the event. Homa Bahrami and Debbie Cohen facilitated.

There were a lot of great conversations and takeaways. We’ll be following up with lists of tips and a few specific task forces, but here are a few of the takeaways I had:

  • Open source (and Mozilla) are peer-to-peer teams, as opposed to parent-child teams.
  • All projects need a conductor and they need music to follow. A music sheet that says who plays what note when. When you don’t have a conductor, or you have an informal one, the music is even more important. We need to plan. :)
  • We talk a lot about how hard it is to be geodistributed but we don’t talk much about the benefits. A geodistributed team is amazing. There are traditional reasons like hiring the best talent or having continuous time zone coverage but it’s also a huge advantage when it comes to diversity (which makes sure our products and solutions work well for even more people around the world) and growing community.
  • There are different types of collaboration and different types of teams.
    • Collaboration can be pooled (we each do our part and then combine them), serial (I develop the product and then hand it off to QA), reciprocal and multidimensional.
    • Teams can be loosely coupled (like a golf team) or tightly coupled (like a soccer team.) Loosely coupled teams are much easier to coordinate in a geodistributed environment. Tightly coupled teams are likely to take a lot more time and energy. If you are on many teams, you might want to make sure you aren’t spending all your time on tightly coupled teams at the expense of your loosely coupled ones.
  • Many people at Mozilla are on many, many teams.
  • Mozillians are very emotionally connected to their work. (As opposed to financially or intellectually connected.) This is one of my favorite parts of working at Mozilla. However, it also means that emotions run high and when someone has diverged from the project, it’s really hard for them to say goodbye.
  • Remote teammates don’t have much signaling communication (random smiles as you pass by) and tend to focus on substance conversations. It’s important to build the signaling back in some how.
  • There are three times it’s important to meet in person.
    • At the beginning of a project to work out ambiguity,
    • At the end of the project to aggregate and celebrate and
    • Whenever there are conflicts.

    (I think this point will be important as we figure out when and how often to have work weeks.)

  • Several people have had success with office hours. Specific times when they are available to chat.
  • Conflicts in geodistributed teams are much more likely to be about relationships rather than tasks.
  • Ineffective teams are likely to have:
    • fuzzy goals
    • ambiguous roles
    • ad-hoc, unclear roles
    • internal focus
    • lack of identity
  • Effective teams usually have:
    • clear goals
    • differentiated roles
    • pre-determined rules for
      • how to deal with conflicts
      • how to build consensus, make decisions
    • external focus
    • shared identity
  • Debbie shared how Mitchell described Mozilla’s decision process. I hope Debbie or Mitchell will share with us in a blog post but basically it was you write an email describing the problem set, the issue you see. You make a recommendation. Ask for specific feedback, allow some time for discussion and then take action.
  • The team leader or orchestrator does not need to run the meetings. Several teams (like the Automation & Tools team) are rotating the facilitator for their regular meetings. This lets everyone play an active role in the project. I believe the facilitator touches base with everyone on the team, gets their status updates and issues. Sets the agenda, runs the meeting and sends out the notes afterwards.
  • Effective geo-distributed team leaders know when to be:
    • colleague
    • context provider
    • orchestrator
    • director
  • We need more team charters. :)

And that’s only part of what we discussed! Lots and lots of good info that Amie and Debbie will helping us get out to the rest of the organization in a way that’s hopefully useful. And in a way that starts a dialogue so others can also share their best practices and working globally knowledge.

How much big is better?

March 3rd, 2012 in happiness, housing

I think I know what a small house is. One year my family of 4 lived in a one room house without plumbing. And some of the neighbors lived in smaller houses. We moved every year and sometimes we lived in spacious houses, other times in small apartments. But we always had enough room. (Although as teenagers, my sister and I might have wished for another wall between us sometimes.)

I was informed last week – 10 times no less – that I live in a small house. We have 1300 square feet upstairs and 1300 square feet in our finished basement. It is not a small house. It’s a big house. Yet the person looking at it kept saying it was such a small, cute house.

She was a designer. I concluded that most people in our area must value big. And bigger. In 1950 the average American home was less than 1,000 feet. In 2006 the average house was about the size of our house, 2300 square feet. The dream house must be bigger than that now. When given the choice between remodeling to fit changing needs or just buying a bigger house, most Americans must pick the bigger house. Since we live in a huge house (by my standards), I figured most of her clients must live in enormous houses.

I spend most of my evenings sitting on the hardwood floors in the kitchen playing with the kids and talking to Frank while he cooks. I want a comfier kitchen/dining room, not a bigger house. I want to continue to hang out close to Frank and the kids, not have a more comfortable place elsewhere. (I’ve got that too.) I have not figured out how a bigger house would add to our quality of life at all. (Luckily the designer seems to understand we want a cozy, warm space for us and friends to hang out.)

What flabbergasts me is the new definition of what a “small house” is. I have nothing against big houses. Or enormous houses. I just resent being told my big house is small. But I guess it’s all relative.

Open source feedback (done wrong): “Look, you have food stuck in your teeth!”

March 1st, 2012 in mozilla, open source, PlanetGNOME

At a party, if you notice someone has food stuck in their teeth, you probably wouldn’t go “HEY! You have food stuck in your teeth and it looks GROSS! I hate it. I think you should go brush your teeth right now!”

But we do that all the time in open source.

Someone writes a new blog post or a new piece of code or forgets to post something … and we criticize them in public. Because it’s open source, right? Instead of emailing them we think their blog post is wrong, we leave a blunt, often rude comment. Instead of IMing them and asking if they’ve considered the privacy implications of their change, we write a public blog post that details how wrong their strategy is. Instead of congratulating them on their new product website and emailing them a few suggestions that would make usability better, we write a long critique in a blog post of our own.

When we do this, this public criticism, we change their ability to respond to it. Now they must respond in public, often defensively. If the feedback was private first, it would be easier for them to change quickly and nimbly. (Or maybe they don’t need to change at all. Maybe we missed something.)

There is a time and a place for public critique. But it’s often not the first place the critique should happen if we want to effectively influence projects.

Most effective people on open source projects communicate privately first.

They communicate via private emails, IMs and even public IRC channels, which are less public than web pages and public mailing lists because they aren’t archived.

So the next time you read something and have burning feedback, consider your audience and how you might most effectively drive the change you are looking for.

Who has your mail?

February 29th, 2012 in mozilla, PlanetGNOME, Web/Tech

Who – or rather, which company – is holding all your email?

Photo by Louis Abate

If you couldn’t login tomorrow, do you have a copy of your email? Many webmail services, like Gmail, make it easy to download a copy of your mail using POP or IMAP but if you use their web client, it’s an extra step you have to think about and do on a regular basis. It’s not something that most people can do easily. Especially if they share a computer with others.

While there’s a good chance, as a reader of this blog, that you are a do-it-yourself kind of technical person and use Thunderbird or Evolution to read your mail on your own computer, most of us don’t. Most of us trust our webmail to be there when we need it. We are trusting a single company to hold and take care of years worth of personal correspondence.

We need a way to backup our data, data like our email, to a trusted place.

P.S. I use Thunderbird to backup all my mail from my email web service providers to my computer. It’s not what it was designed for but it works for now.

Devices as computers will change the world

February 28th, 2012 in kidsoncomputers, mozilla, PlanetGNOME, Web/Tech

At Kids on Computers, we’ve spent a lot of time and energy getting computers to kids that have no access to technology. Many of these places (rural Mexico, Africa, India) have cell phones before they have phone lines or even power. (The second time you blow the power for an entire school trying to set up a couple of computers, you realize how much we take power for granted in developing countries.)

So the new devices coming out right now are really exciting.

These devices, using open source software and open web technologies are going to bring the web – and the world – to more people everywhere.

Disclaimer: I work at Mozilla. At Mozilla we are working on making sure everyone has access to the web and that it stays open and accessible for everyone.

Open source teaches people how to fish

February 27th, 2012 in mozilla, open source, PlanetGNOME

One of the things I love most about the open source communities I’m a part of is that when I ask a question, I just don’t get the answer, I get taught how to find the answer.

A few weeks after I started as executive director of the GNOME Foundation, I asked Dave Neary for someone’s contact information. Actually, it might have been the third or fourth time I asked him for someone’s contact information. He sent me back an email with the contact info I wanted. And a detailed explanation of how he found it. So the next time, I was able to find info like that myself.

I love that when you ask someone in open source a question, they not only answer it, but explain how they found the answer. (I realize some people find that annoying. I really appreciate “learning how to fish.”)

It’s the same empowering attitude that drives people to blog about a problem and how they solved it or found the answer. They are teaching others how to fish.

It’s scary to join an open source project

February 26th, 2012 in mozilla, open source, PlanetGNOME

Photo by DennisSylvesterHurd

Think of the last time you walked up to a complete stranger, stuck out your hand and said, “Hi, my name is …” Depending on how often you do that, it was probably a scary moment. Before you walked up to the person, you had to steel your nerves, decide what you were going to say, and then approach them.

Joining an open source software project is a bit like that. You have to send a mail to a huge list of random people. Or file a bugzilla bug that goes to a ton of random people.

And then imagine the immediate response is “WONTFIX” with no comments. That’s like if the person you got up the nerve to introduce yourself to said, “Not interested.”

I once spent weeks convincing a friend she should help out on an open source software project. She did. And she sent in her work to the mailing list and the first response was full of harsh critique. None of the follow up messages made up for that first message. I never did convince her to push her work forward. Nor to participate in open source again. (She does know exactly what she’d say to that first critic if she ever met him in person!)

What can we do to make sure people trying to shake our hands get a better reception?