Now that I’m back from vacation, I’m catching up on my reading. I enjoyed David Anderson’s Management versus Leadership on ‘The Apprentice’ which prompted me to think about what I would have done in Kwame’s place. It took me a long time to learn, but a manager always has the option of firing people who
Sorin asks another great question: “So please enlighten me : how do you decide, with only interviews/auditions, whether a candidate will be a good addition to a team or a disruptive element“ I’m assuming you’ve already asked questions such as, “Tell me about the project you’re on now. … What’s your role on the project?
I publish a monthly (most of the time) email newsletter, The Pragmatic Manager. The last two issues have dealt with decreasing project time, before and during the project. Clearly, I don’t remember to post notices of the emails every month, so feel free to subscribe yourself.
You’re a project manager. You have too much work to fit into a project (scope) and not enough time to do it. What do you do? Timebox. Timeboxing is a technique to fit what you can accomplish (some of the scope) into the time you have allotted. Timeboxing works when you have fixed schedule
Because I work for myself, I frequently miss things like Secretary’s Day or Boss’s Day. This year I almost missed Take Our Daughters And Sons To Work day. When the Ms. Foundation started Take Our Daughters to Work day, many colleagues poo-poohed it. “Who needs such a thing?” But a funny thing happened. Girls started
Read Bret Pettichord’s How Did the Blackout Happen? to see how cutting yourself off from data can damage your ability to perform your job.
Sorin’s comment got me thinking. How do you make the decision that a candidate’s technical skills aren’t worth the candidate’s lack of relationship, communication, listening, or some other soft skill? Esther was talking about collaborative teams, so someone who won’t or can’t collaborate is not going to work in your environment. But there are
James’ comment and Eric’s comment asked good questions about why I differentiate between milestones and handoffs. Milestones can be a collection of events (handoffs) that culminate in one milestone. Let’s take the milestone “code freeze” or “code complete.” The code doesn’t magically all become complete on one day; some of the code is completed
In the last couple of years, I’ve worked with some project managers who thought the reason they made schedules was to know when the milestones would be met. They thought if they knew when “design complete” or “feature freeze” or “code complete” occurred, they could track the schedule. I’ve never been comfortable with that,
See Esther’s article on Hiring for a Collaborative Team. (Yes, Esther was one of my book reviewers.)