Let’s face it – you can’t escape office politics. Even when you aspire to work with a client on innovation and transformation there are hindrances to that opportunity.
How you handle challenges and petty politics can make or break a relationship – and your reputation.
A few years back, Informulate had been hired by Pillard Inc. This was a huge project, one of the biggest we’d taken on at that time and we couldn’t afford to make anything less than our best impression on them. They worked with sensitive data, so there was a lot on the line for them as well. But we had helped Pillard with smaller projects before, so we had a decent relationship going in.
Mason was part of the Pillard team and one of the requirements stakeholders on the project. Initially, he came across as positive and encouraging but little did we know he was a bit of a political player – looking for every opportunity to gain “points”.
He was not savvy with software development, but he had strong opinions on his pet projects which he wanted prioritized. He pushed hard for what the roadmap should look like, and we were having a hard time managing his expectations.
Even with a big budget, his demands were directly clashing with the work that other stakeholders were expecting – and we had to be fair to the overall mission of the project. Our Innovation Governance methodology was based on data-driven decisions and there just wasn’t enough data to back his big bets.
On more than one occasion, in meetings, we tried to provide impartial guidance on the direction, but he wasn’t buying it. At this stage, he didn’t come out directly but through the grapevine, we heard his quotes like “Why does Informulate get to make the decisions?” and “They are just a vendor, we should be telling THEM what to do” not knowing that we weren’t making decisions but only providing a framework to make the decisions.
Despite our attempts to reconcile, Mason was unhappy and, feeling secure about his authority over us as a vendor, decided to try and discredit us with the higher-ups.
Blowing even the smallest issues and bugs out of proportion, he started to plant seeds of doubt with a number of top management folks on whether we were right for this job. We knew we had to be prepared to respond.
Sure enough – we were summoned into an awkward meeting with management.
Mason: “While we appreciate the new features, Rajiv, your team has had a hard time delivering quality. I have a list here of 14 issues we discovered. Are you aware of them?”
“Sorry about the inconvenience, Mason. I’m aware of some of them but if you send me the list I can confirm the rest as well. Are any of those issues still open?”
“That’s not the point!“ Mason fires back. “Sure, your team can fix the issues but why are we paying for your team creating and then resolving issues?”
“Well, some amount of issues is normal in software development, especially for a big complex implementation like this one. But we are a high-quality team and hold ourselves to a high standard. Over what time frame are you pulling these defects from?”
“A high-quality team? Our users are complaining about these issues. It affects our credibility and adoption rate.”
“I agree that the goal is to have zero production defects, and we have code reviews, QA testing, and even your own team doing User Acceptance Testing before we take anything to production.”
“So you’re blaming us for quality issues? We are a trusted brand and if people catch wind of these issues or worse if there is a security incident – this could have disastrous consequences”
“I agree. We are proactive on security and passed your security tests. In fact, I believe there were security incidents prior to us taking over, and there hasn’t been a single one since…”
It was like a tennis match, we went back and forth for almost an hour before and we had been made to look like fools.
Another round of reprimanding by Mason came in the form of some emails and lists of bugs, raking us over the coals and over-emphasizing every hiccup in the roadmap. We couldn’t sit by and let this continue to happen.
I had our internal team pull together industry benchmarks and defect counts. Then I called our own meeting of Pillard stakeholders/management.
The analysis revealed we had 1-3 defects per thousand lines of code.
Compared to the industry standard of 7-14 defects per thousand lines–we didn’t have to work hard to remind them of the high standards we hold ourselves to and the quality work we provide our clients with. And they could look at our ticketing system to verify all of this independently.
Some of the shareholders in that meeting were so impressed, they actually recommended and hired us out to other projects!
I will be honest, it felt great – turning a major challenge like that into a victory lap in front of Mason. And we’ve used those statistics to sell even more clients.
Long story short – we are still here working for Pillard and Mason has been moved to a different department.
But when this kind of thing happens, you need to stand up for what you believe in. There are a couple of things to remember if you encounter something similar:
- Seek the truth. If you did well, you want to claim the credit. If you did badly, you should want to know so you can improve.
- Use complaints as a teaching experience – don’t ignore challenges. Reflect on your own work, learn what you can do better, and open the door for growth.
Story by Rajiv Menon, CEO and Founder @ Informulate
(Client and character names changed for privacy)
