|Just another Perl shrine|
Comment onby gods
|on Feb 11, 2000 at 00:06 UTC||Need Help??|
According to the Top 10 Reasons to Work at Google, there are a number of workplace benefits that I'm currently being deprived of, namely:
Perhaps Google has been influenced by Peopleware's advice to focus on who does the work rather than how it is done. Simplifying outrageously, Peopleware's formula for success is:
Further to the interview guerrilla tactics discussed in On Interviewing and Interview Questions, this meditation focuses on strategies for finding, hiring, inspiring and keeping top-notch developers.
It seems sound strategy to spread the word that your company is a great place to work. With that done, there should be less need to advertise jobs since top developers will hopefully come to you. Encouraging some of your developers to interact with outside programming communities, universities, and perhaps write a public blog discussing their work may help get the word out and develop contacts with potential new employees.
Social networking and employee referrals are also excellent ways of finding suitable candidates.
Apparently, Google employ the Lake Wobegon strategy, namely:
As already discussed in On Interviewing and Interview Questions, there seems to be a broad consensus that candidates should be asked to write code at the interview and give some sort of technical presentation to their future co-workers.
Induction and Training
Staff induction is considered so important at Hitachi Software that the chief scientist's principal function is the training of new hires! How are new hires trained at your company?
Allowing regular time for self study/self training can be more effective than sending people to formal training courses.
Recruitment seems more important than training -- after all, there is little point wasting time and money training a lemon.
Here is a list of management tips to get the best out of people:
Keeping Staff Happy
"External" motivators, such as bonuses and recognition awards, are of dubious value and may do more harm than good; more sustainable ways of motivating staff should be actively sought.
In addition to the Google benefits mentioned in the introduction, some other ideas that might be tried are:
Because taking benefits away damages morale, it seems best to be conservative and only offer cheapish benefits that can be sustained in the long term. Benefits that improve employee health (e.g. free fruit) are preferred to those that don't (e.g. free soft drinks) and may even pay for themselves in reduced sick leave.
DeMarco and Lister provide a number of interesting suggestions for improving team harmony:
Emotionally Intelligent (EI) Leadership
Daniel Goleman asserts that the primary job of leadership is emotional. The leader primes good feeling (creates resonance) in his staff ... which unleashes the best in them. Emotionally engaged employees usually have higher productivity and achievement. Moreover, various studies have shown that up to 70% of employee perception of their organisation comes from the actions of their leader.
From the six fundamental leadership styles, namely:
Peopleware provides convincing evidence that setting overly tight deadlines does not speed up product delivery. On the contrary, their analysis shows that unrealistic deadlines actually harm productivity and that higher productivity is achieved when working to realistic deadlines. Apart from harming productivity, unrealistic deadlines (especially artificially imposed ones) cause significant long term damage to staff morale, turnover and to the company's reputation for quality. To keep staff happier and more productive, allow the builder to set the deadlines and the quality standard.
As for improving estimating accuracy, keeping historical data on how long previous projects took is a good place to start.
People versus Process
In many disciplines, such as aircraft maintenance, following a strict, well-defined, step-by-step process has achieved excellent results. But what about software development? Should the job, the process, the methodology be strictly defined and the developer ordered to follow it? Or, at the other extreme, should each developer be allowed to choose any process or methodology he/she prefers based on individual taste, strengths and weaknesses? Perhaps methodologies and processes are best agreed by consensus at the team/project level rather than the company or individual level. How formally defined is the development process and methodology at your workplace? How strictly is it enforced?
14-apr-2006: Significant update based on feedback and further thoughts. 14-may-2006: more updates.