Bret on the Blackout
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.
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.)
Oh dear. I was not sufficiently articulate in my last post. Both Frank and David in their comments asked about capacity, the output of the organization over time. That will teach me to post when I’m tired. (Maybe.) Let me try this again. In each of these projects, senior management wanted more features than
A client was optimizing for what they thought was the bottleneck in their software development: the testers. In the assessment, I gathered some quantitative data about how long the testers took to test and how long it took for the other groups to perform their work. (They used a phased lifecycle.) The testers were
I was talking to a hiring manager recently, and she said, “I’d like to get another developer just like Stan.” Well, Stan is a good guy and a talented developer, but why look for someone just like him? The manager explained, “I’m staffing a particularly risky project and with someone just like Stan, I know
David Anderson has an intriguing post, Lawyers, Unit Tests and Performance Reviews. David says “Individual team members can be set specific goals and behavior objectives…” and gives examples. I prefer that team members set their own goals with input from their managers. But the key here is that a technical person should be looking to
I have a column this week on Stickyminds, Multiprojecting: The Illusion of Progress. Thank you Frank Patrick, for naming this kind of multi-tasking (and for reviewing the work-in-progress). Feel free to comment on Stickyminds, unless you want to comment here.