16. Understanding and trust

There has been a pause.. and a long one.

Finally, after a month of absence, I am back to jotting my journey. I came out of my current product manager role. Worse, I was asked to leave. I am now figuring out the next assignemnt and analyzing what went wrong with the last one.

In my next few posts, I will jot down about an ideal group I should be working with.

Notice: Following is a professional rant post! Skip it, if ranting makes you uneasy. or maybe, there is a lesson for some PM some where.

For one, it was clear from the beginning that I was to work on a product with long history of unresolved issues.

Two, I was working for a company that was essentially multiple products bunched together, with no proper insight into vision and direction. Top brass is still too busy tactically trying to hold on for survival like a scavenger holding on to remaining pieces of meat. Strategy was out of question.

Three, product engineering team had absolutely no trust in management, and vice versa. Engineering team was shouting for refactoring and were being ignored. Infact, engineering teams were fired as a whole more than once to curb the voice. But, every new team that came in was sure: they need to refactor code.
On the other hand, people in marketing, sales, customer support, and customers themselves were worried about managing the production deployments, and silence from engineering could mean losing trust with customers, and ultimately losing business.

We lacked leadership. We needed someone who could tell the customers what's wrong, and how it can be fixed, and when it will be fixed. Someone who could take approval from customers and pass on the approval to engineering. We needed transparency between customers and engineering.

Instead, as a scavenger would do, company was discussing exit strategies for the product. Not a bad thing to do, if current resources are limited and there is little assurance of future resources to keep going.

As a product manager, it was my responsibility to tell customers that we are in trouble and need time. We needed patience from our customers. And I went on a spree to start interaction with our oldest and most loyal customers. And as I expected, they understood and offered willingness to stand-by while we fix the product. Efforts were taken to bring transparency to marketing, sales and customer support, and give visibility into engineering operations. Many complained, but everyone understood. Half the battle won!

The other half of the battle was to bring more transparency and visibility to engineering team. (Although I was placed in same office as engineering team, my interaction was limited to engineering managers only, which was later narrowed down to single point of contact: program manager.) Anyways, my job was to tell the engineering managers what customers wanted, while at the same time, to tell customers NO, because engineering is doing something more fundamental.

But, it backfired. And badly.

Engineering team saw my presence and efforts as a waste of time. They were already booked for next 2 years, and were not interested in knowing what customers wanted. They wanted silence so that they could fix the product, and did not want me there with them, in their office. They wanted no interaction: no product manager, no customer interaction, no customer support interaction.

After much effort, my interaction with engineering head improved, and we started to understand each other.

Then, something happened. CEO, CMO, CTO, all changed, overnight! There was choas in the company. Engineering head, with whom, I had finally developed cordial relationship, was replaced. And he concluded that my interactions with program manager are creating choas in engineering and hindering his new relationship with his team. Of course, my superiors also did not want to have a bad relationship with new engineering head.

And here I am, wondering and analyzing: what went wrong?

Here are the possibilities:

1. I was going too fast, and trying to change the company culture faster than could be handled. My attempt to bring transparency and visibility may have been the over-estimation of skills of my conact in engineering team (program manager) to digest and utilize the visibility.
   
2. The new engineering team management reacted too fast to decide visibility is a hole, and fix it. The visibility I was providing (with authorization from my manager) to program manager was somehow proving to be choatic in engineering team. And top management of product management wanted no friction from the top management in engineering, and as result, I lost a chance to further learn from my experienced peer product managers.