Feb 2021: The Awkward Human’s Half-Guide to Teamwork

This is a story of what has been the most difficult things to learn during the transition from being a solo developer to being a part of a team. From being the protagonist to being a member of an ensemble cast.

I’m not going to spend too much time trying to sell you on the benefits of team and community, because that’s not where I get caught up. Whether it was performing in music ensembles or competing on a roller derby team, my life has had no shortage of experiences driving home the idea that a strong community can accomplish more than even the most talented individual could ever hope to accomplish alone. And besides, other people have made the case for teamwork far more elegantly than I ever could. (If that’s what you’re here for, might I recommend Hannah Nicklin’s GDC talk, “Kill the Hero, Save the (Narrative) World” — it’s good viewing even for those of us who don’t need any further convincing.)

And yet, as a student, I always dreaded that day in class when the teacher announced that we’d be doing a group project. Not because I doubted the power of teamwork, but because I didn’t have a firm grasp on the skills needed to make a team work. A modern proverb, often vaguely misattributed to “Africa,” tells us that “If you want to go fast, go alone; if you want to go far, go together.” What it leaves out is the amount of work that “going together” entails.

 
not an african proverb 0.png
 

Together is an action, not a state of being. It’s a skill. Like any skill, you can be good at it or bad at it. And like a lot of skills, the annoying thing is that many of the people who are naturally good at it aren’t necessarily that great at explaining it to those of us who it doesn’t come naturally to. I’m the first to admit that I’m not an expert on any of the things I’m going to talk about for the rest of the article — but I’ve been convinced by other folks on the team that for precisely this reason it might be good for me to write about it.

Assemble!

The first thing you’ve got to know about “going together” is that you can’t go together with just anyone and expect to get far. You wouldn’t make a baseball team with, like, nine pitchers. You wouldn’t find Finding the right people to round out your team can be a struggle of its own and I’ve made a number of missteps along the way. Like everything in this blog post I hardly consider myself an expert, but here’s a couple of pointers that my awkward self has come across (or, in some cases, tripped over) during the development of our first big game.

Being good isn’t enough

We humans are complicated organisms with complicated brains and when you put two of them together for any purpose they become complicated-squared. Many many years ago, after my shareware dev years but before my mobile dev years, I was actually working for another team on a game. My tenure was relatively short there, by comparison. They were a great group of people, they had a lot of talent, and I had no qualms with the way they ran things. And yet… I just kinda wound up floundering with that group. My strengths overlapped with some of their strengths, the team’s needs put me into a few roles I was really underqualified for at times, and I had some creative ambitions that really weren’t being given room to grow within the team. And so, I left… several months later than I should have, to be honest. And it felt good when I did.

So let go of the idea that someone can be too good to not work out. Or that just because you like someone means that you should be working with them.

Get to know your nopes (and your yeahs)

The sentiment here is similar to “know your strengths and weaknesses,” but subtly different. Yes, a lot of the time your yeahs and your strengths will line up, and your nopes will be nopes because they are your weaknesses… but sometimes the you’re good at things that you just do not want to be bothered with. And occasionally, you’ll be bad at something but you’ll have both the desire and opportunity to work on improving it. Framing this as “nopes and yeahs” really helps separate the things you are absolutely on board with from the things that you, you know, could do, if you had to.

 
 

It feels all too often, at least in the American Can-Do Spirit of Entrepreneurial Freedom Spirit™ culture, that “no” is some sort of dirty word. Fight that lie! “No” can be empowerment. Sometimes you need to slam some doors shut so you get your bearings and figure out where to go.

Once you know your nopes, and your yeahs, and the nopes and yeahs of your established team members, be clear and open about them whenever you’re approaching someone new about joining your team. Life is too short to approach a project with a dishonest assessment of your own nopes. Ideally you’ll find people whose yeahs cover your team’s nopes.

Start short (?)

If you’re like me, and you’re conflict-averse to a fault, one of the biggest points of anxiety when talking to someone new is “well what if they just don’t work out? what if I need to have a talk with them?” One thing that I haven’t really tried out yet, but I’m planning to, is to intentionally start with a short contract — around two months, maximum. That way, some sort of check-in is kind of built into the system, it’s not unexpected, and you can re-evaluate whether someone is working or not.

If you’ve tried something like this and it did or didn’t work out, let me know!

Making the Dream Work

Once you’ve got a team… it still takes time and effort to keep things together. And if you’re a socially awkward like me, a lot of these tasks are stay-in-bed-all-day HARD to even start on. If one of your “nopes” from above was “starting conversations” or “wrangling humans” or “by what sick twist of fate was I appointed party leader? I don’t even like it when I’m hanging out with some friends and they hand me the remote, what have I gotten myself into, please send help…” then we are kindred spirits. Like before, I am far from an expert… but I’ve learned a few things along the way.

Above: a screen capture from my Jira board that has totally not been doctored at all

Above: a screen capture from my Jira board that has totally not been doctored at all

Routines force follow-up to happen

If you’re like me, one of the biggest mental blocks you have is trying to follow up with people. Maybe you’re the kind of person who kinda prefers to be left to their own devices and then you project that onto other people, maybe you wind up going weeks or even months not really having a sense of what is happening on someone else’s end. And then the longer you wait to follow-up, the more inertia you have and the harder it is to start that e-mail.

But the fact is… regular communication and follow-up is critical to getting a team working properly. And sometimes a gentle touch isn’t enough. I’m a naturally routine-averse person, but let me tell you, setting up regular meetings with people just winds up working so much better than the loosely-enforced e-mail check-in system that I was using before, and it just takes a little bit of routine to avoid a lot of follow-up anxiety. You do really get more out of it than you put into it, in terms of mental energy. At least if your brain is wired like mine.

Get everyone using the same tools

For a good stretch of development, we were using one system to track art needs, and a completely separate system to track development tasks and QA stuff, and then just relying on lengthy e-mail chains for everything else. The trouble with something like that, though… as the one person who’s using every tool on a regular basis, you’re setting yourself up to be a necessary intermediary for when other members of your team need to interact with each other.

And you know what that means? More e-mails. Nobody wants more e-mails. Nobody. Literally no person wants that. Especially not me.

The cheat code

OK buckle up because this last tip is gonna blow your freakin’ mind: did you know that you can hire other people to, like, send e-mails that you don’t want to send?

If you’re a disorganized mess of a human being… did you know that you can hire someone else to set up development tools like Jira?

It took me far too long to realize this, but I’ve brought a producer on board to help us finally shove The Day We Fought Space over the finish line, and the very first time she offered to start an e-mail chain it was like the sky cracked open and a choir of angels sang out in divine harmony, “why didn’t you do this years ago?”

Catherine Kimport