Ask Slashdot: How Best To Teach Programming To Salespeople?

First time accepted submitter greglaw writes "Our company makes development tools, meaning that all our customers are programmers. If you'll forgive the sweeping generalization, on the whole good programmers don't make good salespeople and vice versa. However, it's important that our salespeople understand at some level the customers' problems and how exactly we can help. The goal is not to turn the salespeople into engineers, but just to have them properly understand e.g. what the customer means when he uses the term 'function call.' Most of our customers use C/C++. Does anyone have any recommendations for how best to go about this? Online courses or text books that give an introduction to programming in C/C++ would be great, but also any more general advice on this would be much appreciated."

BASIC suggestions

[Sarten-X]

As mentioned elsewhere, there's not much better than having Real Engineers go on sales calls, too, to answer the technical questions. You can teach salesmen all you want, but they won't be able to fake the insight gained through experience.

All salesmen should have some familiarity with the industry they're marketing to, though. They should have an understanding of how a programmer's mind works, and how your product makes the customers' lives better. For that, I recommend BASIC more than anything else. Not VB, mind you, but good ol' BASIC [freebasic.net]:

• It's (usually) plain English. There are few abbreviations, and most structures read as a straightforward sentence. That helps to keep focus on general structures and concepts rather than syntax details.
• No overhead. There is no boilerplate necessary to just make something that runs. That means that your first lessons can cover things like "the program runs one step at a time, in order," which is a lesson often missed in many introductory courses, and not obvious to many non-programmer folks.
• Most structures (depending on version), in simple form. No, you likely won't find multithreading, but you can show a function call, loops, conditionals, variables, objects, and most other programming elements just fine, and without needing much other syntax to make a demonstration program. Pick a flavor of BASIC that includes features supported by your product, for illustration.
• No practical application. This is a bit of a lie that really should be told to all students. Make it clear from the start that they should never attempt to write a "real" program in BASIC, not because it's impossible, but because there are far better languages out there. Toward the end of the lessons, start introducing them (especially C/C++, since it's what your customers use). Use that as a leaping-off point to show that all languages are functionally similar.

Once the run-through with BASIC is complete, you can expect the salesmen to understand how to read a simple (and commented!) program, and work out what it does. Show them equivalent programs written in C, C++, and BASIC. Be sure to point out how your product makes life easier, and show how a competitor (or Notepad) doesn't, tying in the lesson with the ultimate goal of making better salesmen.

You definitely won't be producing any great programmers, but you'll give them a glimpse of the mental juggling we do. They'll be able to recognize common use among customers, and possibly even impress a few with their knowledge. That's enough to significantly improve their relationship with the potential customer.

Re:Hire bad programmers with good social skills

[Cryacin]

Actually, the GP is pretty spot on. There are two types of sales people generally, the Hustlers that tend to act like a hairdryer at management, playing buzzword bingo to provide the required level of synergy with the current corporate strategy, or the sales types that tend to understand what they are selling, and explain the benefits of the products.

Contrary to popular belief, most programmers are not socially inept basement dwellers at the mom's house. The sales person does not need to know 100% of the technical aspects, they need to be able to convey what can be done at a coarse level, and then for detail, reference a skilled programmer.

Furthermore, if you are selling into a corporate scenario rather than a small business, your business owner will at best "know of" programming. They will want to know what your product will do for his business, and let his technical guys determine if it really will do that. Really, I have yet to meet a CEO or any other Chief (Insert middle title here) Orifice that has programmed in the last 5 years.

Hence, you'll need a standard winer and diner sales person for the C(X)O's and/or middle line executives/enterprise architects, and a technical sales person for the developers/team leads investigating the technology on a ground level.

Re:Hire bad programmers with good social skills

[FormOfActionBanana]

Don't talk about this like it's magic. Sales is a really tough job and you have to be a 1/100K personality type to succeed. My organization sells static analysis software, and our salespeople are a mixed bunch and have a lot of varied tech experience from their past lives:
  - former military pilot
  - former DEC programmer
  - fool
  - MBA
  - former vintner
  - former VAX/MVS/AS400 tech support

Nevertheless, our assumption is they know all about the customer's problem (manage costs, control risks, pass an audit, build a legacy) but know NOTHING about the technology, and we remind them of such. We pair up the salesguys with a "presales engineer" who is much more techie and a product expert but less responsible for the relationship.

Really, this is a very standard way to do technical sales. I thought everybody knew this.

Re:You need a technical pre-sale consultant for th

[NFN_NLN]

I wouldn't even try.

Sales people need to be adept as selling a business story and should be able to talk to project managers and other budget holders about the business benefits of investing in the tool.

You can't cure willful ignorance. If a salesperson actually gave two shits they would pick up a book and learn basic programming skills on their own.

Why not try the same strategy that helps today's programmers constantly learn new languages, libraries, version changes, etc: if you don't keep up... you lose your job to someone who can. It seems to light a fire under the ass of IT people.

Re:Hire bad programmers with good social skills

[Anonymous Coward]

Yeah, I agree. The idea that programmers are basement dwellers needs to be confronted. If you look at the Jung based MBTI assessments, I know from 20 years of experience in the field that great developers depend on the middle two dichotomies, not the outer two. In other words, an ENTJ can be a good programmer, and so can an INTP. INTP might be your basement dweller, and ENTJ is like P.T. Barnum and Thomas Edison rolled into one. The important part is that they're "rationalists" -- they're good at problem solving, and in most cases like doing it -- that comes from the NT part. (They're "intuitive thinkers" per the MBTI parlance).

If you're looking for a good salesperson that can walk the walk and talk the talk with developers, what you're looking for is the ENTJ. They get a charge out of working with people, and they are quick to make assessments -- a key skill for a salesperson. They're also rationalists, so they can have credibility with your developers (as long as they don't overdue the glad handing -- especially when dealing with *NTP types). An ENTP might do ok, as long as they're not off the scale on the J/P dichotomy (then they become too indecisive and have a tendency to lose a lot of sales because they never "go for the kill").

Of course, if you're dealing with large corporations, what you'll find is that the management layer is not universally filled with *NT* folks as others have mentioned. That's what makes Dilbert comics funny for example -- the pointy haired boss is not, and most likely never could be, a critical thinker. In that case, you're looking for ESFJ types -- the traditional sales guy -- these are people who get a charge out of working with others, tend to notice things like body language, tend to put a lot of emphasis on making people feel good, and tend to be quick at making decisions, which gives the perception of being decisive. They also tend not to like absolutes, which drives rationalists crazy, who structure their whole thought process around solving problems, which requires some absolutes (givens) in order to make progress.

Although MBTI isn't perfect, it does divide the world into 16 categories of people, and that rough categorization can go a long way toward getting the right people in the right seats on the bus. The rationalists (*NT*) make up less than 20% of the population. So if you're interviewing fewer than 5 people to fill a position, then there's a pretty good chance you haven't seen your minimally qualified candidate yet (although, rationalists tend to be attracted to engineering roles, so that's more of a rule of thumb than anything -- we never interview fewer than 5 people, so we can at least say we gave it a fair shot).

MBTI is especially good if you combine it with one of the other assessment tools like HBDI or DISC. (It's certainly a lot better than shooting from the hip -- which is what a lot of shops do unfortunately.) People who don't register highly on the NT dichotomy can actually work ok in a development team for a while, but there's a good chance they won't like it over time, especially if they're the opposite profile (SF), which leads to unnecessary turnover.

Let your salespeople know their limits

[wienerschnizzel]

Unlike others here I don't think you should fire your sales staff and let the tech people handle all the talking. It's not realistic and it's not efficient.

Instead, let the sales people know their limits and when they reach them while talking to the customer, let them propose to organize a meeting between the potential customer and a developer. Have them say "Look, I'm not a coder myself so there's only so much I can tell you about the details of our product but if you are really interested, you could talk to one of our developers."

I love to hear that as a customer - I can tell when a salesperson is out of his/her depth and it's great to see they realize it and are open about it.

Have your developers do consulting duties where they do these kind of talks - you'll have to coach them a bit about what to avoid when talking to a customer - but unlike teaching your salespeople how to code, this is doable.

You can also push the limits of what the salespeople understand up to a point - you'll have to discover what that point is for yourself - after that it's a waste of time and money. You can probably make them do some simple hands-on on coding just so they see what the difference is between code and a binary and how you get one from the other and such things.

Re:Better: use the existing programmers

[Yvanhoe]

When I was an employee I doubted that salespeople were doing a work worth more than what programmers did. They told me I was naive. I became freelance and had to do the sales work. It is really as simple as it look : Meet clients, organise meetings, eat food together, sign contracts and hassle them when they don't pay. Being the programmer of the product gives you an incredible edge in negotiation though : Normal salesmen talk about the advantages of a product without understanding anything about what they say. They sometime sell features trying to guess how hard it is to get them done. Being an engineer really gives you an edge. You know you struck gold when a small feature can be sold for 10 times what it will cost you.