So we’ve decided to stop working with Bob.

Nothing really went wrong, but not enough went right. I knew we were in trouble when I started wondering what he was doing. Waiting is fine, but waiting in the dark isn’t. Leaving the rest of your team wondering what you’re up to is the opposite of making it easy to give you an A.

Everyone drops offline from time to time, the key is status. If Bob had set our expectations it would have felt OK. Instead he just disappeared. We’re not even sure it he did any work.

I feel a little bad about it. I never met Bob face-to-face or even saw a picture of him. I know he was young, male, and worked in high-tech. If I saw him on the street I’d have no idea. He was nice enough on the phone, but we only talked a few times.

This is the strange nature of the teleworker relationship. You try to build trust and make yourself into a real person, but in the end you’ll never build a deep relationship in a couple of weeks.

I’ve made some close friends work remotely —people who stayed friends after we stopped working together— but most of them are just cordial relationships. Most people just go on a different road. Teleworking is an isolating process.

We’ll move on and bring in some new people. Next up, introducing the new team members.

It’s been a week since the first patch on the WordPress editorial calendar and I haven’t heard anything. No phone calls, no emails, not even an IM. And I’m waiting.

This is the hardest part about telecommuting. Sometimes you’re alone until your coworkers reach out. I’m waiting for them and feel stuck. I could call them, but it’s too soon. I glance at the phone for the third time in 10 minutes.

Most projects fix this problem with status meetings. I’m always reluctant to add another meeting, but hearing the voices of your teammates makes a real difference. We don’t have regular status meetings here since the project is just part-time.

My one savior is Basecamp. There’s a calendar where I can see some movement. A few new meetings get scheduled.

No news is bad news

This is the time when my telework fears rear their ugly head. What if they’re sick of the project? What if they’re annoyed with me? Do they want me to leave them alone? Are they mad I haven’t called?

Then I get distracted by something else and things feel a little better. Working remotely means self-sufficiency, but buying your desk chair and fixing your own email is the easy part. Emotional self-sufficiency is harder. In the office we’d chat, I’d see them work, I’d know if they’re avoiding me.

Telecommuters have to get used to waiting.

…I think I’ll call them right now.

The editorial calendar project has gone on for a couple of weeks now. We’ve had meetings and made sure everyone is on the same page, but now it’s time to get real. We’re ready for the first patch.

Computer programs are made up of a very large number of very small pieces. The business of writing computer software is figuring out how to organize and manage all of those little pieces. When a developer says, “it worked on my machine,” they’re probably right, but that doesn’t mean it’s ready for anyone else.

So far my wife and I have have written all the code. Not it’s time Bob to make the first code contribution and submit it as a patch. This is a little scary because up till now I’ve never seen his code. I know he’s a chef, but I haven’t tasted his cooking. This first taste makes a large impression.

Bob’s first patch is more an appetizer than a three course dinner. He’d worked on one of the small pieces I’d suggested as a good way for new programmers to get started with the project. When the patch came in it had some good signs and some bad.

Good signs

He did it quickly. The tasks were all easy and small so a quick response was perfect.

He made a real patch. Unix defines a diff and patch process for submitting code and he used it well.

Bad signs

He wrote a very short email. The first patch is crucial and you expect even more documentation than usual. His email was terse to say the least.

Bob didn’t test it. Developers call this throwing shit over the wall.

Let’s remember that nobody on the team has met Bob face-to-face. We don’t really know what to expect from him, first impressions matter and this is a good time for Bob to make it easy for us to give him an A. In this case the easy A is showing us his work and making sure it works.

Human problems are complex problems

Someone submitting a bad patch on a typical open source project would receive a small rebuke and be given a second chance. Maybe even two or three second chances. But this wasn’t a typical project.

Bob was getting paid by Justin and Colin. That makes this a human problem. They were using this project to test him out. I called Colin and explained the problem to him. He called Bob. Colin put it well, “no bad news over email.”

This is the trickiest part of the relationship. We can’t ignore Bob’s bad patch, but we can’t villify him for it either. In person we’d have a talk, but remotely the system can break down with bad actors. It’s too easy to ignore problems.

So was Bob a bad guy, just a little careless, or the victim or a misunderstanding? We didn’t know. Bob gets a second chance. If the next patch is good we’ll forget the first one. If it’s bad we have a real problem. We’ll just wait and see.

The picture in this article was created by californiaAmy and is used in accordance with the Creative Commons license

In this series I’m writing about a new project I’m working on to create an editorial calendar plugin for WordPress. The calendar is created with a small team spread over Canada and the United States. So far I’ve told you about how we formed as a team and how we communicate.

Now I want to tell you about something that makes this project strange. I work on this project for free and everyone else makes money.

The basics of free

Let’s start with the basics of free: I’m not rich. I don’t live paycheck to paycheck, but I have a mortgage, a daughter, and I live in one of the most expensive cities in the US. I also work hard at a at a day job that writes me checks and pays my bills.

So why am I working for free? Because free pays. I can’t really show anyone the large software projects I work on professionally. I can talk about them and give you the PR material, but I’m legally barred from showing you the code I wrote or even telling you much about it. The editorial calendar gives me a chance to show you my work.

I also believe that the people I help will help me. And that isn’t just an abstract philosophy. This editorial calendar is used by bloggers that will hopefully blog about it. They’ll write good things and the plugin will get more popular. Having written an impressive WordPress plugin helps me professionally.

I also just like writing software and learning new things. This project is making me smarter. Working on open source projects like this one helps me be better at my job.

The only volunteer in the room

The strangest part is that I’m the only volunteer on the team. Everyone else gets paid. Some of them get a pay check and others plan to sell services around this software to make money for the company who writes their checks.

Being the only volunteer in the room felt a little strange at first, but the rest of the team made it OK. I know they’re serious about the project because they’re paying people to work on it and giving me their time. They’re also investing in marketing the project and creating a web presence for it.

I hope they’ll make money with it because I know they’ll pay me back. I don’t expect a check, but over time I’m sure we’ll work together. I’ll need help on some project here or there and I’ll have someone I can go to.

Free software makes sense to me as an investment in my career and my personal network. It gives me the chance to show people what I can do and I’m sure I’ll get paid back.

Do you work with free software? Have you thought about starting? Want to volunteer for the calendar plugin?

The picture in this article was based on a work by jjjohn and is used in accordance with the Creative Commons license

The first task of every new distributed team is learning how to communicate with each other. Some teams plan out their communication ahead of time while others let it grow organically. The editorial calendar project is a little of each.

Email

Our communication starts with initial planning emails. They’re full of are you interested and how should this work. We feel each other out and see what type of collaboration we want.

Our emails are loosely managed. We don’t have a mailing list and sometimes people get missed. The stresslimitdesign team is deciding if they want to work with Bob at the same time they decide if they want to work with me.

These emails have a bit of an us and them feeling since the team hasn’t really formed yet. They go off to discuss and figure out what to tell me. This is typical of transitioning from customer to collaborator.

The emails enevitably lead to a conference call.

Conference calls

We start with a quick-hit call with Justin, Colin, and I. We don’t make any decisions, but we reassure each other of our commitement to the project and set up the next call with the rest of the team.

Our first full team conference starts with a role call. Great to virtually meet you. I’m really excited.

This is a classic leader contention call. Justin and I trade back and forth on the leadership position and everyone else mostly listens.

Subversion

WordPress.org provides a Subversion repository where programmers can share source code. I checked all the code into our repository. Everyone can read it, but I haven’t given anyone else permission to make changes.

Most open source projects make members earn the right to contribute new code. Potential contributors submit patches and do small projects until they’ve proved they’ll benefit the project. Then they’re promoted to contributor status.

I’ve never worked with the other coders on the project and I want to make them earn the right to make changes. I need to assess their skills and working style before giving them the freedom to make big changes. I’m worried that will make them feel like I want too much control. We’ll see if that becomes an issue.

Basecamp

Subversion helps us share code and Eric Craven set up a Basecamp for us to share documents, TODOs, and a calendar. I started by adding all of our documents and many notes. I also added our bug bounties. The rest of the team hasn’t been using it much yet.

Coming up: Next week we’ll look at the issues of managing a project team with some paid members and some volunteers.

Now that I’ve opened up the project and warned you that I’m reporting from the middle it’s time to meet the editorial calendar plugin for WordPress team.

I’ve worked with some of the people on this team before, but most of them have worked together without me. We span two countries and a few hundred miles. There are programmers, designers, project administrators, and expert bloggers. We’ll come together to create a cohesive team.

The first part of building a team is understanding the players. Everyone comes with different backgrounds and different expectations. Some of us are volunteers and others are getting paid. I’ll talk a little more about that later.

Let’s meet our team.

The picture in this article was based on a work by yumiang and is used in accordance with the Creative Commons license

Coming next: We’ll take a closer look at how this far-flung team communicates.

Before I tell you more about the editorial calendar plugin for WordPress team, I have a little warning.

I’ve profiled many teams for The One Minute and from my vantage point as a third party I can provide an unbiased view of those groups. My reporting on the editorial calendar project is nothing but biased. I’m in the middle of it and I’m giving you a view from the middle.

There’s no real problem with that, but not having all the answers is inconvenient. I see people through the lens of my own experience. This is important for teleworkers to realize because our we’re trying to see over a greater distance than our counterparts in the office.

I don’t know what my team looks like. Are they short or tall? Thin or fat? Old or young? I hear their voices and my imagination fills in the rest. Imagination is a useful tool, but it’s wrong as often as it’s right.

This series is about giving you my biased views and letting you know what a distributed project looks like from the inside. Take it with a grain of salt and I hope I don’t offend any of my teammates.

The editorial calendar plugin for WordPress started as a family weekend project and it remained the stuff of evenings, weekends, and other stolen moments for a few weeks after that. But eventually it was stable enough to invite other people and we needed to take a set of random ideas, documents, and code and turn them into a project that welcomed other contributors.

Making a project inviting is essential if you ever want it to graduate beyond hobby status. Successful projects have a clear path for welcoming new comers. Successful projects are open projects and that means taking the time to make everything neat and organized.

Opening up the editorial calendar took three major steps:

Step 1. Consistency

Prototypes are messy. You spend your time wondering if something will work at all instead of planning for the future. Various ideas come together and are discarded just as easily. The result looks more like trash than treasure.

Before I was ready to share my calendar prototype with other people I needed to clean it up and make it consistent. Make sure I did the same things in the same way. Cleaning up the prototype took about a week.

Step 2. Documentation

People only know what you tell them. Other people, even other programmers, weren’t going to know how my program worked unless I explained it clearly. Just giving someone the code is never enough. I added many comments to my code, but code comments are more like sticky notes than blueprints. They’ll tell you how the brake pads attach, but not how many wheels your car has.

Other contributors need to know why the project works the way it does. They need to understand what I was thinking before they can embrace it and make it their own. That type of deep understanding can’t come from the details, it takes a grasp of the big picture.

I wrote my big picture document as blog post. That way I can share it with the team and anyone else that might be interested in the future.

Step 3. Bug bounties

Bug bounties are easy descriptions of simple problems in the product. They’re good places for new contributors to start.

Showing your work to others is scary. It causes a tendency to polish the hood a little too much before unavailing the car. That’s a mistake. Most people are attracted to 80 percent projects. A good 80 percent project has clear goals and a strong foundation, but also enough cracks to grab onto. Polish it up to 100 percent and new members won’t know where to start.

Bounties give new team members an easy first step. I defined four simple bug bounties. I could have easily fixed these areas myself, and I could do it faster than anyone else. At this stage I have more knowledge about my project than everyone else in the world, but that’s what I’m trying to change.

That extra knowledge is what makes this stage so tricky. My ego tells me I don’t need anyone’s help, but it’s wrong. Letting other people take the time they need to learn the project is more important than fixing the problem s right now. To the engineer in me that makes all the sense of combing your hair with peanut butter, but it’s true.

And then I was ready to begin. I had the first meeting with the rest of the team and we started making the project real.

Coming up: Next week I’ll introduce you to the rest of the team and show you a little bit about how we communicate.

Every new project is full of potential and risk. Extending something that already exists is always the safer move, but the blank page holds a wonderful allure. It’s a chance to create a new world; even if it’s just a small one.

I’ve started a new programming project to an editorial calendar plugin for WordPress. The idea of managing your blog as a whole instead of a set of individual posts came from Justin Evans. He taught me about organizing my blog as a single entity instead of a set of unrelated posts.

The idea is good, but I wish I had more support from WordPress. I worked up a prototype and I decided to write my first public WordPress plugin. It started as a project with my wife —we’re two programmers who met at work— and quickly expanded to include an entire remote team.

I sent the idea to Justin and he was happy to collaborate. I’ve worked with Justin in the past. We have a great working relationship and we’ve built a lot of trust even though we’ve never met. Justin lives and works a few hundred miles away from me in Montreal. We built our relationship over a few months while he helped me with marketing and promotion strategy for the book version of The One Minute Commute.

Justin introduced me to a group of people from his company stresslimitdesign, and I’ve found myself once again working with a far-flung team full of people I’ve never met. This is one of the most difficult teleworking situations, but none of us can travel for a new part-time project.

I’m starting a series of articles to show you how we communicate and collaborate virtually in a loosely organized team around an open source project. You’ll see what works and what doesn’t. I’m sure we’ll hit some bumps along the road, but I’m sure we’ll get there.