Problems aren’t just for Managers

Problem over Person

In a team meeting, one of my leaders was struggling with their scrum master. Their engineers keep telling them about boring standups and no improvement.

I asked one of my annoying questions,

Me: “what would you like to do about it?”

EM (Engineering Manager): “Discuss with the group about how I can give the scrum master feedback.”

Me: “Why are they coming to you?”

EM: “They talked about it with the team, but nothing has changed.”

Me: “What does that mean?”

EM: “The engineers all feel this way.”

Me: “Has this come up at a retro?”

EM: “well,they don’t feel comfortable talking about it with the scrum master in the room.”

Me: “why not?”

EM: “You need a manager to give feedback to the scrum master”

Through the questions, we discovered a string of assumptions and fell in to a trap.

Some potential beliefs that got us here:

this feedback is about the person
the team can’t bring up hard things at a retro
the team needs their manager to step in
it’s unsafe to talk at a retro
this problem is someone’s fault

Any of these MAY be true, but outside of misconduct we can often step up to the problem and work it just like we might a bug.

this issue affects the whole team
the manager knows the least about this issue of anyone
the manager can do more harm than good circling around the edges
what ever happened to “continuous improvement?”

We can build the communication and influence skill to help this engineer share the problem with the team at a retro, almost like it’s a bug report.

How can the team flex their continuous improvement muscle and own this issue and its solution? How do we, as a leader, engage build the skills so our engineer can describe the problem in a way their team will understand and rally around it?

Practice makes perfect.

Some example framings of this problem:

“I have trouble staying engaged during our team meetings because they take a long time”
“our standups are too long”
“what can we do to help our standups keep to the timebox?”
“I notice that lots of folks aren’t paying attention during standup, because I get questions later that were answered there”
“no conversation occurs during standup other than just going around the room, I don’t understand how that helps us”

You might hate these and that’s okay. Communication is contextual and you know your voice and how to frame the real issue. (NB: AI can help brainstorm here, but the engineer needs to own the tone and keep it short and sweet; I’ve seen lot of disconnects/hard feelings because folks tried to use AI to help them express an issue only to find out some nuance and values got lost).

You’ll notice some of the examples above are harsher than others, but none are ABOUT another person’s shortcoming. They’re about the symptoms and the problem.

Leaders help engineers prepare to engage in their own discussion or retro WITHOUT a manager. This would be a great time for leader and engineer to use role play and help them practice both expressing the issue and responding to inevitable follow-up questions and challenges.

Once the problem is on the table, the whole team can help own the issue. They have created the situation they’re in together depending on how long they’ve been quiet or even gone through the motions like zombies every day for months without saying anything. The objective is to break the seal and get the issue on the table for discussion.

As leaders, we need to be on the lookout for what behavior and core skills are needed before we jump in to the rescue. Stepping back and letting the team engage CAN lead to more conflict, but over time they’ll build their muscle at working through their own issues rather than calling on outsiders to rescue them. Leaders hope for an interesting organizational problem or performance issue – ESPECIALLY on another team because we can BLAME someone.

As a leader, when did you swoop in to solve an issue when you needed to find a dfferent stance? Other resources for further reading: