Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Businesses Programming

Ask Slashdot: How Best To Teach Programming To Salespeople? 211

Posted by samzenpus from the know-your-product dept.
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."
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Best To Teach Programming To Salespeople? More

Ask Slashdot: How Best To Teach Programming To Salespeople?

Comments Filter:

  • Hire bad programmers with good social skills (Score:5, Insightful)

    by Anonymous Coward on Thursday June 07, 2012 @11:37PM (#40253327)

    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.

    • I would say, have a brainstorm among programmers and project managers to understand their problems and create an excellent presentation that would highlight benefits of your solution. This way, your product would address pain points easily. I always think think that the solution, anybody has generated sitting in closet, fails to touch heart of the customers.

    • Re:Hire bad programmers with good social skills (Score:5, Informative)

      by dragonquest ( 1003473 ) on Friday June 08, 2012 @12:16AM (#40253531)

      "Hire bad programmers with good social skills"

      "You want to hire people who have programming background, but weren't interested or talented enough to pursue that full time"

      And the good news is that these people are in abundance in the lead architect/team leader/technical manager positions. I can confirm their existence and numbers (did I mention abundance?) from all the organizations I have worked with.

    • This sounds like a question to the Internet Oracle
      http://cgi.cs.indiana.edu/~oracle/index.cgi [indiana.edu]

      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.

    • 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

      • Re:Better: use the existing programmers (Score:4, Interesting)

        by Yvanhoe ( 564877 ) on Friday June 08, 2012 @04:30AM (#40254471) Journal
        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.

    • Actually, you should hire smart programmers with good social skills. For all the useless shills in sales, the true gems are the ones that excel in both. You'll find that the best freelancers are actually these people because they can do the work and sell their services.

      Sadly, this isn't what the OP wanted. It sounds like he's got a gaggle of salespeople who are not doing terribly well and the meager feedback that they are getting is that their salespeople just can't connect with the end users enough to clos

    • 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

  • It's doomed. (Score:5, Funny)

    by Anonymous Coward on Thursday June 07, 2012 @11:37PM (#40253329)

    ...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!

  • You need a technical pre-sale consultant for that (Score:5, Insightful)

    by alecclews ( 152316 ) on Thursday June 07, 2012 @11:39PM (#40253335) Homepage

    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.

    • Re:You need a technical pre-sale consultant for th (Score:5, Interesting)

      by NFN_NLN ( 633283 ) on Friday June 08, 2012 @01:01AM (#40253735)

      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.

      • That's about as practical as training all your programers how to negotiate a contract and forcing them to read those bussiness books with titles like "How to win friends and influence people". Specialists exist because it's impossible for one person to know it all, let alone do it all. In evolutionary terms humans are still learning how to cope with the social invention of divided labour when it's applied to another social invention that arose from agriculture - extremely large human tribes, such as the 175
        • Slightly off-topic but regarding How to win friends and influence people [wikipedia.org], 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.

      • 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.

  • Sales Engineer (Score:5, Insightful)

    by SuperKendall ( 25149 ) on Thursday June 07, 2012 @11:39PM (#40253337)

    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.

    • It's been my experience that the best way to solve this particular problem is to find a programmer with people skills, that can accompany your sales guys around. Sales people are not programmers, but programmers are often fantastic sales people. Think about it. As a programmer who has been doing this for any length of time, your resume is a thick obsessively intricate and well put together piece of marketing material.

      You've been able to land multiple jobs at multiple Fortune 500 companies, and you've succ

      • Unless you've got a programmer that has some kind of severe debilitating autism, there's absolutely no reason not to take him on your sales calls, if you know technical questions are going to be asked.

        What about the myriad of techies with a serious sense of entitlement and feel that "going to meet clients is not their job"?

        The main reason not to take developers on sales calls is simple: The developer does not want to go and he knows that since there is such a shortage of decent developers on the market he has a lot of power to either refuse to do things he doesn't want to or even worse, deliberately make a total hash of it safe in the knowledge that firing him for being a prick is difficult unless you ca

        • The main reason not to take developers on sales calls is simple: The developer does not want to go...

          Actually, there's more to it than this. Basically, the reason you don't want a programmer along is that a programmer (even one who wants to go) is unlikely to stick to the sales strategy, is likely to go into unnecessary and unhelpful (and terrifying) detail which derails the sales conversation, will often point out shortcomings as forcefully as benefits about the product you're selling, will not shade toug

    • Are you sure sale people will be talking to programmers directly?

      Oh god, the nightmare scenario ... the PHB buying development tools from a salesman.

      Neither know what it does or how you'd use it. But, dammit, they've got some really great glossies and a Power Point slide. You need to enter the text in EBCDIC, using reverse polish notation, in a bizarre sub-dialect of Tibetan, and it can only handle files less than 4K.

      I really have no idea how a salesman could sell a development tool without either having

  • 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.

    • Re:It should be obvious... (Score:4, Insightful)

      by DerPflanz ( 525793 ) <bart@noSpaM.friesoft.nl> on Friday June 08, 2012 @02:00AM (#40253955) Homepage

      I am sorry, but communication skills aren't key here. Key is understanding what the *client* wants, instead of what the *developer* wants. I have seen many clashes between sales and software development and they all boil down to this:

      Sales: "we need function XYZ in our software"
      Developer: "no, we don't, it's useless, besides he can use tool ABC to flurb the snugger and be done with it"
      Sales: "but the client asks for it"
      Developer: "the client is a dumbass"
      Sales: "he pays your salary"
      [developer walks away and implements XYZ, but only against his will]

      Both development and sales are serious skills and succesfull business manage to do them both right and in the correct balance.

  • Give them a problem to solve... (Score:3)

    by man_of_mr_e ( 217855 ) on Thursday June 07, 2012 @11:41PM (#40253347)

    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.

  • What a Dumb Idea (Score:5, Insightful)

    by Anonymous Coward on Thursday June 07, 2012 @11:41PM (#40253349)

    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.

    • Totally agree!

    • Yes, asking the question of "How can we teach our sales people about tech?" is strongly indicative that the submitter and/or his company don't understand that sales people don't get tech stuff. Obviously.

      </sarcasm>

    • Re: (Score:3)

      by Hatta ( 162192 )

      Why would the customer want a relationship with someone who is clueless about what they do?

  • Give up now, it is impossible.
    • You never know, I heard they were working on teaching calculus to Orangutan's. I suspect there's a similar level of difficulty between the two.

  • Get Some Really Good Sales Engineers (Score:4, Insightful)

    by Squeebee ( 719115 ) <squeebee@@@gmail...com> on Thursday June 07, 2012 @11:43PM (#40253363)

    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!

  • Don't look for one person to fill two roles (Score:5, Informative)

    by hendersj ( 720767 ) on Thursday June 07, 2012 @11:47PM (#40253383)

    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.

  • 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 int

  • A chair and a whip.

  • Really, if you're a programmer, are you going to use a development tool because of something a salesperson told you?

  • Socializing programmers? (Score:5, Insightful)

    by Anonymous Coward on Friday June 08, 2012 @12:11AM (#40253503)

    Robert Heinlein said it best: Never try to teach a pig to sing; it wastes your time and it annoys the pig.

  • BASIC suggestions (Score:4, Interesting)

    by Sarten-X ( 1102295 ) on Friday June 08, 2012 @12:21AM (#40253559) Homepage

    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.

    • 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 insi
  • 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 busy maintaining relationships to pay your salary.

      Whoever put them in your class was a fool. You should be teaching people who need to know how to operate the CRM.

      • The Sales people were the ones that were supposed to be using the CRM system. We had the right audience. CRM, by the way, stands for Customer Relationship Management. Sales people use it to manage sales leads and communications with customers. We led them to water but couldn't make them drink. Some of them got it and actually understood that if they used the system properly it would help to increase their sales and by extension their sales commissions.

        • Oh! I thought they were your salespeople and you were training them on the product (the submitter's story).

          I have a similar situation myself, from the beginning of my career. I implemented some horrible ERP software and for some reason, can't recall, we deployed it using Citrix Metaframe the multiuser terminal server. I needed to configure all customer computers with the Citrix client and show them how to administer their launcher icons. The chief salesguy was exactly as you describe, and I came to him sev

      • 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, esp

        • 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.

  • System level developer, now instructor says.... (Score:5, Informative)

    by LostMyBeaver ( 1226054 ) on Friday June 08, 2012 @12:28AM (#40253591)
    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 :)

  • 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've heard of both C and C++, but never C/C++. What is this supposed language?

    • Clearly, it's one over plus plus.

    • In the first use, about most programmers using C/C++, the slash can be interpreted as an "or". The second use, teaching somebody C/C++, indicates that the user is largely ignorant of C++, and likely of C. In almost all cases (embedded programming largely excluded), competently written C++ and competently written C are very different, sharing mostly lower level syntactic elements.

  • programming teaching (Score:3)

    by phantomfive ( 622387 ) on Friday June 08, 2012 @01:11AM (#40253779) Journal
    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 [amazon.com]. 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.

  • Oh brother (Score:4, Insightful)

    by SmallFurryCreature ( 593017 ) on Friday June 08, 2012 @01:27AM (#40253847) Journal

    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.

    • Re: (Score:2)

      by wrook ( 134116 )

      I think many people are overlooking one important thing from the OP's post. They sell programming tools. The level of knowledge necessary to sell the tool depends a lot on what the tool is. If it's a text editor, then you need very little knowledge of programming. Even a refactoring browser would be fairly easy. But what if the company were selling static analysis tools for C and C++? Maybe along with profiling tools?

      If this were the case I can imagine a lot of awkward conversations as the sales perso

  • 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.

  • Let your salespeople know their limits (Score:3, Interesting)

    by wienerschnizzel ( 1409447 ) on Friday June 08, 2012 @01:36AM (#40253875)

    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.

  • The best way to turn salespeople into credible programmers is to turn programmers into salespeople.

    The other way around is next to impossible.
  • 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 wit

  • 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,

  • 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 t

  • Comment removed based on user account deletion

  • 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 co

  • 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.

  • 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.

  • 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.

    • >> 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 esca

  • Are you out of your fucking minds??!! I thought this article was left over from April 1st.

    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 h

  • 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

  • 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 questio

  • 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)

  • 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

  • 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 leade

  • 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.

Slashdot Top Deals

"I have just one word for you, my boy...plastics." - from "The Graduate"

Close