How to Assemble a Dev Team

i visit an awful lot. it’s a website called the daily click (or “tdc”), where people can learn about how to make their own video games using products from a company called click team. there’s been a lot of talk at tdc about collaborating; different coders, artists, and writers working together to create an excellent video game experience.

at the same time, i’ve also recently read the writings by derek sivers, a creative and visionary guy who helps others develop their business and marketing plans through less-than-conventional means. one of the articles of his i read recently, “how to hire a programmer to make your ideas happen,” also piqued my interest.

i decided to combine these two interests, and came up with an article for tdc readers that lines up perfectly with this newfound rush forward for collaboration. it’s largely a summarization of sivers’ article, but includes the context of tdc so it doesn’t alienate the tdc audience. enjoy!


With all this talk about collaboration and partnerships in creating games, it seemed important to share this information.

I recently uncovered an article–“how to hire a programmer to make your ideas happen”–by Derek Sivers, a visionary business developer and musician; the guy who started CD Baby and several other businesses and creative efforts. He’s released a mass of free materials and teachable content on his website, helping people turn their ideas into a reality.

This is a link to the full version of the article:

The article I am talking about here defines some concrete steps on how to most effectively hire new software development team members. Here’s a snippet about people who start working with you, but for some reason it doesn’t work out:

Some will definitely go bad. Just expect it and don’t let it upset you. They’ll say something has come up, that they can’t start until next month, that it’s harder than they thought, or just disappear and never reply. When this happens, just mark that person’s project as cancelled or complete, and say goodbye nicely. Then carry on with the rest.

This kind of thing happens a lot. Projects start up with tremendous amounts of energy and enthusiasm, but peter out. A major hub-bub ensues when people ask for contributors to a group project, as everyone who reads about it fantasizes that since more people are working on the same project–with their collective wisdom reinforcing everyone’s input–that it’s bound to be a tremendous success.

Then the enthusiasm dies down, and most of the programmers, writers, and artists who were all gung-ho about this new, exciting project simply disappear. It’s either through some spastic flurry of OMG MY LIFE IS TOTALLY SWAMPED RIGHT NOW AND I HAVE NO TIME FOR THIS I’M TOTALLY SORRY…Or it’s like the person vaporized and is simply absent from the team.

I’ve just done this myself actually, inviting a collaboration with another TDC member, but realizing I was in way over my head. We’ve put the project on hold–or at least the collaboration part of it–until we both sort out our schedules a bit. I felt very sheepish about it, and apologized. We’re coming back to it later though…Honest!

These things happen. It’s all part of the development process. Specifically, it’s about developing a team.

So how do you beat this? How do you cultivate a finished product when working with someone other than just yourself? Sivers recommends a few steps for effectively finding team members. Although the full post isn’t very long and you definitely should read it, I’ve condensed it here.

1. Come up with the bare-bones design for your project. Sivers calls this “Version 1.0.” This is the bare minimum that would make you happy.

2. Put together a brief story about what you’re hoping to accomplish with this project/game. I stress this is brief. You can develop a longer, feature-complete design document later, or at least for a different purpose. Keep your story short and to the point.

Here’s an example: “I’m creating a classic platformer adventure about a hero that seeks revenge against her captors in a strange, alien world. She can change her density so that she is able to float in mid-air, sink through the ground, or pass through walls. The character will gain and upgrade these abilities over time, and players will need to use these abilities to reach certain areas of the map and solve puzzles.”

3. Put together your design document. THIS is the painstakingly composed, thorough, long, very detailed list that describes everything that your Version 1.0 should do.

4. Break down that design document into smaller, more digestible chunks. Sivers calls these “milestones.” Actually, it’s an industry term as well, so become familiar with it. The idea behind a milestone is that it’s a small bit that can be worked on, independent of everything else on the design document, which adds to the completed project. It’s one piece of the puzzle, allowing the programmer to focus all their energy and attention to that smaller piece.

5. Make your first milestone a stand-alone project. A game engine is a perfect example.

“I’m looking for a custom platform engine that allows the player to hover in the air for a short time after a jump, as well as sink through platforms as if they were melting, but come out on the other side. The player should be able to do the same thing for walls, as well.” This should do the trick.

6. Post your first milestone as a request anywhere and everywhere it will be seen by potential candidates. Here at TDC, maybe the ClickTeam forums, and other active websites that focus on MMF2 or other ClickTeam products.

7. After receiving your responses (and this is assuming you receive several responses, of course!), choose more than one person to do the job. This may seem odd, but you’re hedging your bets here. What if that one person you’ve picked flakes out on you? What if they work too slow for your liking? What if they simply disappear? There’s always at least one more person who’s looking into the project.

…So when someone says, “So what’s your Plan B?” You’ll actually have an answer. The folks who don’t follow-through with the first milestone for some reason, you can simply and courteously close the deal with them. Say “Maybe next time, but until then, best of luck!”

8. Out of all the finished submissions, pick the person you like the most.

Let’s be honest here. This website and community are full of casual users. Not many people are treating their ClickTeam products like a serious tool to develop the next killer app, fantastic game, or whatever. Most folks are here to have fun, and pick up MMF2 when they have the spare time and nothing else better to do. That’s totally fine, and honestly it’s what I do myself.

But for those who truly believe in the power of the tool they hold in their hands, who spend hours developing new extensions and/or ways to use them, who laboriously create dozens of frames of animation…Those are the folks who will respond to such a process as is outlined above. Those are the people who will finish that milestone project for you, and who you will want to work with.

Stick with them, keep feeding them the milestones, and before you know it, your collaboration will result in a completed project…Which is a rarity these days.

Best of luck to you, Clickers.


note: you can see my original posting of this article here. please note that the version i have posted at fixes some of the typographical errors i made in the original posting.

Leave a Reply

Your email address will not be published. Required fields are marked *