Slashdot Mirror
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."
Really, it's not that complicated. You want to hire people who have programming background, but weren't interested or talented enough to pursue that full time. And they need better social skills than the average software engineer.
That's all. You can't turn a PHB into a good salesman for a product he can't understand.
...objects can be thought of as wrapping their data within a set of functions designed to ensure that the data are used appropriately, and to assist in that use(1)...SQUIRREL!
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.
The conversation with the programmers is key and important to making the sale -- but's it a different conversation about the job benefits of using the product.
So you need to go in two handed -- a business focused sales professional and a technical pre-sale consultant.
You either need a sales engineer that goes along on calls with the sales people, or simply just send some of your developers out to do sales...
Are you sure sale people will be talking to programmers directly?
It seems very unlikely you can train a sales guy well enough not to enter a giant "uncanny valley" of terminology for any real programmer they would talk to. You have no idea how much that puts of programmers at companies.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Have your programmers with the best communications skills tutor your sales staff. After all, your programmers not only know how to program, they know the context in which the sales people will be using the knowledge.
Ideally, you want to give them a problem to solve that they understand. For instance, have them develop a simple contact management application or sales lead database..
From this point, you can provide them with help and training as needed. Perhaps have them work in pairs.
If they refuse to learn, then perhaps they should work somewhere else.
If you need web hosting, you could do worse than here
Your company either does NOT understand sales people or what it takes to be an engineer. Sales are they to create a relationship with the customer. They usually have ZERO cred on tech issues. Have an engineer partner with the sales guy and team sell.
Give up now, it is impossible.
Your best bet is to go find the best Sales Engineers you can, the ones that don't just know the product catalog and can do a demo but who can install, customize and code integrations while providing solutions, solving problems and essentially doing the salesman's job for him.
Those Sales Engineers are rare, but they are the ones who can turn into what's sometimes referred to as a Technical Sales Specialist: a Salesman who can be their own Sales Engineer. Find someone like that and they will be able to sell to programmers.
First came SlashBI, now comes Slashshot!
Pair someone with strong programming skills with someone with strong sales skills. Lots of tech companies supplement their sales staff with "sales engineers" who know the technology. It's not unusual, and many IT organizations are impressed to have someone with expertise sent along with the sales people.
Insanity is a gradual process; don't rush it.
Write a simple well-documented modular program, teach them to step through it, and let them have fun.
Even better if the program does something interesting (from a sales person's perspective, not yours), and if they can interact with the program by tweaking some constants or by tweaking a formula. Finally, you could even record a video that teaches them to step through code instead of you having to conduct a class time and again.
I can't think of a good example though - something a sales person would find interesting and/or hard to do normally. Any ideas?
A chair and a whip.
In other words, to answer the question: you teach sales people the same way you teach anyone else. Some can do it, some can't. You'll find out soon enough. But salespeople, who understand the sales process, will be the ones you want if you're developing software that salespeople use in the field.
It's true for any industry. Designing software for airline pilots? Hang out with them and see what they want and need. Go back and code it. Done.
Interview university seniors graduating with BSCS or Business programs that have an emphasis on computer programming. Be honest that you're filling sales positions. Make offers to the extroverted candidates that demonstrate the necessary social skills. Mentor them with experienced sales people. Have them sit in on engineering meetings and let them contribute ideas, and throw them an occasional development task so that they remain familiar with your products.
If you want a sales staff with technical proficiency, you're very likely going to have to groom them yourself. Perhaps you can hire them away from other companies that do the same thing, but I doubt you can depend on that.
I can see the fnords!
Really, if you're a programmer, are you going to use a development tool because of something a salesperson told you?
"The Greens lynched a hacker in Chicago. Last month, but I think the body's still hanging from the old Water Tower."
Isn't it best to have people work together that compliment each other. Have some pre-sales people (cycle your devs/sysadmins) go along with your sales people to do the deal. Then you can hand the customer off to your support/dev teams and if they wish to increase spend with you you can cycle them back to a pre-sales/sales team.
The team should be made up of at least 2 people with expansion depending on how complex of a problem your trying to solve. I've worked in a team of 20 before just to carry out a proper specification of the problem. Having a combination of people enables you to spot problems early in the deal and expand upon costing or to give you leaner markups and thus be more competitive.
If your really stuck on the idea of teaching your sales team get them to sit with your coders once a week/fortnight/month. And they can be instructed to ask as many questions as possible if they hear something they don't understand. Thinking that you can give a day training to a sales guy and believe it's going to stick is just crazy.
Also running an agile environment where you do regular showcases and stand ups that sales people attend to at least watch can help sales understand the effort that goes into the product they are trying to sell.
I find it hard to teach a sales person anything because they already know everything. Or wont shut up long enough to get a word in. I agree with the above comment of hiring simi okay programmers with good social skills...
Which word didn't you understand?
I can see you may not be very familiar with corporate sales.
Sure all of the people using and even buying what they are offering may be programmers... but that does NOT mean they are the only people at the company you will talk to about a purchase, in fact there are usually business owners that have to OK expenses too and need justification/reassurances. The sales guy is there to make them feel comfortable that buying your product is good for the company.
In fact the very existence of sales people in the equation straight up says that somebody will non-technical will be talked to at some point, or else they could simply market over the internet. You do not need sales people for something programmers would buy directly, like a book or a really cheap text editor.
Thus, both a sales engineer and a sales person are required if sales people are needed but they are selling to programmers.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Robert Heinlein said it best: Never try to teach a pig to sing; it wastes your time and it annoys the pig.
Those two words should never be in the same sentence ....
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:
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.
You do not have a moral or legal right to do absolutely anything you want.
On a prior engagement I was part of a team of people charged with training Sales people on a CRM application. I was probably jaded going in, seeing as I have a general distain for sales people of all types, but my experience there was that most of them had the attention span of a fruit fly. Gregarious, type A, call them what you like but those bozos couldn't pay attention for more than 5 minutes. Fucking Blackberrys going off all the time, stepping out to take phone calls in the middle of class, you name it. They were like a bunch of Kindergarden kids with too much sugar in their systems. Needless to say it wasn't the most successful gig I've even been on. I hope you have better luck that I did. Never again.
I gave up system level programming as a career since I was tired of my hobby and career being the same thing... it meant that for the last 30 years of my life (I'm not that old.... just started young), I have spent a minimum of 8 hours a day 7 days a week... often on vacations too in front of a screen and with no social life. I moved into teaching Cisco networking which I'm finding to be really fun and fulfilling.... I have had insanely good results... I am teaching my fourth course this week and so far I'm already setting new records for evaluations at the end of each week since I have a real passion for it. And oddly, I am making more money (2-3 times as much) as I was making when I actually made Cisco products Doh!
:)
That said... I spend a huge amount of time trying to figure out how to teach topics that are "advanced computing" related to people who need it fed to them in small words and made as simple as possible. I create analogies for things like understanding binary by making an imaginary currency called Binaries (sounds like dinaries) which come in coins starting at one and doubling for each denomination and ask them to make change and put the coins in the proper drawers (which happen to start empty) of a cash register without using the same coin twice. When you remove the math aspect from it and make it a simple task which they have done each time they visit a new country with a new currency they stop being afraid of it and move on.
Programming is often easiest to teach to non-programmers by asking people to "write a program" telling someone how to get from the airport to their house. Things like "If Shell gas station on opposite corner from me and hours of opening are from 6am to 11pm, then turn left". To describe functions, I would ask them to place each actual part of the directions on separate page of a document... mix them up and then on a single page, create a master document which refers to each page as a function to produce the program flow. Do the same with making dough for bread... "Kneed bread violently for 10 minutes"... "If the dough has dried out... add a sprinkle of water." "If the dough is too moist or is sticking to the cooking surface, add a little flour", "Repeat previous two tasks". "Loop back to the kneeding process if the dough has too many bubbles". etc...
I think two hours of this kind of instruction at lunch is enough to teach structured programming. Object oriented programming would require a much longer post
Slashot is apprently under stain to produce revenue to sustain herself.
What would be a good avenue to help slashdot to get back to its root?
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
I would try it the other way round: first techie, than sales rep.
I've known a lot of techies that have become real good sales reps. I don't know a single case, where it worked the other way round.
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.
Those are the smart lads and ladies who CAN program but who also have social skills enabling them to help sell. They understand what the customer needs and wants, or better yet, can explain what it is that already exists that will do the job just fine.
I've heard of both C and C++, but never C/C++. What is this supposed language?
In my company we used a Python book, "Learn Python the Hard Way." Gave out assignments of 1-2 chapters a week, and had them return the typed in program. It's simple enough that anyone can figure it out, and have a basic understanding of functions, programming logic, etc.
A good book for learning C is The Absolute Beginner's Guide to C. It explains things simply enough that anyone can understand C. You can do it the same way, maybe have a contest and give out prizes to the first people who are able to reach certain goals.
"First they came for the slanderers and i said nothing."
Comment removed based on user account deletion
Yes, thats how it is in EDA industry.
The "requirement" bit is mostly done by the AE or Product engineer, who knows the product.
Sales guy job is to
1. Arrange for an EVAL, i.e, get a foothold in the customer
2. Post EVAL, negotiate a deal
Unfortunately, many other tech vendors do not follow this route.
My Aurora : http://www.youtube.com/watch?v=o91ZsGwJYyg
FB : https://www.facebook.com/TanveersPhotography
The poster is obviously not a good programmer because a good programmer can program in any language and talks in pseudo code to avoid getting trapped in language semantics and workarounds when discussing a concept rather then actual code.
Teaching sales staff C/C++ is way to deep. Teach them coding concepts but not an actual language. Hell, you might change language and then all your sales staff would need retraining.
As for training failed programmers as sales people. Congrats you just made sure every project you get will have been masterminded by someone who thinks he could do it better.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
The only way you'd teach the sales people I've known programming skills is to figure out a way to put it on a Game Boy cart and physically shove it their head.
Remember "WKRP in Cincinnati"? How would you have taught programming to Herb Tarlek.
This sounds like a question to the Internet Oracle
http://cgi.cs.indiana.edu/~oracle/index.cgi
The Internet Oracle has pondered your question deeply. Your question was:
> O Oracle, great and all the rest
>
> how do you get sales people to learn programming?
And in response, thus spake the Oracle:
} You offer a commission.
}
} you owe the oracle a piece of informaion that is correct but unhelpfull, yesterday's weather for example.
As of Postgres v6.2, time travel is no longer supported.
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.
Introduction to Computer Science and Programming (6.00SC) & Structure and Interpretation of Computer Programs (6.001). Those two things will give them a basic understanding of CS, what code actually does, and how its organized in different paradigms. There is no need for them to learn the actual syntax of a language to understand how and why things are organized.
The best way to turn salespeople into credible programmers is to turn programmers into salespeople.
The other way around is next to impossible.
it wastes your time and it annoys the pig
A company I worked for had sales people teamed up with "presales technical support" people. Sales happen at two levels, the people who are actually going to use the product and their managers. Developers will actually be put off by someone who spouts verbage about how it will improve productivity and reliability but obviously doesn't understand how or what. You need someone who can sit with them and demonstrate the product features.
Management on the other hand just want the bullshit spouted, together with some nice figures and an "excellent deal" so they can feel that they have done a good job negotiating. Given this, if they check with their lead developers and they say "yes this can help us", you have almost certainly got a sale. On the other hand if the developer turns round and says "The sales guy couldn't get it to work properly", or "we weren't shown anything that will help us" then you shouldn't get a sale (though I did work briefly for a company where the management forced unsuitable tools on development staff because they were cheap, so it is possible).
Which BASIC? The one that's like the various BASICs of the 1970s/80s, the one that's like PASCAL (one of the "visual basics"), one that's like Java (a later "visual basic") or one of the others.
I'd say ignore the lot of them - LOGO has a lot of structures similar to other languages and usually provides very clear feedback as to whether the program is working as intended or not. It gets forgotten because it's only really good for teaching, but if you don't intend to do more than give the salesfolk the insight they should have got in high school then go for it.
I don't know if it's going to help with the problem though. Anything simple enough to quickly teach to a beginner can lead to some people mistakenly deciding an entire profession is trivial. They are unlikely to understand without some sort of extra input that although programming is actually very easy to do it is not always easy to do it well within the limits imposed by reality (eg. big stuff on small cheap phones), or other things that add complexity.
At that time their job was to take the class and they were not doing their jobs effectively. Don't try to put it back on the above poster due to some problem you appear to personally have with trainers.
If somebody mismanaged things and put people in a class that should not have been there it's not the trainers fault. They have no excuse of being "busy maintaining relationships to pay your salary" when their management has told them to put that on hold to do another task, so sorry kid, no excuse there, especially since neither you or I know what the above poster does when not running classes or who the salesfolk were actually talking to. Personally I have trouble with some that have a very high frequency of personal calls even when I'm in the process of attempting to buy something from them, but that can apply to undisciplined people in any profession.
I'm a trainer myself and I'm sure GP is a fine trainer. I never said anything was his fault; simply that those salesguys didn't belong in his class.
Actually, based on GP's followup, I don't think those salesguys belonged in their jobs, at all.
Take off every 'sig' !!
Even if your sales staff have rudimentary understanding of what programming is, they'll still have no idea of what your customers do all day long, aka shovel through mountains of git branches and core dumps all day long. They'd need to have written their fair share of code to fully appreciate and communicate the usefulness of the tools you're selling.
Have the existing sales bring one of your own coders along when they meet customers. The coder should be in charge of presenting and demo'ing the product: he, more than anyone else, will be able to communicate how and why he uses your product. (Hold: your coders *do* use the tools they make because they find them very useful, right? Because if not, fix that first.)
A sale involves many aspects, including cold-calling, setting up meetings, dealing with the paperwork, worrying about invoices, etc. all of which is best taken care of by existing sales reps.
Another aspect is to convince another programmer to buy. This should be done by someone who can explain why and how he uses the tool, complete with demo. Surely there are a couple of coders in the existing staff who can do this. Ideally, it should be someone with a knack for picking up realistic feature requests -- and be commissioned for reporting them..
Both should get commissioned for the sale.
To quote from Wikipedia
Myers-Briggs Type Indicator
The use of the Myers-Briggs Type Indicator as a predictor of job success has not been supported in studies,[15][16] and its use for this purpose is expressly discouraged in the Manual.[17]
Another case of HR pretending to have a scientific basis for predicting job fit to a profile, and totally missing the point of the original question. Presumably these guys know how to get the sales people they need, but realize that they need to speak the language of their customers.
I would suggest that the best way to train sales staff for any technical product is to take the best communicator from your technical staff and get him (or her) to run a regular seminar on the product, explaining the kind of problem the product is designed to solve and how the customers are likely to use it. Over a shortish time, the seminars will get better and you might even find that involving more techies actually improves the sales and the product.
nec sorte nec fato
Whenever we are dealing with a customer that isn't exactly sure what he/she wants, one of the salespeople would take a technician with him when first visiting the customer. That way all the really technical related questions get answered by the tech person, and if the salesperson is smart (cross your fingers) he'll pay attention so next time he'll be able to answer the question himself. Might take a few times before he manages this skill, and of course the tech person will have to invest some time, but in the end it really pays off. The salesperson will (hopefully) sell the product and the technical people can start right away without having to ask a lot of questions afterwards, or swearing at sales for selling something that they can't deliver.
And not because it's technically too challenging. The reason you don't teach them ANYTHING at all about programming is because of a fact that transcends computer science and indeed is present in all facets of life. It is a simple and well known truth that the more you know about a subject, the more you know of your own limitations within that subject. This comes with a caveat, though. When first introduced to a subject, a person is more ignorant of that subject than they were when they didn't even know it existed, because they know something about it and think that knowledge extends far beyond where it actually does. Essentially, they gain a new perspective, but they don't know how to use that perspective correctly.
So to show someone that they can do the same thing those really smart engineers can do and give them the know-how to turn basic ideas into actual working code, they immediately internalize that process and look at problems in a new way. They begin looking at problems as engineers, not as salespeople. But they ARE NOT ENGINEERS. To give them that perspective without the full understanding it requires to be used properly is a really, really bad idea, in my opinion. You know how those really novice engineers will say "sure, I can do that" to any problem, without knowing about and therefore not considering the > 9000 edge cases they need to deal with because the basic idea is so simple you can explain it to a third grader? Now replace "really novice engineer" with "salesperson who is also a really novice engineer." I can't imagine a more horrific situation.
Just don't teach programming to salespeople. Your company has better things to do than to teach a whole sales force.
Hire sales people that have a technical background, or do business with technical consultants.
First I can tell you that getting sales people to use Goldmine would be an accomplishment for most companies. The best salesmen would get toilets installed for desk seats as they are the laziest people in the world. But if you have bizarrely motivates sales people ...
Python. Don't bother with C++ (which I love and use every day) as that will be an exercise in futility. Go with python. It will make them hip and give them the lingo. I wouldn't go much past hello world but if you can get them to write some code from scratch and then run it then you will have the best trained sales force on the planet.
Then and only after you have won that battle get them to fire up an IDE and compile the same sort of hello world that they made in Python in C++ and then they will have a vague idea of what is happening.
My reasoning is that you type very little in python that makes no sense. C++ has too much that is initially explained as "That is just how we do it. It will make sense later."
How many of us learned to program with:
10 print "My name on the screen!"
20 goto 10
and showed this off to friends?
You're probably better off just training the programmers, or hiring people with programming experience. Salespeople (and business majors in general) tend to go into those fields specifically to get the highest pay/work ratio they can find.
If you have sales people that are anywhere close to having a little value they can identify a qualified lead. Once you have that good lead take a technical sales engineer to the customer for a follow up. This does two things, it wasted less time, and the customer has shown a commitment to the process. The trick is finding a technical person that can go out and speak in public. This type of person has been seen out in the wild. Sales people are sales people, it really doesn't matter what they are selling (pretty much). Sales is a process, and it is not easy. Remember, the sales person does not need to be to technical because I seriously doubt cold or introductory calls are done w/ a customers technical folks. The customer technical folks is who you want your technical sales engineer to talk to on this second visit.
Salespeople have no time to lose. Teach them to program what is useful for them. VBA is shitty, but contains functions and most of the bases of programming.
Excell is very important for salespeople and they will more easily understand the aim of exercises.
You can't cure willful ignorance..[snip]..if you don't keep up... you lose your job to someone who can.
Was that first sentence a fraudian slip? Have you not heard of commissions? Too few sales and you won't just lose your job, another sales guy in the same office will TAKE it because he's IS a better salesman and he wants the commisions you're failing to pick up. There's nothing a sales head likes better than handing out bonuses and commissions, it's not only indisputable proof that his crew are doing their job, it's also his wheelbarrow full of cash at the end of the year.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Our company makes development tools
Here is your problem. Unless you are Microsoft or FSF, no one wants your tools if there is an alternative, and people would only grudgingly use them if it's the only way to make some hardware work. That includes CPU manufacturers themselves.
Contrary to the popular belief, there indeed is no God.
I've been teaching my 9-year-old daughter programming. We started with http://www.codecademy.com/ learning JavaScript but have now moved on to Python, which she prefers because of the Monty Python references. JavaScript is similar enough to C++ (those annoying semi-colons!) to give them a bit of the flavor, and CodeAcademy makes it easy to give them a taste. On a side note, Python has a great free intro book, Think Python: http://www.greenteapress.com/thinkpython It's not turnkey like CodeAcademy, but it's very well written for someone who has never programmed before. I think Python is easier to learn but it is less similar to C++ than JavaScript, so there are pluses and minuses to using it in your situation.
Slightly off-topic but regarding How to win friends and influence people, the socially inept neckbeards on /. are probably better served reading it than extrovert business/salespeople. It's more of a self-help book on developing general social skills and is actually a good read. It's probably not the best example for your otherwise valid point.
This post was generated by a Cadre of Uber Monkeys for Monkey-Man2000 (603495).
Having worked around sales people for a lot of my career, I can tell you one thing: the good ones don't give a shit about programming. Period. If it doesn't make them money, they don't have time for it.
I am also a member of a Linux User Group. These guys really care etc. but they are also complete nerds who don't understand concepts such as: "Thank you." or "May I...?" - let alone marketing.
Myself, I'm a hybrid. I have tried doing both and I am a lousy salesman (I care) and I'm a very shitty programmer (I don't have the attention span) so I think I have a fairly objective perspective!
*** Don't be dull.***
best buy tried some thing like this and look at them now.
The Geek Squad used to be good now it most part it's the up sell squad
My co-worker is a genius, able to answer about any question technologically speaking. I am a talker and have been friends with him for ages. He's a way better programmer than me. I like people a lot and was a teacher for a couple of years and between the two of us during our weekly meetings, demonstrating what has been accomplished we both come out making our company look good. It's easy for me to explain stuff in normal people terms and if there is a super technical question he steps in and it goes well. It works very well for us, but our approach is primarily internally focused; that is, I am not selling but demonstrating for the non-programmers that work with us. I have a feeling that I could be a salesperson in the future, but only because my friend, and boss, has made me a better programmer. He's been working on me for years.
>> no one wants your tools if there is an alternative, and people would only grudgingly use them if it's the only way to make some hardware work
Mod parent up. I've worked for a couple of software companies now and at every single one of them I've helped the company make money and cut costs by killing their standalone SDKs and switching resources into applications instead.
Here's why I hate selling toolkits to programmers (and love applications selling to IT):
1) Programmers suck time and often get escalated to YOUR programmers, whereas IT folks can almost always be handled by a well-trained (and far less expensive) support department.
2) Programmers have little loyalty and an innate curiosity (they love to try your competitors' toolkits), whereas IT folks mainly just want to do their job and GTFO.
3) Programmers can never believe that toolkit X costs Y, because they could "obviously" have written [subset of X] in [basewage*(Y-1)] time, whereas IT folks mainly compare your product to its competition and say "meh - looks like an OK deal."
4) Even if a programmer loves your tool, you then often begin the process of helping that programmer build a business case to management for acquiring it, which is twice as much work as starting a deal with an IT group that already understands business needs and budgets.
5) There's more, but I have work to do today...;)
And yes, I started my career as a programmer, so I've seen both sides.
Ask them to write a program, give the functional result a monetary value, and tell them they'll get n% of it, where n is the percentage of properly formatted, bug free lines of code.
It makes much more sense to teach a programmer sales skills than to teach a sales guy basic programming knowledge. Programmers are honest and appear honest to customers too, which is a massive plus when selling to other programmers in particular. You should know that in your experience of say, Krishna vs. a guy like Cédric or yourself :-)
I feel that's my profile: I'm sales, and somewhat technical: I used to dabble in assembly/basic/C as a kid, have a few Linux PCs around and build+admin my family's PCs... I usually take jobs in fairly technical companies, including in fields I originally have no clue about.
You do need to recruit sales rep are are somewhat technically inclined and competent. Some sales rep literally cannot do mental calculations....
Here's what helps me:
- not being threatened and treated as an idiot. My first batch of questions are bound to be idiot ones. Snickering at them will just shut me up and make me look for another job.
- having pre-sales tech support with me on a handful of outings. Not other sales rep, unless they are *very* technical, but a true (non-autistic) tech guy. First I listen, then I parrot with supervision, then I no longer need supervision.
- having time to read the docs, and to play with the product with a tutor
- taking the same training class as our customers, having time to read the materials.
- include a frank presentation of competing products. Our product is *bound* to have strong and weak points. Not warning me about our weak points (and workarounds ?) will just make me look like a clueless idiot.
The Cloud - because you don't care if your apps and data are up in the air.
They're called sales engineers, who are sometimes supported by "pre"-sales engineers who might have a bit more product knowledge or spend time working on or supporting the product.
The sales engineer's purpose is to sell directly to the end user and thus needs technical knowledge. The sale's rep should be selling to the end user's boss who lacks the technical knowledge. I used to work in technical sales, and our company actually became more successfull by transitioning away from sales engineers to sales reps who sold directly to the guys with the purse strings.
It worked well for the company, but probably does not address the needs of the client as well, at least not without pre-sales engineer's help.
Bring back the old version of slashdot.
made:
"A computer program is instructions for a machine."
First, they should generally understand the nature of the endeavor.
Executing a computer program is like navigating a maze. You (ie. "flow of execution") move through its paths, taking detours (changing course) based on the state of values (ie. content of variables). The only way to definitively know the state of values (ie. to debug) at any point is to print them to the screen. This is like your program sending up a smoke signal, flare, or radio beacon.
of course you can also throw together a bunch of projects that they can "practice" on (just have REAL PROGRAMMERS make sure that they will work and mark what bits can be changed)
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Most of the people I know who quote or use the Myers-Briggs for job placement cheated or gamed the system in the first place. They read up on how to answer the questions to get the result they wanted. They they said see, I am a natural leader. We did this where I work. It was very odd. All the 'natural leaders' types sucked at getting anyone to do things. Work sucked, people hated going to work. Not many people would openly say they liked the bosses. Over time those people left and were replaced with the team player people in leader positions. Now everyone gets along. Work is a good place to be. We get more things done.
Yes we could have just left, but not everyone can or wants to pack up the family and move. The other job offers were for less money or required a move. The Mrs. (aka the Boss) did not like the areas where we would have moved too. Being a weekend father is not my thing.
A salesman needs two skills. One is the ability to sell, the people skills. In addition he needs deep product knowledge. If you are selling development tools, you need to understand development and exactly how these tools will make the programmers more productive.
It is not unusual to require multiple skills for a job. How is this any different?
I have often been approached by salespeople with little product knowledge. They never succeed in selling me stuff.
When I am interested in a technical product, I call the engineer. Usually they can quickly get me the information I need to make a purchasing decision.
Have a take an introductory course. http://www.udacity.com/overview/Course/cs101/CourseRev/apr2012
By far the best way to teach programming is the first programming language taught to me when I was 4 in 1983 -- LOGO. Extend it with the features that you want your salepersons to know -- function calls like drawCircle() would be easy. It's very straight-forward, and the vast majority of concepts can be boiled down into something suitable for the turtle-friend.
How do we best teach salesmenship to programmers?
Yes yes, I understand that you tried to wave off the number one response to your question by marginalizing the difference between programmers and salespeople as a "sweeping generalization" but it is in fact a real issue that cannot be dismissed. The Blank Slate was smashed years ago. Persuasion and programming are two wildly different cognitive skillsets.
If you find somebody who happens to have BOTH skillsets, that rare individual should probably have a leadership role in the sales organization to help steer the people underneath to do their sales work in a manner that is rational and aligned with what your product truly delivers to the customer.
But the real solution to the problem you are outlining in your question is A TIGHTLY INTEGRATED RELATIONSHIP BETWEEN YOUR SALES ORGANIZATION AND YOUR SUPPORT ORGANIZATION. Doing this right isn't easy. It's more than just giving your salespeople a batphone to the helpdesk. Both groups need to collaborate to determine how each side can work to help the other group acheive their goals. There are a variety of effective models, but it begins with both groups realizing that they have a shared responsibility to ensure happy customers.
Put them in a time machine.
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
You're under the mistaken belief that everyone is capable of really understanding basic programming skills. For examples of how well that assumption works out, look at the quality of code we got out of the waves of late-90s grads in the dot-com era, and more recently from the majority of offshore consultancies that hire new comp-sci graduates by the thousand.
And frankly, the level this guy is talking about is a few notches above basic.
I think you gave up on the solution a bit too easily. People make their purchases based on two principles: the elimination of doubt and trust in the other person. The more doubt and the less trust, the less likely a sale occurs.
Who helps eliminate doubts and create trust with technical programmer customers better than a programming sales rep? I'm pretty sure the non technical sales-charmer type isnt a big trust builder either.
narrow subset of the American Programmer population that what you describe as the behavioral norm is nothing but an old and tire descriptional cliche?
Where do you think the cliche comes from?
Folk tales? Urban legends? Stereotypes perpetuated by media?
Its well rooted in truth.
It's well rooted in the American psyche and popular culture, like the pocket protector cliche, or the cliche that one day (extremely soon as I've heard again and again and again from the masses) computers will learn to write programs, making us programmers obsolete.More concretely, during the 70's oil crisis, it was a well rooted cliche among a large number of the population to believe big oil companies kept their tankers away from ports to up the prices (despite the more sensible explanations of that economic phenomenon.)
Being well rooted has no logical bearing on a cliche being truth or false.
The sad part is, a lot of these guys seem themselves as normal and have no idea how much of a dick they really are.
But that is true of any type of sociopath or introvert... or of any normal being with personal flaws for that matter. It is still an unquantifiable statement, an stereotype. We can argue about personality types and the prevalence of high functioning autism or ADHD among engineers, scientists (and for that matter people in the creative arts.)
But to describe what amounts to borderline sociopath tendencies across a professional disciple and trade, that's just perpetuating a stereotype, one that you can only measure by the strength of your personal convictions in believing it to be true. It is subjective.
Their massive ego frequently prevents them from seeing themselves as others outside their field see them.
That is the typical human condition except for the rarely few gifted in the humane department.
No offense, but perhaps this also describes you?
That is a possibility, but without proof of it, that is just speculation of your part, one that cannot be measured for truth or falsehood, ergo one that cannot be used to logically defend a position or argument. And if you were to take that as a certainty, then you would have created a convenient, self-fulfilling strawman + "petitio principii" with which to counter-argue my original statement.
We frequently refuse to see our own failings in others.
Typical human condition, not one exclusive of a particular trade or profession.
And introspection is something I rarely see in my peers. Its sad.
It is sad only if we seek a reason to be upset or a target to point finger at.
Again, typical human condition. You can find that in any trade. With the exception of some social studies on individuals in business leadership positions, I've never seen any objective measure by which one can say engineers are this or sociologists are that beyond the realm of speculation.
It is sad if you decide to believe it is. Things can be seen as sad, happy or irrelevant, moral, immoral or amoral depending on how we chose to see the world. For me I simply accept the imperfections of the human condition, coupled with the fact that people in general are capable of love and affection and respect, but that simply must cope with their own specific imperfections as they go about their business.
I don't find it sad (most of the time) because I chose to see and appreciate the goodness in people. And that choice is not dependent on the temporal/occasional flaws that people will inevitably exhibit from time to time.
In other words, if I find something sad, it is because I am personally unable find a redeeming attribute on that which I'm observing. Whether that ability or inability is objective or subjective, that is truly a function of the individual.
Get them to go to http://www.udacity.com/ and take the CS101 course. It'll teach them python and the general concepts of programming without being too difficult and it also takes the pressure out of you (or someone else) teaching them ... and at the end they can get a signed certificate to say they did the course (it holds no weight for getting a job, but at least it's a nice piece of paper). :-)
Sure enough, the cow costume was hanging up next to the superhero outfit and sailors uniform. (S,Spud)
"Never attempt to teach a pig to sing. It wastes your time and annoys the pig."
Hire and assign a programmer to each sales guy. Split the sales comp between them. The sales guy does the glad handing. The tech guy talks tech to the customers.
Start with http://www.ibiblio.org/pub/docs/books/eckel/
Casteism
Last time I wrote code the language was 'c', so if he's doing 'p' then yeah, that'd be pretty freaking awesome.