I’m a big fan of managers admitting their mistakes. (It’s one of the lessons I learned early as a manager.) I take that seriously, seriously enough that when someone found a glaring error in my last SD column, Future Fixes, I asked the editor let me publish a correction and I sent in replacement text […]
Last week at the Software Development conference, I met a software director. His group, a total of about 30-40 people (I’ve forgotten the exact number) is responsible for all the software his company produces. He has two managers managing those folks. He’s busy, so although he requests that his managers have one-on-ones with their staff,
First read Esther’s entry about the Secrets of Motivation for some great pointers on not demotivating people. If you’re having a cynical day or need a chuckle go to Despair.com. At dinner last night, some friends were talking about motivational posters — and we all laughed. One colleague told me about these sarcastic motivational
Hal asks a fascinating question in Variation is an Enemy Enabler of Project Success: How can we take advantage of serendipity rather than forcing an outcome in our projects? (paraphrased) One technique is to observe and listen to the project. When PMs observe their projects, they look at and listen to: How people work together.
I was reading David Anderson’s Working Smarter Not Harder and thought about managers. David’s right, a few small improvements can dramatically increase a team’s productivity and therefore lower the cost of development. But I contend that most of the productivity costs in software is the way we mismanage software projects. If managers worked smarter, they
The only good thing about this current spate of worms and viruses is that the spammers seem to sending less spam. Naively, a few months ago, I bemoaned the state of automated spam filters. Now I wish my mail program (Eudora) and spam filter (SpamSieve) could detect these ridiculous pif files and delete all mail
Earlier this week, I was at the Rational User Conference. I was part of a dynamic panel, “The People Factor: Experts Weigh In On The Soft Side of Software.” One question was about how technical managers or project managers have to be. Murray Cantor, one of the other panelists, summed it up this way:
Release trains, the technique of planning releases on a particular date several times a year (such as quarterly releases, on the 12th of the last month of the quarter), can help you manage your development and test staff as well as machines and tool resources. I wrote about release trains a while ago here.
Hal’s post about the meaning of project management got me thinking about accountability and how we use it in organizations. In the last three weeks, I’ve heard these definitions: “I want to know who’s accountable. Who do I get to fire if they screw up?” “The testers/project manager/management team is accountable for the bugs.
In his comment to my previous post, Babu said, “unqualified project managers quickly sink a project which would’ve otherwise fared better.” (Keith, I’ll respond to your next comment in another post.) I’ve had the pleasure of meeting great project managers, and some not-so-great project managers. Here’s my list of necessary skills for great project