Elevate Spring Summit has been announced (Thu, Mar 11th)

🔥

Plato

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Don't have an account? 

Balancing Your Team and Product Sponsor’s Requirements

Team reaction
Stakeholders

29 January, 2021

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

Balancing Your Team and Product Sponsor’s Requirements
29 January

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.

Team reaction
Stakeholders
Jadon Naas

Jadon Naas

Product Development Lead at InMotion Hosting

Handling Frustrating Feature Requests
27 January

Michael Smith, VP of Innovation at Hadean Supercomputing, shares how he successfully reframed the dreaded feature requests into a stakeholder engagement exercise that helped him sell and test his roadmap.

Roadmap
Stakeholders
Michael Smith

Michael Smith

VP of Innovation at Hadean

A Company Merger: Two Locations and Multiple Challenges
26 November

Matt Pillar, VP of Engineering at OneSignal, recalls how he helped merge two engineering teams at two different locations and how legal and cultural context made all the difference.

Team reaction
Remote
Company Culture
Cultural differences
Team processes
Matt Pillar

Matt Pillar

VP Engineering at OneSignal

Measuring the Morale of a Team
26 October

Colleen Tartow, Ph.D., Director of Engineering at Starburst Data, shares her approach to measuring the morale of a team while emphasizing the importance of regular check-ins and one-on-ones.

Team reaction
Internal Communication
Motivation
Colleen Tartow

Colleen Tartow

Director of Engineering at Starburst Data

Driving Clarity of Charter in a Large Organization
27 September

Jeffrey Wescott, Director of Engineering at Splunk, describes how he introduced clarity on ownership between four disparate teams by drafting a charter that precisely demarcated who owned what.

Team reaction
New Manager of Manager
Managing Up
Reorganization
Ownership
Jeffrey Wescott

Jeffrey Wescott

Director of Engineering at Splunk

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.