John had been working for almost six weeks on a single part of the design persistence code. He had made no discernable progress. His original estimate for the project had been “2-3 days.” As John’s manager, and as the engineering manager responsible for the timely delivery of our project, I needed to do something. I stopped by John’s office for a visit. 

“They want us to use an OODB,” John stated flatly. “It won’t work.”

I was confused. I knew the project inside and out. Our team, ten software engineers including John, had worked out the plans together, in our own conference room, on our own white board. There had been no mention of an OODB at any point in that process. The planning documents – sketchy as they were – that we had jointly developed during those meetings – made no reference to any specific implementation details. 

I was, therefore, very curious to find out who “they” were. 

“What makes you say that?” I asked, cautiously. The intuition I had developed in ten-plus years of experience managing extremely talented engineers told me that I might be about to make the dreaded transition from professional engineering manager to amateur psychotherapist. I did not like that prospect one bit.

“Corporate Engineering, They want us to use an OODB for our persistence strategy, but it won’t work for what we need to do. If someone interrupts the process during a write, the project data file could be corrupted and…”

“Wait,” I interrupted. “Corporate Engineering isn’t involved. I’m pretty sure they don’t even know our project exists.” 

John continued as if I hadn’t spoken at all. “They don’t understand that a design node could be orphaned if all of the edges of the graph are re-pointed to…”

Now it was my turn to switch into “ignore” mode. My worst fears were confirmed. I let my mind start to work on the Real Problem while my ears periodically sampled representative bits of John’s ensuing fifteen-minute diatribe. John had built an elaborate fantasy in his head, and that fantasy had utterly paralyzed him. He could do no work. He simply sat in his office making rhetorical circles in his own head, coding and de-coding, more intent on proving the impossibility of his task given an imagined set of constraints than with actually finishing the project.

John (not his real name, by the way) was a brilliantly talented engineer, and a genius. He had a PhD from a well-regarded university (we’ll call it “Stanford”). He was a recognized expert in the technology we were developing. John was so brilliant, in fact, that he could immediately give you ten reasons why any given solution to any given problem was completely unworkable, and usually have you end up believing him. It was not an endearing trait.

In this particular case, the fantasy that John had constructed involved a team known as “Corporate Engineering.” This team was comprised of two senior software engineers who had apparently been deemed too talented to lose, but too badly behaved to be allowed to work on any real product development project. One was a founding engineer – with employee number “three” or “four” (in a company with thousands of employees) – and he was so entrenched in the way things were done in the “old days” (yep, coding in Pascal) that he couldn’t be persuaded to even consider the validity of “passing fads” like C or C++ (which is what all the cool kids were messing around with). The other one was a more recent “trophy” hire – proudly plucked from the nest of our biggest rival company, heralded with an accompanying gloat-o-gram press release from our recruiting team. This guy had published an impressive stack of deep-thought theoretical papers on possible advanced techniques for solving various future EDA problems. The stack of papers was so high, in fact, that it obscured the fact that he had absolutely no useful real-world skills and, as a bonus, was a dyed-in-the-wool sociopath (Corporate Edition.)

“Welcome to Corporate Engineering.”

Nobody knew what Corporate Engineering did, and nobody really cared. Most of us were just grateful that two more troublemakers were off the streets, and we could go about our business of developing software in relative peace. One thing that Corporate Engineering most certainly did NOT do was review, approve, direct, or in any way have any influence whatsoever on our project. Nonetheless, John had somehow concocted an elaborate scenario where Corporate Engineering, surveilling us all from their stealth-black helicopters, had issued some unspoken, unwritten edict that was now over-constraining his portion of our project to the point where he was dead in the water. John explained how he had tried repeatedly to come up with a way to do the implementation “the way THEY want me to” and how it was now becoming clear to him that it was simply impossible.

I asked John if we could perhaps opt for a simpler, more straightforward approach – at least temporarily – in order to keep the project on track and to give us something that we could use for the time being.

John looked at me as if I’d just proposed making a dessert of puréed puppies. 

I knew at this point that I was facing a lost cause, and I immediately opted for Plan B. I re-directed John to a task more to his liking – he was to evaluate the three best-known algorithms for handling one of the problems our system needed to solve, and to make a recommendation to the team on which one we should implement. The task John had been stuck on, I re-assigned to a new engineer – a fresh-out-of-college hire with a Bachelor’s degree from a local state school.

After two days, the new engineer had a working persistence module – based on a simple text file. It’s probably still in use today – more than a decade later. It was fast, clean, and straightforward. Meanwhile, John spent over two months on his new assignment, evaluating and considering the three candidate algorithms. He ended up concluding that none of them were satisfactory, citing at least one corner case where each one would either produce sub-optimal results or fail entirely.

John was shocked when I fired him. It was incomprehensible to him that the company could possibly let go of a brilliant, pedigreed engineer like himself, while keeping so many young, inexperienced, barely-qualified programmers. Clearly, he concluded, it must be about the money. He told me flat out that he knew that corporate executives were trying to get rid of him because his salary was too high, and they wanted to ship his job “overseas” (even though our part of the company had absolutely no overseas development staff, and didn’t outsource any of our work.) John was wrong. The decision to fire him was mine and mine alone, and I’m fairly certain that no “corporate executive” ever even knew his name.

John’s case was not that unusual, although it was a more striking example than most. Many times in my career as an engineering manager I saw otherwise-talented engineers become obsessed with bizarre “us and them” conspiracy theories that absolutely killed their productivity and sometimes their careers.

In my roles, I often straddled the two worlds of management and engineering. I knew that management had no secret master plans or subversive side-plots where they were skillfully manipulating the engineers toward some dubious destination. They were just hoping-against-hope that the engineers that they had hired would be able to create a winner – a product that would be profitable for the company – on something like the timeline and budget those same engineers had promised. 

I knew that a small subset of the engineers believed otherwise – that the “real plans” had not been revealed to them, and that they were being manipulated and controlled for some nefarious purposes that had little to do with the stated project goals. Some spent enormous amounts of energy trying to understand and thwart these imagined conspiracies. Others simply resigned themselves to what they saw as an inevitable fate. Luckily, we had enough clear-headed, practical people on the team that we accomplished some truly spectacular feats. Sadly, not everyone who started on the team was able to make that journey with us.