Traditionally, open source software has relied primarily on asynchronous communication. While there are probably quite a few synchronous conversations on irc, most project discussions and decisions will happen on asynchronous channels like mailing lists, bug tracking tools and blogs.
I think there’s another reason for this. Synchronous communication is difficult for an open source project. For any project where people are distributed. Synchronous conversations are:
- Inconvenient. It’s hard to schedule synchronous meetings across time zones. Just try to pick a good time for Australia, Europe and California.
- Logistically difficult. It’s hard to schedule a meeting for people that are working on a project at odd hours that might vary every day depending on when they can fit in their hobby or volunteer job.
- Slower. If you have more than 2-3 people you need to get together every time you make a decision, things will move slower. I currently have a project right now that we are kicking off and the team wants to do everything in meetings. We had a meeting last week and one this week. Asynchronously we could have had several rounds of discussion by now.
- Expensive for many people. When I first started at GNOME, it was hard to get some of our board members on a phone call. They couldn’t call international numbers, or couldn’t afford an international call and they didn’t have enough bandwidth for an internet voice call. We ended up using a conference call line from one of our sponsor companies. Now it’s video.
- Logistically difficult. Mozilla does most of our meetings as video meetings. Video is still really hard for many people. Even with my pretty expensive, supposedly high end internet in a developed country, I often have bandwidth problems when participating in video calls. Now imagine I’m a volunteer from Nigeria. My electricity might not work all the time, much less my high speed internet.
- Language. Open source software projects work primarily in English and most of the world does not speak English as their first language. Asynchronous communication gives them a chance to compose their messages, look up words and communicate more effectively.
- Confusing. Discussions and decisions are often made by a subset of the project and unless the team members are very diligent the decisions and rationale are often not communicated out broadly or effectively. You lose the history behind decisions that way too.
There are some major benefits to synchronous conversation:
- Relationships. You build relationships faster. It’s much easier to get to know the person.
- Understanding. Questions and answers happen much faster, especially if the question is hard to formulate or understand. You can quickly go back and forth and get clarity on both sides. They are also really good for difficult topics that might be easily misinterpreted or misunderstood over email where you don’t have tone and body language to help convey the message.
- Quicker. If you only have 2-3 people, it’s faster to talk to them then to type it all out. Once you have more than 2-3, you lose that advantage.
I think as new technologies, both synchronous and asynchronous become main stream, open source software projects will have to figure out how to incorporate them. For example, at Mozilla, we’ve been working on how video can be a part of our projects. Unfortunately, they usually just add more synchronous conversations that are hard to share widely but we work on taking notes, sending notes to mailing lists and recording meetings to try to get the relationship and communication benefits of video meetings while maintaining good open source software project practices. I personally would like to see us use more asynchronous tools as I think video and synchronous tools benefit full time employees at the expense of volunteer involvement.
How does your open source software project use asynchronous and synchronous communication tools? How’s the balance working for you?
A recent conversation on a Mozilla mailing list about whether IRC channels should be archived or not shows what a commitment it is to remain open. It’s hard work and not always comfortable to work completely in the open.
Most of us in open source are used to “working in the open”. Everything we send to a mailing list is not only public, but archived and searchable via Google or Yahoo! forever. Five years later, you can go back and see how I did my job as Executive Director of GNOME. Not only did I blog about it, but many of the conversations I had were on open mailing lists and irc channels.
There are many benefits to being open.
Being open means that anybody can participate, so you get much more help and diversity.
Being open means that you are transparent and accountable.
Being open means you have history. You can also go back and see exactly why a decision was made, what the pros and cons were and see if any of the circumstances have changed.
But it’s not easy.
Being open means that when you have a disagreement, the world can follow along. We warn teenagers about not putting too much on social media, but can you imagine every disagreement you’ve ever had at work being visible to all your future employers. (And spouses!)
But those of us working in open source have made a commitment to be open and we try hard.
Many of us get used to working in the open, and we think it feels comfortable and we think we’re good at it. And then something will remind us that it is a lot of work and it’s not always comfortable. Like a conversation about whether irc conversations should be archived or not. IRC conversations are public but not always archived. So people treat them as a place where anyone can drop in but the conversation is bounded in time and limited to the people you can see in the room. The fact that these informal conversations might be archived and read by anyone and everyone later means that you now have to think a lot more about what you are saying. It’s less of a chat and more of a weighed conversation.
The fact that people steeped in open source are having a heated debate about whether Mozilla IRC channels should be archived or not shows that it’s not easy being open. It takes a lot of work and a lot of commitment.
Kids on Computers is planning a trip to the Huajuapan de Leon, Mexico area in June. If you can, please join us! If you can’t, please consider donating to help the labs we’ll be working on.
Most of us will be going down for a week or so. There are travel stipends available for those willing to spend a month helping in the area.
What could I possibly do to help? I ask myself this every time I go. Especially since I usually drag my kids along. Here are the things you can help with.
- Technical skills. If you can plug in computers, troubleshoot basic hardware problems, install Linux on lots of different kinds of old hardware, figure out why a mouse isn’t working, any of those things, you’ll be very much appreciated! We have to have at least one Linux guru on every trip. The rest of us follow directions. Upgrading 20 old computers in a school with no internet can be a long, manual process; it goes faster with more hands.
- Language skills. This trip is to Mexico. A large majority of the volunteers will not speak fluent Spanish. None of the kids and teachers in these schools will speak much English. If you can help translate, that’s a huge benefit. Not just when setting up the labs but when figuring out where to get supplies or going out for dinner. And if you don’t know the Spanish words for technical gadgets, it’s sometimes a really funny experience, especially when you’re not sure what you are trying to describe might look like. I’d never used ethernet crimpers until a trip to Mexico.
- Teaching skills. When we teach a class, we like to have lots of helpers. Helpers to show people how a mouse works, how to double click and how to change windows. Often neither the kids nor the teachers have used a mouse or a keyboard before, much less opened an app or saved a file.
- Logistical, herding cat skills. When you have 4 or 5 schools you are trying to work with, all spread out in different towns and 8 or 10 volunteers with different skills and you need a Spanish speaker with each group and someone who can figure out why the network is down in this school and someone who can update Linux on 4 laptops in another school … you need some logistical people. People who can help track who is where and what needs to be done.
- Documentation and note taking. We have all sorts of things we should and try to document. What computers are in which school? What’s installed on them? What finally worked to get Linux installed on that computer that had no USB drive? What should we bring next time? What worked in that class? What didn’t? What apps did the kids use the most? Every evening we try to spend some time working on this, but having someone dedicated to documenting what we’ve done, what works and what still needs to be done, who could do it while we are at the schools, would be great.
- Errand runner, make things out of paper clips person. We are always missing something, short something, need something. We soldered ethernet cables at one school! After stringing them across a road!
Besides just logistical efforts, there’s the benefit to you and what your support brings to the area.
- Support local efforts. I recently read this effort that said international volunteers are often just in the way. I agree, that sometimes local resources exist and if they are there, you should use them. In our case, I think there are very few people with technical skills in the little towns we go to. We do try to pull in local university students and technical people whenever possible. And we have to go back frequently, because going once, setting things up and then leaving isn’t helpful. They get new teachers, forget passwords, computers break.
With the travel grants, we hope to get local university students from nearby towns involved. But the other major benefit of bringing in outside people is that you get local people excited about it.When we set up 18 de Marzo, because we were there, we were able to bring in local media, the local school district, the mayor … because we visited the school, the school got more interest from local supporters.
Unfortunately, they still don’t have internet access nor an accessible high school. But they do have a super involved parent organization and a full time computer teacher funded by student families!
- Spread the word. If you go on vacation to Huajuapan de Leon, you’re going to have the experience of a life time. And you are going to share your pictures and stories with all your family and friends. A few of them may join us next time. Or donate. Or just be more aware of the world.
- Spread your horizons. I take my kids so that they can see that kids have fun without Xboxes. They have a blast playing soccer and making new friends. And, yes, they did find the only arcade machine within miles. In the back corner of a little tiny store tucked away on a side street.
What to expect?
- It’s slow. Most of us are used to scheduling every minute of our time and being as efficient as possible. It doesn’t work that way on a volunteer trip to rural Mexico. Just getting there takes a while. We fly down to Oaxaca, spend the night. Walk across town the next day, get a van ride, drive through the mountains, walk to our hotel. Work doesn’t start until 2-3 days after you leave home!
- It’s not perfect. This is a volunteer run trip. And each trip presents different challenges. And not everyone has phones. Almost no one has internet. Getting from school to school means coordinating rides, arriving to find out they weren’t ready for you or the teachers were on strike, figuring out what equipment you need, what some of you can do while a couple of people drive all the way back to town to buy as much ethernet cable as they can, waiting around while your most seasoned Linux guru figures out why the installs aren’t working, … if you enjoy the people, what you are trying to do and use the time to get to know each other and the schools better, it’s great. If you came just to do technical work, it’d be frustrating.
- Friendly people. The other volunteers and especially the teachers, families and students are awesome. Everyone is appreciative, helpful and outgoing. Just super. The parents usually feed us. Lots of people give us rides. Some people open up their houses. My kids make friends everywhere. Terrific people.
- Not completely modernized. We stay in Huajuapan which is a decent sized small city. It’s got lots of restaurants and a few hotels. Grocery stores and mobile phone shops. And the water is often not hot. And the sidewalks can prove challenging. You might end up riding in the back of a pickup truck. Or walking a long ways in very hot, humid weather. On the good side, there’s no McDonalds and all the little shops are very interesting and very reasonable.
- Beautiful. The area around Huajuapan de Leon is gorgeous mountainous country side.
- Pretty inexpensive. Airfare is a bit pricey but after that it’s not expensive. Hotel rooms run $10-40/night. Dinners might run $3-15/person depending on what you decide to eat. So you can stay there pretty inexpensively. The van ride to Huajuapan is so cheap, I can’t figure out how the price of the ride from Oaxaca can cover gas. I spent a good hour of the trip doing math in my head and I have no idea how they are making a profit. Cabs around town are just $1-2, but cabs out to the other towns where are labs are can be quite pricey. (The cab drivers are friendly though. Avni and I took a cab out to Saucitlan de Morelos once and the cab driver was not just worried about leaving us there when we couldn’t find our friends, he was worried about the whole town because they had no phones and no cell service!)
So should you come? If any of that sounds fun, absolutely. We need you and you’ll be doing good in the world while having fun. If you can’t, no worries. If possible, contribute to some cause to make the world a better place. You can donate to Kids on Computers! 🙂
I read an awesome book last month, Little Princes: One Man’s Promise to Bring Home the Lost Children of Nepal by Connor Grennan that made me realize that in addition to saving the world and solving big problems that affect millions of people, we also need to make sure everyone has a champion.
Little Princes is about this guy who decides to quit work and travel around the world. In order to look less like he’s on a boondoggle, he decides to stop in Nepal and volunteer at an orphanage. While there he falls in love with the kids and makes a personal commitment to several of them. He also discovers that many are not really orphans but rather children whose families are trying to save them from being recruited as soldiers.
When he finds out that 7 of the kids he promised to help have gone missing, he starts a nonprofit, raises money and goes back to find those 7 kids. He sees hundreds of needy children, but he hunts for those 7 kids. (He also opens an orphanage and does a ton of great things along the way.)
I struggled with that for a while – his ability to continue hunting for 7 kids while tons of others could have used his help. He passes hundreds of kids who need his help and focuses on finding those 7. At some point, I think I would have given up and gone to work fixing the political system that caused the problem. Trying to fix it for just 7 kids would have felt pointless. Then I realized that I fight every day for the 2 kids in my house. I help hundreds of kids indirectly through my work but I am a champion for the individual kids that live in my house. And they have not just me but their dad and a huge extended family of parents, grandparents, aunts and uncles.
So everybody needs someone who is fighting for them as an individual. And all of us need to fight for the individuals we believe in as well as the causes.
So what does this mean? I think we need to focus more on relationships, not just causes. In the open source world, we do this a lot through events and blogging. We do it when we say we’re a “meritocracy” and each individual earns their role. We value the individual and form tight bonds that aren’t dissolved when someone changes roles or gets hired or fired. The individual is more important than the role. The project is made up of individuals.
I think there are also opportunities for a different kind of mentorship. A much more accountable, visible mentorship.
The Mozilla Summit is coming! On June 15th, 50 Mozillians got together for a planning session and I discovered just how much Mozillians focus on getting great things done!
We met to help shape the Mozilla Summit (a 2,000 person conference happening later this year) in a way that would move Mozilla forward. We spent the first day talking about top issues and the second day planning out the topics and sessions.
Photo sent to me by Shez (But Shez is in the picture so not sure who the photographer is!)
Of all the trips I’ve taken this year, I think the Mozilla Summit Planning Assembly was the one I looked forward to most – a chance to help shape the future of Mozilla and have great conversations with people who are passionate about the same things I am! I also admit I was really worried that we were too big of a group to get anything done. Turns out I was not alone. We all showed up ready to set the content and agenda for the Mozilla Summit.
A day of tough discussions and building trust
We had some excellent conversations Friday night and Saturday. We did a number of different exercises designed to start conversations and pull out key themes. For example, we started out Saturday with an “unpanel”. Four people sit in the middle of the group. They have a conversation. There’s an empty chair as well and whenever someone in the audience wants to join the conversation, they slide into the empty seat and one of the four sitting there self selects to go back to the bigger circle leaving an empty chair as an invitation for the next person. While at first it didn’t seem very different than a big group conversation where you passed around the mic, it turned out to be a great way to keep the audience engaged in the conversation. Every one was listening hard. The topics we covered were varied but a lot of it centered around non paid staff vs paid staff relationships – culture and responsibilities. We also talked about things like whether there’d be technical roadmap decisions made at the Summit, how people like to communicate, etc. One of the key takeaways for many of us was that we were all worried about similar issues!
Over the course of the day, two themes arose:
- Old timers and new hires are having a hard time trusting each other at Mozilla. I’m sure I didn’t get all the nuances but it felt to me like old timers think new hires might not have the “Mozilla DNA” and might not have an appreciation for our mission and open source methods. And new hires think old timers are stuck and so concerned with consensus they aren’t always getting things done. Over the weekend, I think we made great progress in killing that stereotype and building good relationships that bridge the gap. (Lukas Blakk wrote about this experience as well.) I have to admit that personally I’m not sure where I fell on this stereotype other than feeling rather annoyed at both groups and some how personally responsible for both stereotypes. As a hiring manager, I’ve hired many of those new people. As a long time open source community member, I feel like it’s my job to make sure the “open source” way is considered and well represented. I also think that part of the problem is how members of each group introduce themselves and represent themselves to the world – more on that later.
- Mozillians like to get stuff done! By the end of the day, we were all extremely uncomfortable with all of the discussions, panels and world cafe exercises with no clear idea of how it was going to produce an agenda for the Summit. Luckily our leaders and the Unconference organizers heard all of our concerns and when we turned up the second day, we got to create a rough outline of an agenda and topics for the Summit!
Getting down to work
On the second day we did a “World Cafe” exercise. We had about 7 rooms and 3 time slots and everyone wrote in the topic they wanted to cover in one of the slots. We then did some consolidation and managed to squeeze everything into the ~20 slots.
The idea was to cover themes or topics we thought should be covered at the Mozilla Summit. Each session was to identify Session Title, Goals and Outcomes, People for Followup and What has to happen between now and the Summit. They were all captured in etherpads.
All the sessions I went to had great conversation. It was rather tricky to focus on how that topic would be covered at the Summit instead of just discussing the topic. We tried to focus on how the conversation would best happen at the Summit: what type of presentation it would be, how much should be a proposal vs a discussion, if it was one presentation or a theme, etc. Some times the topic you signed up for was not the topic your group ended up proposing. I attended discussions on communication, diversity (Dino and Lukas have a great diagram for a starting conversation!) and helping companies that aren’t used to “open” work with effectively with us.
Then Mark, Debbie, Mitchell, Kate and Mardi grouped all of the topics into themes – interestingly “People” had the most topics. Other themes included Strategy, Product, Process and Purpose.
So now we have themes for the Summit. And a lot of proposed topics.
I found it really valuable to spend this time as a group planning for a big event. When you are going to bring 2,000 people together (in groups of 600) I think it’s essential to spend some time uncovering what the real issues that we need to discuss are.
My take aways:
In addition to the bigger goal of planning the Summit, I took away a few more key things:
- It’s important to work together, preferably in person. We built a lot of trust over the weekend – trust that would have taken much more time to build during our regular day-to-day lives and over the internet. I hope we can take that experience and bring it to the Mozilla Summit.
- Mentors. After a conversation with Gandalf, I came away thinking part of the solution might be holding mentors more accountable and some how measuring their success over time. We also discussed short term mentorship projects too.
- How you introduce your self matters. With a few exceptions, most of the volunteer Mozillians introduced themselves as being “a community member” or a “Rep”. Most of paid staff introduced themselves by their functional role or team, “Firefox for Android”. This is natural as while we all feel like part of the greater Mozilla community, paid staff has in general been hired to do a particular role. But I feel like it’s a big part of the disconnect.
- Lots of communication formats are needed. Lawrence Mandel pointed out that not everyone does well speaking in front of large groups at conferences, so whatever format the Summit takes, it needs to enable lots of communication vehicles, meetings, parties, irc, etherpads, newsgroups, … a way for everyone to find enough of their comfort zone so that they can be comfortable enough to participate fully.
The Mozilla Summit Planning Assembly was one of the trips I was most looking forward to attending this year and it lived up to my expectations! I’m very excited for the Summit now! (And for all the planning that still has to happen before then!)
Photo by Fadzly @ Shutterhack
Many of us working on free and open source software have strong values and we want to make the world a better place. I’m comfortable predicting that the rate of vegetarians, recyclers, hybrid vehicle owners and just general environmentally conscious people is higher than average in free and open source software projects.
We want to work with and support companies that support our values. We buy brands like Seventh Generation products, we try to support companies like System 76 and ZaReason. And we avoid “evil” companies. After hearing Dish Network was the Meanest Company in America, I’m researching other cable providers.
But how much can you restrict your partnerships to those that perfectly align with your values? Is a company evil if it doesn’t match your values in all areas? I personally buy products and have business relationships with companies that I may not be 100% aligned with. (Although some may be too far from alignment.) Sometimes it’s because I haven’t done any research – I buy gas where it’s most convenient not from the most environmentally conscious gas provider. Sometimes it’s because there’s not much of an alternative – if I want high speed network at home, Comcast is my option. Sometimes it’s because I think that while they are not perfect, they are providing a service that makes my world better.
If you partner with someone who doesn’t share all of your values, assuming the partnership goes well, you have a chance to influence them. My friends are much more likely to listen to my opinions than someone I’ve never had a coffee or a beer with.
Now, I realize that open source software projects are often less in the position of partnering and more in the position of accepting donations. But again, I think your chances are greater for being a positive influence if you are working with them than if you are not. You should examine the organization’s motives and make sure if you are part of a political play, that you are comfortable with that move. I still remember the wealthy individual trying to build a big chain store in the town I lived in who donated a house to a family in need. While it was a great donation, and I would thank him for it in person if I saw him, I also know it landed him on the front page of the paper in a positive light at a very controversial time. Should the family have turned down his donation? Probably not. Should those that were anti-big-chain-store have done something differently. Probably.
But the fear of being associated with a company that’s not perfect or of being used as part of political play should not hold us back from investigating options and starting partnerships.
I think open source software projects often hold themselves back. They don’t investigate partnerships that could be beneficial because the other organization is not perfect. Proprietary software is not evil – a lot of really great innovation has been led by proprietary software companies. And doing business with an organization that has proprietary software will not make an open source organization any less good. There will be no perfect organization just like there is no perfect person. You have to recognize the opportunity for good in people and organizations and work with them where it can make sense for both of you.
Make the world a better place through partnerships because if you insist on doing it all yourself, it’s going to be a long road. Personally, I want to visit the stars someday, so I hope those that share a vision of star travel work together even if they don’t always agree on how to do it. I want to live in a world where everyone has access to computing power and the internet and control over their experience and their data. I think in order to do that, we’re all going to have to work together. And we’re going to have to work with those that might agree on pieces of our plan but not the end vision, and that will be ok. The super helpful Comcast guy might not share my vision of the world, but he helped me make it possible for me to continue working on it.
The number of long form blog post have been declining for years. Most speculate that it’s because most of us spend more time microblogging on Twitter and Facebook. Certainly, when I started blogging in 2004, I blogged a lot of things that I would only tweet now. In November 2010, Jeff Bercovici wrote on Forbes:
53 percent of hobbyist bloggers say they update their blogs either somewhat less or a lot less than they have in the past. […]
Those who say they’re blogging less often were then asked to say why. While the most popular answer was “work/family commitments,” the next two most common choices were “I am devoting more time to microblogging (eg. Twitter)” and “I am devoting more time to social networks.”
I think it took a bit longer for that trend to happen in open source software and my technology blogs, but it has come. I found myself really missing good blog posts by independent individuals and decided to see if it was my imagination, or if I really was reading less blog posts than I used to and here’s what I found on my two favorite planets: (Numbers not 100% accurate.)
While I didn’t have a good way to measure microblogging numbers by the same authors as were in Planet, I do know that most of the people whose blog posts I miss are regularly posting on Facebook or Twitter.
The thing is, I miss reading all those blog posts. I’ve tried looking for more blogs to follow but not been really successful at finding new ones. I’ve tried reading more nonfiction books but books don’t provide the same type of thought food or blog ideas as blog posts do. Neither do tweets or Facebook posts.
At the same time, I have to admit my own blogging has gone down drastically from an average of 6 blog posts a month in early 2011 to an average of maybe 1 a month now.
It’s possible that microblogging is a better medium for the 5 blog posts a month that I now tweet instead of writing. And that the one post a month I write is the only one that should have been in long form to begin with. But I don’t think so. I think I am just sharing less well thought out ideas.
What do you think? Do you miss blogging? Have you noticed the decline of blog posts? Do you miss them?
“Where there is no competition, there is no market. This is why start-ups who “have no competition” have trouble engaging partners and making sales.” – Geoffrey Moore, Escape Velocity
Open source projects often shy away from competition. They value collaboration and leveraging existing solutions. But competition is good for more than making you run faster. Competition helps define who you are.
This is why the Nike iPod sensor had such a hard time when it came out. There was nothing to compare it to except pedometers. In contrast, Fitbit and Jawbone’s Up have met with a lot more initial success. And just about every article about them compares them to each other. (Interestingly, Nike has a new, similar product called Fuel Band that is mentioned in very few of the articles.)
GNOME and KDE defined each other by competing in the Linux desktop space. Without an option between KDE and GNOME, very few Linux desktop users would know what a “desktop” was or what part of the Linux desktop was created by GNOME or KDE. By defining each other as competition, they helped explain who they were and what problem they were trying to solve. They also constrained themselves to the Linux desktop. That was good as it let them shine in a defined space, but if they want to move to new markets – like mobile, they’ll have to be careful to define new competition to explain to partners and users who they want to be.
Firefox, Internet Explorer, Safari, Opera and Chrome have a long history of competing. They’ve helped define each other and the web.
So don’t be afraid of the competition. Choose your competitors wisely and let them help explain your story.
We all have blog posts we haven’t written. Boris Mann wrote about why he hasn’t posted some.
Here are the top 7 reasons I haven’t published some of the blog posts I’ve written.
- Half baked. My idea was half baked. A lot of times I find myself blogging about things I’m still trying to work out. Perhaps those half baked blog posts would spark interesting conversations but I often find myself saving them as drafts and starting a conversation in email or in person. These are the ones I think maybe I should publish.
- Twitter. I tweeted it instead. Many things are only worth a tweet these days. When I first started blogging in 2004, I used to blog interesting links. Now I tweet them instead.
- Too personal. Often I realize I need to talk directly to the person, not blog about them. Many times I want to blog when I’m frustrated about a person or a situation. In those cases, I usually just write the post, save it as a draft, and then call or email the person I’m frustrated with.
- Too rude. The person I was blogging about would know it was about them. I actually keep a list of the funny things I want to tweet or blog about but I need to wait a few months so that the subject doesn’t know it was them … these are usually the really funny ones. Although often they are tweets, not blog posts. And no, that tweet was not about you! 🙂
- Too private. I used to blog a lot more about my kids and my personal life. After some really negative comments on a post about my kids, I decided to make most of these private. I still tweet about the funny things they do and blog about some of the insights they give me, but most of my posts about my family are now private.
- Time. I have lots of really good topics I’d like to blog about. In many cases, I’ve started the post. I just haven’t taken the time to polish it and publish it.
- Not mine. I find this the most frustrating one. Often there’s a really good opinion, idea or a news item that I think should be shared but it’s not really mine to share. I’ve often offered to interview or guest post for someone but they rarely take me up on it.
Take a look at the draft posts you have. What are the top reasons you haven’t posted them?
Do you think I should post more of the above topics? How would you suggest I do that?
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?