A list of conclusions from

Almost all project failures are due to sociological problems, yet managers spend most of their time on technological issues because those are the issues they were trained to handle.

Take care of your people first, and they will take care of you.

Quality equals Productivity. If you can't identify with this, it's excusable, you've probably never done any Software Engineering, or at least any that others don't have to clean up after.

Get motivated people to work for you, then let them do their own estimations, help them buffer the schedules if too ambitious. Pressure does not help to increase productivity, let their pride in their own work be the driving force.

Technology investment for productivity gains have to be made with a long term view, and expectations have to realistically consider how long it typically takes for the corporate culture to assimilate the new process, methodology or tool.

Workplaces should be customized to enhance the productivity of intellect workers, this investment gives the most bang for the buck.

Fix the workplace before putting resources into anything else!

If you're not going to perform a detailed study of workplace requirements for each type of worker, at least differentiate between the different categories such that those who need more space and privacy get more than those who don't.

I'm not sure how practical it'll ever be to try to measure any aspect of a software developer's productivity as our architectures, paradigms, methodologies, tools and languages are in constant flux. But I have always believed that you can't confirm improvement of anything you don't measure. On the WWATS project, I used to keep very basic statistics like number of lines of code needed to accomplish a task, lines per module, stability of each module (how recently it had to be changed) in relation to the rest of the system etc. just to get a rough idea of how each member of my team is performing. Your gut feel for any belief is improved with some real raw data.

In the technology realm where devising or using more appropriate algorithms yield order-of-magnitude instead of fractional improvements, it's such a shame that it's so damn difficult to concentrate at work because some bean counter decided that 36 sq. ft. of dedicated space should be enough.

Even though improved phone technology has broght us "Do Not Disturb" modes and voicemail, we have to make a conscious effort to ensure that they are put to use to protect our flow periods.

My most productive days as a software engineer were in Milpitas, Building 6 when I had my own office with a door on it. But if the company really wants to reduce my dedicated space and effectiveness by 70%, so be it! I'm not going to work overtime just to get back the hours which they didn't consider important enough to protect in the first place.

When opportunities arise, we have to battle hard to make our workplaces more condusive to intellectual work by following the guidelines provided above. That's why Bill Joy moved his team out as Aspen Smallworks. And in similar fashion, James Gosling must have had a creativity-condusive environment off-site at 2180 Sand Hill Road when he conceived Java on the Green Project.

Try not to be influenced by appearances to bring in talented people, then let them be themselves to get the most out of them.

Hiring the right people is paramount so a lot of effort should be put into examining samples of the candidates' past work, testing the candidates' expertise using a small barrage of test questions, and auditioning candidates to test their communication skills.

It is of the utmost importance to take care of employee development and create a sense of permanance with a career path.

Continually changing the way we do things is good not just because you're trying to improve, it also keeps people interested. But don't ever use tons of bureaucratic methodology as it will choke your organization. If you have to use standards, only use the proven ones and do your best to keep your usage light.

From my own experience, real work gets done so much faster and better in great teams that effort should be put into forming them.

doesn't matter how ludicrous a manner in which a jelled team operates as long as it is highly effective.

People have a natural tendency to learn to work well with each other if they have the same goals. We must try not to impede this phenomenon and instead make full use of jelled teams

Give your team many opportunities to succeed together, starting off with the smallest of projects, then increasing in scope and difficulty as they succeed in the previous ones. You don't have to restrict this team-building activity to work-related projects.

Choose your people carefully, then trust them completely because that's the only way to really succeed. Rules are not as important as what makes sense. Team chemistry is as important as skillsets, maybe more. The best bosses do what they are best at and leave what their workers are better at to them.

The elements that facilitate team formation and jelling may be counter intuitive, but if a manager is brave enough to provide the above mentioned environment, the team will reward him with success as they try to protect the enjoyable environment.

Whether we use the above-mentioned techniques or some of our own, there is a need to constantly breathe life back into our work. We spend way too much of our lives working to find it a drag.

Good managers try their best to sense who needs direction and who doesn't, and provides direction for the former while only removing barriers for the latter.

Don't be discouraged that you are only one trying to change something silly in your work environment. If it is obvious enough, you may be able to easily get your co-workers to join in your efforts.