In my ten years of experience in product, indirectly influencing a development team has been a constant challenge. With an ever-growing organization & individual aspirations, it has become tough to keep the team aligned to the overall product vision. Politics, personal biases, and miscommunication between team members mar their ability to deliver exceptional value to the customer.

Over the years, I’ve built a framework when dealing with the technical team-members of my development team. This framework should work for all of you, with a few exceptions.

Product managers with a background in technical have to be especially careful in managing the team — their personal biases can come in the way of effectively guiding the team to the ultimate goals. I’m pretty technical myself, so this bias of mine has cost me some brownie points with the team. Thankfully, the team has been understanding and have highlighted these instances for me to improve. After all, we’re all in this together 🙂

Before we begin, it is important — as it is always important in any instance — to understand the psyche of the team and their members. The team demonstrates a group behavior, not unlike a pack of lions, and then an individual behavior that can surprise you. Only when you understand the team, individually, can you better align them with your overall objectives. We are, after all, never directly responsible for the team. Keep this in mind.

Note: This article is long. I’ve divided it into 3 parts, to make it easier for you:
Understanding your engineering team
Do’s to follow 
Don’ts to follow

Understanding your software team

To understand your engineering team, quickly, you’ll have to make them go through, very subtly, various sets of difficult situations. I know this sounds a little weird, but bear with me. My rationale for this is that it brings predictability to the team’s behavior. The below scenarios if you test, very subtly, should give you a deeper insight into the team.

If you’re willing, these scenarios also demonstrate the various spheres of influence within the team. Extremely useful to know when you want to get things done with the least amount of friction.

Note: Engineers reading this — I’m sorry, but you folks are complex beings. Brilliant, eccentric, and unpredictable! We, product folks, thrive on predictability, so this is done without malice to understand your herd-mentality.

Try to keep these experiments independent of each other and for a short duration (2–3 sprints at max).

Scenario 1 — Scope-creep

Easiest to do — simply try to introduce a new story into an existing sprint. Provide vague reasoning for why the story is important, but emphasize that it is important & urgent.

What to look out for

1. Did the developer discuss with the wider team before they engaged in the story?

If the developer didn’t bring this scope creep in the stand-up or to the team lead, there could be an inter-team issue. While we want the team to be independent in their decision making, a scope creep ought to be discussed before it is rejected.

2. How did they say no? Did they verify with the architect/team lead? Out-right nos are both good and bad. Good in that they are strong-headed in the SCRUM process, bad in that they haven’t taken time to understand the rationale behind the work.

3. If they commit to the story, see how they negotiate on the remaining stories — that’ll throw a good light on the team’s ability to adjust to change & their estimation capability.

Scenario 2 — Least Popular Solution Favoring

In a backlog grooming session, favor an unpopular opinion. Use phrases like, “I think there is merit in what <team member> is saying”.

What to look out for

1. Backlog grooming is good for expressing ideas. Every team member’s idea is to be valued. If the team rejects the idea that the opinion/solution proposed is worth further discussion, they could have some bias they hold (either against the solution or the person).
2. If the solution/opinion is let-down gently with proper justifications, you have a great team that respects each other. Else, there could be something lurking in the background that might rear its ugly head during an emergency.
3. If they reject the notion that a product manager can weigh-in on the solutions, it might be a problem for you, later on. Given the complexities of the product function, there may come a time you need them to work on the solution you favor due to its simplicity, rather than the technically elegant solution.

Scenario 3— Testing for self-alignment

This can be tested by attempting to skip or cancel one of the regular meetups of the team. Or create a bit of misalignment for the team. Typically, I use the skipping of backlog grooming on a single occasion to see if the team asks for the session again.

You’re looking for the team to demand the session. They need to know what is coming up to plan their work better. The team needs to self-organizing. Failure of this self-alignment indicates a team that might need more SCRUM cadence hammered into their calendars.

Scenario 4 — Vague requirements

This is an excellent way of knowing how the team works on vague requirements. In a backlog grooming session, provide a vague requirement in a story. Try to keep some basic details, but skip on the specifics.

You’re looking for the team’s ability to ask grilling questions on the requirement. Without clarity, the story cannot be completed. This creates debt for the future, especially during the sprint.

If the team asks good questions and sends the story back for further details, you know that they’ll not estimate any random requirement. Else, they’re more likely to be cow-boyish in their approach.

Within the first couple of sprints, you should gauge the team’s ability to work together and deliver. These tests should reveal individuals who sway the opinions of the team as well as the team’s ability to handle adversity.

Note: if you’re not confident, please DO NOT do these things. There is a lot of trust riding on your ability to deliver value — if you mess that up, you’ll forever lose the team’s trust.

Additionally, I recommend you have 1–1 sessions to understand the individual aspirations & abilities. It pays to know the strength of your team before you send them out to battle for the right value delivery. You are a general-counsel. You need to know how the troops move and their strengths.

Now that you can understand the team, let’s look at the do’s & don’ts.

Do’s with dealing with the team

Do show glimpses of your product decision making

Time & again, it is essential the team understands the challenges you face AND the decisions you’ve made. I expose the team to the business/customer requirement madness, on certain occasions, and how much I’m holding back.

The goal is to ensure that the team understands the vitality of your role. Earmark a few stories for the team to understand your thought process behind choosing a certain goal. Engage & ask if they’d have done this differently. If you get their buy-in, you wouldn’t need to ‘influence’ or sway their opinions. They’ll be with you, right in the trenches.

Do provide a technically challenging item in the backlog

If you empathize with the team, you’ll notice that the team enjoys spending time breaking down a complex problem. If your sprints are filled with trivial work (story points range from 1–3), it’ll be difficult to keep the team engaged. Sure, they’ll deliver, but intersperse your sprint backlog with some high-effort items. It’ll give them something to work on that isn’t just changing the colors of a button.

I keep a separate technical debt backlog filter and invite the team to add a few items from that backlog within the sprint scope. This helps them realize the issues they had with a previous code and as a team, they improve. Problem-solving is their bread and butter, it helps to add flavor from time to time. Work in conjunction with the architect/team-lead if you can to identify these issues.

Do discuss before committing to features/improvements

In a different organization setup from the ones discussed above, there may be times where a commitment is asked from you. ALWAYS differ to the technical team lead, if they’re present. If not, commit after discussing it with the team. These are negotiations, with a lot of moving parts. It helps to keep all those parts in the know and getting their buy-ins.

Personally, commitments before discussions have been some of the lowest points in my career. It feels like a betrayal of the team and the trust they put in me. It might feel good to be seen as someone who can commit things in front of stakeholders, but the cost is too high. The team will deliver, no doubt, but you’d have lost the trust. And that’s difficult to get back.

Do be a servant-leader

Servant leadership puts the needs of the employees before the profits & deadlines. Sure, those things matter, but even more important are the people who make it happen. In my view, product managers need to display servant leadership — by keeping the aspirations of the team first.

I do this by sharing information — if I know a feature that the team worked on increased revenues by X%, I share that success with the team. Where possible, I praise the team in full view and commend them for the effort they put in. If the team wishes to conduct some exercise to investigate a part of the customer journey, I push for that with the stakeholders. I exhibit value delivered, and the savings incurred. In short, I keep the team engaged and happy without sacrificing the product vision.

Note: There are a few that are never happy — no matter what you do. Ignore them.

Do get buy-in from everyone

The team has to be bought into the sprint goal. They have to buy in on the items that they’re going to work on. Only then can they deliver the value you desire. Every effort should be made to align the team — even if it means having a 1–1 conversation with those who fall out of line.

Justifying your actions doesn’t trivialize your position. It only makes it stronger.

Don’t when dealing with the team

Don’t solutionize

Product managers with a history of technical know-how have the biggest issues when it comes to this. It is not easy to stay away from architectural solutions. However, you have to remember this important thing: YOU ARE NOT THE EXPERT. Repeat that in your head. You are not a tech expert. If you are, then you’re in the wrong role.

This does not mean that you’ll outright discard the technical side of you. No, this is a tool you can use to ask questions. Asking questions is free, giving answers is expensive. If you are certain that a technical solution proposed has a weakness, ask if the solution holds in the scenario you propose. Don’t confront — simply inquire. I’ve got better value delivered from the team by simply asking questions in scenarios I think the solution wouldn’t hold. The value isn’t purely customer oriented — I too have grown in my technical understanding, validating the right & correcting the wrongs.

Avoid asking too many questions and checking the team every step of the way. If you find yourself doing that a lot, due to the team’s maturity in tech, invite a senior member. You cannot be seen as a technical guide.

Don’t trivialize

Contrary to popular product manager belief, a button change isn’t a 5 min job. Nothing can be achieved in 5 mins. We should never trivialize work to be done/work done. Keep that in your mind.

In a similar vein, don’t question estimates. Estimates are democratically arrived values for a story. The entire team has agreed that it takes a relative quantum of time to do a particular task. Your previous experience or understanding cannot come into play here because no two situations are different! Similar tasks are not the same unless indicated otherwise. There are many moving parts to changing a button interaction — just think of the Google search button. You’ll know.

If you have a problem with the estimate, take it up with the team lead, privately. Again, you’re just trying to understand the complexity and prodding for avenues to reduce the scope, if possible.

Don’t boss around

I’ve seen product managers complain about how the team is loitering around, playing pool, or something that is not contributing to the sprint goal. And I always ask them — are you contributing to the work to be done? If not, have a coke & a smile and shut up!

It helps to remember that the team took up the tasks in the sprint — you didn’t assign it to them. You only set the sprint goal, the backlog, and the definition of done. THEY chose the stories for the sprint. You influenced, yes, but it is for them to do.

Another thing that is important to remember, you are not responsible for the team’s work. If the work is poor, you can always escalate. However, DO NOT ever cite the times you found them slacking off — you’ll make more enemies than friends. Only talk about the quality of the work.

Don’t attribute success to individuals

The jury is still out on this one, but I personally never favor attributing success to individuals in a public setting, no matter how amazing the work is… It only creates additional barriers within the team & a culture of individual contributors. We don’t want that.

Instead, I prefer calling out individuals in a team setting. That way, they get the recognition of their effort, while the team knows of their contribution. In a town-hall, the team is praised, collectively.

Some of the things I’ve written here could be different in your organization. I’ve seen in product-led organizations where the team reports to the product manager — which, IMHO, is recipe for disaster. Ideally, the delivered value is a collaboration between the development team & the product manager.

Even then, try to implement the above and see if it works. Bring changes in smaller increments, just to see what works and what doesn’t. Individually, these items do not guarantee success — however, they can greatly improve your position in the team. Together, though, I find them to be extremely effective.

Your mileage will vary.

Thank you for reading! I encourage you to talk to your developers and understand how they’d like things to be done. You’d be surprised how many of them have valuable suggestions that can make you a better product manager.

Do share with me if the above suggestions have worked for you. I’d appreciate it!