The Embedded Muse (TEM) isn’t specifically devoted to BIOS, but BIOS (and especially EC developers) will definitely find value in it. TEM contains discussions on topics pertinent to embedded systems developers, product reviews (typically for test equipment), coding tips, job listings, famous quotes, and engineer jokes. Jack also runs a seminar called Better Firmware Faster, which I’ve never attended (sadly) but that my colleagues, who have attended, swear by.
I especially liked a recent article entitled Boss Management from TEM issue #334, which I’ve posted below. I think there’s a lot of wisdom in this article, and it’s worth 4 minutes of your time to read.
You can find out more about Jack and his work at his website, The Ganssle Group. Specifically:
Jack’s bio: http://www.ganssle.com/bio.htm
Jack has written six books: http://www.ganssle.com/book.htm
Jack on Twitter: https://twitter.com/jack_ganssle
Boss Management
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.
A sure way to gain your leader's enmity is to present him with problems and no solutions. Saying "Uh, the flash is full and we're still only halfway done with the code" is simply a form of slow career suicide. You are 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.
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 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.
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 of design work will be worthless. Until you understand the scope of the project in excruciating detail you simply can't create a valid estimate.
And, yes, I understand that agile approaches can be very effective. But the boss may have very good business reasons for needing a ship date before the project is far along. Alas, there is an essential contradiction between management's and engineering's needs when it comes to schedules, one that I believe will never be resolved.
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.
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?
Post a Comment
Be sure to select an account profile (e.g. Google, OpenID, etc.) before typing your comment!