Fog Creek Software
Discussion Board

Psychology in the work place

To start this, I am not a programmer, I am what you would call a manager (Although I prefer to refer to myself as a problem solver, coordinator and the guy who tries to keep everyone happy (the customer the engineers and all other departments).
I also have a philosophy that I report to engineering and not the other way round. As I know nothing about writing code, why should I tell them how to do stuff? I just need to make sure they know what needs to be done and obtain a delivery date that is acceptable to the customer and make sure that date is met. Easy right? Well I don’t suppose anyone here needs to answer that question! What I am looking for is how better to manage people from a psychological point of view. What I am talking about is not about messing with peoples minds, but how to do the following:
•    Motivate people to want to work harder and better (as opposed to making them work harder)
•    How to get senior management to approve projects they are not really interested in. (This is mainly how to best deal with office politics at a senior level).
•    How to get customers to accept that delays are due to them (if they truly are) – i.e. how to make people realise they are wrong, get them to do something about it and still get to work with them.
I am aware of most of the standard stuff on the above, I was looking more for some higher grade blow me away books on how to manage the psychology of the work place.
I know many of you have more experience then I and I was hoping you could direct me to a suitable site / book.


Julian Jackson
Wednesday, August 25, 2004

Read "How to Win Friends and Influence People" by Dale Carnegie?
Wednesday, August 25, 2004

Yep, many years ago. And Painless Software Management, The Mythical Man-month, and 48 Laws to Power, by Robert Green (this is the sort of book I am refering to - we know what we want - this book shows you what to do to get what you want)

Julian Jackson
Wednesday, August 25, 2004

I'd recommend Gerald M. Weinberg.

Weinberg has been writing about systems and programming (and consulting as well as management) since the 70s. He writes a lot about how to set up positive feedback loops that encourage desired behaviour (that's your first question). Your other 2 questions are essentially about what he calls "congruence" - how to make people's actions and their goals line up in the context of a wider system.

If you haven't tried him, and if you're interested in the human aspects of systems, I'd really advise you to give him a go. Out of the Weinberg books to hand, perhaps the most immediately relevant is "Quality Software Mangement 3: Congruent Action" (ISBN 0-932633-28-5).

Wednesday, August 25, 2004

Read PeopleWare?

Mr Jack
Wednesday, August 25, 2004

I second the vote for "Peopleware."  See Joel's review:

Ewan's Dad
Wednesday, August 25, 2004

There are a number of good books about this.  A couple have already been mentioned.

I would recommend
Hearing Cats (a book on how to manage programmers)
The career programmer: Guerilla tactics for an imperfect world (this might help with upper management)
The mythical man month

Peopleware will help a lot with motivation, basically give people a nice work environment, ie enough room, some drawers, shelves and a decent sized desk and people will appreciate that.  It matters more that it is reasonable quality than plush.  Also putting people in their own offices, or with only two or three people in might help.  Windows also help :) 

You could try asking your engineers what prevents them from getting things done.  Maybe an annonymous questionaire or something?

With regard to educating customers, don't say you'll add feature x straight away.  Say you'll figure out how much it will cost and how long it will take.  As soon as you mention that the all important new feature doesn't seem that important.  If it is then they know there is a cost in either time and/or money.

Wednesday, August 25, 2004

That should be Hearding cats :)

Wednesday, August 25, 2004

I did get Peopleware on Joel's recommendation. But I don't think I gave it as much attention as it deserves. Will dig it out and read it again. The Weinberg site looks exactly the sort of thing I am looking for, thanks for the tip.

Julian Jackson
Wednesday, August 25, 2004

The chapter you are looking for is called 'Open Kimono Management' or something along those lines.

Mr Jack
Wednesday, August 25, 2004

You also want to read:
Waltzing with Bears,
Death March,
Software Project Survival Guide,
Debugging the Development Process

Peopleware is one of the most important.

Wednesday, August 25, 2004

"That should be Hearding cats :)"

Actually, Herding Cats ...

A different (and anal-rententive) Steven
Wednesday, August 25, 2004

Thanks for all your help guys! I have compiled a list of books that I have, have ordered, and am going to order (based on recomendations and my reviews of tehse books). I have also made a separate list of books that were recommended and look good, but I think take backstage:
Book list:
Books I currently have
•    The Mythical Man-month - Frederick P. Brooks
•    48 Laws to Power – Robert Green
•    People ware – Productive Projects and teams - Tom Demarco, Timothy Lister
•    Joel on Software – Book 1 – Joel Spolsky
•    Design of Everyday things – Donald Norman

Books I have ordered:
•    Don't Make Me Think: A Common Sense Approach to Web Usability - Steve Krug
•    Small Things Considered: Why There Is No Perfect Design - HENRY PETROSKI
•    The Peter Principle - Laurence J. Peter
•    Joel on Software: etc – Book 2 - Joel Spolsky

Books I need to still get:
•    Gerald M Weinberg
        o    Quality Software management – volumes 1 – 4
        o    Are your lights on
•    Waltzing with Bears - Tom Demarco and Tim Lister
•    Death March – Edward Yourdon
•    In Search of Stupidity – Merrill Chapman
•    Emotional Design – Donald A Norman
•    Project Software survival guide - Steve McConnell

Other books to consider getting:
•    Rapid Development - Steve McConnell
•    Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams - Steve Maguire

Julian Jackson
Wednesday, August 25, 2004

I think a strong fundamental approach to Project Management will get you 2 of your points.  When you start a project, you need buy-in from the team and the customers.  You need early participation from your team as well as the customers in defining the scope of the project, the specifications and project plan.  Once you have this together, make sure you enforce the change request system (that you made clear up front will be followed) and manage your risks.  Keep the customer informed (good and bad) of progress.  The team, if they see you sticking to the plan and taking their inputs seriously will naturally come on board (you also need to remove roadblocks out of their way).  You hold the customer to the change management process- they will respect this also and realize that you are focused on getting the project done on time.  The customer will clearly see how their changes effect schedule. 

Books like "Project Software Survival Guide" will help define this process.  I would suggest reading several different books to get a wide perspective so that you can adapt different techniques to your personality/style/organization.

As to your point about senior management- Dont even bother trying a project that they think is insignificant/not interested in.  If you dont have their buy-in, you will never be able to manage the project (you will be forced to use your resources against other priorities, you will not be able to keep the project from wandering).  Nothing kills morale faster than busting a hump on a project only to never see it finished/thrown away.  How you get senior buy-in is a sales job (if they arent interested to start with).  You need to convince them that they need the you do this...hmmmmm....


Wednesday, August 25, 2004

You can't make anyone want anything they don't already want. You can't make them work FULLY (attending with thier whole mind) on anything they don't want to do.

So, the key is to find some aspect of the task/project that they ALREADY WANT to achieve. (maybe it's writing cool code, a good GUI, gets them laid. Whatever).

Diplomacy of the art of letting someone else get your way.

Motivating them to do something they don't really want to do is manipulation. E.g., "there's a big raise if you'll work overtime on this boring telemarketing call management progam" is extrinsic motivation (motivation comes from OUTSIDE the person). 

I'll give you a great Steve Jobs example:

He was trying to get the developers to make the Mac boot faster so he said 'millions of people will boot up every day. If you can shave 2 seconds off the boot time you'll save those PEOPLE 2 million seconds a day. 555 hours a day. 16,000 hours a year.

Judge for yourself: who do you hear complaining about boot up time? Windows users <g>.  (No, I'm not a mac user <g>)

Mr.Analogy (Shrinkwrap ISV company owner)
Wednesday, August 25, 2004

In the anecdote I heard Jobs extended the time to lives saved. Something like, "shaving 2 seconds off the boot time saves the equivalent of 1 persons entire life.

Wednesday, August 25, 2004

I guess it would be even better then if there were "millions" of Mac users in the first place. :)

Wednesday, August 25, 2004

Having a list of books is great, but what about suitably insightful web sites such as this or a degree that one should go do that covers this topic? The two options I have looked at are and MBA and a BA psychology. Quite frankly I would rather read all the books on the subject first, finish writing my second book and then if there was still anything missing then look at a degree. But seriously, are there any good qualifications out there that deal with the psychology of the workplace in detail (looking at solving problems as opposed to pointing out that they exist)? 

Julian Jackson
Wednesday, August 25, 2004

First, try yelling at them.

And if that doesn't work buy Tom Landry's hat.

Or maybe get them all hammocks.

Wednesday, August 25, 2004

Take a look at NLP. I suggest "Smart Work" or "NLP Business Masterclass".

Wednesday, August 25, 2004

My apologies for chipping in -- but there is 0 need to motivate a programmer. Just get off my back, I'm having fun here.

Wednesday, August 25, 2004

Alex, thats probably a fair comment.  However, there is a lot that can demotivate a programmer (anyone in fact).  Bad work environment, impossible schedules, pain in the ass boss to name just a few.

Wednesday, August 25, 2004

>but there is 0 need to motivate a programmer.
>Just get off my back, I'm having fun here.


1) You must be working at a company quite different from those I have encountered - if so consider yourself fortunate

2) This notion that programmers just wanna have fun is unfortunate - it sets us up for manipulation and poor treatment. Nobody says "Well, doctors just want to cure people so we don't really have to pay them well." If I just wanted to write code I'd have a few home projects.

Wednesday, August 25, 2004

Julian, you sound like a pain in the arse. You construct your little list of management books as if it's the answer to your job. It's not.

If you think it is, you're dangerous.

Management material
Wednesday, August 25, 2004

Actually, Frustrated, I think Alex has it spot on. Don't put obstacles in the way of your developers and they will enjoy their work and be more productive. It isn't about paying them or not.

Thursday, August 26, 2004

Management material, you are quite correct. Let us hope that none of us fixate on only one aspect of learning or our job that we forego all else, loose our human touch, and become a "pain in the arse".

Julian Jackson
Thursday, August 26, 2004

"Don't put obstacles in the way of your developers and they will enjoy their work and be more productive."

And they'll spend all day on XAML, longhorn,  or whatever new fangled technology that interests them and is totally irrelevant to your business... been there ... seen that.  Let's face it 90% of programming is tedious repetition and programmers get bored quick.

Programmers need to be given deadlines and held to them.

Bilge Rat
Friday, August 27, 2004

*  Recent Topics

*  Fog Creek Home