Curtis Schonick

Disclosure : I am the founder of Skystra.com. Everything detailed here happened, exactly as described. The only edits are to names, protecting the privacy of those involved.

In Part 1 of my Culture of Sales series, I described the problem we faced : how our company was growing in headcount exponentially, but our new customer base wasn’t. In this part, I’m going to share how we converted the most notorious group of team members to buy into this new culture : Developers.

Every company, wether it’s a technology company, or a small family shop, will come across the need to hire a developer at one point or another. Or a team of developers. Which was the case for Skystra. As a tech company developing a cloud hosting platform, our need for a development team started near the beginning.

Developers are key to a business building and expanding its products and services. Nothing can be built without developers putting in their time, effort and energy into millions of lines of code. And that’s where the problem starts.

When I tell you that developers are key to the success of a businesss, let me also share that developers are not the most open-minded bunch, nor easy to talk to when it comes to areas outside of development. This is because, by the very nature of their work, developers are usually completely silo’ed off from the rest of the business. The directions on what to do come from the top, usually with no contextual explanation of how it will be used, how will customers interact with it, what are the business goals, and so on.

The very first developer I approached, let’s call him Eric, was an enlightening experience. By all accounts, Eric was a solid developer. Code required little peer-review. So when I approached Eric, I assumed an easy conversation about how he can help increase our sales. I was wrong.

Me: “Hey Eric! We just hired a new sales team, and I was wondering if you have any ideas how we can help them, or any input into how the new team should work?”

Eric : “Nope.”

A single one word answer. That was all the feedback a developer who was with us since the beginning had for a brand new team that was designed to increase the revenue of the company, so we could continue hiring more developers and other team members.

The even more stunning part? This conversation went about the same way with the other developers too. A few more words, but in essence, the same outcome.

At this point, would I have been justified to just fire the whole group and start new? It was an incredibly frustrating experience. Instead of going the nucelar options, I had to think about this a bit more. None of these developers are bad people. They’re not anti-social. They just had zero input and interest in anything that didn’t directly concern them. So how do we make something like new customer acquisition a concern for backend developers?

Give your team context and business goals. Give them a framework to understand how the things they build and do will be used. What value do those things have?

The first step was to involve our developers in customer focus group meetings. We held a number of small “town hall” type meetings with customers, and had a representative from every department, ready to listen and ask questions. The first thing that became very clear : Developers coded our systems, but actually had no idea how customers are actually using them!

When customers would bring up certain workflows, or how hard something is to do on the platform, the response was always the same from our developer group : “You should be doing things this way.”. It reminded me of an old Steve Jobs meme during the iPhone 4 era, customers had connectivity issues, and Steve just said “You’re holding it wrong.”. The truth is, customers are the source of revenue in any company, and you better listen to them, not dictate to them.

And now we come to the core change made to the development group, which also applied to all other departments. A new mandate was formed : You must think of yourself as a potential customer before ever writing one line of code. What do customers want? How do they want it? How will they use it? If you don’t know, ask them. Do not assume anything.

We also created a direct line of communication between our new sales team, and our product team. There would be no more silos. The feedback would come directly from customers, potential customers, and the team helping convert those potential customers. No filters, no management layer obfuscating things. Pure, honest, and direct communication.

3 months after making this change, our sign up rate went up 11%. Our new sales team’s conversions between leads won or lost improved by 6%.

We had just taken the first steps at recovering our free cash flow, and growing our new revenue at a higher rate than our expenses.

It doesn’t end there, so we’ll discuss how we achieved scalability in sales in Part 3.



SOURCE

LEAVE A REPLY

Please enter your comment!
Please enter your name here