Accepting Tough Decisions
30 December, 2020
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
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.
Adi Purwanto Sujarwadi
VP of Product at Evermos
Piyush Dubey, Senior Software Engineer at Microsoft, shares his journey of climbing up the career ladder through awkward times dealing with an introverted manager.
Senior Software Engineer at Microsoft
Richard Maraschi, VP of Data Products and Insights at WarnerMedia, speaks on how he increased user engagement using measurements and experimentation.
VP Data Product Management at WarnerMedia
Sambit Kumar Dash, Founding Director at Lenatics, shares an analogy-based technical conversation.
Sambit Kumar Dash
Founding Director at Lenatics
Often in technology product management, this issue comes up. Generally, there is no consensus on it. I do not feel it harms being technical. Here is a story to illustrate the same.
Sambit Kumar Dash
Founding Director at Lenatics
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.