Accepting Tough Decisions
30 December, 2020

Director of engineering at Ex-HPE
Problem
I believe that every manager encountered a similar situation: a few of my VPs and a chief architect wanted me to change direction for one of the areas that I was responsible for. The hypothesis was that the change would accelerate our time-to-market. I disagreed; however, as the back-and-forth discussions continued, this started distracting the teams. I decided to embrace the change and proceeded to collect more data so we collectively can reach a data-driven decision.
Actions taken
Spoiler alert: I woke one morning, and I decided I should change the roadmap.
But how did it all start? It started with me realizing the toll these discussions are taking on the teams as they’ve begun to question the relevancy of what they’re working on pending a significant decision on the roadmap. At the same time, I realized that we didn’t have data to guide the discussion and conclusion. From the very beginning, the hypothesis presented by VPs and the chief architect was that if we change direction, we will get faster to the market.
However, there wasn’t any data to back this hypothesis. As the discussions back-and-forth went on, I decided to embrace the change to fast-track the assessment of what it would take to change the direction in terms of the costs, time to market, etc. This would allow us to compare, albeit at a high-level, the two approaches.
From the very beginning, the sense of unease permeated our conversation as I perceived it as a unilateral pressure. However, once we started doing the scope, the conversation became more pleasant because we were going down a particular path.
I let the data speak rather than me trying to justify my position. We looked at the original plan and compared the data -- it didn’t seem that the approach my superiors were pushing for would save us any time. Then we brought in people from product management to weigh-in on the problem. They were unconvinced looking at the data that changing the roadmap would bring us any faster to the market. More interestingly, product management assessed the two approaches based on potential revenue and advised that we stay the course. They were also very persistent that we should base our decision on data. For weeks, before turning to the data, I tried to challenge the hypothesis without having any concrete data to corroborate my position.
However, I was under pressure to agree with my superiors, and the whole ‘convincing’ thing was disruptive to my team that didn’t know if they should continue to do what they were doing or not. It was dragging on and on, causing uncertainty within the entire organization. In those circumstances, I felt that making a decision -- any decision -- would be the best. I didn’t want my ego or holy righteousness to get in the way. I stepped out of the debate and decided to manage it from the outside, becoming personally detached.
I decided to accept the decision I disagreed with and that I thought was not right because any further prolongation and endless debates would cause us more harm and slow us down. The team was confused and increasingly demotivated. Getting them back to the state of productivity and focus was more important than delaying the decision and establishing who was right and who was not.
Lessons learned
- When looking at different options, come up with the KPIs to help guide the discussions. Data won’t necessarily decide for you but will inform your discussions and take the emotions out of them.
- Emotional intelligence is vital in managing stakeholders. Understanding why folks are advocating for certain things is essential as you prepare your response.
- When considering roadmap options, engage Product Management early on. Their input is valuable from a business perspective. Even though we kept the same roadmap, we tweaked some of the features to bring them to market sooner without compromising the business objectives.
- In roadmap discussions, there isn’t an absolute right or wrong. Be comfortable in shades of gray guided by data.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
9 May
Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Pavel Safarik
Head of Product at ROI Hunter
4 May
Brad Jayakody outlines the roadmap to maintaining a healthy balance between technical debt and team growth. However, just as balancing acts go it is important to have a strong foundation.

Brad Jayakody
Director of Engineering at Motorway
4 May
Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Kamal Qadri
Head of Software Quality Assurance at FICO
20 April
Mike Nuttall, CTO at MyTutor UK, puts emphasis on the importance of creating and reviewing company roadmaps to strategize growth and alignment within an organization.

Mike Nuttall
CTO at MyTutor
14 April
Suryakant Mutnal, Engineering Manager at PayPal, discusses the importance of time management and the necessary structures in order to create internal consistency.

Suryakant Mutnal
Engineering manager at PayPal
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.
