Fog Creek Software
Discussion Board




It's about results.

When I first worked for a software company (18.5 years ago), the boss used to go around saying, "Programming doesn't make money!"  I didn't have a clue what he meant.  A few years later, he switched to, "The master programmer solves problems without writing code."  And thus I was enlightened.  :)

Writing code doesn't make money.  You may think you have a job writing code.  No.  You were hired to solve a business problem.  Just like the user of a program wants to get their job done, not work the program, the company that hired you wants to get *their* work done.  How it gets done, is unimportant.

Sometimes, the best choice for solving a business problem is to use an existing tool.  Sometimes, that tool is something you pay for, and sometimes it's a community project. Does it matter?  Yeah, in little ways, but it doesn't fundamentally change the job.

I don't get paid to program, I get paid to solve the business problem.  In practice, this usually means I'm getting paid to:

1. Understand the business goals
2. Know how to translate them into technical goals
3. Find and evaluate tools
4. Assemble a solution

Think open source is a threat to your wages?  Maybe that's because you still think your job is *writing code*!  I'm not much concerned about people lowering the cost of writing code, because I sell results, not code.  In fact, lowering the cost of writing code is *good* for me, because it increases my productivity and/or profit margin.  If I can produce more value for my employer, my value to the employer is also increased!

I might be wasting my time writing this, as I doubt this will sway the folks who've already made up their minds, who prefer to rage against the imminent death of the illusion that there was ever any real money to be had in writing code.

But what the heck, maybe this post will help *somebody* get a little better idea of how to have a viable career in software.

Phillip J. Eby
Thursday, September 04, 2003

Being on firm fixed price taught me this REALLY fast.

Philo

Philo
Thursday, September 04, 2003

You don't make money by writing code; you make money by *shipping* it.

Norrick
Thursday, September 04, 2003

Doesn't fog creek make all its money writing, and then selling, code?

rz
Thursday, September 04, 2003

Phillip Eby, I don't know any good software developers, including opponents of the open source zealotry, who think their job is "writing code."

In fact, the description sounds more like the typical user of oss packages - grab this, hack this, cross our fingers, bang it all on a CD.

I think, in a way, your comments underline one of my earlier points. Open source is fine if you're just developing web apps or other typical low level stuff. Go ahead. However don't try and tell me to give away source code to stuff you could never do.

ab
Thursday, September 04, 2003

Dijkstra put it very well:

Lines of code are not an asset; They are a liability.

Ori Berger
Thursday, September 04, 2003

Amen and Hallelujah!  It's a fine line to walk saying "just get it done and ship it" though, because you'll be accused of a providing a non-optimal solution, or of being unconcerned with quality.

It amazes me sometimes how poorly cost-benefit is weighed when developing software.  We had a developer here who wanted to write his own grid as soon as he ran into a couple focus issues.  I see the same type of thinking (although not as bad) all the time.  The only discipline that comes close to the poor cost/benefit analysis we see in software is marketing - and they have have an excuse; lack of verifyable results.

The residual cost of having a lot of code is generally underestimated.  Think of the time in your career that you've looked at a 7,000 line source file and thought "you know, this really should be about 300 lines".  Ignorance of API is a common culprit.  Just today, I waded through a complicated function that gets a temp directory.  The developer could have called GetTempDirectory().  Or maybe there was a reason they couldn't?  I'll never know.

Certain aspects of buildings are typically constucted with horrendous quality.  Why?  Because no one will notice or care.  Take a T-square to your walls sometime to see.  Most building designs are just direct rip-offs from other buildings.  Really, isn't most software being written today a clone from something else?  Shouldn't a web developer just rip off the design of a site (in a different market, of course) to save time?

Bill Carlson
Thursday, September 04, 2003

There are many here that will read Phillip's post and say "Duh!", but yet our industry is chock full of people who fail to grasp this most basic concept.

Before college, my father always encouraged me to get a bachelor of science, then go get an MBA. As a physicist turned business owner, he knew the tech industries were overloaded with bright people who loved science, but just couldn't grasp basic business rules.

Not that you need an MBA to understand business, but his point was well taken: Technical people that "get" business are in short supply and in good demand.

Mark Hoffman
Thursday, September 04, 2003

Half of the things you guys rail about make absolutely no sense to me.  I think maybe it's because I've worked solely in companies where software was a P&L center, i.e. we shipped code.  Real code a lot of times, not just a compiled .exe or .lib.


Thursday, September 04, 2003

I don't know, Phillip. I agree with you in the absolute, but the job market and the rules for hiring are formulated in many cases by techies on ego trips who misuse the selection process as a way to reaffirm their self evident eternal technical superiority.

Many, many times I've walked into interviews filled with good ideas of how I could be an asset and provide the beneficial result I thought that the client or employer was seeking - and been *completely* whipsawed by some !@^*@ pathetic get a life nurd who wanted me to belch and fart every public method in MFC.

To land a job, results and ability to achieve results or benefits do *not* matter. What matters in that context is shaping the perception of the hiring person(s) so that they believe that you are their man (or woman as the case may be.)

Candidate selection for most corporate jobs (and even many small company jobs) is so completely artificial that there is little if any relationship to cost justification. Personal rapport and chemistry, and performing "tricks" on demand is what usually helps.

Bored Bystander
Thursday, September 04, 2003

Mark Hoffman wrote:  "Not that you need an MBA to understand business"

Exactly.  An MBA is just a ticket that gets you in certain doors.  With a few exceptions, you don't really learn anything useful in business school.  And yes, I have an MBA, so I'm allowed to say this.

Alex Chernavsky
Thursday, September 04, 2003

I know in my company the corporate IT developer has gone from solution provider to "resource pool" code monkey. I think we should be much more concerened when our employer forgets that we excel at providing solutions and not lines of code.

m
Thursday, September 04, 2003

Phillip,

No offense but you sound like you are a naive business programmer to me.  The fact is, not all computer programming jobs are the same.  This is one reason why I enjoy reading Joel's articles (and why I occassionally read Slashdot articles) -- in many instances he has a different perspective on things than I do.

"You were hired to solve a business problem."

In many situations this statement is simply untrue.  I am a business programmer and I have worked as a full-time employee, a contractor/consultant, and as an independent consultant and it has been my experience that each work situation is different.  That is, sometimes I get hired to write code all day long, sometimes I get hired with the expectation that I won't be coding, and somtimes I get hired with the expectation that I write code and do lots of other things.

"...How it gets done, is unimportant."

Well, that is one reason why most people don't want to do maintenance work.

"I don't get paid to program, I get paid to solve the business problem."

Good for you.  Personally, I think you need to qualify what you actually do for your clients/employer because in my opinion the four bullet points you listed were pretty vague.

"Maybe that's because you still think your job is *writing code*!"

Well, it might not be the only thing I do, but for me it almost always plays an important role.  I primarily get paid for producing technical results.  I currently can't find anyone willing to pay me to:

* Manage large software projects
* Design large enterprise systems

One Programmer's Opinion
Friday, September 05, 2003

I think you're being just as neive as the people you're criticising.

You're not just paid to write code. You're also not just paid to get business results.

You're paid to WRITE CODE THAT GETS BUSINESS RESULTS.

They're opposite sides of the same coin. You need to be able to do both.

And as some other posters have said, this assumes you're in a certain industry, not all programming jobs are the same.

Sum Dum Gai
Friday, September 05, 2003

"You're paid to WRITE CODE THAT GETS BUSINESS RESULTS"

I can go either way on this. Either you're completely wrong, or if you're right then it's a sign of poor management.

Let's say I'm hired to build a system that will store data in a relational manner and allow querying on it. Instead of hitting the requirements document, I recommend purchase of SQL Server. Bought, installed, problem solved.

Have I done my job? I didn't write a line of code.

What about when you buy third-party components? Are you not doing your job?

Solve the problem. Good management doesn't care how you do it.

Philo

Philo
Friday, September 05, 2003

Building "a system that will store data in a relational manner and allow querying on it" isn't phrased as a business problem, it's a technical problem. If you're solving that, you're not being employed to solve business problems, you're being employed to solve technical problems.

If feel that falls under the category of my last sentance - not everyone works in the same field.

I find it extreamely unlikely that there are many real world business problems that can be solved using 100% off the shelf components. Someone has to write the glue.

Sum Dum Gai
Friday, September 05, 2003

AB: did I say anything about giving anything away?  [Checks original post...]  Nope.  You must have me confused with somebody else.  :)

RZ: Fog Creek makes money selling *functionality*, not by writing code.  If writing code made money, they wouldn't have reused IE's HTML control to do HTML editing, they'd have written one of their own.  Code is just a means to an end.

Bored Bystander: I realize that not every hiring process is functional.  However, the *customer* of the hiring process (the business owner or investors) wants the result, not the code, even if the person they've put in charge of the hiring is clueless.

One Programmer's Opinion: if in all those situations you speak of, they didn't need the code to produce a result, then why were they having code written?

Sum Dum Gai: Often business problems can be solved by *solving the business problem* and not writing or buying any code at all!  Sometimes, solving the business problem can be done with paper or a procedure, or even just a shift in perspective.  So "somebody has to write the glue" simply isn't true, unless you call human-enacted procedures "glue". 

9 out of 10 requests for software enhancements that come across my desk end up requiring no programming whatsoever, because the business problem can be solved through proper use of the existing tools.  If I were under the impression that my job was to "write code to solve business problems", I'd be spending all my time solving non-existent problems, and have no time to actually *advance* on longer-term business goals.

Phillip J. Eby
Friday, September 05, 2003

> ), the boss used to go around saying, "Programming doesn't make money!"

Maybe I'm just cynical, but I think this could also be fairly translated as:

"Remember, I'm the boss! You all are just code monkeys!"

or more simply:

"Remember who's the boss!"

To co-opt your title: It's all about the pecking order.

I'd agree with you that looking at the Bigger Picture is good; but I'd also point out that I've found some business people to get *uncomfortable* when the techies start to get too business-savvy, because it disturbs the Natural Order of the Universe, namely the one where they give the orders.

Perhaps that's why the hard-core techie is so relentlessly dissed on this board: because he simply won't play the game.

Peter Breton
Friday, September 05, 2003

One Programmer's Opinion,

When were you hired to not solve a business problem? Unless you were working for the government or academia then I'd venture to say that yes, you were hired to solve a business problem.

The problem may have had a technical solution, but I can't imagine any company paying someone to write code unless that code solved a business problem. The problem might be how to incorporate a new feature to save money, to boost our product against competitors, etc.

Too many people view the technical solution as an end unto itself, completely forgetting that the original purpose of solving the problem is to drive the business. Not playing techie with all the cool toys.

Mark Hoffman
Friday, September 05, 2003

> Too many people view the technical solution as an end unto itself, completely forgetting that the original purpose of solving the problem is to drive the business. Not playing techie with all the cool toys.

This is like a paradigm post for Joel on Software: it's always Business Uber Alles.

Gentlemen, I don't disagree; that's the way our moden society is organized; but I invite you to consider a wider, more humanistic world where we try to understand *why* people behave as they do.

Perhaps hard-core techies are playing different games, with different goals, than the people who run the businesses.

My old boss called playing with cool toys "a necessary evil": if you didn't want to do it (at some stage in your development), then you probably wouldn't make a good techie. I think he was right too; rather than squeezing out all the playing, I'd ask what the best way is to harness it.

Peter Breton
Friday, September 05, 2003

Mark,

At my current job, I was hired to solve a critical technical problem that nobody else could. I was interviewed on my technical skills and told to go apply my technical skills. I was given a non-management, technical position and use my technical skills day in and day out. So far, nobody has listened to my "business ideas" and I have had little time to solve business problems. Does this sound black and white enough?

StickyWicket
Friday, September 05, 2003

Peter,

Don't get me wrong. I'm all about playing with cool techie toys! All am I saying is that the toys can't be the focus. Solving the problem is the focus. If the toy solves then problem, then that's great. But I've seen many instances where people try to solve every problem with their favorite toy for the simple reason that...it's their favorite toy.

Sticky,

I think you missed the point. No one was suggesting that you try to edge into management and help them run the business. Solving business problems isn't just the domain of the suits. If you were hired to solve a technical problem at a for-profit company, then I assure you that the core problem is a business one. And if you solved the technical problem then you have contributed to solving the business problem, even if you didn't know what it was.

Mark Hoffman
Friday, September 05, 2003

StickyWicket: I think you don't understand Phillip's basic idea.

In you case, you *where* hired to solve a business problem. Which problem? A critical technical problem that nobody else could solve.

They didn't hired you because: "look, there is a problem here, let's just solve it and be happy!", they probably hired you because: "look, there is a problem here, we will probably lose income because of this problem, let's hire someone to solve it!"

So, in the end, even while you are writting code all day long and they don't bother what you think about the strategy, you are just solving a business problem for them...

whatever
Friday, September 05, 2003

Synchronicity...

I was just talking to my boss, who was making a comment on a feature I'm working on. I explained to him how I short-circuited the issue before it became an issue. He made the observation that so many developers don't think forward - they react to requirements and then fix the problems later.

Funny how he just summed up the difference between people who "write code for money" and people who solve business problems, and why the latter are worth much, much more to an organization.

Philo

Philo
Friday, September 05, 2003

If your company makes money not from consulting, but from developing software -- that's your business model -- what's marketing going to say, "Nah, you don't need us, your process is fine as it is"?

So often you're stuck with having to justify the deal marketing or new business development closed and has handed to you... so you make eye candy, reinventing the wheel but with the different GUI, what else can you do? Tell management they really don't need all those features, let's re-negotiate for less?

Rick
Friday, September 05, 2003

Peter: you might interpret it that way, but it definitely wasn't what he meant.  When he wanted to remind us he was the boss, he'd do so directly and explicitly.  :)

Phillip J. Eby
Friday, September 05, 2003

People like do what they already know.
People like get good compensation for their job.
People want to keep their good jobs.
People think their role is superior.

Is that makes a sence for you?

Evgeny Gesin /Javadesk/
Friday, September 05, 2003

This discussion is best interpreted in sociological terms. It's an attempt by the less technically capable to assert superiority over those who are more technically capable, by claiming:

1. non-technical elements of the role are easily separated out,

2. are more important than technical elements, and

3. that technical competence and business competence are mutually exclusive.

My response is that none of the above are true.

.
Friday, September 05, 2003

You're *so* right...  obviously you have found me out.  My technical skills are clearly no match for yours...  No doubt if we compare the code and writings that I have published on the net with your own undoubtedly larger corpus, I will be sorely ashamed by the comparison.

No doubt that's why you post with your real name, so that anyone can search for what you've done and what you stand for, whereas I must post in cowardly anonymity for fear my skills will be tested and found wanting...

Oh, wait, I've got that backwards.  Never mind.  :)

Now that I've responded to the trolling portion of your post, I'll just note in relation to the rest, that I never said any of those things, and I agree that they are false.

But, many people do *believe* that technical and business skill are incompatible, and in their presence it's generally best to conceal whichever skill is the one they consider less valuable.  That is, when you're with technical people who think that, conceal your business skill, and when you're with business people, conceal your technical skill.

If I'm with both at the same time, though, I'll conceal the technical skill, since technical people with those beliefs are rarely in charge of anything important.  Also, it's strategically more useful, in the event I need to take the technical person down a notch.  I just let 'em mouth off about technicalities until either 1) the business people are tired of listening, at which point I nail the tech with a ludicrously obvious business question that makes their lack of business priorities painfully clear to the business people, or 2) I lead the guy out on a technical limb that I can then cut out from under him at any time, because he's underestimated my true level of understanding.

This latter approach is more useful if the techie is a "pet" of a businessperson (i.e., the businessperson thinks they're valuable for some reason), because then I can force them to go along with whatever I say, or else risk being exposed as an idiot, by the fact that they have no idea what *I'm* talking about.  (Not that ignorance == idiocy, but usually these guys *feel* that way about it, which opens them to the attack.  OTOH, a person who's not afraid to admit they don't know something, is a person with an open mind, in which case no "attack" has taken place!)

Every developer in "hostile territory" needs to know these kinds of skills, or they will not survive the coming changes in the industry.  You need to understand business in general, your customers' business in particular, and you need to know how to handle sales and politics.  Because you will be competing with people and companies that do understand them.

Phillip J. Eby
Saturday, September 06, 2003

--But, many people do *believe* that technical and business skill are incompatible, and in their presence it's generally best to conceal whichever skill is the one they consider less valuable.  That is, when you're with technical people who think that, conceal your business skill, and when you're with business people, conceal your technical skill.--

This is terrible advice. If you are a bad ass technical person and a bad ass business person, you should never conceal either trait, ever.  In fact even if you are not so bad ass you should always act like a bad ass. If you carry yourself like you can talk the talk and walk the walk , you end up floating above all the middle management idiots you seem to be describing.

rz
Saturday, September 06, 2003

>> If you are a bad ass technical person and a bad ass business person, you should never conceal either trait, ever.

This is terrible advice.

There is CONSIDERABLE strategic advantage in playing down your talents.

For one thing, flaunting your abilities makes anyone with a chip on their shoulder or personal insecurities within a 10 mile radius want very badly to gang up on you and tear you down ASAP.

This is not a moral or character principle, it's simply the way people are made. And IT and engineering being male dominated fields, the very worst thing you can do is make an issue of the "fact" that you may be in possession of the real truth and the straight scoop.  There are ways to establish your competency to others without inspiring the alpha male feces-flinging reaction in others.

My role model in this is Col. Jack O'Neill of the Stargate SG-1 series. His "thick as a brick" act is intended to lower other's defenses.

In real life, this works. So does the opposite.

Bored Bystander
Saturday, September 06, 2003

Yep.  My old boss had a deliberate practice of typing with only one finger when he was in front of customers, and of making mistakes and/or acting like he was having a hard time figuring out what to push, so that the (very non-technical) customers would be able to feel superior instead of intimidated, and thus conclude that the software was easy to use.  After all, they were showing *him* how to use it, not the other way around.  He was also working around another prejudice that many business men (and I do mean *men*!) had at that time: that people who know how to type are secretaries!

(And before somebody makes a smart-ass remark about "sure, he *meant* to make those mistakes", I'll note that it was software that he designed, and in many cases, had written, right down to the hand-assembled machine code we used in speed-critical portions.  Ha!  Less technically capable declaring superiority over the more capable, my ass...)

I must admit, I never could quite bring myself to fake slowness for the customers, but I *did* learn to cut back on both my flashy moves and my attempts to educate the customers about things they didn't really care about.

One other lesson he taught me about programming that was career changing: truly new ideas are incredibly rare, and truly new problems even rarer.  Chances are good that whatever your problem, five people have already written books or papers on the problem with good approaches to a solution.  If you neglect your reading and research, you'll spend an awful lot of time painfully reinventing approaches that you could just "steal fair and square" from a book or paper.

Ah well, I'd best stop before this becomes even more of a rambling nostalgia thread than it already is.  :)  Crazy to think that when I started my career, the machines we programmed for barely had enough memory to hold the contents of this web page!

Phillip J. Eby
Saturday, September 06, 2003

bored, philip, the situations you describe sound really lame. i guess my take on it is that there are situations that exist where you don't have to play stupid games to be successful. i'm glad i've gravitated to those types of situations.

rz
Saturday, September 06, 2003

rz,

Suit yourself if you think that the only thing that matters is pure talent and demonstrating that talent.

There's a massive body of human relations knowledge out there - people like Dale Carnegie and his acolytes - which basically says that the best way to form relationships is to take an interest in the other person and make them feel superior, on top, etc.

I don't mean ass kissing, either. I had SATs of 710/720, and I know for a fact that the "brightest kid proving himself syndrome" pisses everyone off REALLY quick and creates rivalries out of thin air.

I mean that it's possible to make other people feel important and masterful w/o demeaning yourself. Look at it this way. If you don't create an issue by being "all that", you have room to maneuver...

But, suit yourself.

Bored Bystander
Saturday, September 06, 2003

I didn't say anything about downplaying people skills. You guys are talking about situations where the boss is pretending to type with one finger, where you should conceal your business acumen around techies, or your technical acumen around business people.

What I'm saying is that you can have a very successful career avoiding situations like that in the first place. Life is too short to be dealing with BS like that. Have some dignity.

Maybe you guys are stuck in some location where you feel like you have to play those games to survive. I don't buy that you have to play dumb in order to make a sale. You can make friends and influence people without downplaying your talents. You don't have to pretend to be incompetent in one area to make other people feel good about themselves.

BTW, thanks for posting your SAT scores.

rz
Saturday, September 06, 2003

Hmm, I haven't read the whole thread yet, but I've always found it charming when some ceo plays the nontechy old Fuddyduddy character.  You have to admit he's got a sense of humor.

sammy
Saturday, September 06, 2003

I'm not sure I see where there's a conflict between my old boss' dignity, and helping somebody past their fear of technology, to buy some tools that'll help their business.

Similarly, I don't see a conflict between my dignity and getting across an idea that'll help the company I work for.  But perhaps I'm confused by my silly notion of wanting to help people learn and accomplish things...  and thinking that getting that result is more important than making them bow down before my mighty knowldedge and "mad skillz".

Phillip J. Eby
Monday, September 08, 2003

"But perhaps I'm confused by my silly notion of wanting to help people learn and accomplish things...  and thinking that getting that result is more important than making them bow down before my mighty knowldedge and "mad skillz". "

Certainly I agree that producing results is the critical aspect over pumping up a false ego. 

The thought of acting incompetent as a means of achieving those results is where the dignity aspect comes in.  In the area of helping others to learn and accomplish things, I would think the majority of people would rather have a confident teacher over a blubbering idiot.  But maybe that's your culture.

Joe AA
Tuesday, September 09, 2003

> The thought of acting incompetent as a means of achieving those results is where the dignity aspect comes in.

Exactly.

You're being more than a bit disingenuous here, Philip.

How many of those customers would still buy if they found out how your boss was tricking them? How many sales would your boss lose if his little act were exposed? Not all of them, you'll say. Sure -- but more than a few, I'd wager.

It's one thing to not tell everything you know, another thing to actively mislead people.

Portabella
Tuesday, September 09, 2003

Most things that are "sold" interpersonally are sold based upon personal chemistry and rapport, not upon facts and objective details.

I think this is true even (and especially) in the instance where a developer interviews for a job. The decision makers can posture all they want that they are selecting the best "man's man" studly Godlike programmer but what they usually pick is someone who happens to like the same things that they do and whose personality meshes with theirs.

Getting back to self effacement and "dumbing down" for a prospect - in a sales situation I think that it's perfectly legitimate to play a role that makes a prospect more comfortable. In fact, if you fail to do so you'll probably lose the prospect, unless they have already made a very firm mental commitment to your product or service.  Sic: not doing so puts you at a competitive disadvantage.

I think it's amazing that a point like this is being misinterpreted so wildly.

Bored Bystander
Tuesday, September 09, 2003

> that it's perfectly legitimate to play a role that makes a prospect more comfortable

I think the point that's being made -- *not misinterpreted* -- is that out-and-out lying isn't necessary to make the prospect more comfortable. Whenever you "lay it on thick",  many people will get pissed off if they find out. They'll feel -- and rightly so -- that you're making a fool of them. Some will be enlightened enough to laugh. Others will be enlightened enough to wonder what the reason for all the BS is.

I support the people who feel that it's beneath their dignity to play those kinds of games.  And there's plenty of ground between the wheeling-and-dealing old boss and the Anal Super Techie stereotype.

Please don't get me wrong: I think it'd be fun to meet Philip's boss, I'm sure he's quite a character, and no one can say that he lacks a sense of humor!

Portabella
Tuesday, September 09, 2003

I think many of the people that Roger (my old boss) "fooled" were well aware that he had more technical competence than he let on, and were grateful for him allowing them to "save face".

It's important to understand that the purpose of the maneuver he performed was to protect the *customer's* dignity.  Had he not done this, then many customers would have felt it necessary to reassert their authority/ego by dismissing computer-related things as irrelevant.

However, once their one-up status was assured and the purchase decision made, he saw no need to be slow in working the machinery to charge the customer's credit card.  I never saw anybody become upset at his sudden transformation to technical skill, because by that time they were sufficiently secure in their position as a knowledgeable and progressive decisionmaker, so as not to care how much he knew about computers.  In fact, at that point his skill would be considered a mark of their business acumen in choosing the right people to provide services for their company!

Keep in mind, too, that I'm talking about an era when high-priced business computers had 48K of RAM and cost $2500 for a model with dual floppy drives.  People maybe had a distant young relative who knew something about computers.  This was a much more sensitive and threatening issue to many businesspeople, particularly in the real estate industry, many of whom swore to retire before they'd deign to touch a computer (i.e., lose face by having to study something that sounded intimidating).  Since most of our customers were small-to-medium real estate offices, often located in rural areas, sensitivity to these strong emotional issues was a necessity.

In my case, I was able to get away with appearing to know more, because I was almost 20 years younger than Roger...  and therefore wasn't as much of a threat to many egos.  (He's a kid, what does he know?)  However, in some of the sales situations I was in, I ran into similar ego issues and didn't know how to handle them.  They required that I display positive shared business knowledge, and establish myself as a fellow salesperson, which I didn't know how to do yet.

Phillip J. Eby
Tuesday, September 09, 2003

Oh...  important other point...  salespeople love a good sales pitch.  Real estate people are salespeople.  When Roger gave group sales presentations on the software, people often *applauded* because they thought it was a great pitch.  They then bought the software, because it is an article of faith for salespeople that a good pitch will result in sales.  Buying a product that has been given a good pitch, therefore, reaffirms the salesperson's belief that they too will be successful if they can just give a good enough pitch.

Naturally, as with any generalization, there are exceptions, but I saw this happen often enough to agree with Roger's assessment of the general rule.  It was a few years, however, before I was able to get the same kind of success in one-on-one presentations.

Anyway, I just wanted to point out that we weren't selling to stupid people.  They knew exactly what he was doing, because they were salespeople, and they loved it not only because he allowed them to save face, but because he was a *good* salesperson, and salespeople like to buy from good salespeople.

Last, but not least, please don't assume that the "playing slow" tactic is necessary to sell even real estate software *today*.  (For example, you'll find far fewer real estate business owners today who are as truly *afraid* of computers as people were in the 80's.)  I brought this up only as an example of one particular kind of situation in which concealing technical skill -- or at least not focusing on technical issues -- was a vital part of establishing rapport necessary to achieve some result.

Phillip J. Eby
Tuesday, September 09, 2003

*  Recent Topics

*  Fog Creek Home