I’m excited to announce that Roy Osherove’s interview with me is now posted on IT Conversations. Here’s the link to the interview. Roy interviewed me about the hiring book, and of course we segued into project management and management issues. Enjoy!
We’re teaching my older daughter to drive. She’s had her permit since late August, and we try to make sure she drives 2-4 hours/week. In reality, that’s not a lot of driving. Just commuting to work most likely takes you 5 hours/week. But this past weekend, my daughter drove back from our ski weekend in
In Greg’s provocative comment, he says, “The idea that contributor initiatives are a drag on an organization speaks more to the insecurity of the management than to its skills.” I’ve been noodling that comment since I received it. I agree with Greg that some managers are insecure enough to insist that they make all
If you’ve hired new people or transferred people into your group, you know that they’re not immediately productive when they start. If you’re lucky, they start to be useful in a month, but you most likely spend closer to six months or even a year before they raise the entire group’s productivity. One technique for
Take a look at Ask My Advice. If you’re hiring a senior manager, it’s difficult to imagine not using a recruiter. But the recruiter fees can be a heavy tax to pay. But, take A (Anthony?)’s advice: Ask why someone would want to work at your company Negotiate with a smaller recruiting firm for a
Read The Graphing Calculator Story. (Thank you to Obie Fernandez for finding this gem. Some ideas that stood out for me: The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends. …he told
Originally published in Computerworld. This time of year is loaded with resolutions, predictions, and anticipation of great things to come. In that vein, let’s celebrate the New Year with how a project manager might fit new words to an old tune. ‘Tis the season to be humble Fa la la la la, la la la
I’m looking for a reference to something I thought I read but can no longer find. Technical people can work up to 6 hours a day on technical work. They may be at work longer, reading email, going to meetings, getting coffee, but they can only effectively do 6 hours of technical work a
I’ve had several discussions about maintenance in the past few days. I’m beginning to think I have a different definition of maintenance than other people do :-). For me, maintenance is fixing problems in code. Maintenance is short, small, well-contained and code-based, and should be fixed by the developer(s) who created the problem. So
I had dinner recently with someone who said, “We put our candidates through the wringer. First we test them, then we interview them, then we give them another test.” I spoke with someone else whose manager wants an extensive role play to pit candidates against each other (sounds a little like The Apprentice to me).