Search This Blog

More on the Productivity of Software Developers

It was my former boss who introduced
me to the principles of Performance Management and he gave me a job to do which
enforced learning.

“Get out there, learn about Performance Management and
implement a system here that will get our people to work harder and
smarter. Incentivise people and they will be motivated to improved
productivity.”

So I did. I learned from asking people questions and I
learned from the Internet. I learned about ‘The Balanced Scorecard’ and I
learned as much as I could find about Key Result Areas (KRAs), Key Performance
Indicators (KPI’s) and ‘Agreed Targets’ – measurable performance targets agreed
between managers and employees.

And in time we introduced it at the workplace. And my word,
did it work. In our payroll bureau our monthly error rate on payrolls was
reduced from a monthly average of 5 to 0.5. It worked so well that our
administrative staff – the tea maker, the cleaner, the drivers and the
gardeners – asked why they could not be brought onto the scheme. So we did. The
tea maker who had previously complained that management did not advise him when
tea and biscuits were needed in the boardroom stopped complaining. Instead he
asked daily if and when tea and biscuits would be required and he monitored the
use of the boardroom so that he would be aware of when we had guests, then he
automatically brought in the tea, coffee and biscuits.

My most valuable piece of learning was that to be
meaningful and valuable to the organisation, targets to be measured should be
OUTCOMES, not OUTPUTS and I learned that an outcome was the consequence of
doing a good job, while an output was nothing more than doing a job. For
example, the outcome of running a payroll was a satisfied customer, while an
output was simply running an error free payroll.

So we started measuring outcomes and not outputs.
Wonderful. Customers were happy, management was happy, the business grew.

Most staff knew that they could earn a monthly bonus
by doing more. And they did.

But we found the problem of the Software Developers
and our inability to set meaningful ‘Agreed Targets’ that measured outcomes,
not outputs.

Has he finally solved my problem of Performance Management
for Software Developers? Perhaps he has, but again perhaps not. Pink argues
vociferously that providing incentives for people to work only works for some
people and not others, depending on what they do and how they do it.

What then does Pink tell us?

Incentives work for one-dimensional jobs but they do
not work for multi-dimensional jobs. In fact, in multi-dimensional jobs,
financial incentives can be damaging. And he demonstrated the realty of this
through the ‘candle problem’. You want to know about the ‘candle problem?
Here’s the link to Joachim Ramm’s Master’s Thesis: http://bora.uib.no/bitstream/handle/1956/6340/100116498.pdf?sequence=1

People in Multi-Dimensional work are motivated, not by
money or other financial rewards, they are motivated by Autonomy, Mastery and
Purpose

1.Autonomy: The freedom
to choose when and how to do the work. Independence, self-rule. The urge
to direct our own lives.

2.Mastery: To be the
best at whatever it is you do.

3.Purpose: the yearning to do what we do in the service
of something larger than ourselves

Now the question is:
Is software development a single dimensional or a multi-dimensional discipline?
Pink argues that in some cases software development or simply put,
‘programming’ is single dimensional but it other cases it is not.

What is it in or case? Our developers are being asked
to be creative. They are being asked to be innovative. They are being asked to
solve customer needs that are frequently unique and require creative,
innovative thought. They are being asked to think ‘outside the box’, using
their diffuse thinking mode. There is no doubt that they are in a multi-dimensional
job.

But they are also in desperate need of money in this
desperate economy with its desperate limitations to be able to send their
children to school. Schools are expensive in Zimbabwe. Proper schools that is.
And every parent wants his or her children to have the advantages in life that
a good school can create for them.

So here’s my solution to the Product Developers
motivation: Pay the developers what they would receive if and when they
achieved their performance objectives bonus level. Then give them the freedom
to work where and when they want but they can only work on business needs of
the business. (There could be special cases for doing something different
sometimes). Give them opportunity and encouragement to learn new languages, new
techniques, new procedures and once a quarter, take them out into the
businesses of those who use the systems they develop. Let them see how their
systems are being used, let them talk to the users and find out how they think
and feel about the systems they have helped to develop. Let them see for
themselves the results of their work.

Get link

Facebook

Twitter

Pinterest

Google+

Email

Other Apps

Comments

Post a Comment

Popular posts from this blog

I have been in the
firing line recently for failing to develop acceptable performance management
targets for software developers. I consult for a business that believes,
strongly, in performance management – setting Key Result Areas, Key Performance
Indicators and performance targets for all staff. We measure performance
monthly. When staff members over-achieve they are rewarded with a bonus. When
they under-achieve we investigate to determine why. Sometimes it is because
they had inadequate resources, sometimes it is because they didn’t have the
skill and sometimes it is because they didn’t have the will. Top management expects
software developers to write bug-free code. Nevertheless we employ a tester to
check. Testing is what is done in the software development field – it is
essential to product quality. So the question I am
being asked by management is why? Why can’t developers be like everybody else
in the organisation, excel at their work and develop bug-free code? So I did some
re…

In my previous blog I
wrote about why software developers can't write bug-free code. But I am still
faced with the problem of developing performance targets for Software
Developers. Against all global advice of course. That has been said already. On the subject I have
been meaning to ask Angie Culverwell, Product Development Manager, how she
knows who is a good product developer in her team and who is not. So today I asked. "I know that A is
a good developer because he ‘cares’ about his work. I know when he finds a
development problem, he will find a way round it, because he cares. I know also
he produces code with bugs but that is inevitable. When I give A a job to do it
will be done, usually on time. But the problem of
creating timelines is that they are either based on thumb-suck or based on the
need as defined by the Customer Service Manager and/or the User. So measuring a
Product Developer on the basis of meeting timelines is not always a good idea.
In fact it is never a g…