You remember Gwen, the IT Project Manager who was having difficulty recruiting experienced software developers? I caught up with her on the weekend and am happy to report that she has found herself some developers. In fact, she found one group of ace engineers who had worked together before and were on the lookout for more work. She was excited, she said. An opportunity like that, with an established team who have experience, knowledge and a proven record of working well together is a PM’s dream come true. She recommended them for hiring. And got turned down.
Since the last time I met up with Gwen, her situation has changed significantly in one regard. She has a new boss. Let’s call him…Phil. And she doesn’t like Phil very much. You see, Phil’s a liar.
When he was interviewing for the position of Gwen’s boss, Phil told the team that he had worked for a number of high-profile companies. Equivalent examples would be Google and IBM. The problem was, his CV never mentioned such work, only one stint with a largish player more than five years previously. A far cry from the sharp and far-sighted IT strategist he was trying to pitch to Gwen’s company. After he left the interview, Gwen checked up on him via the intertubes. He had also said that he was currently on contract with a particular local company to help the team meet some deadlines. But, on his public profile, he claimed to be a “Senior Director” at the company, not a contractor. And, the next morning, his title had changed…to Chief Technology Officer for that company. I know this is true because I saw the print-outs Gwen had made of his profile, one in the afternoon and another one the following morning. Looking at the timestamps on the printed pages, I could see that Contractor Phil had magically morphed to Senior Director and then CTO in less than 24 hours!
Because the Hiring Manager, now Gwen’s boss’s boss, thought Phil was fantastic, he was hired. And swiftly started doing things that proved to Gwen that, instead of being a high-level strategist, he was nothing more than a smooth-talking two-bit coder.
Gwen is a Project Manager, right? Below her, she has several Team Leads. Below the Team Leads are Senior Software Developers. The Seniors guide the regular Software Developers. And there are even two Junior Software Developers. It’s a standard structure for IT projects.
Phil was hired for his connections. (At that level, that’s really all anyone is hired for, which explains the dismal state of IT in the world today. That and the huge influx of badly-educated Indian software engineers. (*) And yes, I’ve managed them, and a whole lot of friends have also managed them, so I know of what I speak.)
It was Phil’s stated job to set up meetings with several very influential government/business leaders in Singapore in a bid to drum up more business. Makes sense, right? So what does Phil do?
He terminates the agreement with the company’s first ever customer. He didn’t want to talk to them, never met them, and sent emails instead to all the parties saying that he “didn’t believe a continuing relationship” offered any “benefits” to anyone any more. So what happened to all of Gwen’s developers, who were busy working on extending said customer’s functionality? She tells me she’s got them investigating some esoteric problems on database interrogation techniques and real-time processing while she waits for the work to roll in.
But, the work isn’t going to roll in. Because Phil isn’t interested in meeting any important business leaders. Instead, he spends his time asking developers for their code and then questioning them as to why they are solving a problem in a particular way.
Contractor oops! I mean CTO Phil is quite representative of a lot of managers in Singapore and, no doubt, Malaysia. They don’t have the skillz to fill the job they’ve been hired for, so the company ends up paying for an exceedingly expensive code reviewer (if they even know that much) who still gets shown up from time to time by the Senior Developers and, through his incompetence, manages to actively hamper the company’s business. Phil obviously knows he’s out of his depth, hence his reluctance to do anything that someone of his position should be doing, and is frightfully insecure as a result. While he spends his working day calculating the average wait time for each developer at the coffee machine on the floor (I’m not making this up; Gwen’s tone of voice was rather dry as she related this), hiring decisions and business meetings are left to dangle in the breeze. Gwen tells me he took one look at the CVs for the group of developers Gwen and her team had interviewed earlier, and flatly refused to approve their hiring.
“They’re too good,” she told me. “Better than him. I’ll never get them.”
You could make the argument that, as there’s no work coming in, maybe it’s just as well that team didn’t get hired, but that’s not really the point. Meanwhile Phil’s boss visits from overseas every month, they spend days snugly cloistered in the office, and then Grand Poobah jets out again. Gwen says she used to have some respect for Grand Poobah once, but now it’s all gone.
(*) Back when I was a developer, there was a tactic used by Sales and Marketing that us coders used to call the “Mongolian Horde Principle”. The reasoning went like this: “You say it will take three people two years to code this system. Well, in that case, if you hire three hundred people, it should only take you a little more than one week to complete it. (Oh, and I sold the system last month and you’re due to install it at the customer site in three weeks.)” To update this method for the modern era, and mindful of the huge number of Indian so-called IT engineers in the marketplace, I suggest changing the name from “Mongolian Horde Principle” (which infers something theoretical in nature) to “Bangalore Mob Method”, which is how it’s currently implemented at innumerable IT projects around the world. The exact same reasoning applies. But hey, they’re cheap and that’s all that matters, right? If nobody cares about quality, why should you?
