Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Balancing Your Team and Product Sponsor’s Requirements

Stakeholders
Team Reaction

29 January, 2021

Jadon Naas
Jadon Naas

Product Development Lead at InMotion Hosting

Jadon Naas, Product Development Lead at InMotion Hosting, shares how he managed to motivate his team while handing a directive product sponsor and his demanding requirements.

Problem

I was leading a team of engineers tasked to build a brand new product. The product sponsor was quite decisive about how they wanted it to be done, and the engineering team was mostly skeptical, if not certain, that it wasn’t the way to go. As a team lead, I was between the hammer and the anvil. I had to work hard to keep the team motivated and absorb the frustration and upset while handling the very directive sponsor. I was doing my best to convince the sponsor to consider options proposed by the team and have them rethink that their way is the only and the best way to complete the project.

Actions taken

From early on, the team felt that we should explore different options, and people were assigned research to look at different possibilities. They would delve into research for a couple of weeks, digging deeper and often getting excited about the potential prospects of alternative options. But it seemed that none of the options our engineers explored and presented could convince our sponsor that they were worth considering, if not pursuing. Needless to say, that attitude hurt and upset a lot of people. I knew that keeping the team motivated to proceed with the original (sponsor’s) plan would not be easy.

To make most of our work, I asked the product sponsor for clear objectives so that people would know what exactly they should be working on. I made sure to answer all the team’s questions and to leave none of their concerns unaddressed.

For example, we were building a cloud product, and one of the main things that was not clear from the initial requirements was whether it was a private or public cloud. I would have to get explicit clarification about this from our sponsor, as well as for any other feature and functionality we were building.

To keep the team up and running, I had to help people understand that there was still value in the work they did, even if they disagreed with the way it was done. I would ask them to document their work carefully, and if, after six months or a year, circumstances would change, we could use that documentation to advocate for another approach. I also encouraged them to look at their current work as a learning investment and a possibility to do the things they never did, rather than a waste of time.

The team was particularly hurt because the sponsor would approach the team asking for an opinion and when presented with an opinion different from their own, they would discard it without any serious consideration. The side effects of this kind of behavior were that the team felt that their autonomy was jeopardized, and my authority as a team lead undermined.

As a team lead, I tried to convey to the sponsor how the team felt, but to no avail. There were times when the sponsor was enormously unhappy with the progress the team was making and even wanted to go for disciplinary actions against people who they thought were responsible. I tried to mediate and convince them that delays do happen and are part of our job. In one of the most dramatic cases, when the sponsor threatened with disciplinary actions against one of our teammates, I decided to take the blame, saying that I was responsible for conveying mixed messages and thus causing the delay.

Lessons learned

  • Set and agree on objectives as soon as you can. That would ease discomfort and ensure that the team is on the right track.
  • When you ask someone to do the work, make sure they understand the value it has. Instead of asking them, “Do this research”, explain why this research is important and how it will be used. They don’t necessarily have to agree with the approach that was decided upon, but they should be able to see the value in it.
  • Don’t give people more work than they can handle. Pair people up instead of having them work individually. People can more easily become demotivated if they are overloaded with work or isolated. Having them paired up together can transform the dullest work into a tolerable if not pleasant experience.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Firing Somebody for the First Time

23 November

William Bajzek, Director of Engineering at Sapphire Digital, remembers the first time that he needed to make the ultimate sacrifice on behalf of the well-being of his team.

Leadership
Firing
Team Reaction
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

The art of managing up

19 November

James Engelbert, Head of Product at BT, shares how managing up is all about being an excellent manager to bring the best out of a team.

Mission / Vision / Charter
Managing Up
Internal Communication
Strategy
Stakeholders
Cross-Functional Collaboration
James Engelbert

James Engelbert

Head of Product at BT

The Benefits of Stakeholder Communication

17 November

Piyush Dubey, Senior Software Engineer at Microsoft, shares how to understand the stakeholder communication process better and why it is essential.

Meetings
Internal Communication
Collaboration
Ownership
Stakeholders
Piyush Dubey

Piyush Dubey

Senior Software Engineer at Microsoft

Securing A Fluid Transition to an Established Organization

2 November

Priyanka Naik, AVP of Product and Technology at J.P. Morgan, describes her switch from a startup to a large company and how she created rapport with her new team.

Internal Communication
Coaching / Training / Mentorship
Stakeholders
Cross-Functional Collaboration
Priyanka Naik

Priyanka Naik

AVP - Product and Technology at JP Morgan

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.