More on the Productivity of Software Developers

It was my former boss, Steve Marshall, 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 at Payserv 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 to Payserv. 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.

And then I watched and listened to Daniel Pink on TED

Daniel Pink is a great speaker on TED. http://www.ted.com/talks/dan_pink_on_motivation?language=en

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.

Managing the Performance of Software Developers

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 good idea."

So Angie measures the performance of her developers on the basis of attitude. But how do you put numbers to attitude? Can we say A has a ‘3’ attitude this month and perhaps only a ‘2 attitude next month? And B has a ‘1’ attitude this month and a ‘2’attitude next month? Attitude tends to be a fixed attribute. We can talk about it at the Annual Review but not as a monthly performance target.

Do we then perhaps measure performance on the developer’s hours worked? No because hours worked does not measure ‘productivity’. Sometimes it is measure of lack of productivity when it takes, say A 50 hours to develop a piece of software and 100 hours for B to do the same. Neither is it an ‘outcome’. It is only a measure of output. Hours worked therefore cannot be a measure of ‘performance’.

So we are back to ‘square one’. Is it possible to develop realistic performance measures for product developers? 

Anything is possible. Miracles we perform immediately, the impossible takes a little bit longer. 

Watch this space.

Learning to Chunk and Why Software Developers cannot write bug free code

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 research. On the Internet, where else?

Developers worldwide develop code with bugs. It’s unavoidable. According to one site, if business managers think they can set performance targets for developers like they do for everyone else in the business, they are mistaken. And if there is an HR Manager out there who can develop suitable targets for developers that enable the effective management of their performance, he or she will be the next speaker on TED.com. And moreover, will be sought after by Bill Gates, Tim Cook, Mark Zuckerberg and everyone else who matters in the software development field.

I haven’t given up – not yet.

But I had some thoughts recently:

I am attending a course on the Internet called “Learning How to Learn” with Barbara Oakley and her team from the University of California, San Diego. I thought I knew nearly everything about learning – after all I wrote a book on the subject in 1999 – but I enrolled because I thought there might just be something new. And of course there was. I learned very early in the course about the focused mind and the diffuse mind. The focused mind is what we all use to do our jobs – even developers use the focused mind. The diffuse mind is for something else. We use it for creativity and innovation, for ‘understanding the whole’ and not just the parts that make it up. We should, according to Barbara, use both but at different times.

So I did some diffuse thinking.

I thought back to my book on learning and how it evolved. I remember writing for nights on end. But I remember more that I sent it to a colleague for editing. My colleague, Howard Dean, held on to the hard copy pages of my book for three months and then sent it back in a large envelope which I opened and first I read his covering note.

Fortunately.

He wrote: “You have a natural story-telling ability, but……” And he then went on to say there were a few corrections needed.

I looked at Page 1 and there were three or four red marks in ball-point pen. I looked at Page 2 and saw the same. There were, I was to find, red marks and writing on EVERY page. I was shocked. How could I have written such drivel? But because of the comment on the cover note, I didn’t throw the whole lot in the waste-paper basket. I took up the challenge and repaired all the ‘bugs’.

The book was eventually published and I won the Zimbabwean Personnel Practitioner of the Year in 2000.

On the question of developers and bugs, my diffuse thinking continued working. And I did some 'chunking'

Successful authors all have editors who find the ‘bugs’ in their work. I know this because nearly every successful editor acknowledges the help he or she received. Only after the ‘bugs’ have been found and repaired do the books reach the market. Authors and Software Developers must have something in common, methinks. The difference probably being that developing software is a far more intricate and exacting task than writing a book, (or a blog like this).

How does one manage the performance of an author? Quite simply by the number of books he or she sells. And perhaps that is how we should manage the performance of a Software Developer? Well, not exactly the same way, but on the successful or unsuccessful deployment of the software.

But like the author who ‘develops’ books with ‘bugs’, we should expect the bugs in the original software and managers should not penalize software developers for creating them. They should instead employ Software Testers who excel at using their diffuse minds to make every attempt to break the software before it reaches its market.

So software developers, like authors of books, rely on a colleague, a partner – in the case of an author, the editor and in the case of the software developer, the tester.

My problem is not over though: how do we manage the performance of a software developer on a month by month basis? There has to be a way.