Today’s coaching session revolved around a young developer recently moved into an established team. The developer had experience in Agile teams with specific practices, and this team’s practices were VERY different, and almost non-existent. As opposed to a product team with a defined backlog process, this new team is catch-as-catch can, and largely individualized. This developer was concerned, greatly.
“Where is the product owner? Why isn’t she engaged here? Where are the stories? Where is task breakdown?” And on and on, indicating worries great and small. He was half-convinced the entire structure was broken, and needed to be rebuilt from the ground up.
Man oh man, could I empathize with that.
There were a lot of complexities to unpack in this developers complaint, but I called out his newness to the team. He was joining an extremely stable team, with established norms and structures. It is entirely possible that the Agile mindset and culture of the team needs to change, but for an engineer, the first thing to do is get competent on the platform.
This team is a bunch of individuals working. That is a problem. Fixing the process needs to happen, for sure. That isn’t the purview of a brand-new-to-the-team engineer. Nobody is going to listen to someone who comes into an organization and immediately vents about how everything is broken.
Process absolutely matters, but for this engineer, engineering has to count first. That’s what I coached him to do. I recommended he get good at the tech FIRST, and then talk about process improvements.
After that conversation ended, I setup a meeting with the product owner. I wanted to see what sort of issues she was seeing, and if there was anything this principal software dev could help with.
Christopher Brown's - Blog 
“Nobody is going to listen to someone who comes into an organization and immediately vents about how everything is broken.”
Some of the (imo better) managers at Microsoft had the opposite viewpoint–that we should pay special attention to the sense of broken-ness identified by new folks since they are not yet “infected.” Just something to consider.
LikeLiked by 1 person
Managers being open to hearing that sort of feedback from a new team-member is decidedly rare. I find engineers try empathize with those feelings of ‘it’s all broken’, but usually just brush it off with a ‘still, what can you do?’
Fundamentally, for this team member, I think it’s important to target a little empathy for the team you’re coming onto, if they are ‘broken’. Teams create norms and processes optimized for their external constraints. New team members build more goodwill understanding those constraints.
LikeLike
> I think it’s important to target a little empathy for the team you’re coming onto
Agreed.
> Teams create norms and processes optimized for their external constraints.
Now that’s well-said right there. I’ll be stealing that.
LikeLike