In developer relations, we are often a cross-functional team, sometimes seen as a support and amplification mechanism for core teams like engineering and product. A “nice to have”, but not necessarily required component for program success.
Personally, I am not comfortable being considered “nice to have”, so how do we change that?
We need to inject ourselves into the early decision-making process for a product, make people understand that a great developer experience isn’t just “nice to have”, it’s critical to any developer-facing product’s success. Without this, developer relations can be relegated to being a bandaid to a poor product experience, plugging holes with documentation when they should actually be product changes. I believe that the most impactful thing we can do in developer relations is influence product to make the right decisions for developers and establish a culture of excellence around the developer experience.
But how do we do that?
In this article I’ll share my recipe for how I approach this problem, what I have found works, and hopefully it will work for you as well.
What not to do
Convincing a room full of stakeholders and decision makers that prioritizing your idea is a vital skill for most professions. Many technology companies attempt to have a democratic process for ideation where it’s not suppose to be about who has the most impressive title in the room or the loudest voice, but who has the right idea at the right time to solve the right problem.
However, even if that’s you, there’s an art and a science to convincing people to believe in your proposal because everyone else in that room likely is convinced that they have the right idea. In developer relations, it can sometimes be a challenge to show why product improvements related to the developer experience should be prioritized.
You may hear statements like, “Yes, I admit this is an issue, but how big of an issue is this?”, “Can you show what impact this will have?”, “Who is asking for this?”, “People are figuring it out now, so why change it?”, or “Can’t we explain that in the docs?”
Sprinkling some doc magic onto a broken experience is not going to solve the underlying issues, but how do you make other people understand that? Before we dive into my approach for this problem, let’s take a look at what does not work.
Throw it over the wall and hope someone picks it up
I see this all the time. People collect the feedback or have an idea based on their experience with the product, but beyond sending an email saying we should do X, Y, and Z, there’s no follow through on the idea.
This is not going to be a successful strategy no matter how great your idea is. The people receiving these emails likely already have a plan in place and a roadmap in mind, it takes more than an offhand email to convince them to make changes to that plan.
Put yourself in their shoes. Let’s say you have a vacation planned to go to Hawaii. You did the research, you even bought your ticket and booked the hotel, would someone emailing you suggesting that you should change your plans and go Aruba because they say the beaches are better change your mind?
Probably not. What would change your mind?
Maybe if the trip to Aruba was free, or there was something happening in Hawaii that would significantly impact your chances of having fun there. Bottom line is, it would take a lot. Jonah Berger, author of “The Catalyst: How to Change Anyone’s Mind”, says that gains have to be double to overcome switching cost. Remember this.
Scorch the Earth
You can pound the table, complain, get loud, and scorch the Earth to intimidate people to give you resources to pursue your idea. You may get what you want in the short-term, but this is not likely a long-lasting recipe for success.
As Carl W. Buehner is credited with saying, “They may forget what you said — but they will never forget how you made them feel”.
Passion about an idea is good, but anger is not. Anger reads like a lack of confidence, while calmness exudes confidence. You need to learn to work with people, understand what they care about, and be able to articulate why what you care about is vital to the success of the program.
Complain but offer no solutions
You know what exists now is not good enough, but other than complaining privately to your work friends, you offer no solutions and can’t understand why no one cares about this or fixes the issue.
Obviously, this is not going to do anything. Complaining privately might feel good, but it’s ineffective to get what you want.
You have to take responsibility for problems even if you didn’t create them if you care about having them fixed. You need to make others care about the problem and the solution.
So how do you do that? Let’s now turn to my strategy to making people care.
Strategies for influence
We’ve looked at what you shouldn’t do, but what strategies should you be using. Below is my recipe for getting buy-in for an idea. It’s not about using just one of these, you need to use them in combination. Even if you don’t work in developer relations, I believe these strategies could work for you.
Own the problem and solution
If you want people to overcome the switching cost, you need to put in some work. Dive deep into the problem, do research, talk to developers, try to figure out the scope of the problem.
Put together a document explaining the problem, scope, and potential solutions. Enumerate the pros and cons to those solutions and the amount of effort and resources required.
You need to be prepared to be the expert on this. The document helps show that you’ve thought deeply about the problem, the research should help scope the size of the issue, and you’ve already done legwork on potential solutions. This goes a long way to demonstrating that this is coming from a real place and there’s concrete ideas about how to take action. It’s much easier for people to get behind something that feels real and solvable than something much less defined.
Show what it means to not solve the problem
While you’re taking your deep dive into the problem, you need to demonstrate what the cost is to not solving this issue. Articulating this with statements like “it creates friction”, “it slows developers down”, or “it’s confusing to developers” is not going to be good enough.
Those may be true, but you’ll likely hear your co-workers and stakeholders acknowledge it’s an issue, but is it the “big” issue to focus resources on right now?
“It might not be an ideal situation today, we can address it later, but developers will figure it out.”
Instead, you need to frame the problem in terms of costs. Try to answer these questions:
- How does this problem negatively impact growth numbers and how would solving it positively impact growth numbers? Show actual numbers.
- What financial cost does this problem have today? You can look at things like developers failing to complete the sign up process or launch something on your platform due to the issue or bugs reported that support teams have to deal with or how much out of band engineering time has been devoted to dealing with one-off issues related to the problem.
- What are your competitors doing? Sometimes highlighting how the competition is doing a much better job than you can really motivate someone.
Build a coalition
It’s important to build momentum for an idea and support that goes beyond just you. Start with people you know, pitch your idea, hear their feedback and questions, rework your pitch accordingly, and then extend your circle of support.
This way, when it finally comes time to discuss project priorities, you won’t be the only one in the room that knows about this idea. The people you’ve primed can jump in to help support you.
This creates more of an uphill battle for those that might instinctively want to de-prioritize your suggestion. Now, it’s not just you they are turning down, it’s a room full of people.
It can also help to speak with key stakeholders 1:1 ahead of a group meeting. I’ve found that some individuals are more amendable to new ideas that aren’t their own when approached 1:1 versus in a group. It’s a strategy worth trying if you find yourself being unsuccessful with particular people in the larger setting.
Over prepare
I originally had this strategy suggestion as “Be confident”, but it’s hard to control confidence, but you can definitely control how prepared you are. And being fully prepared can lead to confidence.
You want to show that you are an expert on whatever idea you are pushing for. Know the numbers, know what matters to everyone in the room, and be able to answer questions succinctly. If you can do that, people will see that as confidence even if you’re nervous.
Use the collation you built up as a way to prepare. Starting with the friendliest faces amongst them, have them try to pushback on your idea. Do you know the answers to their questions? Can you respond to their pushback in a constructive way?
Always having an answer ready for any probing question and remaining calm are attractive qualities and will draw people to you. This will help immensely with getting people to believe in your ideas.
Chase it down, hustle, don’t give up
This goes back to the first item I highlighted in this section about owning the problem and solution, you also need to continue to own it even if you first meet resistance. Try to find out what would other people need to see to be convinced to prioritize your idea. Based on this information, you can find new data or adjust how you articulate the problem to convince those people.
And if you do not succeed at first, keep trying. Give it a break, but bring it up next quarter. Maybe you’ll have more evidence or stronger data at that point, but if you really care about it, don’t just drop it.
Timing
You need to pick the right time to push on something. For example, if your company just set priorities for the next quarter, resources have been allocated, various leads have all aligned, now is probably not the best time to pitch something new. There just won’t be much energy available to entertain it and even if people agree with you, it’s not likely to derail an existing priority meaning you’ll end up having to pitch it again during the next prioritization meeting for the following quarter.
I try to start building my coalition about an idea 1–2 weeks ahead of any kind of larger prioritization effort. At any reasonably large company there’s a million things going on, a million ideas floating around, people tend to have short-term memories and are always chasing the next big thing. You want whatever you’re pitching to still be top of mind, so you can’t start these conversations too far out.
Reduce scope if needed
Sometimes you have to compromise on your vision a bit in order to get buy-in. People might not be ready to fully commit and want to see some positive ROI before investing further.
If you have to compromise, figure out what the minimal deliverable scope is that can help create more momentum for further investment in this area. If you can do that and prove there’s value in solving the problem you care about, people will be more likely to expand investment in the future.
Success often builds from prior success, so compromising now to get your foot in the door with an idea can be well worth it if you can measure and show the impact. This will make the next idea pitch easier and you may not need to compromise so much upfront.
Final thoughts
Our job is to care about developers, so our natural reaction to pushback on an idea that will improve the developer experience is that the internal decision-makers don’t care about developers. However, that’s often an unfair and short sighted view of the world. A product or company lead likely does care about developers, but it’s one of many things they care about. The bottom line is they care about the success of the product. It’s our job and responsibility to make them see that prioritizing developers is a key component to achieving product success.
Influence is about making people believe in you as much as it is about believing in your idea. Also, if it turns out you were right and your idea leads to overall program success, that builds trust, and you’ll have more support for future ideas. People will want to believe in what you say and you won’t have as much legwork to do to get ideas prioritized.
We all want to be successful. Connecting and showing program-level success due to making the right product decisions for developers is how you start to build a culture of excellence around the developer experience.
