When I was interviewing for the Community Manager job with Palm’s Developer Relations, I found myself sitting in a conference room with the person who would ultimately be my boss, and we were talking over various aspects of the job and the usual interview questions and chatter.
And then she got a smile on her face and the question came out of left field: What would you do if I asked you to lie to the developers?
It’s actually an easy answer. I said I’d lie.
Because I would. And did. Because for all I tried to be the internal advocate for my developers and promote their needs and comments around the company, I was also the representative of the company out into the real world, and my primary role was presenting and protecting the company interests. (any developer I worked with who never realized this at the time, I’m sorry to break it to you now, but really, it shouldn’t be a surprise….)
And then we went into a 45 minute discussion about the implications of lying, and all of the complicated issues surrounding it, such as damage control when we got caught (no IF we got caught. ultimately, you will), and how part of my role was helping advise the company to try to make sure we never got to the point of having to lie (a good idea in theory, but people need to listen to your advice for you to influence decisions).
And to me, that’s at least the theoretical purpose of the Developer Advocate role, no matter what job description it’s tied to. It’s the person who not only interacts with the developers, but synthesizes down what the developers are saying and spreads that condensed version of the developer into the different part of the organization so that people planning products and making decisions that impact the developer can understand what they’re saying and what they need to be successful. (this, of course, assumes that people within the organization actually want to hear what the developers are saying. To the degree you have people deciding what developers should have, vs figuring out how to give developers what they’re asking for and saying they need, you have a conflict. Which in my experience is handled by finding out about meetings where decisions are made well after they actually happen….)
These are the kinds of questions that ought to be asked when trying to hire this kind of role, or in trying to figure out if you want to be hired. It’s all well and good to get all touchy and feely about taking care of developers and working with them to be successful (and yes, we did all that, too), but where it gets real is when it hits the fan, and then everyone on all sides need to know how people are going to react because that’s the time when you least can afford surprises.
(the honest fact is, I think my parrot could be a develop advocate for a platform when things are going well. What defines a good one vs. a weak one is how things go down when things aren’t going so well. I just wish my time with webOS had had fewer of those times, and more of the “yeah, this is easy!” times…)
What defines these roles is how the people in them handle crisis and challenge. And the ones that handle crisis well tend to be the ones that know that crisis is inevitable and do as much planning and work ahead of time so that when it hits, there are already options in place to handle whatever comes at them. And hopefully, is watching both the inside and outside of a company closely enough to know the crisis is coming, even if they can’t prevent it…
