Managing People Is Harder Than Managing Projects
Five quotes from Michael Lopp’s Managing Humans that are worth a project manager’s attention.
I wrote about Maxim Dorofeev’s Jedi Techniques in an earlier article. It’s a good book, and some of its techniques work well in project delivery. But if I were choosing books I’d recommend to every PM, Michael Lopp’s Managing Humans would be higher on my list.
I’ve read it in the original English too. Lopp writes about engineers, managers, workplace relationships and management mistakes. He doesn’t pretend to be the perfect manager who can fix every problem with the right framework. He understands the people he works with and is honest about the times he got it wrong. For me, it’s one of the most useful books on working with technical teams. I’ve picked five short quotes worth thinking about, whether you run an engineering department or coordinate a project team.
1. “Don’t Be a Prick”
An excellent management rule. Obvious, yet somehow it keeps needing an explanation in the workplace. Lopp spends a lot of time on how well a manager understands the team. Developers, analysts and testers are people with different personalities, professional interests and ideas about how to work together. Worth remembering.
PMs don’t always have formal authority. They still need to get things agreed with people who don’t report to them. Respect, consistency and the ability to have a normal conversation do more than trying to manage a team entirely through statuses and deadlines.
2. “Stay flexible.”
An important observation: a management approach that works brilliantly for one person can be completely wrong for another. That’s a reason for PMs to be a bit more careful with blanket advice. One team works well with very few meetings and flags problems without being chased. Another needs more frequent check-ins during difficult development stages. Forcing the same process on both because it appears in a popular playbook is questionable.
Being flexible means understanding the cause. If people are falling behind, don’t just add more status meetings. The problem might be dependencies, estimates, unclear tasks or priorities that keep changing. Work out what’s getting in the way first. Pick the tool afterwards.
3. “He wants to learn.”
That’s Lopp’s explanation for why a manager makes time for one-to-ones. Their value is in the things a report won’t tell you. In development, a task status rarely tells the whole story. Someone can be getting the work done and meeting every commitment while doubting an architecture decision, clashing with a colleague or thinking the chosen approach makes no technical sense. None of that shows up in the tracker.
Talking to the team shouldn’t stop at deadlines and whether a feature is ready. Dig into what people think is happening, what problems they see and what they would change. Especially when they know the technical side of the product better than you do.
A PM shouldn’t take over the engineering manager’s role or start scheduling one-to-ones with absolutely everyone. How you work together depends on the team structure. There still needs to be a way to get honest feedback, whatever the org chart looks like.
4. “Stop coding.”
An interesting provocation. Lopp starts by arguing that moving into management means stepping away from doing the engineering work yourself. Then he points out the limits of his own advice. There’s a familiar parallel for PMs. The more technical you are, the more tempting it becomes to pick up small tasks yourself or get involved in decisions the team can make perfectly well without you.
You do need to understand architectural constraints, dependencies, the reasoning behind estimates and the consequences of changes. Otherwise, discussing deadlines quickly turns into forwarding messages between the client and engineering. The question is where useful technical involvement ends and stepping on someone else’s toes begins.
5. “Does he do what he says he’s going to do?”
Lopp describes a manager who discussed problems, held meetings and suggested solutions, then did almost nothing to make them happen. A familiar character. The job title doesn’t particularly matter. Projects have plenty of room for endless risk discussions, meeting notes and follow-up calls too. If nobody then makes decisions, removes blockers or follows through, all that activity has very little management value.
A PM makes commitments to the client, management and the team all the time. Every unkept promise chips away at trust. Sometimes it takes only a few instances of “I’ll look into it” followed by the manager conveniently forgetting all about it. I like that Lopp judges managers by what they actually do. You can know all the terminology, run immaculate meetings and sound thoroughly confident. The team will still notice pretty quickly whether you can make anything happen.
There’s enough professional self-deprecation in the book to stop you mistaking a management title for proof that you’re always right. And enough experience to make you rethink a few habits in how you work with your team.
I’m a project manager. About working with russian clients and teams, sharing experience and things I’ve noticed.