feature article
Subscribe Now

Black Helicopters

The Career-Limiting Blame Trap

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.

2 thoughts on “Black Helicopters”

  1. quite credible reports do certainly exist. they are dealing with projects that were known to be doomed at a certain point in time but the setup was not unveiled to the general project staff until a certain decision point was reached. knowing all options and ticking for the most rational one based upon facts and understanding is sort of a success factor. but it only works if the ticking action takes place rather than being postponed.

Leave a Reply

featured blogs
Dec 4, 2020
As consumers, wireless technology is often taken for granted. How difficult would everyday life be without it? Can I open my garage door today? How do I turn on my Smart TV? Where are my social networks? Most of our daily wireless connections – from Wi-Fi and Bluetooth ...
Dec 4, 2020
I hear Percepio will be introducing the latest version of their Tracealyzer and their new DevAlert IoT device monitoring and remote diagnostics solution....
Dec 4, 2020
[From the last episode: We looked at an IoT example involving fleets of semi-trailers.] We'€™re now going to look at energy and how electronics fit into the overall global energy story. Whether it'€™s about saving money on electricity at home, making data centers more eff...
Dec 4, 2020
A few weeks ago, there was a webinar about designing 3D-ICs with Innovus Implementation. Although it was not the topic of the webinar, I should point out that if your die is more custom/analog, then... [[ Click on the title to access the full blog on the Cadence Community si...

featured video

Improve SoC-Level Verification Efficiency by Up to 10X

Sponsored by Cadence Design Systems

Chip-level testbench creation, multi-IP and CPU traffic generation, performance bottleneck identification, and data and cache-coherency verification all lack automation. The effort required to complete these tasks is error prone and time consuming. Discover how the Cadence® System VIP tool suite works seamlessly with its simulation, emulation, and prototyping engines to automate chip-level verification and improve efficiency by ten times over existing manual processes.

Click here for more information about System VIP

featured paper

Reducing Radiated EMI

Sponsored by Maxim Integrated

This application note explains how to reduce the radiated EMI emission in the MAX38643 nanopower buck converter. It also explains the sources of EMI noise, and provides a few simple methods to reduce the radiated EMI and make the MAX38643 buck converter compliant to the CISPR32 standard Class B limit.

Click here to download the whitepaper

Featured Chalk Talk

Bulk Acoustic Wave (BAW) Technology

Sponsored by Mouser Electronics and Texas Instruments

In industrial applications, crystals are not ideal for generating clock signal timing. They take up valuable PCB real-estate, and aren’t stable in harsh thermal and vibration environments. In this episode of Chalk Talk, Amelia Dalton chats with Nick Smith from Texas Instruments about bulk acoustic wave (BAW) technology that offers an attractive alternative to crystals.

More information about Texas Instruments Bulk Acoustic Wave (BAW) Technology