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

"You don't care about quality" A story of single metric bias

3 February

This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.

Product Team
Productivity
Team Reaction
Alex Shaw

Alex Shaw

Chief Technology and Product Officer at Hive Learning

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Building A Team
Leadership
Ownership
Stakeholders
Cross-Functional Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

Dealing with Uncertainties and Adapting as You Go

14 June

Muhammad Hamada, Engineering Manager at HelloFresh, addresses the uncertainties brought on by the pandemic, how these have affected our work environments, and how we can adapt.

Goal Setting
Internal Communication
Collaboration
Roadmap
Stakeholders
Prioritization
Muhammad Hamada

Muhammad Hamada

Engineering Manager at HelloFresh