Hi there, it’s Professor Anne again, ready to welcome you to my highest level Developer Relations class, this one focused on making things work over the long haul with your development partner. In my last two posts, I’ve focused on how to find the right developer for your project and how to make a deal that serves you both in the long run. This week, I’ll be wrapping up this series – for now, at least – by examining how to maintain a productive and mutually beneficial relationship with your developer throughout the production process.

A great long-term developer/client relationship is a bit like a marriage, with each side supporting the other and helping one another grow and thrive (that’s the goal, at least!). So the following advice is rendered in my best relationship book-ese, the kind of snappy truisms I trust will put this blog up there with The Rules and He’s Just Not That Into You in the pantheon of self-help titles. Think of the following as a few chapters from IP Holders are from Mars, Developers are From Venus…

Chapter 1: Be Upfront About Your Needs

In work relationships as in personal ones, you can’t get mad if you don’t tell them what you want. (At least, you shouldn’t.) As Carla spoke about in her post on the dark art of communicating effectively, keeping lines of communication open with whomever you’re working with is key, and honesty is the best policy. When you know exactly what you want, this is fairly straightforward. It gets a bit stickier, however, when you’re less certain of your plans.

If you’re waiting for inspiration to strike, or for decisions to come from further up the chain of command, remember — there is nothing wrong with telling your developer what is going on! They are your partner for a reason, and may be in the best position of anyone to help you make decisions. You can always say, “I’m not sure about this, but I’m thinking the next phase will look like this…” or even, “Just a warning my boss is about to look at this for the first time, so there may be some changes coming up.” Letting the developer know where you are in your process and what you need to help move decisions along is ultimately to everyone’s benefit. Be brave enough to be vulnerable!

Chapter 2: Don’t Be Afraid to Ask for What You Want

Following close on the heels of being upfront and honest about where you are and what you are planning is putting your foot down when you need to. Although the developer is your partner, you are also essentially hiring them to execute your vision (in most situations – if they’re going in as a full partner or on a revenue share model things might be slightly different). Assuming you’ve hired a developer to make something and you are clearly the client, you need to ask for what you want, and if you’re not getting it, keep asking — unless you’re making changes that are beyond the original scope, which I’ll address in a minute.

If you find yourself giving the same notes over and over, or just failing to connect with a member of the development team, ask how you can reframe your comments more helpfully, set up a phone call, a Skype catch-up, or best of all a face-to-face meeting to figure out what’s going on. It’s okay to be demanding sometimes — that’s what you’re paying for, and any good developer is going to want to provide what you want and work out any kinks in the process. But in the absence of strong direction, they’re going to have to fill in the gaps as best they can, which is likely to make everyone uncomfortable in the long run.

Chapter 3: Celebrate Important Milestones Together

When you’re running full speed ahead on a project with a long-term goal still far in the distance, it can be easy to gloss over the completion of major elements, but it’s important to take a moment and enjoy the achievements along the way. When you receive a great script, or an initial iteration of an awesome feature, or a first complete build (bugs and all), take a moment to celebrate the work of your development team. Pick up the phone, send a gift basket, whatever it takes. It can be as simple as saying, “Thank you,” and calling out team members specifically for the work they’ve contributed. What’s critical is to let everyone take a moment to pat themselves on the back. The encouragement and momentum of those little celebrations can truly reinvigorate teams and keep a project humming even over a lengthy production period.

Chapter 4: Be Consistent… Except When You’re Not

We’ve talked on this blog many times about being wary of feature creep, and there’s little more frustrating to a developer than a client who keeps trying to pile extra items into a deal without offering a requisite amount of money to make it happen. It’s your responsibility as the vision behind the project to choose a direction and keep honest about it and what you’ve engaged the developer to do. So if I have one thing to say here, it’s DON’T BE A JERK ABOUT SCOPE! You know what you agreed to, and so does your developer, so don’t pretend otherwise.

At the same time, have you heard the phrase, “A foolish consistency is the hobgoblin of little minds”? No developer wants to deliver an app or a piece of software that’s fundamentally broken or ineffective in some way due to your obstinate adherence to a flawed initial concept. It’s important to set up key points — say, user testing or peer review moments in your process — where you ask yourself if what you are doing is working and how you might improve things.

Ideally, you should build room into your scope of work to make these kinds of adjustments. If you don’t, and then realize at some point that serious changes are essential to the success of your project, acknowledge to your developer that you’ve come across an unforseen circumstance and ask them if you can apply additional resources to getting necessary changes made (this translates to: pay them more money!) or trade some previously conceived features for new ones that you now realize are larger priorities.

Chapter 5: Don’t Expect Them To Fix You

All relationships are only as strong as their weakest member, and sometimes…. that member is you. It’s okay to bring some uncertainty into your relationship with a developer. In fact, sometimes that’s ideal. You may be working with a developer to figure elements of your project out, which is fine, but you cannot expect them to fix things about your project (or your organization, for that matter) that are fundamentally flawed.

If you don’t know what you want to do on some basic level, or what your market is, or when you need to launch, that’s really not your developer’s problem. They are there to make the thing that you hired them to make, not to solve epic business strategy problems, or worst of all, mediate between you and team members on your side who disagree. Respect the fact that your developer is there to help you make something, and if there is something on your end that’s holding up key ideas, or feedback, or funding, that’s ultimately your responsibility to resolve.

Chapter 6: Pay Your Bills

Ok, so this one doesn’t exactly fit the self-help apparatus (or if you’re into that kind of relationship advice, I think you’re on the wrong website!), but one of the best pieces of advice that I can give you in working with a developer is to pay their invoices, and pay them on time — assuming they’ve delivered on their end of the bargain. It’s nearly impossible to have a meaningful creative conversation with anyone about a product you’re working on, when all you can think about is, “You owe me $10,000,” and that’s true regardless of what business you’re in. Be accountable, and your developer will do the same.

So there you have it, my crash course in Developer Relations comes to a close with a little advice that I hope will help you in any number of long-term relationships… If you have other questions about working with developers, send ’em our way and we’ll consider adding Developer Relations 104 to the course catalog! (Or we’ll just write you back.) You can email us at KidsGotGame@NoCrusts.com, follow us @NoCrusts on Twitter, or sign-up to receive email updates.