Review: Peopleware

The book, Peopleware by Tom DeMarco and Timothy Lister, comes highly recommended by Joel Spolsky and Jeff Atwood over at the Stack Overflow Podcast.  It is probably most famous for its repudiation of the idea that cubicles make a better work environment for programmers than offices.  There is a lot more to this book than just an attack on cube farms, though.  The book dates from another era of the technology industry.  It was first written in1987 with an update in 1999.  Most of the content ages very well though.  It carries a lot of sage advice that managers today would be smart to read.  Alas, the book appears to be out of print at present.  Check your local library.  That’s where I got mine from.

The book begins with a discussion of people and shipping quality software.  Among the insights are that you can’t squeeze more than a certain amount of work out of people.  If one demands a lot of overtime, people will slow down, do more of their own things on your time, and otherwise use up the time that was supposed to be gained.  The authors make the argument that quality, if allowed to be driven by the team, will be higher than if driven from above.  Peoples’ innate sense of quality is probably higher than the user demands.  Based on these statements, the authors refute the notion that the only way to get work done is to set tight deadlines.  The idea that work grows to fill an allocated space is—they say—false.  I’m not sure I fully agree.  Work does expand to fit the allocated space.  The solution is not, however, to set insane deadlines to squeeze out the work.  Instead, the solution is to set a rational deadline and keep track of progress via frequent checkpoints (ala scrum).

My favorite section is that one which talks about people.  The authors assert that great people are born, not grown.  That’s not quite true.  They are born with innate talents and then grown to greatness.  The key point though is that those born without the right abilities will never be great.  You can’t teach everyone to be a great programmer.  Sorry.  Because of this, and the difficulty in getting rid of someone once hired, it is important to set a high hiring bar.  It is better to hire and then retain the right people than to hire the average person and try to grow them into above average performers.  It’s also important to retain stars.  Invest in them. 

Beyond individuals, teams are important.  The authors spend some time talking about what makes great teams work.  Unfortunately, they don’t give a formula for creating one.  No one seems to know how to do this.  Maybe some day we’ll figure it out, but for now the consensus seems to be that they just happen.  Managers may not be able to create a well jelled team, but they can certainly prevent one from happening.  The authors calls this “teamicide” and give several examples of behavior that causes it:

• Defensive management – Managers must trust their teams.  Attempts to succeed despite their failure only poisons the environment.
• Bureaucracy – Paperwork and policies that are arbitrary and disrupt the work flow.  If management is more interested in paperwork than results, the team notices.
• Physical separation – People interact better when they sit near each other.
• Fragmentation of time – Give people only one top priority at a time. 
• Quality-reduced Product – Management cannot demand a shoddy product or the team will stop performing.
• Phony deadlines – Deadlines should be real (and realistic).  Fake ones to force out more work just cause people to check out.
• Clique control – Let people group up.  It’s called a team.

There’s a lot more in this book.  If you can find a copy, get it and read it.  There’s a lot here for every technology manager.

Spotting the "Uncoachables"

Interesting article from Harvard talking about how to spot people who can't be coached.  The author gives 4 symptoms to look for, but they basically boil down to one.  Does the person want to change?  If someone isn't interested in changing because they don't sense a problem, are burned out, or think everyone else is to blame, no amount of coaching will get them on the right track.  The author advocates walking away from these people.  That may be an easy option for a consultant, but it usually isn't for a manger.  Sometimes you can fire the person or encourage them to move on, but this isn't always possible.  Sometimes it isn't even desireable.  The uncoachable person may have high value in another aspect of their personality.  What then? 

The only viable approach when someone doesn't perceive a reason to change is to modify their attitude.  You have a reason you want them to change.  Get them to recognize it.  Note, however, that their worldview is not necessarily yours.  What motivates them may not be what motivates you.  If someone is overly sure of themselves, telling them their actions offend other people probably won't help.  They won't care.  However, telling them their actions put in jeopardy a promotion or their project or their ability to make an impact may.  Determine what their motivating factors are and couch your discussions in terms of those values.  Then, once you have convinced them there is a reason to change, work on the change.

Review: The Effective Executive

I read The Effective Executive by Peter Drucker because it was highly recommend on the Manager Tools podcast.  Despite what its name may imply, it isn’t written to company executives.  Instead, Drucker defines an executive as anyone with decision making ability.  This certainly includes all managers within a modern technology company and most of the frontline staff as well.  Drucker outlines 4 major areas of concentration for becoming more effective.

The first is your time.  Here the advice boils down to measuring where you spend it.  Time is the one thing everyone has in the same quantity and you can’t get any more of it.  If you want to make effective use of your time, know where you spend it.

Once you know where you spend your time, how do you decide where to apply it?  The next piece of advice involves making a contribution.  Determine where you can most make a unique contribution to the organization and spend your time there.  Ask yourself, “What can I contribute?”  For the rest, try to delegate to others.  Set the bar high and determine what active contribution the position should be making.

Next up is building on your strengths.  This is very similar to Now, Discover Your Strengths.  Drucker advocates hiring and rewarding people for their strengths, not their weaknesses.  I think he dismisses weaknesses a bit too cavalierly.  A significant weakness can overwhelm someone’s strengths.  It can make others view them negatively which can create a negative feedback loop.  However, his advice to focus hiring on strengths instead of a lack of weakness is on point.  People will accomplish a lot more in their area of strength than in a place where they are merely not weak.

Finally, Drucker talks about making effective decisions.  Toward this end he recommends concentrating on only one thing.  Have one focused initiative at a time.  Clearly define what the “boundary conditions” are.  By this he means understanding the specifications the decision must satisfy.  Build action into the decision.  A decision without action has no impact.  Measure the effectiveness of the decision.  This ensures not only that the decision was right, but that it stays right.  He also dedicates a whole chapter to making decisions not between right and wrong but between two courses of action neither of which is clearly right or wrong.  His advice here is essentially, argue both sides.  Don’t make the mistake of jumping on an early decision.  Instead, thoroughly vet each of the alternatives.

Overall I found this a good book.  Perhaps not as good as the hype, but useful.  I found myself doubting the reviews during the first part of the book.  The advice seemed solid, but obvious.  The second part which discussed decision making, however, was much more useful.  I truly enjoy the last three chapters.

E-mail Is Not A Good Motivator

Another conversation I find myself having over and over is telling people that e-mail isn’t a sufficient mechanism for communication.  I already discussed how e-mail isn’t a good medium for handling disputes.  It also is not a great motivator.  In today’s world where people get hundreds of messages a day, it is too easy to ignore.  Receiving an e-mail saying “Please get this done” sometimes doesn’t work.  This is especially true if there is no inherent power in the sender.  A manager’s mails less likely ignored, but those from a peer often are.  People are busy.  It’s going to take more than just 1/100th of their inbox (much less in some cases) to prompt action.

Too many times I’ve experienced aa conversation that goes something like this:

Manager:  “Why weren’t the widget’s waxed by 5:00 for the presentation?”

Report:  “I asked <other person> to do it.  I sent mail several times.”

Report seems convinced that they are absolved of responsibility because they asked.  In e-mail.  More than once.  Isn’t that enough?  What more should Manager expect?

If it is truly important that something gets done by <other person>, mail just doesn’t cut it.  As I said, it is too easy to ignore.  A different tactic is necessary.  One that expresses the importance by the level to which Report is willing to go to get it accomplished.  “Escalation?” thinks Report.  Maybe telling <other person>’s boss about it?  No.  Not yet at least.  Escalation ruins relationships and should be used only as a last resort.

The solution is as simple as it is old.  In today’s world, it is also more unique than it should be.  Try an analog approach.  Pick up the phone and call.  Walk down the hall and stop by <other person>’s office.  It takes some effort, but it will likely garner the hoped for results.  Amazingly enough, most people react differently to human contact than they do to an impersonal e-mail.  Personal contact creates some level of relationship.  It tells the person you care enough to expend the energy.  This might communicate that you care about them as a person or it might merely tell them that you care about the work.  Either way, they are more motivated to get the job done.  Two more benefits are that a personal visit is a lot harder to ignore than an e-mail and you know the message was received.

This effect works equally well with reports as it does with peers.  If something is truly important, say it in person as well as e-mail.

10 Papers Every Programmer Should Read

I’m always on the lookout for good reading material.  Michael Feathers over at ObjectMentor has served up a great post entitled 10 Papers Every Programmer Should Read.  I intend to.

Now, Discover Your Strengths

This is the title of the follow-up to First, Break All the Rules by Marcus Buckingham.  The first book was brilliant and really challenged the way we think about what makes someone successful at their job.  Now, Discover Your Strengths attempts to follow up on that with an in-depth discussion of “strengths.”  Strengths are a combination of knowledge, skills, and what the authors call talents.  A talent is “any recurring pattern of thought, feeling, or behavior that can be productively applied.”  Basically, it is your innate ability to do something.  If you aren’t born with a talent for, say, public speaking, no amount of training will make you Steve Jobs.  If you don’t have a talent for abstract thinking, you’ll never make a great programmer.  Sure, you can become competent at either, but you’ll never make it into the elite of your career discipline.

This sounds about right, but the authors don’t do a lot in this book to justify the position.  There is some talk about the way our brains develop neural pathways.  This may be the reason but the evidence in the book is not sufficient to really make the case.

The core of the book revolves around the premise that you will become much better if you focus on your areas where you have talents (these are your strengths) than if you spend a lot of energy trying to remove your weaknesses.  There is a lot of good anecdotal evidence for this in the stories of Tiger Woods, Cole Porter, and others. 

Unfortunately, the book spends a lot of time on StrengthFinder which is a questionnaire consisting of 180 questions, the answers to which will reveal which of the 34 identified strengths you possess.  The questions felt a lot like those you would find on a Meyers-Briggs test.  With the purchase of the book you can take the quiz once.  It will then tell you what your top 5 strengths are.  I was unimpressed with the test.  While Meyers-Briggs usually aligns well with how I view myself, this one didn’t.  It had elements I think are pretty far from my strengths and didn’t have things I think are.  Either I have a very wrong view of myself or the test is flawed at least in my case.  I suspect the latter.  Maybe I wasn’t able to understand what the questions were asking well enough.  There were several that could be interpreted in very different ways.  Whether or not the test is accurate, the information about the strengths themselves is paltry.  Each gets about a paragraph describing it and a page telling managers how to deal with someone who has it.  I’d like to see a lot more discussion for the individual what to do with their strengths.  This was almost wholly lacking.

The end of the book asserted the case that organizations should focus on strengths instead of skills.  An example of this is hiring for strengths and not specific knowledge or skills.  This may be a good idea, but I don’t feel the case was made strongly enough.  It was more assumed to be true than truly justified.  Even if true, it will be very hard to implement.  Should an organization make each interviewee take a test before being hired?  I’m sure the owners of the test would love that, but it sounds impractical.  It also ignores the ramp-up time someone with only strengths and no present skills takes to become productive.

The overall theme of the book—to pay attention to strengths and not weaknesses—seems right.  I’m persuaded that this is true, but more because of preconceived notions than because of the book.  The follow-through seemed weak.  This is disappointing because the first book in the series was truly eye-opening and much better justified.  Overall, I can’t recommend this book.  Borrow it from the library and read the relevant portions in a day or two. 

Check Out Stack Overflow

I’ve recently become quite addicted to the website stackoverflow.com.  It is a joint venture between Jeff Atwood and Joel Spolsky.  There is an accompanying podcast if you want to hear about the creation process.  The site itself is a question and answer site for programming questions.  Want to know how to do a simple Perl hash equivalency comparison?  Ask.  Want to find the best book on C# for experienced programmers?  Ask.  There is quite an active community and most questions are answered in short order.  You don’t even have to sign up to ask your first question.

If you want to stick around longer than one question, you can answer questions and earn reputation for doing so.  Greater reputation means more abilities on the site.  At one level you can change the tags on questions.  At another level you can vote to close questions.  Still more reputation and you can actually edit the text of questions.  Reputation is granted by users voting for the best answers and questions.  It’s amazing how addicting it can be to try to raise an arbitrary score.

The site has only been open for  a few months and already it is a treasure trove of knowledge.  Joel recently stated that the site gets something like 2 million uniques a month.  As I write this, there are approximately 90,000 questions that have been asked.  Almost all have answers.  This is crowd sourcing at is best.  Once people start linking to it in large numbers, expect to see it shoot up the rankings of programming-related searches.

There are downsides to Stackoverflow’s popularity.  Questions don’t stay on the front page for long.  I suspect they will have to create sub-pages for different topic areas the way Reddit did with its subreddits.