Saturday, November 21, 2015

Encouraging self-organization

I was on a train, going back to work from a lunch, when my phone beeped. I look at the screen, to realize someone was pinging me in Flowdoc. That's how my team, working remotely, communicates. I curiously checked what was going on.

One of my developers was asking if I'm around, and I told him where I was. Having a discussion on mobile isn't really a problem, so I asked "How can I help you?".

He mentioned the feature he was working on, that I knew just as well as he does. But what he said next surprised me. He said he has been thinking about the purpose of the feature and why users want it, and come to a conclusion that as he understands the purpose, it will be severely damaged if the end user isn't able to select multiple targets for editing in combination of what he is implementing.

This should be a normal discussion to have, but it really isn't. I can't recall that particular developer ever before reaching out to me for a discussion without me initiating it and never saying much about caring for what the user can do. It's had always been me.

With the discussion of the purpose, he introduces a change he has already implemented to the multiselect feature. It's a change where, me having sat more with product owner, the word around in priorities is that it cannot be implemented, because it would slow down the functionalities around it. His questions are more about how to make that right, not about if making that in the first place is right. I know it was outside our priorities with a strict interpretation. But it is definitely in benefit of the users.

We had a longer chat about other purposes, limitations or risks of the things he was thinking of. The reason he was discussing it with me was that there was yet another connected and very complicated feature, which he had forgotten many times in the past with me pointing out how that had been broken as a side effect. And now he wanted to work it through with me.

With the little slowness that the communication channel created, I had time to reflect what was going on in my head with the discussion. I had two conflicting views:

  1. I want to recognize the progress of initiating contact and showing caring for user needs and encourage that behavior with positive feedback
  2. I want to scold him for implementing a new major feature without discussing priorities with others before implementing. 
I'm happy to notice that I don't follow my second instinct of scolding for breaking the rules. I focus on the positive. The time is used already. We want to go forward and create value. He is creating value. So I dig into the details:

  • I'm happy that he is implementing a feature that users have expressed need for, that we have prioritized out with reasons of performance
  • I'm concerned he did not pay attention to performance in coming up with his solution, and help him work that through. 
  • I want to be helpful in making the feature work since it is apparently coming in soon, even if I did not know of it. 
We add more aspects to the feature, making it even better. With talking to me about a specific problem he was having and felt need to discuss, he also tells me he found a solution. Without me ever saying much about my concerns, he remembers to close with the idea: I only spent a day on this feature. 

I'm happy he did. And I wish we would never make our developers feel they can't take the initiative. Rules are meant to be bent. And that's a hard one for me, as a Finn (we love rules) and as a tester (yep, gatekeeper lives deep in me still). 

No comments:

Post a Comment