Horrible Bosses and Horrible Colleagues

If you've not read Dunning and Kruger's seminal paper Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments then you should absolutely go read that first, and then come back to this article. This missive explores the ideas of that paper further, especially as applicable to engineering organizations.

In pursuit of this goal, let us assume that you, whom we shall consider the paragon of competence, work for an incompetent manager. Unfortunately because of what is called the Dunning-Kruger effect, your manager thinks of himself as supremely competent; and thus, when in a technical argument with you, he considers his point of view at least as good as yours, if not better.

To further compound the misfortune, he usually overvalues his "experience" - the sum total of whatever he assumes he knows, has learnt and has distilled from the pure engineering consciousness that only he can peer into the recesses of.

How do you ever tell such a person that he is wrong on some technical topic? After all, he can always pull up how in his day, all he could play with was a PDP-11 into which he shoved in cards punched with his fingernails. Or how in his day, a multimeter was all that was needed to debug his fantastic circuits? And how you, young whippersnapper, who may have a command of Verilog not seen since Phil Moorby and Prabhu Goel, or a command of C not seen since Brian Kernighan and Dennis Ritchie ever measure up to his arbitrarily high standard of designing ripple counters with 74 series logic?

One suspects that you have been set up with such magnificent examples of irrelevant experience. You can never satisfy such a boss - because he is so full of himself that he can't really see beyond his nasal orifices.

Then there's the boss who while technically incompetent, is extraordinarily competent when it comes to people and to politics. He knows the ins and outs of the organization, who's being promoted, who got passed over, who's got which car, who plays golf with whom and so on. He can grease any wheel with a rapidity that makes you feel minuscule in comparison.

Such a boss expects you to play his games - if you fail to do so, woe unto you, and if you do, then you can kiss your technical competence goodbye, because so embroiled will you become in his machinations, that will be all you can think about.

If you see a pattern developing here, one congratulates that competence we credited you with at the beginning of this piece. Cutting right to the chase, as it were, such horrible bosses abound in the industry. It is a miracle that Moore's Law has applied for this long, because growing numbers of incompetent people in any organization must eventually spell its demise.

The difficult question is what you, the competent engineer, will do about it. On the one hand, there is that nagging question of having an income. On the other, there is the torture that so many engineering organizations excel at doling out. Angst such as this is what led to the creation of Dilbert, or the movie Office Space.

If you are in a situation like this, then you will want to know what to do about it, and if a solution to the problem exists. But we are getting far ahead of ourselves. We need to explore the incompetence theme a bit further first.

Firstly, we have to consider how the incompetent boss or colleague evaluates you - the competent engineer - and secondly we need to investigate how you evaluate them.

Per Dunning and Kruger, the incompetent do not possess the metacognitive ability to understand your skills. This means that in their eyes, you are no better than them, a corollary of which is that no matter how hard you try, you can't convince them of your skill. Again, per the same paper, you won't think them so utterly incompetent, and you'll likely underestimate yourself. Add to this the general feeling of nausea that the competent get when singing their own praises, and you have the worst possible situation: Incompetent bosses who think they are better than they really are and you worse than you really are, compounded with you more or less unable to disagree.

Now consider another scenario - say you aren't really that competent, but your boss is. In this case as well, you will be under-appreciated, but rightly so.

Looking at this entirely from your point of view, all that is visible to you is that you are under-appreciated. This bit of data - most likely true - doesn't reveal anything about reality, though. Similarly, looking at it from the boss's point of view, all that is visible is that you don't measure up - and this bit of data also reveals nothing of the real state of affairs. Both cases are like looking at the result of a logical-OR operation and trying to decide which inputs are in which state. It can't be done.

This is a bit of what is called a deadlock. Both parties are right and wrong at the same time, and no move can be made. Unsurprisingly, situations such as these end in separation; the engineer quits or is made to quit.

For the sake of completeness, there are two more cases to consider. You, the astute reader have already figured this out - we've done cases 01 and 10 - each bit denoting the competence of the boss and you. We have to do 00 and 11, that is the cases where neither is competent and the case wherein both are.

The case of 00, wherein neither your boss nor you are competent, is easy to dispense with - if such is the case, then this article is of the remotest possible interest to you or your boss, and vice-versa.

The last case is also easy to dispense with - it is a utopia that one hopes everyone will live in, but is nearly impossible to come across in real life. A priori, one might postulate roughly a 1 in 10,000 chance of this happening - or at least a low enough probability to not waste words over.

Among the two cases we first discussed, the most interesting case is that of the smart engineer with the um, thick boss. The case of the smart boss and thick engineer usually gets resolved easily enough - with a well deserved pink slip.

At this point we are ready to start thinking about what to do when you are a smart engineer who is living the nightmare. The key to solving the problem is very helpfully given to us by the very same paper, and nicely enough, right in the abstract.

The insight is that when the skill level of the incompetent is raised, it also raises their metacognitive ability to recognize their own lack of skill - which while seeming paradoxical even to the authors is actually absolutely logical and correct. This harkens back to that old truism that only the wise understand the wise.

And thus the solution presents itself - if you desire to stay on in the same organization, working with the same boss - and there may be pressing reasons for you to do so - then you must raise his level of competence enough to at least appreciate yours.

Naturally, this is no easy task, and you may even think that putting in so much effort may not be justified given that you can probably get a different job easily enough (you are uber-competent, right?) but while contemplating your choices, it is worth keeping in mind the abysmal probability of your new boss being competent enough to appreciate you. (Now there's a tantalizing thought - "Is it possible to identify a competent future boss during the interview process?" -  and as usual, we'll leave it open for some future post.)

And finally this missive must end with that all important question - you think that your boss is dense and that you are smart - and this article has only really focused on that 01 case - but how do you know this for sure? One can only answer with another old truism - "Know thyself". But seriously - and this is the actual essence of the Dunning-Kruger paper - if you are really smart, you'll find a way to prove it to yourself.

Productivity in Electronics Design

One has heard it innumerable times, especially from management types. "We reward productivity", or "We want greater productivity", with the common variant of "result orientation" thrown in for good measure.

That's all very nice, and it sounds really nice as well, but we engineering types don't get excited when we hear miscellaneous morphemes of the sort.

No, not at all. We are far below all that. We need specifics. What is productivity? - and one means a real definition - a mathematical one. Without such a definition of a quantity, it follows that one can't really think about measuring it, much less increasing it and then rewarding it.

No, certainly not - without a meaningful definition of productivity, the whole management concept of increasing and rewarding it axiomatically reduces to a game of dangling carrots in front of donkeys.

After not much thought one can come up with some kind of definition like "amount of work done per unit effort". One can then immediately proceed to blow a neat little hole in that definition - what is "effort"? OK then, how about work per unit time? That's nice again, but for something like manufacturing widgets. How could one measure creativity that way? What if one didn't get any ideas for a month and solved three problems in three minutes? One recognizes manufacturing as a linear process, so any slope like definition of productivity - number of widgets made in a day - to use a tired old example - works.

But creating something is a nonlinear process, and measuring slopes of nonlinear things is an exercise in non-existence. It is fallacious application of mathematics at best, and at worst, a fairly certain method to kill the motivation levels of an engineering organization.

Having thus destroyed that pedestal of management - productivity - at least as understood by the not-so-rigorous, we now proceed to figure out measurements that do matter, and then go about trying to really optimize and improve them.

Say we are designing an ASIC. We'll concentrate on ASICs for this piece, but the concept can be extended to any kind of electronics design, or for that matter, any kind of design.

One parameter of significance is the total time taken from concept to completion. Reduce this, and rather predictably, thou shalt win the gratitude of management. Another good parameter to measure is the team size for the project. Reduce this and thou shalt also win the gratitude of management.

This is easier said than done, however. Astute readers will already have recognized the problem - that "reduction" is a difference operation. That means that one needs to have two time lines, or two team sizes. The problem of course is that nobody does the exact project twice - in time or space. So one of the numbers required for taking the difference is necessarily a guess, or an estimate - just short of being imaginary. No, not imaginary as in mathematics, imaginary as in fictional.

And yet, as any experienced engineer will tell you, a guess is better than no data at all; and many estimates of time lines and team sizes are surprisingly accurate, notwithstanding the empirical methods used to arrive at them.

So what if one took an estimate for time or manpower, and met the budget for a change? Better yet, what if one beat it by any significant amount? Now that would be a good achievement, wouldn't it? Whether or not the management was impressed with it or was even told about it, one's team would certainly be grateful. Now that's that kind of gratitude that could genuinely lead to better quality, or perhaps a lower attrition rate.

One hopes that we agree that attempting to reduce time and team size meaningfully would be a good thing. So then, what is a meaningful reduction in time or team size? One posits that anything less than a 30% difference is lost in the noise. That is, given the inherent variability of the design and creation process, saving anything less than 30% on time or team size could be attributed to any number of other hard to measure factors - good management, good team integration, better engineering practices or pixie dust.

Stated alternately, if you went to your management and claimed a 10% reduction in time for a given project, they'd probably send you on your way with a pat on your back and nothing else. Because it couldn't be proved to the exclusion of other factors that this 10% was won because you did something differently. In this one actually could sympathize with the management - the signal to noise ratio for this kind of measurement is abysmal.

This is an important insight - that "productivity" as it is defined today is exactly what one suspects it is - a game of dangling carrots before donkeys, not only because its definition is vague; but also because even when it is defined with some semblance of rigor, the noise in the measurement obfuscates the signal to the point of uselessness. Keep this in mind the next time you unsuccessfully ask your management for a 10% raise for a 10% increase in productivity. The former measurement has nearly infinite SNR and the latter, nearly zero.

But there is a way. If the reduction in time or team size is greater than a third or so, then the improvement rises above the noise floor to establish itself firmly as signal - that is a true increase in the reciprocal measure - productivity or some analogous concept.

Improving productivity in ASIC design is somewhat like flying an aircraft. Any of thousands of causes can cause a crash, and innocent errors can string together to spell disaster. Quite like that, there are a thousand factors conspiring to kill productivity. And like the operation of an aircraft, you must tightly pin down the entire development chain.

In the case of an ASIC, you must plan out in some detail the various steps - concept, architecture, modeling, RTL, verification, performance, synthesis, timing, place and route, signal integrity, post-route verification, emulation, bring-up, debug, failure analysis, QA and so on. You must plan out resources - people, server time, tool licenses etc. You must develop cross-functional relationships, however strange that sounds. Any one of several such steps goes wrong, and your chip is toast. It is in the milieu of such pitfalls that we would like to decrease time or team size by a third or more.

It has been seen time and time again that execution time increases dramatically when the number of iterations for a given task increase. Iterations increase because of specification changes or because of not anticipating issues and problems or because of execution errors. There isn't much that can be done about the latter two, since it truly requires experience and skill to do ones job right. There is, in short, no process that can replace experience and skill when those specific qualities are required.

Specification changes are another matter. Sadly, more than anything else, even a well planned design is not immune to this curse - which causes teams to repeat whatever has already been done. Not surprisingly, this is a factor in creating boredom, and a desire to not work now, but rather wait until the specification has "solidified", as it were - and time lost thus is like the rent of empty hotel rooms - lost forever.

One has to accept that specification changes are more or less unavoidable, especially in a design phase that lasts several months. During this time, new data many-a-time come to light about desirable features, what the competition is doing or about what customers prefer, that often necessitate changes in the specs. Unsurprisingly, most teams are loath to respond positively to such changes.

This stems from a well justified desire in teams to not iterate. However, design teams choose to avoid iteration by going at it sequentially, as if every future step depended on past ones. Perhaps this is because we are humans - we expect temporal sequences in effects to map bijectively from temporal sequences in causes. This need not be so - indeed the very insight that such causality is an assumption is one of the most dramatic harbingers of future success.

Breaking temporal sequences requires doing things in parallel, as it is known colloquially. "Parallelism in the process" is not a new concept - it is widely used in manufacturing, for instance to dramatically speed up an assembly line. The new thing is trying to apply it to something that is inherently the antithesis of an assembly line - design and development.

Parallelism not only means thinking about and planning out several of the steps in advance, but actually executing them ahead of time too. Thus, the smart engineer will do those parts of the RTL  first that can be used simultaneously to create a software emulator of the chip so that some members of the team, for instance those who do back-end work can spend time writing bring-up scripts. Sometimes such connections are non-intuitive, so some thought is necessary to determine connections between steps, and do as many in parallel as possible.

Once again, the sharp amongst one's readers will realize that much of this is easier said than done - for instance, there is always the perturbing thought that a change in specification will now impact  multiple teams, compounding all the evils of iteration.

This seems like a huge stumbling block, until one comes to the understanding that if one could identify and automate away those processes or sub-processes that need iteration then one could parallelize away to one's heart's content.

Thus, in the specific case above, a register generation tool that takes in a specification and simultaneously generates RTL and all that would be needed for verification, emulation, bring-up scripts, standards compliance and audits or whatever-else-not would mean that an architecture team, an RTL team, a verification team and a bring-up team could work in parallel, with all attendant benefits.

This brings us to the real point of today's article: To successfully improve the vague notion of productivity, one needs to parallelize the process - and to parallelize successfully, one needs a proper toolset for automating as many tasks as possible. Specifically, one needs to create tools that allow simultaneous development of a multitude of sub-tasks with nearly zero penalty for iteration on any of them.

So is such a toolset possible - even if only conceptually? One asserts that indeed it is, and hopes that this rather titillating thought will suffice until future missives.