Developers are sacred in the startup world. They’re in demand (especially here in the Bay Area) and they build truly amazing things. So it’s not surprising that many companies err towards building walls around their developers. They try to keep them safe from distractions and annoyances, so the developers can work their magic.
Unfortunately, developer magic is useless unless customer ideas and issues are being addressed. And that requires working with the support team…which can be fraught with frustration. How do you build a balanced relationship with your development team?
Respecting boundaries is of major importance. As outlined in the brilliant post by Paul Graham, developers need “maker time” – uninterrupted periods where their brains can drill into a complex task. Throwing issues at them left and right is a huge distraction, and likely to annoy the hell out of them. Using an official channel for bugs (such as Codebase or JIRA) keeps things under control.
This requires some serious acceptance of give and take. The development team needs to accept that they have to spend time fixing bugs, or the system will become a bug black hole. And the support team needs to understand that not everything will get done.
Another useful tip is for the support team to bring the full context of issues but not prescribe solutions. As I mentioned in my presentation on collecting customer feedback, it’s important to bring fully fleshed out pain points to developers: how many people this affects, on what systems, what exactly is frustrating, how upset they are, etc. But it’s equally important to avoid suggesting a solution. That’s the job of the product team, and taking that away from them won’t engender any good will.
Of course, the simplest way to encourage good support/developer interactions is for the two teams to like (or at least respect) each other. Break down the walls! Support agents should be sitting near developers, lunching with developers, playing dodgeball with them, etc. If you don’t really know each other, things are going to be even more awkward. It’s amazing what having a beer together can do.
These are insights from my experience here at UserVoice, as well as from my community manager discussion group. But undoubtedly this is just scratching the surface of ways to work with your development team. What tricks have worked for you?