#150 - Project Management Is Communications
Plus: The limits of quantitative metrics; "Nicer" feedback holds women back; Usefully uncomfortable 1:1s; Bringing the band back together; If you really want to send that email, don't send it yet.
Last week I talked about how project management is mostly not about tools. This week I want to spend some time time talking about some key skills we need — communications tools that are going to be much more helpful than Gantt chart software.
Project management is kind of daunting because so much is written about it. It is a hugely broad field which covers everything from half-week solo efforts to massive multi-year construction projects. It’s so broad because it’s applicable to so many endeavours - so it’s kind of hard to separate out what we actually need for our kinds of work (which is typically about a few people working on something for a few months with relatively little requirement for physical equipment booking, etc.)
The one thing that matters for all projects everywhere, and is even more important for our projects is this - project management is a system of communication between humans to get something successfully finished.
Project Management systematizes effective communication and coordination between humans to get something successfully finished.
Projects are, after all, pretty much defined by involving multiple humans working on something that has to be finished. And that means the hardest part of the work is almost always the communication between the humans, and their coordination (which is just a special type of communication).
We have decades (arguably centuries or millennia) of recorded experience with working on projects, and we know how they fail. It’s a fairly short list, and a surprisingly timeless one. The main causes are tediously common. Sure, sometimes it is because not enough planning occurred — since we coming from the world of research are pretty good at planning projects, that’s not usually our situation. More often our issues are:
People not agreeing (or worse, mistakenly thinking they agree) on the goals of the project at the outset - sometimes this manifests itself as people being unhappy with a finished project, sometimes it appears as scope creep, sometimes it appears as unrealistic expectations
Internal timelines slipping because of lack of clarity on deadlines or feedback on missed deliverable deadlines
Internal quality problems because of lack of feedback on deliverable quality
The “customer” (whoever is “receiving” the project) isn’t getting the information they need, so start stepping in and causing havoc
Unexpected surprises, which are pretty much every time something that someone could have brought up as a possibility, but didn’t.
These are all communications problems
In research, we have a lot of experience with projects: every big experiment and analysis, every paper, every collaboration is one or more projects. But the situation in research is a little unusual. The people doing the project are the people directly benefiting from the project. Everyone has a personal interest in that paper (say) getting published. There’s a pretty clear common vision on what the paper should be (and when there isn’t, it’s a mess). And the timelines are usually generous enough to allow a fairly gentle collegiality to the pace and cadence of work getting done.
When we have other people depending on us for the project output, the timelines are shorter, and the people who benefit from the project being done aren’t necessarily the people doing the project, things change. The need for clarity ramps way up because everyone doesn’t share a common mental model of the work, and someone responsible for the project (like us) has to be much more active in communicating about the tasks being done.
The main areas where we have to get good at communication for project work are:
Drawing information out of people (to prevent surprises, to ensure common clarity on goals)
Verifying shared understanding
Communicating your own understanding clearly and effectively
Assigning deliverables and monitoring them
Providing and receiving regular feedback on the deliverables
That can look like a daunting list, but the good news is that these skills, these communications tools, are almost universally applicable!
My favourite way of thinking about communication comes from an article by Roy Rapoport on better communication (#66):
Communication only exists as a mutation of someone else’s internal state
Focus entirely on what mutation you’re trying to accomplish
Be thoughtful about how to accomplish that mutation
Validate THAT mutation occurred
We can use that as model for building these skills
Drawing information out of people: this can mean working on your active listening skills (as with Hands’ article in #24) with individuals or groups, or brainstorming (such as Cohn’s article on “premortems”, looking for risks at the start of a project, in #35). The main skills here are:
Asking open ended questions
Asking lots of followups, even when you think you know the answers'
Collecting the answers and only evaluating them later
Verifying shared understanding:
The main skill here is to practice paraphrasing back to people what you think they said (#39) and getting confirmation, or asking for a paraphrase to make sure that what you communicated actually did get across
Communicating your own understanding clearly:
Practice writing and speaking concisely
Learn what works well with your team
Communicating the same thing multiple ways and multiple times
Assigning deliverables and monitoring them:
Understanding the level of detail needed when assigning a task, as with task-relevant maturity (#148)
Regularly following up, even if it feels uncomfortable - finding out what the status of tasks are (ideally reported somewhere centrally), and asking what’s next to make sure they understand next steps
Getting good at providing helpful feedback. The key skill to develop here is to get used to providing feedback on small things early, and to focus on the actual observable behaviour or output, and the impact on the work on the team.
Getting good at receiving feedback - taking note, asking followup questions, and not reacting right away - as with other kinds of collecting data, you evaluate it later.
Next week I’ll talk about how these communication skills get used in the standard communications practices of project management, and how we can use them not just to get things finished, but to make sure the team is continually learning and getting better at what they do.
What questions do you have about effective project communications? Are there other things I should mention? Just hit reply, leave a comment, or email me at firstname.lastname@example.org.
Resources I like for this:
The material here started with a talk I gave to new leaders as part of a larger course.
The Leader Lab Book covers a number of key communications mini-skills, and then how to combine them for a variety of leadership tasks.
Google’s free Project Management Certificate on Coursera is a heavier-weight and more process and technique focussed than we really need, but it’s well thought of.
With that, on to the roundup!
Becoming a Manager
You can’t lead a team with a spreadsheet - Matt Schellhas
Use Surveys Sparingly - Jonathan Dursi, Research Computing Teams
At my companion newsletter specifically for technical research support team managers and leads, I recently urged readers to not overuse surveys. They superficially seem like a way to turn all sorts of messy human stuff into nice clean numbers which can be plotted. But for much of what we want to know, we can’t meaningfully do that. We have to actually talk to people, and get lots of rich, interesting, but complex qualitative data that requires judgement to distill, and even more judgement to decide how to react to.
Shellhas makes the same point about managing a team. It’s very appealing to rely on some kind of metrics and to just not intervene as long as the numbers are good enough. But that doesn’t work. In addition to the well-known issue with metrics called Goodhart’s Law (“When a measure becomes a target, it ceases to be a good measure”), the fundamental issue is that there’s no small set of numbers which can describe how well functioning your team is:
The map is not the terrain. Many important things to a business are not quantitative. Stuff like customer satisfaction, employee morale, brand awareness, and engineer productivity. There’s no objectively true number for qualitative metrics. It’s all subjective.
We’re hired for our judgement. It takes practice and skill to apply that judgement to the messy, complex world of human beings. Sometimes we’ll get it wrong! But there aren’t actually alternatives. Shellhas again:
Any jackass can point at a graph and people will optimize it. Maybe that’s why companies love them. It takes skilled leadership to balance clear, quantitative goals with the squishy, qualitative, usually long-term goals of the company. It takes a skilled leader to sort out piles of subjective assessments in a fair and balanced way.
Women Get “Nicer” Feedback — and It Holds Them Back - Lily Jampol, Aneeta Rattan, and Elizabeth Baily Wolf
Sadly, this isn’t the first time this newsletter has covered this - back in #53 there was different research indicating the same thing.
Corrective feedback is hard to give. There ways to practice and structure it to make it easier! But it is still hard. For people who were trained in the very collegial environment of academic research, giving helpful corrective feedback can be even harder.
And - it doesn’t matter. That’s the job. It’s our responsibility to give feedback so people can grow professionally. We don’t have to like it! There are other jobs out there if we find it intolerable.
The authors describe their research, where managers (men and women) give “nicer” feedback to women. That sounds lovely and all but in practice they find that it means that the feedback is watered down and useless. That (measurably!) slows down the professional and career growth of the people the managers were being “nice” to.
I urge you to aspire to be kind, and not merely “nice”. It’s not kind to watch people struggle with something but not say anything because of our own discomfort. It’s not kind to let some of our team members be held back in their professional and career progression because they aren’t being told what they need to do better. Women, and other groups facing unfair bias, have enough challenges in career growth already without our uneasiness about giving clear feedback becoming their problem.
The Art of the Awkward 1:1 - Mark Rabkin
This is an older article which crossed my browser this week - it has an interesting idea for one-on-ones that might help with giving feedback:
Commit to saying one rather awkward thing every 1:1, and get the other person to commit too.
Obviously, we’re talking about remaining professional here, but the idea of (mutually!) committing to bring up work issues or feedback that are one notch less comfortable than we’d normally raise seems like a potentially quite productive way to encourage us to be more candid with each other.
What do you think - I’d be curious to hear if anyone’s tried this. Leave a comment, or hit reply or email me with your thoughts!
The 20/30/50 rule for remote team retreats - Chase Warrington
Warrington’s article is about team retreats or off-sites, but it applies to teams that are hybrid and bring the team together periodically (like meeting days, etc) as well.
For the retreats, Warrington suggests using this rare and expensive in-person time in a fairly unstructured way:
50% free time
As I’ve written before, while Management 101 is about managing individuals, and the relationship between manager/leads and team members, Management 201 is about building the team as an entity in itself (#128).
The office, or off-sites, or any situation where we’re consciously bringing the team together for some reason, is a tool. We want to be pretty intentional about using that tool for what it is best for. Warrington argues that in-person is best for that Management 201 work:
[…] in-person time isn't about the “hard work” — the actual tasks we’re paid to complete — that can be done equally well, if not better, remotely and asynchronously. It’s about “soft work” — catching up over coffee in the break room, exchanging gossip, connecting over shared interests — that might not look like work at all, but is essential for any cohesive team.
Depending on your situation you might not want to lean as heavily into unstructured time as Warrington suggests, but being mindful about what we want to accomplish, and making sure we’re using the tools we’re applying in the most effective way, is always a good idea.
Managing Your Own Career
Wait - Roy Rapoport
We get invested in our work (you don’t get into research for the easy wins), and, well, we have opinions about things. Sometimes those opinions are very strong, very negative, and We Have To Say Something Right Now.
Take it from someone who’s been there - it’s a bad idea. Rapoport shares some advice he got early on:
Wait until you’re no longer feeling absolutely compelled to send that email, because the mere fact you feel this strongly means you’re likely compromised in figuring out how to interact right now. Wait until you think you can not send that email. And then, if you want to, send that email.
(The Leader Lab book again is pretty good on this - amygdala hijack, etc.)
And that’s it for another week. Let me know what you thought, or if you have anything you’d like to share about the newsletter or management. Just email me or reply to this newsletter if you get it in your inbox.
Have a great weekend, and good luck this week with your team,