Boss Management

Bosses need to be managed too. Originally in Embedded Systems Programming, June, 1999.

For hints, tricks and ideas about better ways to build embedded systems, subscribe to The Embedded Muse, a free biweekly e-newsletter. No hype, just down to earth embedded talk. 23,000 other engineers subscribe. It takes just a few seconds (all we need is your email address, which is shared with absolutely no one) to subscribe to the Embedded Muse.

Pity the poor engineer. The victim of capricious management decisions, bearing the brunt of the boss's mood swings, suffering when a supervisor's Prozac prescription runs out, and subject to random schedule and specification changes. Or perhaps the pointy-haired boss has sub-human intelligence and less common sense, subverting the developer's best efforts to get projects out.

 Maybe the honcho is harried and distracted, generally unavailable and paying little or no attention to engineering till the day before scheduled shipping, perhaps communicating so poorly that this ship date suddenly surfaces as a big surprise to all but him.

 Tales of dysfunctional, disinterested and quite insane management peppers the apocrypha of engineering. Many of us do know of a leader whose style is indeed quite psychotic, but I suspect that the stories far outweigh the reality. Most engineering leads come from the universe of us, and most of us are pretty reasonable.

 It's true that hiring and promotion practice is flawed when supervisors come from the ranks of the supervised without regard to leadership ability and people skills. Raw technical talent is swell, but has little relevance to managing.

 Doing the work, and managing the work, are two completely different skill sets that barely overlap. There's no question that engineering proficiency is useful to a manager, but it's also clear that the progression from engineer to manager means cultivating quite important very non-technical competencies.

 It's a rare individual indeed who can be master of more than one profession, especially such disparate ones as people skills and microprocessor development, whose breathtaking advance leaves even the most dedicated of techies struggling to stay up-to-date. More often than not, engineers who successfully make the transition to management start to see their development skills atrophy. 

And this, I contend, is a natural part of the scheme of things. Really great engineers keep their edge by studying the field constantly, and by honing their skills through steadily building new code, designing new circuits, and developing more systems. 

Really great managers tune their skills by listening closely, monitoring and correcting their own and their people's mistakes, finding ways to provide needed resources, and helping their people be more productive over the long term.

 A Venn Diagram showing the intersection of these manager and engineering skill sets would come up null!

 So of course the boss has no idea what you're talking about when you discuss the merits of C++ versus C, or various ways of dealing with memory allocation problems. When his eyes glaze over that doesn't indicate he's an idiot; rather, it should merely raise a flag that you're communicating poorly.

 I believe management is a two way street, at least when the managed are professionals who are as intelligent and as highly educated as their bosses. If you obediently respond to the boss, and wait for the "latest bit of nonsense from that idiot in the corner office", then either your company is quite broken! or you don't understand that the difference in skills, pressures and motivations between the boss and you means you've got to proactively manage the boss as he attempts to manage you.

 But first I'd like to dispel a myth about management. As a young developer I bought into the general belief that the boss was an all-powerful creature who could fire at will, capriciously, maybe even simply to create a rule of terror. Though Stalin-like purges do occasionally happen, in these days of full employment the boss is hostage to the engineers. Losing a good developer is a nightmare; if one's poor people skills means turnover ticks up even a bit, then the boss will be in a world of trouble.

 And yes, I recognize that bosses span the spectrum, occupying all niches of the bell curve. Some shine, others are ogres. In my experience most do honestly want to do a good job. Too many, though, are so battered by pressures from above and below that they have difficulty making decisions that do a good job of balancing technical and customer needs. The boss needs help from his people.

Options

A sure way to gain your leader's enmity is to present him with problems and no solutions. Saying "Uh, the ROM's full and we're still only halfway done with the code" is simply a form of slow career suicide. You are technical the expert. Your boss is relying on you to solve these sorts of problems. Engineering is all about solving problems, not shoving them off on someone else.

Give the boss some options; help him understand the tradeoffs behind each one. Don't expect this person to suddenly master the intricacies of FPGA design to find a way to route the part; present alternatives (a bigger part, different routing strategy, perhaps reducing product features, maybe partitioning the design differently).

 I've been in innumerable meetings where problems surface and no one has thought through potential solutions. Creativity can come from brainstorming sessions, but that's generally among technical peers, not in a meeting with the boss, a secretary, and a couple of engineers. Come to meetings prepared to rationally discuss alternatives and their merits.

 Give options and corresponding tradeoffs. If none are appealing, you may have to go back to the drawing board, but at least the alternatives you've considered, even if rejected, will narrow the universe of choices.

 Present a problem without options and you can be quite sure that the ultimate resolution will be one you don't like. Give some well thought out choices and the odds are that the result will be one you can live with.

 Yes, some problems are intractable or require resources that only a manager can bring to bear. Sometimes you may just be exhausted and need to talk; the wise leader will understand and let you babble (though not in a meeting with others), perhaps even if he understands little. Sometimes it makes sense to go to the boss just to talk things through.

 Far too many years ago, as a young developer I worked on a new technology that few engineers, let alone managers, understood: microprocessors. Problems abounded; as the only micro person in the group no peer could give much advice. My boss wisely understood this, and listened  patiently as I'd talk about problems. He had little to offer, but understood that the act of talking things out helped me form my own understanding.

 The manager's role is to facilitate your work; there's a give and take, so sometimes babbling without solutions may be appropriate. Don't use such babbling to abdicate your responsibility to generally solve problems, though.

Speak Bosseese

You cannot manage your boss if you speak in a language he finds foreign. The lingo we use with our peers is incomprehensible to most of the rest of the world, and all too often to the  yes">  boss as well. If you want something - a resource, a schedule extension, or even time off - put your arguments in cogent English, not in some personal extensions of the C standard.

 Too many developers use talking as a way to obscure communication. Instead of a concise problem description they start off with a review of header files, interrupt masks, and all sorts of details presented in a random sequence guaranteed to confuse the most savvy of listeners. In my opinion this indicates poor critical thinking skills and an inability to parse the unimportant from the important.

 Recognize that if boss works more with profit and loss than ones and zeroes you'll have to talk in terms of finance, not engineering. Return on investment, depreciation, and the like does in fact rule our lives, so expressing problems and solutions in those terms - when possible - is surely healthy.

 We can't open a paper without reading about the communications age. The constant harping about communications by those who least understand it drives me nuts. Yet I do find it ironic that we engineers who invented the technology of communication all too often have no idea how to use these mechanisms effectively.

 Once upon a time we could work in relative isolation from the rest of the organization. No more. We're talking to customers, managers, peers and the press all of the time, electronically and verbally. This suggests that one of the most important talents everyone needs, techie and boss alike, is effective communication and persuasion skills.

 I tell engineers who have trouble forming their thoughts into coherent English to study communication as they did calculus. Take a Dale Carnegie class. Go to ToastMasters. Learn to persuade and explain, as good communication is a skill you'll use in every phase of your life.

Training

Ultimately both boss and employee must recognize their individual differences, strengths and weaknesses. Just as the wise supervisor is always subtly training his subordinates to move up, those workers should be teaching him the important parts of their jobs. Not that the boss needs to learn to write C code! Instead, we must teach him how his decisions effect the product development effort.

 One example is scheduling. How often has your boss asked for an off-the-cuff estimate to incorporate an enhancement in a product? There's always pressure to respond immediately, yet we know that any such answer will, in general, be meaningless.

 When building a new design we know that a schedule based on a day, or even a week, or design work will be worthless. Until you understand the scope of the project in excruciating detail you simply can't create a valid estimate.

 You can, though, produce a range of dates based on your understanding of the system's scope. It's better to give a plus/minus number, backed up by a written though perhaps brief spec, than to toss off a simple "oh, about 6 months, I guess".

 Maybe this means sitting down with your supervisor from time to time to show him how casual scheduling leads to failure. Give him succinct, concise data extracted from books and studies. Give the meat, not the filler; digest the information rather than load up his desk with massive tomes.

 It also means taking data yourself. When you do cave to pressure and produce that system design in an afternoon, show him later how much the system grew as a real design evolved.

 Teach the boss how he cannot count on heroics to save every schedule. Show how heroics, though occasionally a useful management tool, fail when used as the general solution to late projects.

 Show him that he's crippling productivity by imprisoning developers in noisy cubicles with no privacy. Give him alternatives (like working at home a day or two a week, enforcing quiet times, and removing distractions).

 Bugs that appear late in the project drive managers berserk, yet all too often these are the same managers who chant "why aren't you writing code" from the outset of the program. Educate everyone, including your boss, that bugs will be maximized by skipping the thoughtful up-front work like code inspections and careful design. 

Above all, teach him the real cost of code. Firmware is the most expensive thing in the universe. Study after study shows that commercial code, in all of the realities of its undocumented chaos, costs $15 to $30 per line. A lousy 1000 lines of code - and it's hard to do much in a thousand lines - has a very real cost of perhaps $30,000. The old saw "it's only a software change" is equivalent to "it's only a brick of gold bullion".

 The cost of code also illustrates why every manager should look at every requirements document and brutally strip out features. Too many specs look like the Federal Budget, with features added by every customer and marketing weenie. Lots of features equals slow progress and expensive development.

Conclusion

Dilbert depicts the worst of dysfunctional management, and in so doing encourages us to laugh at all bosses. The comic is great fun but, by making a parody of the boss-employee relationship, further polarizes development groups into "us versus them" mentalities.

 We do need bosses - at least good ones, who understand our challenges in a meaningful way, and who provide us with appropriate resources and guidance. We've got to recognize that the boss/employee relationship is one fraught with tension and change, that the boss's needs and pressures may not always coincide with ours. The resulting give and take can be either a nightmarish struggle or a recognized part of being employed.

 If you're a frustrated employee today, recognize that someday you may be on the other side of the fence, faced with a higher level boss who cares about nothing but getting the product out and making a profit. How will you balance that pressure against the demands of your developers?