This post was written collaboratively with my friend Kai Rathmann. The reason for this will become apparent very shortly.
The thesis of this post is essentially: make things with people. We want to introduce a new-ish framing for how to relate to people, called “project partners”. A project partner is someone that you are doing (or have done) a project with. The project can be large, but doesn’t have to be. The key is that you have the experience of working together towards a specific, external, common goal.
Doing a small project with someone is great for a number of reasons:
So what kinds of things could this be? Let’s go over some examples. This is Kai speaking:
In one of my Skype calls, we hit on an interesting topic and started collaborating on notes right then during the conversation. At the end of the call we gave ourselves the task to brainstorm about the topic for a follow-up discussion. Our exploration of the topic both during subsequent calls and offline resulted in a nice Google Doc.
Another idea was collaborating on online research where we complemented each other well. We wanted to find out how easy it would be to provide a particular service in the country of my conversation partner. I knew more about the details of the service and compiled a list of general questions, and they knew more about their country and set out to find the answers.
My largest project growing out of a conversation so far has been collaborating on design work for a nonprofit that I volunteered for.
And this is Malcolm speaking:
I first heard about the concept of Project Partners from Sebastian Marshall’s talk at GiveGetWin’s Gotta Be Good Tour. The following week, every interesting conversation eventually turned into me saying “let’s do a project together!”. Everyone thought it was a great idea, but of the 5 or so to whom I proposed this, only one actually took me up on it: Oliver Habryka. We didn’t even know what we wanted to do, but we had a lot of shared interests so that didn’t faze us. We ended up creating a worksheet to help people have more impactful conversations by encouraging them to think of valuable things to talk or ask about, and to follow up on the conversation with small value-adds or projects.
Later this summer, I was at the Center for Applied Rationality’s Alumni Reunion. It was very “unconference”-like, and so I figured it would be fun to do a few talks. My friend Ethan Dickinson and I decided to co-present a couple of sessions on Robert Kegan’s Constructive Developmental Theory (see recent relevant blog post) which we had talked extensively about over the previous week or so. We spent only about 20 minutes preparing, 40 minutes presenting, and then maybe another 20 minutes debriefing, so this was a really compact way for us to learn a lot more about what it was like to work with each other. We found that we had a lot of mutual trust and ability to give sensitive feedback, and it made us a lot more interested in future collaborations.
One of my favorite examples of a partnery project is when two of my friends teamed up to make me a birthday cake this year. It’s so simple, but they had to coordinate ingredients, plan the design for the cake (which was epic) and then actually create the cake itself, which they did during part of my birthday party. Working under this time pressure, as we’ll mention later, can be really helpful. Unless you have specific food-related hangups, I think that if you can’t even get through baking a cake with someone without getting annoyed at them, you probably don’t want to try a bigger project like a startup. Or a marriage. At the bare minimum, you want to make sure that the two of you have the ability to effectively deal with any frustrations that do arise.
Edit Aug 2020: I now actually think that “effectively dealing with any frustrations that do arise” is actually way more important than not having any frustrations in the first place, because in any large project like a startup or a marriage, there will be frustrations, disagreements, and misunderstandings. So if you only tackle a tiny project where everything’s easy, you won’t learn about how you navigate those. Which is not to say not to do tiny/easy projects! I’m just pointing at what can be learned from different sizes.
Other examples I’ve been involved with or aware of include making halloween costumes together, editing a book, and attempting to rig a sort-of-voting, sort-of-luck contest. Mike MacCauley described to me how he and one of the other founders of BufferBox (since acquired by Google) had worked together before and knew they were a good match. They needed a team of four though, so they did hackathons with classmates to see who else they liked working with.
I think there’s also probably a lot of room for collaboration on subcomponents of larger projects. For example, if anyone wants to help me with the copywriting for Complice, let me know. This wouldn’t just be you doing a thing for me—we’d have to work together to figure out how to concisely explain what is on some levels a complex and nuanced philosophy around productivity.
As Malcolm mentioned, it’s easy to propose this to a bunch of people and have them say yes. So in some ways, you can just throw this idea out at everyone and see where it sticks. On the other hand, that’s going to involve a lot of misses, because people will say “yes” but then the thing doesn’t happen. We have some advice for this at the end of the post, but there’s another factor you can take advantage of to improve your chances of having a project partnership: context.
One simple context is when you’re meeting someone for the first time. Maybe you were aware of each other over the internet before or not, but for whatever reason, you’ve found yourself in a virtual or physical conversation with this new person, and hey!—they seem interesting, so you want to get to know them better and develop at least some sense of a relationship with them, rather than just having them be “someone you met” or “an acquaintance”.
But why should people who’ve never met you get to have all of the fun? What about your existing acquaintances? In particular, people you wish you knew better than you currently do. Do you have a shared interest with them? Or complementary skills? Is there a subcomponent of one of their own projects you could help them with, or vice versa?
Another good time to propose a project can be after having done something else with someone, assuming you’ve enjoyed that. For example, if you’re a student, then perhaps after a school group project, reach out to someone on your team and ask if they’d like to work together on something else. (The school project itself will teach you some of the relevant skills, like working with someone, but doesn’t have the greater benefits to your sense of being able to just start and finish projects because you can.)
The above examples are situations where you might want to do a little project with someone. But there’s also a situation where you almost certainly want to: Before doing a large project with someone. Malcolm mentioned this to someone while talking about the project partners idea, and they immediately facepalmed and said, “Yeah, if I’d done that with my (recent ex-)cofounder, I might have realized he was a sociopath before we were a year into a company with seed funding.”
In all of these cases, it can be helpful to already have a specific project idea, because even if you end up going with something different, it gives the other person a better sense of your purpose. If all else fails, though, try: “I just heard of this really cool concept called Project Partners! [Insert either an explanation or a link to this blog post], and I thought that it would be fun/valuable/worthwhile for us to work on something. Want to brainstorm?”
When you propose a project with someone and they’re interested, there’s a few things to keep in mind to improve the chances of success.
Make sure everyone knows what the next action is. This staple of GettingThingsDone™ advice is good to keep in mind in any situation, but it is especially important for getting started on the project after your conversation.
Set an expectation for the time-frame. For a first project with someone, we recommend aiming for results in one to two weeks. Bigger projects can aim for their first milestone in that timeframe.
Ensure you both actually have time for the project. Kai once started work on a project with someone who had a vacation coming up a few days later, which disrupted the flow of the work. It would have been better to defer the project until after the vacation, and then start it together.
Pick something you both care about—both in terms of the work required (e.g. in this case, writing a blog post) and the topic (about project partners). Also, make sure that the particular task is something they’re comfortable with. Someone might not be used to writing long texts, for example.
If you’re creating something, decide in advance how intellectual property will be handled. Or, more simply: What are you going to do with the thing you create? Give it away? Sell it? (Are profits split evenly? Does more money go to the person who successfully makes sales?) If you’re writing something to be published, where will it go? Early on, Malcolm and Kai clarified that this would be posted on Malcolm’s blog, though Kai gets to republish it on his own if/when he makes a blog.
Advanced: “Eat salt”. This comes from Sebastian Marshall’s talk. Don’t just do a thing, but do a thing that is hard, under pressure. Perhaps a hackathon. Or something else where you need to deliver. Though if possible, maybe get practice with chiller things first.
Collaborating on a project is a great way to connect to another person. Aim for the right size, use the right context to propose it, and keep some of our past lessons in mind to increase your chance of ending up with a satisfying result.
As an experiment, we suggest using this Facebook thread for you to find someone to collaborate with on a new project.
Malcolm and Kai (we did this!)
Constantly consciously expanding the boundaries of thoughtspace and actionspace. Creator of Complice, a system for achieving your important goals.