Balancing Your Team and Product Sponsor’s Requirements
29 January, 2021

Product Development Lead at InMotion Hosting
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
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.

Alex Shaw
Chief Technology and Product Officer at Hive Learning
10 December
Supporting principles on why being data led (not driven) helps with the story telling.
Vikash Chhaganlal
Head of Engineering at Xero
29 November
Why DevSecOps matter and what's really in it for you, the team and the organisation?
Vikash Chhaganlal
Head of Engineering at Xero
28 November
The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.
Vikash Chhaganlal
Head of Engineering at Xero
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.

Muhammad Hamada
Engineering Manager at HelloFresh