Nate Duehr wrote:
> Great point.  This article does a pretty good job of describing how not to
> hire the bad ones:
>
> http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

I read it this morning (someone else posted a link to it earlier), and it 
does have a lot of good points, but.. it has this unfinished feel, even 
though it's "v3.0".  Especially towards the end (author got tired?).

I skimmed over the other two articles (on screening resumes & phone 
interviews), and they look interesting -- maybe I'll read them later, too. 
We use the same exact process, in that order, and came up with a lot of the 
same conclusions.

> No, which is why I believe it has merit.  (GRIN)  Ultimately in a support
> group you're paid by only a few factors, and one of them that's objective 
> is
> whether or not you know how to fix things properly and/or provide
> workarounds in a way the customer is not upset.

Yes, but how do you measure it?

> (Bigger picture, you're paid if customers keep signing service contracts.
> Ironically if the code were perfect, and easy to use/install, the service
> contracts would cost less and there'd be very few support people.  When
> engineers screw up, they guarantee I still have a job... so, by suggesting
> ways to make our products permanently better, I'm technically working 
> myself
> out of a job, right?  This is one of the horrible deep Catch-22's of the
> software support industry.)

I think that if you're good, you've got absolutely nothing to be afraid of. 
The company will downsize the poor performers first, and there will always 
be the need for tech support. Worst comes to worst (products require zero 
support), you can join the engineers. :)

> But engineers are rarely paid for what they actually do, they're paid for
> release dates... release junk, you still released ahead of schedule, and 
> you
> still have a job and a bonus... as long as you met the general
> requirements.  Many times engineers can even convince managers to drop
> important requirements near the end of a project, because guess what... 
> the
> manager's bonus is based on the release date too...  That's just wrong.

Yes, and I believe that Agile helps to drop the non-essential features and 
keep the important ones, early in the project. You may not agree with 
everything about Agile, but you've got to concede that iterative development 
is better than non-iterative.

> Simple.   Did it work for the customer?
>
> (The same metric any small developer or business uses daily to prioritize
> their work, or they go out of business.)
>
> All the other metrics, in the end, don't matter.

Sure. But how do you *measure* these things? That's the $1M question...

>> Does the support department have an objective measure of the impact of a
>> particular bug on the product's performance? Or does the Engineering
>> department go without a bonus, simply because someone in the Support
>> department is having a bad day?
>
> Come now... not just one person would determine this.

Departments usually have only one head. Even if she's not a czar, her 
opinion can override that of a bunch of techs.

> Have you seen the rediculous number and types of metrics most large 
> support
> departments have these days...?  Ticket systems have grown into their own
> world of multi-million-dollar systems (after you pay all the consultants 
> to
> upgrade the thing because it's so complex no one in your own organization
> can even work on it at that level).

Yes, I've heard first-hand accounts. Having quotas for number of calls 
answered per hour (or per day) is stupid. Reps end up hanging up on the 
customer, hoping that when he does call back, it will be someone else he'll 
yell at. It's an easy metric to measure, but it's the wrong one.

> I think that one of the solutions is to have someone from outside both the
>> Support and Engineering departments decide who gets the bonus. That would
>> assure at least some level of objectivity.
>
> Sure.  Fine.  Sales?  LOL!

I don't see why not. The single most important measure of the success of a 
company, is it's long-term sales figures. It's in the Sales department's 
interest to reduce the cost (bugs), and increase the value (features, 
performance, stability) of a product.

> Technicians peer's should be technicians.

I'm afraid you will get only one side of the story then. Engineers tend to 
like working on "interesting" features more than "important" or "valuable" 
features (the two sometimes don't coincide). Technicians have their own 
interests, which conflict with those of the engineers and the customer. The 
only way is through compromise and collaboration.

>> Money is not the only (and not the most important) motivator. Surveys
>> consistently demonstrate that it's not at the top of most people's list 
>> of
>> things that make a good job. Salary offered must be competitive, but
>> things
>> like "interesting work", "a good boss", and "growth opportunities", tend
>> to
>> be higher priorities than money.
>
>
> They only say that AFTER they have a job and are getting paid.  Ask anyone
> without a job.  Maslow's Heirarchy of Needs skews those surveys, because
> they only ask those survey questions of people who already have jobs.  The
> few that will stand on principal and not work because they want something
> "more interesting" when they can't pay the rent, are few and far between.

Sure, absolutely. Having a job (or the fear of losing it) is a motivator in 
itself. But, 'that only makes a guy work hard enough not to get fired' 
("Office Space").

The money question is separate from the "having a job" issue. Some people 
with jobs decline offers that would mean significantly higher salary-- so 
they value the things I listed more than money.

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist