Accepting Tough Decisions

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.