Subscribe: Apple Podcasts | Spotify | Android
There are different roles related to the execution of a project. Some examples are: program manager, project manager, and product manager. Jhansi Reddy, Principal Technical Program Manager at Microsoft, explained the differences between these roles. We also talked about how to transition from a developer role into a program manager role. Other topics that were covered are: conflict resolution and building trust with customers.
Transcript
I’m Edaena Salinas, software engineer and host of The Women in Tech Show, a podcast about what we work on, not what it feels like to be a woman in tech. For more information about the show go to wit.fm
There are different roles related to the execution of a project. Some examples are: program manager, project manager, and product manager. Jhansi Reddy, Principal Technical Program Manager at Microsoft, explained the differences between these roles. We also talked about how to transition from a developer role into a program manager role. Other topics that were covered are: conflict resolution and building trust with customers.
ES:
You are in program management- So first I want to begin talking about the space. In your opinion is there a difference between the roles Program Manager, Project Manager, Product Manager..?
JR:
I would say yes, there is a difference between the roles, but ultimately it depends on the company. I think various organizations have this role defined slightly differently, but I can share with you what I think these different roles mean.
Product Management- By definition, product managers own the success of the product throughout the product lifecycle, they manage the end-to-end product.
Project Management- Project Managers tend to focus more on the execution aspect. They might have less facetime with customers, but we see many project managers working on large projects with lots of dependencies.
Program Management– A Program Manager is the liaison between customers and engineering. They work on how things are implemented; they are also involved in prioritization and delivery of features and are part of the core engineering team.
ES:
You come from a software engineering background. From your experience, what is the difference between the Program Manager role and the Developer role?
JR:
There are many differences, but to boil it down, as a PM you are thinking about the overall execution and as a developer you are working on a smaller piece of the whole ecosystem. You may own a feature and go very deep into the execution of this feature, but a PM is focused on all the features and how they work together. You could think of this as a close-up view of the feature and implementation versus a 5000ft overview.
ES:
You mentioned that the Program Manager is a liaison between the customer and the engineering. It sounds like you work with a lot of different people and conflict is often inevitable in these situations. Do you have any advice on conflict management?
JR:
This is a great question- not just for PMs but for anyone working in a corporate environment. Managing conflict is a skill we all need to learn. My approach is to first acknowledge that there will be difference of opinions and viewpoints and I take an ‘Open and Growth mindset’. Consider the way you approach those you may be in conflict with. Instead of something accusatory like, “You did this wrong” or “I think this is right”, go with “can you help me understand…” or “can you help me solve this problem?”. The ultimate goal should be working with the person to resolve the issue; it can also be important to be willing to experiment.
I love the phrase “Let’s try it”. For example, we were working on a project and the project team was getting huge. Instead of having a stand up with roughly 25 people, we approached it with the thought “How can we do this in a different way?”. We tried splitting up the group into different work streams that could have their own stand-ups and ceremonies; by using the word “experiment” when we broached this subject, that made this process much easier. I wasn’t saying, “we are doing this” I was saying, “let’s try it” and see if it works.
ES:
When you are a manager or a tech lead you work with many new teams, managers, and customers. How do you build trust with new customers?
JR:
CSE is a global organization, and we work very closely with new customers on our code-with engagements. Every few months we work on a new project so initially the question is ‘do they even trust us?’. Are they comfortable sharing the problems they are experiencing, do they trust us to deliver, can they work openly with us? I want to acknowledge that in the virtual space its even harder to build this trust. Before COVID we would go to the customer and spend some days with them, whiteboarding, working in their space, going out to dinner with them… Working closely with the customer and getting to know them helps build that trust and rapport. Unfortunately, we don’t get that opportunity right now.
To bridge that gap, we tried some icebreaker activities to get to know the teams, both ours and theirs, better- as people not as programmers. We asked questions like, “What was your last online purchase?”, “What is your favorite drink?”. I found that these activities, as well as genuinely being curious about folks, asking “How was your weekend, how are you?”, really builds trust with your team and for your customers.
ES:
As a Program Manager and being in charge of the overall execution- how do you approach a situation where a team is not meeting deadlines?
JR:
The first thing I would want to understand is why- is this a problem of estimating? When we are doing sprint planning, we are committing to getting a chunk of work done. Sometimes the scope of the user story or feature is not completely defined and there are a lot of unknowns. Perhaps the developer was doing investigations and, in the process, they found more issues or incompatibilities and that’s why this work wasn’t getting done.
I suggest doing a deep dive into the individual user stories during a sprint planning or a prioritization exercise and ensuring that everyone understands that implementation of this story means; what is the definition of done, what is the acceptance criteria, what needs to be developed. I often recommend that first we do a spike user story where we actually figure out what to implement first. Once you figure out exactly the 4 things we need to implement this story, then you can have another user story where you can define what that feature should be. The majority of the time, it’s a lack of understanding on the scope. I would go as far as to say that 80-90% of the time, the reason the developers are not meeting the deadlines is because the scope was not set correctly.
For the other 10-20%, it might be that they need help and aren’t asking for it. In these cases, a one on one with that developer or the team could help to brainstorm solutions. Additionally, involving a more senior developer or SME could help them ramp up or unblock so they can meet their goals.
ES:
Coming from a Developer role to a Program Management Role, how difficult was it to avoid micromanaging and successfully make the transition?
JR:
I would say, per my blog post (link), I made this ‘micromanaging mistake’ initially. When I made the move from dev to PM, I was very close to the code we were working on; code I wrote. And I was going back to my comfort zone, of brainstorming ideals and development, but in that process I was overlooking my PM role. It wasn’t until I separated myself from that and starting moving towards the execution aspects of being a Program Manager that things got better.
Ultimately, I want to be there for the developers to help them organize, but I want to avoid micromanaging. I don’t want to track their process, I don’t want status updates several times throughout the day. Except for during stand ups, I want to give them the autonomy to experiment and implement. I want the details in the design review where the whole team can give feedback; but I don’t want to tell them how to do it. This also boils down to trust; it’s up to them and I trust them to execute well. I also trust that if there is an issue or a blocker they will feel comfortable with me both as a leader and as a developer to bring me into the situation.
ES:
Has having a history as a developer helped you be a Program Manager?
JR:
As a Technical Program Manager, it has been super helpful. I still consider myself a developer, I have the viewpoint of a developer; I can help with prioritization and organization because I understand the sequencing involved in development.
For an example, say there is a feature you would like to implement. You have a UI team and a Backend team. In terms of sequence of events, when I prioritize, I know that the UI team is waiting to connect to the backend team. I can suggest getting the swagger API contract out first, even though we haven’t started development yet so we can unblock the UI team and they can work on integration. Meanwhile, we can get to work on the backend. I can work with the Dev Lead on the right estimations because of my background and I can walk customers through similar work that I’ve done on other projects.
Just recently I was working with a customer planning to do some Machine Learning algorithms to detect text in some forms they are using. They wanted to do full-on ML models, but I suggested we try a quick out-of-the-box solution like an OCR first. I was able to articulate my experience with other customers and those architecture solutions, to suggest a “crawl, walk, run” process. This means that maybe we start with something small, then add more functionality in the next sprint, and so on and so forth. I was able to lean on my developer skills to explain it to the customer.
ES:
Would you say that not having these dev skills would be a hinderance as a PM?
JR:
I would say that it completely depends on the kind of PM you are. As a technical program manager (TPM), I feel I am better for having that development background.
ES:
How does one transition from being a developer to a TPM?
JR:
I can talk through my journey and share some tips. My first question would be: Does your group or team have a shadowing opportunity? I recommend trying to shadow the role you are working towards. Perhaps, for even just part of a project shadow the PM. Join in meetings, observe the day to day, see what it entails, and what activities are they involved in, so you can get a good understanding of what you might be getting yourself into. I would also recommend trying to figure out what “flavor” PM you want to be. Talk to various product, project, and program managers and consider the different industries as well. I would also recommend reading up on the roles. Lastly, I would say, if possible make the switch in your own org or company so that the transition is easier. Like I said, PM roles can vary based on the company, so knowing the team, the products, and how the company defines the role can simplify the transition.
ES:
What about for those just coming out of school? Would you recommend they start out as a developer or a PM?
JR:
Initially I would say if you are not sure, try development first. But ultimately, do your homework; talk to a few folks and try and figure out what is most interesting to you. At the end of the day, what is it that excites you to go to work everyday? Is it the code? Solving the code, going deep? Start as a developer! If you want to think about strategy, collaboration between teams, putting puzzle pieces, maybe starting as a PM is not a bad idea. Follow your passions. You can always try another role later.
ES:
One thing I have appreciated about my interactions with you is your mindfulness, especially in regard to taking breaks and stepping out from long meetings. I know yoga is also a big part of your day. Can you talk a little about this?
JR:
As you know we get digital overload, especially with the virtual experience. That is why taking those microbreaks is so important. To help remind you or keep track, there are a lot of tools available – apps or plugins on teams. Regardless of the tool, you need to make sure that you are taking microbreaks- small stretches at your desk, standing up, moving around- it makes all the difference. Having back-to-back meetings, sitting all day, and not moving is not good for you! And it does not help your focus. I might even say if there are meetings where you are not on camera, stretch then, at least stretch your hands that have been typing all day. If you have an opportunity to take a meeting on your phone so you can go for a walk (maybe even outside!) to get some fresh air, take it!
Sponsors
The Women in Tech Show 