What a F-- Mess
A Story On Bad Vendor Management
Hey, fellow Leader 🚀,
I am Artur, and welcome to my weekly newsletter. I am focusing on topics like IT Management, Innovation, and Leadership, with an Entrepreneurial mindset. My goal is to help you navigate the IT corporate landscape. Make better decisions, create awareness, and share real-world stories.
It has been a wild ride since I published the first article on the SoW. Exchanging views with you and hearing feedback on how these articles have been useful is what drives my motivation to write. Leave a comment, subscribe to the SoW, and be part of the community.
If this article resonates with you, or you know someone who might find it useful, just share the link!
Sometimes we get a very bad apple in our project basket. The goal was already challenging enough as it was, but we also had to deal with a “talker” during the project execution.
After a while, I started to see signs that something wasn’t right, despite the status being reported as “Everything is fine, nothing to see here”. When I finally popped the hood, it was a mess: I realized I was dealing with a total pile of sh!t.
This kind of situation happens even to the most experienced managers. It happens because we try to create the right conditions for our team to evolve and improve their skills, accepting errors as a natural part of the learning curve.
However, sometimes enough is enough, and we have to deal with someone who refuses to take responsibility for bad work.
For today’s article, let’s walk through a real case involving a project called “Unicorn of Truth” (fictitious name). It was executed in a fully remote setting by one of our favorite engineers (and I’m using the word “favorite” with heavy irony here), whom we’ll call Francis.
The First Impressions
The “Unicorn of Truth” project required someone with a very specific set of skills (and no, this isn’t a John Wick movie).
These skills are not easy to find on the market, especially with the constraint that we only needed someone for a limited time. It was the kind of job typically given to a freelancer, with the potential to extend into a maintenance contract once the “Unicorn” was delivered.
Francis was dropped in front of us straight from IT heaven, and we quickly felt he was the right person for the job. The interview was great. He seemed to know his “unicorn business” inside and out, possessing both the communication skills and the technical chops to pull it off.
Before the project even kicked off, he delivered a comprehensive SoW (Statement of Work) that felt fresh from an AI generator. Much like every other piece of documentation in circulation right now. We were ready to start.
The First Signs That Something Was Wrong
While we were laying the groundwork and setting up the infrastructure, the first cracks began to appear. Our friend Francis would only connect in the morning, ignoring any Teams messages sent in the afternoon until the following day.
We were now officially burning calendar days, and the project hadn’t even properly started.
Because Francis was fully remote, we couldn’t exactly pull him into an office to assess the “Unicorn’s” progress in person. On top of that, we hit infrastructure issues that required back-and-forth collaboration. Given Francis’s delay in replying, these issues took days to address instead of hours.
We immediately scheduled a call to let him know that the lag between communication and action was far below expectations. The topic was addressed swiftly. We both accepted mea culpas regarding the infrastructure hurdles that shouldn’t have been there in the first place.
The compromise was that Francis would provide daily progress reports. From experience, I already knew this would only work for the first three days before everything reverted to the status quo.
AI Is Not A Magic Wand
In this day and age, AI is everywhere, and it’s great to see it being adopted more routinely. However, AI can also be used to mask lazy work. Because AI provides what appears to be a “clean” output, people often assume it won’t be challenged.
But having the ability to copy and paste from a ChatGPT window isn’t the same as understanding the subject matter. It only proves you know how to prompt, copy, and paste.
AI tools now allow mediocre professionals to disguise themselves as experts who understand the game. Looking back at the end of the project, it was evident that Francis was relying far too heavily on AI without providing any genuine insight of his own.
He was saying and writing what, at first glance, seemed like the right stuff, but in practice, his output was a pile of sh!t.
Babysitting Morphed Into Micromanaging
It’s normal to keep an eye on progress and ask for the occasional status update. The problem starts when you feel the need to hover because you know something is wrong in “Unicorn Land”.
It became part of my routine to check his work every few hours just to see if there was any progress at all.
I kid you not: once the feedback was consistently that the Unicorn would be ready for testing “in a matter of hours”. Those hours turned into three weeks. Every day brought a different excuse for why something hadn’t worked as planned.
He was becoming too comfortable making excuses, and I started to feel like he was just throwing sand in my eyes. He was still facing infrastructure challenges that required another team’s involvement (which complicated things), but the level of trust had plummeted.
For every issue that surfaced, his first instinct was to shift the blame and provide an excuse. Francis was delivering 90% excuses and only 10% actual solutions. His “deep research” usually took about five minutes, just long enough to find the perfect handful of sand to throw in everyone’s faces.
I needed to fire him. FAST. But the project sponsor and some senior managers kept me from hitting the red button: “We just need a bit more time”, they said. “He just needs to deliver this one piece of the project and that’s it”.
The Unicorn Is Available For Testing
Finally, the long-awaited message arrived! The “Unicorn” was ready for testing, and I immediately jumped in to check.
Right away, it was clear this version was missing the very component that distinguishes a unicorn from a horse. Instead of a majestic unicorn, we got a plain, vanilla brown horse Texas-style. Francis had “challenges” with the unicorn part, and it took several more days just to deliver a version of what we actually expected.
By this point, my patience was nonexistent. Communicating with Francis was only possible after five minutes of breathing exercises between every line in the Teams chat.
Dealing with fully remote positions isn’t all rainbows and butterflies.
On the first day of testing, actually, within the first five minutes, the “Unicorn” couldn’t even walk. The application was throwing errors left, right, and center. I couldn’t believe what I was witnessing. I created a series of bug tickets, and Francis gave the same response over and over again: “It is not related to the unicorn features”. The project wasn’t even a functional horse.
If We Cannot Fire: Shock Treatment
An emergency meeting was scheduled, and even the CEO of the vendors insisted on joining.
We laid out exactly how badly things were progressing, using factual cases as evidence. We agreed to a few more compromises, but only on the condition that action would be immediate.
Honestly, I did my best not to explode in pure anger multiple times while witnessing such a level of amateurism from the vendor on such a complex project.
Anyone in a leadership position must control their emotions and clearly state the problem at hand. We have to stay factual. Losing one’s temper is a public admission of a lack of control.
For the next three days, things actually improved. Testing finally began to address the “Unicorn” elements of the project.
Until, that is, even weirder bugs started to appear.
The Pressure Mounts
After several days of unstable progress, I began demanding explanations for the increasingly bizarre bugs we were encountering. I asked for direct root-cause analyses and the specific steps Francis was taking to address them. He avoided sharing the information, and I insisted. Several times. This was the definitive sign that he was hiding something.
To my surprise, I discovered Francis was “fixing” each case manually at the user level. This meant that if a new user connected to the platform, they would experience the exact same issues reported in the bug tracker. He was essentially hardcoding his way out of a testing phase.
Francis then tried to shift the focus to how the tests were being conducted. His suggestions were designed to muddy the waters and disguise his poor deliveries. It quickly became a “Me vs. Francis” situation.
He even started calling out other people to back his opinions in meetings (colleagues who have remained silent to this day) as a way to gain leverage against my stance. As the project Lead, I was the last bastion of quality. I could never agree to proposals that murdered our standards just so Francis could buy more time to hide and “fix” things.
In every management meeting, I explicitly asked to fire him, pointing to massive cost deltas and project impacts. Yet everyone, even the CTO, asked for more time: “We’re almost there, we just need Francis to deliver X.” It felt truly odd. I began to suspect I wasn’t being shown the complete picture.
But all the excuses finally fell short the day a major component of the project was deleted from the database. There wasn’t a better monument to signal a poorly executed job than that.
The Turn Around
Yet another emergency call was scheduled with the vendor, but this time, we started asking the kinds of questions a client shouldn’t typically have to ask.
Since we were working with a freelancer in a fully remote position, we began digging into what other projects Francis had on his plate at the same time. We asked what kind of SLAs the vendor had with him and what kind of follow-up they were providing, aside from my daily “Are we there yet?” status updates.
I interrogated every small detail. Information that the vendor had every right not to reveal. But the objective was achieved: it became clear that Francis was juggling multiple projects, and his contract with the vendor didn’t support the level of service we expected.
We made a lot of people uncomfortable, but we successfully forced the vendor to review Francis’s situation. Despite all the feedback we had provided, the root cause had been hidden from us.
Furthermore, there was a political pain point between my company’s and the vendor’s senior management that was being handled with extreme caution. This was the real reason I faced so much internal resistance to firing him. Extensive negotiations were happening behind the scenes, and my “Unicorn” project was being used as a lever to force prices down.
Once everything was out in the open, it’s not like everything turned into rainbows and butterflies overnight. However, it was enough to speed up the fixes. I was finally able to review Francis’s planning while accounting for his other commitments. I managed to negotiate more allocated time and fewer distractions, allowing him to finally focus on the “Unicorn” we were promised.
Problems still arose, and things remained tense. My relationship with Francis was forever tarnished, but at least progress happened, and a “Unicorn” was delivered. Along with a massive discount, which honestly, cost us all too much.
That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.
Cheers,
Artur