Client Team Feedback: Part 2 – How

As software consultants, we are sometimes asked to provide our perspective on team skills, practices, tools, effectiveness, etc. in addition to designing and building software. In Part 1 of this two-part series about client team feedback, I shared how I look at the questions of who is asking for feedback, what topics they’re seeking feedback on, and why they’re asking me for feedback. In Part 2, I’ll discuss some of my goals when sharing feedback with a client. Here we go.

Be specific.

Specific feedback supports specific responses. This applies to both positive and encouraging feedback as well as identifying opportunities for improvement. Share specific examples when possible.

  • Sam did a great job connecting the development team’s work to the business value provided during the sprint demo last week.
  • TypeScript types didn’t catch the missing field this time, but it could have if we were more diligent about eliminating any types from the codebase.

Summarization can help avoid focusing on unimportant details and instead communicate the scale or breadth of an opportunity, but avoid the trap of overgeneralization. I try to include at least one very specific example.

Be respectful.

Respect and professionalism are important when dealing with potentially sensitive topics that can come up during client team feedback conversations. Obviously, complaining and contributing to gossip are out of line. I also rarely share anything that would be surprising to the subject of a feedback conversation or that I haven’t already discussed with them directly. If the person I’m talking to can’t help or doesn’t need to be aware of something, I don’t share it.

Outside of those sensitive topics and situations, there are ways to show respect to the team that demonstrate and earn trust.

  • I share my perspective and make sure that people understand that it is my own perspective.
  • I encourage direct follow-up with individuals instead of speaking on their behalf. e.g., “I don’t want to speak for Raul, but I’m sure he’d be interested in discussing this topic with you.”

Be positive.

The term “feedback” can immediately conjure negative connotations, but I love to share strengths I’ve observed and things I appreciate about team members. I suspect the recipients appreciate it too.

  • This team is great at running experiments and learning. When people have ideas, they figure out how to test them cheaply and share the outcome with the team. It keeps the continuous improvement cycle alive and well.
  • I really appreciated Laurent’s work last sprint resolving the production issue and related questions. He engaged calmly, made everyone feel confident that it was being handled, and got it done.

Be helpful.

I’m happy to discuss skills, attributes, and outcomes that I think are important for people in various team roles. For example,

  • A scrum master should be a good facilitator and be able to create a safe environment for earnest continuous improvement conversations to happen.
  • Developers on this project need to work with AWS services regularly, especially Lambdas and Step Functions. We lean on Joe for a lot of that knowledge and experience right now. Professional development in that area could help the team.

However, I don’t evaluate how individuals fit their jobs. As an outsider, I don’t set or completely understand another organization’s job expectations, so I can’t judge meeting the expectations. They may hire for different skills than I would, optimizing the team for different phases of work. It simply doesn’t work for me to do that type of evaluation. Sharing things that are important for specific roles does help equip managers and team members to do their own evaluations.

I like to share resources and information from people I respect (books, articles, the Atomic Spin blog, etc.). Good leave-behind materials can give people an opportunity to dig in on their own and make it easy to share with other people.

I often suggest team activities that follow up on a topic and create more team ownership and buy-in. For example, discuss as a team what skills we think people need to have to be effective as a developer on our team and project so that each person on the team has the tools and language to discuss professional development goals with their manager.

Be prepared.

I aim to be prepared for the conversation by answering the questions I posed in Part 1 and thinking through the context. I like to know what topics I plan to discuss and what topics I won’t. If possible, I like to discuss plans with a trusted pair beforehand.

I hope this little series will help you be prepared if and when you’re asked for client team feedback. Let me know in the comments if you have other considerations that you keep in mind in these feedback situations.