Finding

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.

Hiring

Apparently, Google employ the Lake Wobegon strategy, namely:

• Only hire candidates who are above the mean of your current employees.
• No hiring manager.
• All hiring at the company level, not the project level.
• First decide which candidates are above the hiring threshold, then decide which projects they can best contribute to.

How does your company do it?

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.

Inspiring

Here is a list of management tips to get the best out of people:

• Focus on strengths not weaknesses. Provide opportunity to use and develop strengths. Ensure each employee has interesting and challenging work tailored to their strengths.
• Provide a nurturing work environment: respect, trust, integrity, support, openness, value learning. Encourage risk taking. Support learning from failure. Satisfy a desire to grow and create. Long term focus. Encourage individuality. Allow personal rearrangement of workspace to suit each employee. Reduce stress. Make it fun.
• Listen.
• Provide ways to achieve personal goals inside organisational goals.
• Remove blockages and unnecessary administration and bureaucracy.
• Notice when people do good work. How best to reward staff? Generally, I feel team-based rewards are more effective than individual ones.
• Provide a career growth path.
• Build effective teams (see below).

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:

• Provide a free healthy bowl of fruit.
• Provide a quality espresso machine.
• Give away free computer books.
• Allot time for self-training in an area of interest.
• After a period of three years (say), allow a developer to work for three months on a Skunk works project of his own choosing (remember that Unix, Apple Macintosh and IBM PC were all originally Skunk works projects).
• Avoid situations where employees may feel compelled to resign to save face. This can happen, for example, when you hire external candidates and promote them over existing qualified employees.
• Prefer growing leaders inside the company to recruiting externally.

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.

Team Harmony

DeMarco and Lister provide a number of interesting suggestions for improving team harmony:

• Interview Auditions. When hiring a new team member, the candidate is asked to give a technical presentation to the whole team and the whole team decides whether to hire or not.
• Allow individuals to form their own teams and "bid" for projects. For example, developers who are friends and get along well together could form their own team and bid for a project.
• Encourage teams to develop their own distinctive personality (by wearing all black for example, like IBM's legendary "black team").
• Give project teams a power of veto over release of a product they feel is not yet ready. Put another way, this is following Philip Crosby's general quality advice of allowing the builder to set the quality standard.

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:

• Visionary
• Coaching
• Affiliative
• Democratic
• Pace-setting
• Commanding

only the first four are suitable for inspiring and keeping staff over the long haul. Goleman suggests you switch between the first four styles appropriately and cautions against using the last two styles, except in short term emergencies. Moreover, for long term company health, it's vital to rely not on one leader, but to cultivate leadership and EI skills throughout the organisation.

Deadlines

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?

References

• Peopleware: Productive Projects and Teams by DeMarco and Lister
• Primal Leadership: Realizing the power of Emotional Intelligence by Daniel Goleman et al
• Quality is Free by Philip Crosby
• Joel: Whaddaya Mean, You Can't Find Programmers?
• Top 10 Reasons to Work at Google
• Lake Wobegon strategy
• TimBoy criticizes Lake Wobegon strategy
• Google hiring like its 1999
• On Interviewing and Interview Questions
• How do you find good perl programmers to hire

14-apr-2006: Significant update based on feedback and further thoughts. 14-may-2006: more updates.