Engineers don’t like salespeople. They see them as tedious, aggressive and lacking in depth. They’re generally wrong; salespeople can be earnest, caring, friendly and genuine. But, when you try to cross the communication chasm between sales and engineering, it’s important to remember you are swimming upstream against a tide of stereotypes.
I’ve worked at places where sales was explicitly banned from communicating with engineers. It was believed (probably based on experience) that if sales could communicate directly with the engineering staff they would cajol them to build whatever the latest lead needed. This is a legitimate fear, running a company often means deciding not to build something a lead wants which is not what a salesperson wants to do.
That said, it often is necessary in a small company to do everything you can to make customers and potential customers happy. That requires a line of communication between the people selling and the people building. So how do you get what you need from developers as a salesperson?
Let’s get a few things out of the way right away. The stereotype is that developers are not quite like other people. They don’t care as much for small talk, they like to argue and to be right. Like every stereotype, it just isn’t true for everyone. Many of the developers I know are affable, gregarious and care more about people than arguments. Like any other interpersonal situation, the best bet is always to judge the person you are talking to based on their actions, not your preconceptions.
Let’s take a look at how a request might go:
ACME needs search by Thursday or they’ll churn
There are many things wrong with this communication style.
Don’t make your problem, their problem
This is just a property of dealing with anyone, not just engineers. We all know what our job roles are, and an attempt to pass your responsibilities onto someone else isn’t gonna engender good feelings.
ACME needs search by Thursday or they’ll churn. That’s $20k in monthly revenue which would be a big deal for the company.
Development priorities are generally set somewhere near the top of the company, not by any individual developer. Similarily, development work takes time, even if something might not be done yet, there may be some very good technical reasons it’s taking so long. If something didn’t get done, it’s likely that was the fault of the priorities set from on-high, not the developer you’re talking to.
A better course is to ask for help:
ACME needs search by Thursday or they’ll churn. That’s $20k in monthly revenue which would be a big deal for me. I know it’s not your fault or your problem, but if you can help at all I would really appreciate it.
Realize What You’re Asking For
If you need something done, it means other work won’t get done. That means the big task set by the CTO may not happen this week. Or, worse, it might mean you are asking a developer to stay late, missing out on their families and hobbies. This might seem like a reasonable price to demand for the success of the company, but remember that overworking has very real costs. It lowers productivity in the future, and it takes a toll on our lives. It’s also a great way to lose developers to other companies who show them more respect.
Explain The Business & Customer Value
Developers want to create good software. They want to solve user’s problems, and they want the business to succeed. In the modern world however it is a sad fact that many companies don’t do a great job of communicating the business’s day-to-day with its developers. Developers are generally smart and interested, they are capable of understanding what is going on if it’s explained, and it’s likely they’ll agree with the need to get this task done. Explaining the bigger picture is the absolute best way to get developers to work hard for you:
We’re working hard to make a really aggressive sales target this quarter. It’s not easy, but if we can manage it it will really help us raise our next round of funding. I know it’s crazy, but ACME said if we can’t get search done by Thursday they’ll cancel. I know it’s not your fault but do you think we can make it happen?
The last example included two new elements: “I know it’s crazy” and “do you think we can make it happen?”.
“I know it’s crazy” shows that you understand that the idea that a couple frantic days of development should be required is not the norm. That’s important because developers are often used to other parts of the organization not understanding that there are limited resources and it’s not always possible to drop everything to put out the latest fire.
“do you think we can make it happen?” shows that you respect the developer’s opinion as a contributor to the companies success. You aren’t giving an order or a demand, you are explaining a serious situation to a coworker and asking for their input and help.
When you ask that question the developer may say “no, I don’t think we can get it done.” That is not a bad response! Would you rather find that out now, or when the deadline has come and gone? Also, it gives you a chance to brainstorm and find out if maybe something simpler can get done which will satisfy the customer.
I’ll be the first to admit that being a software engineer can be one of the cushyiest gigs ever to exist. That said, it also comes with the stress of any job, including that of having to deal with many people who want many different things and who don’t understand the work involved in any of them. Empathy to that challenge can get you very far.
Explain The Problem, Not Just The Task
Engineers solve problems. You don’t ‘build a bridge over the Hudson’, you find the best way to meet the current river-crossing traffic demands which balances cost, building time, reliability, traffic on the river and a thousand other factors. An engineer familiar with your product will have many of those constraints in their mind. If you just ask for the first solution you can think of, you may miss out on something which is both faster to implement and better for the user.
They need search so they can find their customers who are filing support tickets.
Might get you the response:
Well, we can’t get search ready in time, but we could make a way for their support tickets to link to their customer pages. Would that work?
Ta da! A solution which will get done, and will blow away the customer’s expectations.
Accept That The Best Answer Might Be No
There is always more to do at any product company than there is time. It’s possible that this specific customer request will never come up with any other customers and the customer doesn’t bring in enough MRR to make it worth it. It is a well recognized concept that there are customers of many organizations who actually cost more in support than they pay. If you can’t get more cash out of the deal it might be time to say goodbye to this customer.
Work At Least As Hard As They Do
It’s no secret that salespeople don’t always know what a developer does day-to-day. Even more true though is that many developers don’t really know what salespeople do. It can look like the job of being a salesperson is just chatting on the phone and going out to fancy dinners all day. Of course, sales is an incredibly challenging job, but the perception, however wrong, matters. To an engineer it can look like you spend your time making promises they have to keep. The best remedy is to stay in the trenches, working hard at your job, showing you are just as committed to the companies success as you are asking them to be. If the goal is to get your team committed to your goals, no one should be suffering alone.
Of course, this goes the other way too. It doesn’t feel great to watch developers play a game of ping-pong when you are stressing over the latest deadline. It’s valuable to remember that everyone needs to blow off steam sometimes. It can be helpful to remember that every organization has a certain amount of engineering resources. That number is never ‘every engineer working in front of their computer furiously 24 hours a day’, it’s ‘engineers working as hard as they’re able to given the constraints of their lives and personalities’. The goal is to use the resources you have as well as you can, not demand superhuman endurance.
A Formula You Can Use
Here is the four-step formula you can use any time you need to get something special done by a developer:
1. Explain the ‘big picture’
Explain why this matters to you and to the organization. Don’t assume that the engineer knows what is going on inside the sales team or the organization, they might not.
2. Make a personal appeal for help
Ask, person to person, for help in getting this done, recognizing you are asking for something above and beyond.
3. Detail the problem and what you think a solution might be
In a few sentences explain what the customer asked for and what problem they are trying to solve. The second part is very important, as what they literally asked for may not be a very smart thing to do at all.
4. Listen and collaborate on a solution
The developer might need some time to think, or might have a solution now. Building a product is a collaborative process, it’s not about any one customer at any one time. But, if it’s in the interest of the company, or you have been able to express how important it is to you personally, it will get done.
Here’s a complete example of a request that would have a good shot of getting you what you need:
Right now we are trying to hit a pretty big sales target set by management. We’re all going a little crazy trying to make it happen, but it’s a challenge. I have this prospect who would bring in enough revenue to make a difference, but they’re asking for a way to export their data. They need it because their compliance requirements say they need an offline backup of all customer data, even what we store. I know it’s not on the product roadmap, and it’s a big ask, but can you think of a way we can solve that problem for them and close the deal before the end of the month?
If you liked this and would like more, subscribe below!