How to Give Amazing Project Feedback (Part 3)
Unpacking the most common pitfalls to giving actionable and insightful project feedback and how to address them. (Part 3 of 4)
Problem Two: Treating All Projects Like Big Projects
Some people think that all projects should go through the stages I outlined previously.
The truth is, if your product roadmap is well balanced, maybe 30% of your projects are tackling big issues that need to go through a big process.
Most of the work falls into the other 70% of small-to-medium sized projects that ideally can move much more quickly.
For example, projects where the problem space is well defined, we’ve done recent work on this area before and are refining the experience further. This is phase two, or phase five, of a more significant initiative. The project is a tiny experiment leveraging existing design components with new copy.
And so on.
You might be asking, what does the size of a project have to do with feedback? A refined process needs refined feedback.
If your company has made a point to define the templates, RACIs, checkpoints, etcetera for big projects, it has hopefully also created a refined process for smaller projects or experiment tracks.
While these types of projects have fewer stakeholders and therefore fewer people weighing in, there are still common pitfalls with giving feedback on small or medium-sized projects.
Your feedback is retreading over hard-won ground.
This often happens when someone new comes into phase two (or later) of a long and multifaceted project and plays catch-up, making it the team’s responsibility to arbitrate previously made decisions.
My solution is to encourage teams to surface decisions already made in their framing to ensure feedback can be focused. This can be done with slides or other context setting that explicitly calls out what the team is and is not focusing on at this point.
However, if the team doesn’t do this, then, by all means — ask — preferably before the meeting so you can be prepared and not accidentally open up a can of worms.
Your feedback is too exploratory, given the project’s scope or ROI.
Some projects are just rounding off previously accrued debt. They should be small and quick. There don’t need to be many cycles spent on ideating concepts or making the team go through unnecessary hoops; it just saps creative energy that should be spent on more significant projects.
This can vary depending on the seniority of the people on the project — more junior people who are only working on small or medium-sized projects do have the bandwidth to spend time ideating — and having them do so can help elevate their craft.
However, if you have a more senior person covering small to substantial projects for a program, their craft should be strong enough to work through smaller projects quickly. Your feedback should reflect that faith in their ability and help them move through minor project work with velocity.
Your feedback is micromanaging.
While this can happen on big projects too, micromanaging habits are the most apparent when even small project work goes under intense scrutiny.
Although micromanagers are the most egregious group for this last problem, leaders who work under executive micromanagers can often adopt those traits out of fear for their status and reputation at a company.
If micromanagement is a culture problem at your organization, unfortunately, that is not something that this article can solve. However, I want to empower people to keep micromanagement from “running downhill.”
Be the change your want to see in your organization’s culture. If you find yourself nit-picking everything, ask yourself why.
If the craft or quality of work is poor, that is a different problem and should be addressed with coaching or other support. But if it comes from a compulsion to control or an inability to let something go by without ‘putting in your oar,’ that is something to look at in yourself — ideally with an executive coach so you can course correct the behavior.
The cost of micromanaging is high — it can create unnecessary delays on small projects, deplete the working team’s energy, and drain morale and the feeling of autonomy.
And while the micromanager’s rationalization for “why” is a desire to produce better outcomes, long term, it leads to worse output — why put forth the effort when someone above you is just going to “tell you what to do” in the end? Talented people leave, and those that stay innovate less.
This brings us to the last part of this series: how do you deliver empowering feedback that isn’t prescriptive, playing “gotcha,” or vague and confusing?
Practice.
Full Series
- Introduction
- Problem One: Wrong Feedback for the Project Stage
- Problem Two: Treating All Projects Like Big Projects
- Problem Three: Ineffective and Disempowering Feedback
