Editor’s Note: This is the second in a series of articles spotlighting Women in Product & Engineering. Priyanka Mazagaonkar, Director of Engineering for Selligent, shares her experience being a scrum master.

In my previous blog post, I recounted my overall experience playing the different roles of a team manager, a scrum master, and a product manager in parallel. Now, I’d like to focus on one of these roles. While I have learnt (and am still learning) so much from playing all of these roles, I have had the most edifying journey being a scrum master.

I was ably inducted by people who were already playing these roles for the other teams and if there was one aspect of this experience that was a breeze, it was the detailed guidance I received. I also knew that things never work the same in local and in production. (Yes, that is the engineer in me speaking; and yes, that part of me will never really be mute or moot!)

I realized being a scrum master could and would be in direct conflict with me also being the line manager for the team. This was a topic that I discussed extensively with Dimitri Vanderhaeghe, one of our solid team of scrum masters, and my “scrum mastering” mentor. As I started playing the role, I let two main principles guide me:

  1. Be a facilitator 
    The team should have relevant discussions amongst themselves and arrive at a decision.

    This quality comes naturally to some people and not so naturally to others. I fall into the second category. I've always considered myself to be a part of the team and hence wanting to contribute fully to all discussions. I am (still) learning how to carefully guide discussions to stay on topic, on time and in scope, without necessarily contributing to the content of the discussion.

    I found that the key to this balance is to ask open-ended questions, a strategy that I borrowed from my management toolkit. For instance, if I see that the team has been discussing certain blocking dependencies for a story, instead of directly suggesting approaches for removing the dependency, an open-ended question would be, “Do you think there may be a way to remove this dependency?”; or better still, “What do you think makes this dependency a blocker?” 


  2. Be a friend and ally for the team 
    The team should be comfortable coming to you with topics they would not be comfortable discussing with their manager.

    The first challenge was to be able to establish trust in the team so that they could come to me purely in a scrum master capacity (and not as their manager). My overall management style became a strong asset on this front, and my open working relationship with my team allowed for that trust to be built-in fairly quickly.

    The second challenge was, of course, for me to effectively compartmentalize these roles in my head. It was risky to just assume that I would draw the right lines for each case or conversation and I needed a consistent, well-defined process in place. To that effect, I sought some inspiration from the concept of parallel and serial processing. While most people in technology would know parallel processing as a mode of computer operation, it is also deeply relevant in neural coding and how we as humans process information. The brain can seamlessly combine multiple aspects of incoming stimuli, compare these with stored memories, and help us comprehend an event to the best of our capability.

    It goes without saying that there was no hardware fix for the kind of compartmentalization I needed, and I hence attempted to put in software firewalls, so that connection to certain stored memories (aka, the “manager” store in my brain) is conditional or on-demand under specific circumstances.

    In layman’s terms, every time a member of the team wanted to talk to me as a scrum master, I did not let the manager in me listen in on that conversation. Then, just like a scrum master would bring something to a manager’s notice, I would follow up or act on certain issues based on filtered or generalized information. Easier said than done, I know, and I admit that I have often leaned more on one side as I have walked this path; but such minor transgressions have just served the purpose of adapting the firewall better.

    The most important lesson that I have learnt from being a scrum master is knowing how and when to step back – and when to step in and facilitate. Ironically, this is also one of the most understated qualities in a good manager, with a minor difference: when there is a need to step in, you do that and direct the team.

My team would be the real judge, but I do believe that being a scrum master has also made me a better manager; and despite the necessary compartmentalization, I sense that these two roles have created a synergy that makes me constantly adapt and improve. That’s agile right there!

Priyanka Mazagaonkar is Director of Engineering at Selligent Marketing Cloud. She has worked with the software technology industry over 15 years, having started her career as a software engineer and moving on to a management role soon after. She has been managing engineering teams across the globe for many years now and has a keen interest in exploring how products can make an entry into Cloud and related domains. She has extensive experience being a part of and coordinating with offshore teams, especially in the area of new development and technology exploration. 

Comment, Like, Share

See our platform in action

book a demo