Jeremy Glassenberg is an experienced product and developer relations manager across multiple industries. In this session from DevRelCon San Francisco 2019, Jeremy explains what you need to understand in order to handle difficult personalities in your partner community.
All right. Well, welcome everyone. Basically, for the next 20 minutes, I am just going to vent about the worst partners I have ever dealt with in developer relations.
No, but I have selected a handful of stories, some good stories actually, some challenging, and some really bad stories that I think align very well with what we’ve all experienced when working with partners, and in my case, in a good mix of industries.
Try going through my summary quickly, this is my most hated, about me, my most hated slide, the “About me” slide. But basically I’ve worked on a lot of developer platforms in a good mix of industries.
The ones I’m most well known for are Box and TradeShift, then I have a long list that either nobody’s heard of or that I’m not allowed to talk about, but have worked in enterprise technology in various areas to be and supply chain, as well as in education technology at Edmodo.
And on a consulting basis, I’ve worked actually in private space, I’ve worked in drones. So I’ve seen a lot of things in the world of developer platforms.
One thing that I have seen across all industries is a lot of jerks. So we’re going to get into that. This spans across industries no matter what, you’re working with partners, there are a lot of difficult people.
I do want to set a base first then go through this quickly just where I think we’re positioned as developer advocates in the world of APIs, and I will actually challenge an earlier presentation that highlighted how, you know, very often, well I would agree that developer advocates are very often covering for the failures of product, and I’m saying that as someone who is actually primarily a product person. Usually, I join an early-stage startup.
I joined Box when I was less than 20 as a product manager for the developer platform. But to actually make the platform successful, I had to become a developer advocate and over time manage both product and build our developer relations team.
I’ve done that a few times so as a product person, I would agree very often developer relations is making up for things that we didn’t accomplish as product managers.
However, no matter how well-designed an API is and developer-facing product is, we still need developer relations. I’ve learned that a lot from experience, this comes from John Musser basically the top 10 list of what developers can’t stand when they’re working on a new developer platform.
I’m sure most of you have seen this. Eight, nine and ten are about API design and product. One, two, and three are about communication support documentation.
So very often, developer relations is just more important than the core product. This is where I also have to emphasize that you can’t make a developer platform 100% self-service in practice.
Speaking as a product person, there is no set it and forget it. Things should be designed that way in principle to have a developer platform that is so simple that it can be self-service, but I find that among our better partners they still need guidance, they need to coordinate with us and so developer relations is vital.
For some reasons, there’s this general bias in the world of developer platforms. There’s also this you just build it and people will come, if you build it they will come.
You know what? As a Midwesterner I have to highlight this movie where it comes from, “If you build it, they will come.” The customers who they attract with that philosophy are the baseball players who took a bribe to throw a World Series. So even in that movie, they’re not actually attracting the customers you’d really want.
So we understand the importance on the product side of things of having developer relations, that relationship with the external developer community. And when I’ve built out developer relations teams or when I’ve just been on the product side and partnering with a developer relations team, I have a lot of empathy because I know how much this job can be a pain.
Because inevitably, you know, when you join a company, you meet the team, you know who you’re working with, but then you’re working with that external community, and you just don’t have control over who you’re working with.
Fact is, partners are going to be difficult. In fact, our species has simply evolved from other species that naturally have jerks in their societies. Now I actually have a whole talk on the psychology of psychopaths in chimpanzees. I’m not going to get into much of it here, but I do find that it is important to understand difficult personalities.
I’ve studied a lot about narcissistic personality disorder and the different types of narcissistic personality disorder. We don’t have time to go through that today. I will share some reference articles later but I do encourage you all to study this.
When you’re dealing with difficult personalities, it’s important to segment the difficult personalities so that we can progress in order to manage them. And I’m going to share some very simple tips to segment these kinds of personalities.
By highlighting what I find to be the most important error in Silicon Valley culture, the most important misjudgment in hiring, this assumption that you have to hire these aggressive super Type A kind of people, but also be careful because Type As are hyper-competitive and they don’t get along with other Type-As. It’s actually all B.S.
They just haven’t looked into the psychology of Type A personalities to understand that there are different types of Type As. And I’m sure we’ve encountered the Type As that we like on the job.
In its simplicity there’s Ego Driven and what some say is Mission Driven but I think it’s more important to say Empathy Driven. Those who are working those extra hours because they like helping people. Their mission is to build something that helps people.
These are the kind of people who, when they’re working on your APIs, they find flaws in your APIs, either design flaws, gaps, bugs, they let you know about them. They don’t complain about them, they try to find a workaround and when they find a workaround, they let you know how they worked around it.
They ask for permission to use it if they’re afraid that there may be some sort of TOS violation and those teams you find, they are the best. That not only are they the easiest to work with, the most pleasant to work with, but they’re the best at execution. They’re building the better products.
The worst are the toxic ones that have taken up a lot of your time, and there’s a spectrum in the middle in practice. They are the Type B and Type C personalities who just aren’t executing and sometimes they’re part of a team where you know you need to get them over a hurdle to get them to execute, to get something done but you just don’t have control over that situation.
There’s also the good personality who’s gotten frustrated and so it’s important to segment out the people who are genuinely toxic from those or are just a little frustrated or those who just for various reasons aren’t executing.
Once you understand who you’re dealing with, we can apply a process of response. That understanding goes to the assessment step, that’s step two, but we’re going to start in step one which is basically, be aware that you’re dealing with a difficult personality.
You can usually tell by when you’re getting angry. So I’ve gotten enough experience in dealing with a difficult partner, starting to get angry and then actually writing a response while I’m still angry.
Now I have this self-awareness thing that tells me when I’m getting angry, “Hey, you’re getting angry. Don’t send an email now.”
In fact, if you’re running a team and you have some junior developer advocates you may want to try writing a Zapier script that can work with an Android watch or an iWatch and detect if the individual’s heart rate is increasing while in Gmail some email will just get marked as read. And when that happens, try to just trigger auto snooze. I hope Gmail like now has like snooze in their API so you can just like automate this.
But no, like try to, we probably don’t have that in the Gmail APIs yet, so we have to remind ourselves take a moment to assess the situation, don’t respond right now.
Assessment. We start with understanding the problem. The problem could be two factors, what are they trying to achieve and what’s stopping us and within that, it is probably dealing with a difficult personality.
So that’s where we have that segmentation, understand the difficult personality. Is this that we’re dealing with a narcissist who’s going to be adamant about taking things the wrong direction?
Is it that you just have a frustrated partner who for whatever reason they were legitimate we may have done something wrong, we have to turn this around?
Then what’s the goal here? Is it to just get this product launched in our marketplace? What are we trying to do next?
And I have to emphasize there are different types of goals if you’re running a marketplace or if you’re just running an external API and maybe just want to maintain long term relations with a company where you don’t think they’re actually going to be a long term excellent partner.
Either way, and whatever the reasons, I’d say it is never the case that the goal is just to prove that you’re right. Now some of that is our own ego to have to prove that we’re right. Some of that is a logical thing that we’re trying to move from point A to point B, you’re trying to this logically and you’re going to state the facts and you may be factually right.
Be careful here, because good developer advocates, we’re lower in ego, and if you’re dealing with a difficult partner who’s higher in ego, who’s higher in narcissism, one thing you know about narcissism is that you probably care less about being right than they care about them being right.
So being right here is probably counterproductive to your goal. Try to remind yourself of that to avoid that mistake when you’re establishing what really the goal is, what is the personality, I understand the psychology of this person.
With that, I can figure out how to actually execute on this situation to come up with a solution. And that solution is going to involve communication, only then do you actually respond.
So I want to share a few examples of how we actually do this in practice. I’m going to start with the easier ones, a lighter situation. This isn’t really a high ego partner. This may be the inexperienced partner.
I’m running a marketplace of 2000 apps and I’m at a startup where I have two developer advocates with me managing this and we have to grow this by another 2000 developers in the course of a year. We don’t have time to take every single phone call that a customer wants but they feel like they need to take up our time, that they don’t really know how to communicate better so they start sending messages like this.
We have to get around this issue but we don’t want them to feel like we’ve shut them out. We need to make this conversation more productive.
So we have our goal, what’s the solution? Sure. We’ll offer to talk with you. We’re going to give you some time and what this is actually about is directing the person to send us an email with some more context, some content, because we understand that 90% of the conversation can actually be handled more efficiently through email, sending technical information back and forth rather than getting on that call without really any sort of agenda.
And when we actually get on a call by that point, we’re going to have a much more productive call. So this avoids the who’s right who’s wrong, it just sends them the right direction and they may learn from this that they can actually be more productive if they’re just getting started in API world.
Let’s move a little bit farther down the narcissism spectrum and get into some let’s say inflated sense of entitlement.
So this is my favorite challenge when dealing with an apps marketplace. Developers coming along and saying, “So when are we going to get featured?”
My favorite are the ones who say, “When are we going to be made a default as an enabled for all of your users as a regular feature?” I have so many emails of these startups coming to me. The founders, the developers of smaller companies saying, “We just see that you have so and so many hundreds of apps or thousands of apps in your marketplace and we don’t want to just be, you know, stuck being part of that.”
Okay. Younger me, my default reaction is to say, “And why do you frickin’ feel like you shouldn’t be with everybody else, why you’re entitled to be better than everybody else?” But obviously that’s not a helpful response.
So let’s think through the goal here. Now, in this case, I think there is some ego here but it’s slight. Another quick tip about narcissism, it tends to actually decline with age with the exception of the more extreme cases of a psychopath, and yes. we’re going to get to those.
So the goal here is to try to get them still to be more like our better partners.
Better partners still want to be featured in our marketplace, but they know how to ask about it, they’re going to start by asking, “We’d love to, you know, talk with your sales team, get some more of a sense of what your customers want so that we can build an app that’s a better fit for you. Oh, and we understand that you know, everyone in your marketplace wants to be featured, we obviously do as well. It will be great to understand what we can do to make you, you know, happier to actually potentially make us a featured app.”
You know, they want to make this win-win, so can we try to direct the conversation this way. There are ways of doing that by communicating, you know, we’d be happy to discuss ways of making you a featured service or you know, our metrics for making someone a featured app or basically, do we feel that this is an app that’s a great solution for our customers?
So if you’re open to talking with our sales team, getting some feedback, making some updates to your apps that really is a good fit and we think you’re a good fit for our customers, sure we can talk about featuring. Try to send them the right direction, give them an opportunity.
All right. I’m trying to go a little bit faster, because I know we started late here. Well, let me go through the more fun, some of the more extreme examples.
So this is where we start getting to higher ego and this is also where we really just have to say no to a customer.
When you work in APIs, I’m sure you’re seeing developer relations but on platform product. I’ve seen the dark side of APIs, a lot of security holes that were opened up and then covered up in API world.
I’ve got a lot of partners, this happened to me in education technology where I was in K12 education, so I was running a service, we were running a service that was actually used by students under the age of 10.
And I’ve also seen it in enterprise software companies including enterprise security companies. They want to launch in our marketplace. We’ve caught a security issue or a privacy issue.
People have different policies in what happens when there’s a UI issue. When it comes to security or privacy, we always say heck no. We’re here to help you out. We can offer free QA and then we get something like this, “Oh, this is just an MVP.”
I’m in product, I teach product management classes I know what an MVP is. MVPs don’t have security holes. They may be missing some features where you’re not sure what the customer wants. You want to test, but you don’t test security holes.
Do I have like three more minutes or before 20?
Person: Like three minutes.
Jeremy: Three minutes, okay.
Anyways, we try to pitch this in their perspective, try to make it feel like it’s their idea, it’s not in their interest to launch something like this. Unfortunately, you’re dealing with higher ego individuals and so this is where I have to emphasize tactically make sure your team is ready for what may come next.
This is the, this is a more extreme challenge that I’ve encountered. So we’re having this conversation around a security issue. They happen to just know somebody else at the company, and they’re just going to go reach out behind my back and start complaining about me.
Maybe they’ll take some quote from an email and manipulate it. And sometimes that’s the fellow director or V.P., Sometimes it’s a C-level and a few occasions it was actually one of our investors. Yeah.
So I’ve learned to be prepared for this by basically letting many members of the company know that this situation can happen and what they should do as protocol, when this happens, is first just forward the email to me.
I know how to stay calm, I can share the conversation to understand the situation and what do they do? Consistently, just have them reply to the person and CC me so that they know they’re not going to get around me.
I don’t have to call them out for it. This is actually also the only time when I say you may not want to respond immediately. I’m a big fan of quick response time. Here I feel like you let them squirm a little bit.
But and then you can continue the conversation. We just made it clear that kind of shenanigan isn’t going to work.
So we’re down to just a couple minutes. I’ve saved the last slides to just cut through these faster if we need to. But I’d like to share one example I was asked, is there a difference between small company, big company.
What I just shared here applies to just difficult personalities that can happen in big companies, that can happen to small companies, I’ve seen this at unicorn startups, but there is a difference when you are dealing with a difficult individual at a bigger company.
When it’s a bigger company, you probably have teams talking to each other so you have your own colleagues to work together to assess how to respond and also you have a team of people on the other end with whom you can work.
So at the biggest secret sauce, I have years to find an advocate on the partner side. Now that doesn’t mean pull some sort of gossipy shenanigan like what I’ve experienced on the other side, but you may find that there’s one difficult person and someone else in the team who knows how to execute.
That’s probably one of those empathy-driven Type As who probably hates that difficult partner more than you do because they have to work with them full time.
So you can basically find a way of working with them directly to get things done in such a way that that difficult partner if they’re high ego, as long as the project is done and they can get the credit for it they’re fine with it. Other trick to the goal is it’s not about getting the credit sometimes.
So to summarize here, what this really comes down to, most of them are the basics that we already know. Listen to your developers. In order set those goals, drop ego. Remember that it’s less about being right and more about getting something over, over hurdle.
And also I’m going to share some examples in the last minute we have here just to emphasize that there are a lot of tactics you can apply, I only had so much time to share them here. So it’s important to study this to understand the different personalities and then how to react.
I’m going to cut through a few of these faster. Do you have like 30 seconds left or one minute? Okay. So in the last 30 seconds, I’ll emphasize one more thing that a lot of this is still ultimately about alleviating pain points.
There is a 90-10 rule that you’re going to probably spend more time with difficult personalities. So how do you alleviate that? There’s some controversy over how to handle it, but I do agree that whatever product can do to help you out by minimizing those cases where it’s just a legitimate frustrated developer either by improving the product or setting the right expectations with your community we can minimize those cases, most of those cases of dealing with a difficult partner.
For the most difficult, again for future references, this book I actually highly recommend for product managers as well. It literally breaks down about a dozen different types of extreme narcissistic personalities.
It really helps you also to alleviate your ego, because you can just immediately assess why are they doing what they’re doing and there are different ways of responding to each of them.
So hopefully that and these others will be helpful in dealing with those more difficult crazy types of people you just have to deal with. Thank you.
Indeed has seen a huge uptick in Hacktoberfest participation from their engineering team. Hear how they did it.
People were organising communities long before developer relations. So what can we learn from those that went before?