The best part of coaching is getting to listen and interact with co-workers about what problems they face on a daily basis. You don’t need a title to have this enviable role, just the desire to care about others around you and help. I was afforded one such occasion recently when I noticed a frustrated smile on someone’s face as I passed them in the hallway. As with most coaching conversations, I began with an empathetic, “what’s wrong?”
“Have you ever walked up to a developer at the end of the day and asked them what they accomplished today?”
I sat down, because this was clearly not a simple question to answer.
Nuts and bolts, a PM on this co-worker’s team had approached an engineer in this manner. It obviously irked said developer and was voicing his frustration. After a few more qualifying questions surrounding the experience, I ventured some honest words that hopefully shed some needed perspective on the situation.
Truth is, I have approached team members with that request. I’m not proud of it, and wish I could tell the interested party I had never strayed.
Reason for that is, self-managing teams should never need to be micro-managed or suffocated with needless questions during the course of their work day. Scrum masters are taught to bring a notebook and take notes on what is going to be accomplished that day and then wait for the next morning to validate if that happened. Once upon a time, I was meticulous in this exercise because I wanted to have a written track record of how successful the day was for everyone and be able to point out when roadblocks were cropping up.
(In fact, I would still recommend this activity for new SMs, PMs or Ms of any kind. It’s a good muscle to train to keep up with the daily tasks of your teams.)
The challenge leads back to expectations, I warned. If you say that you will only have a meeting to discuss progress once a day, you must leave them to it and swallow your questions. If you pester them throughout the day with status updates, you will only create an unsafe atmosphere for them to raise their hands for help. I had to learn that lesson the hard way once upon a time.
That being said, you can find all sorts of ways to get status without pestering. If a dev is waiting on a comp from art, there’s nothing wrong with asking either party if the deliverable had been met. If QA finds a high priority bug, you are more than welcome to ask what an engineer is in the middle of so you can re-prioritize.
You could just ask for permission to change the rules for a day — like on release days — but that would just teach the team that you can change the rules whenever it suits you. Respect boundaries first and then learn how to push them on occasion.
As I said when I ended the conversation, “protecting the team sometimes means even from you.”
One thought on “Blog Post: Protecting a team sometimes means “from you””