Hello Lizardnation,
speaking as a programmer, besides the paycheck at the end of the
month, the greatest reward that compensates for my work is:
interesting work. Some could say money comes first, but there are many
jobs that bring in money. There are less jobs however that stay
challenging on a constant basis. Even some jobs I've been through as a
programmer were not challenging, and regardless of the pay I felt the
need to escape such an environment. If it's not stimulating and
educating, it quickly becomes plain boring. As employee you also lose
valuable time, because you could have learned something on the way.
Now for the model of compensation; you may think it to be tempting to
reward in a project & deadline oriented matter. And why not? This
holds true for many start ups in IT. It seems to be a motivation
factor; the more efficient the staff works, the more free time they
will end up with.
More free time? Paradoxically, some studies have shown the exact
opposite is true. Suddenly, people who don't work for the clock --
say, 9 to 5 -- but for themselves, will work longer and harder for
certain periods. This you might say is what you want. But does longer
work result in better work? I should think not. It certainly will lead
to burn-outs, frustrations among the team, maybe even less teamwork --
and mobbing. Yes, it might result in longer work, temporarily. But
some of that work now may be time spend by the employee on building up
defense mechanisms; rhetorics or facades why this or that project
isn't finished yet. It will certainly not make it easier to help
others in a team, or asking for help; suddenly, for every minute you
spend on "the other ones project", you pay for it from your own
pocket.
One thing I learned during my years as programmer: there's always a
deadline. Rush yourself through this one project, and the customer
will come up with even tighter deadlines on the next. Once you
understood the next deadline will always be there, you won't easily be
motivated by that factor alone. You then have to motivate yourself --
often, this is done simply by taking a break. This you may call
"everything outside of 9 to 5". It will help recharge the battery. You
can only really do that if you're at least able to forget that this
very instant, you could squeeze some more work through the pipeline.
Especially programming & developing ideas (which is my focus here as
it's the only perspective I can share from experience) is no job where
you're able to produce the same quality at the 11th hour. So, no
deadline can pressure me into working every weekend and second night,
just to finally end up with being so appalled at what I do that
quitting becomes the only option.
All this is (how could it be else) just my opinion. Personally I owe
it to myself to give all I can, and to make sure to be able to do so
tomorrow still. I hope this is of some inspiration to whatever
compensation plans you finally decide on. |
Request for Answer Clarification by
lizardnation-ga
on
12 Jun 2002 03:52 PDT
Hello J_philipp,
Most people want to produce and be wonderful at what they do and
deliver more than they've been ask to, with the very rare exceptions.
What we actually do is generalize the exception and treat everyone in
a negative way.
If I may rephrase the question, as I come from a development
background. How do I suggest a compensational structure that allows me
to provide management with the means to gauge the results of
developers and their surrounding team?
They're both humans after all, but they don't seem to understand each
other's priorities and if they do, they don't use the same language to
communicate them.
Methods were invented to cater for these gaps. A method which would
allow a creative technical person the roam and have the inspirational
zone they need to produce and also for that same method to keep those
trying manage it all and are responsible for the financial
deliverables to stay out of the way and complement as they allow
things to realize their potential with them playing a supportive role
and be able to identify achievements and productivity as they
understand them which is not usually apparent to them when dealing
with technical staff.
That sounds all well and good, but we don’t want to go misapply the
right thing by doing it the wrong way and come up with bad results.
You’ve addressed a very important problem, how about a solution that
suites both sides? :-)
/Lizardnation
|
Clarification of Answer by
j_philipp-ga
on
12 Jun 2002 05:15 PDT
Hello Lizardnation,
one simple solution: reward with responsibility (not free-time).
Responsibility results in skilled workers to create an environment
that will be challenging and push them to their limits, thereby
ensuring the job stays interesting. This would be true for a staff of
programmers, or e.g. designers.
Also, make sure everybody realizes the goal. If the goal is a product,
then don't let them work for the management, or the boss. Let them
work for the customer. Yes, that means they will have to answer to
customer feedback. They might not like it all the time, but they will
try to have the best possible customer feedback next time. They will
try to make better software just so that they will be kept from
one-hundred support calls a day.
Now, you may or may not want to express responsibility in company
shares, too. This means a percentage of the company's monthly (or
quarterly, or yearly) revenue goes directly to see the wallet of the
programmers. Or entire staff. Again, make sure your rewards are either
shared equal or kept secret -- you don't want to have a team where
everybody is jealous at each other, because that could cause
counter-productive acts of sabotage.
"I didn't forward that email last week? Oh, sorry. Let me send it
now."
What does that mean for the management staff? I should say, to them:
- Communicate the goals, not the solutions. (The solution is technical
and in the responsibility of whoever should lead this project on a
technical basis -- depending on your team size, this might well a
manager of its own.)
- Give positive feedback, almost exclusively. Don't worry: Negative
feedback will be returned by the customers, if you put them in touch
with the programmers. (No matter how good the product, there will be a
bug.)
- Make responsibilities crystal clear, not only to the single employee
in charge of this or that project, but also to the whole team. Make
sure the one responsible knows how to share that responsibility with
the team.
- A daily meeting (depending on team size, only for certain groups,
but at times for everyone) should almost be a given.
- A monthly, or bi-monthly meeting with every single employee to
discuss projects, and very importantly: discuss the revenue created by
certain projects the programmer worked on.
Also, I don't think everybody needs to speak the same language -- but
have them respect each other. I don't understand everything management
needs to do and how they do it (and vice versa). I don't want to
either. The respect is often strengthened if responsibilities aren't
blurred, but shared just enough so that one sees the troubles and
complexity on the "other side".
Hope this is of help.
|
