Foreword — This speech discusses career survival strategies for embedded systems engineers. It was delivered by Wind River CEO Ken Klein as a keynote address at the 2005 Embedded Systems Conference in San Francisco. Enjoy . . . !

---

Hello and thank you for coming.

Today I want to share my perspectives with you. I'm one of those guys who sits in a board room and obsesses everyday over the bottom line. You're an engineer or engineering manager in the developer trenches. Everyday you contend with big technology challenges, growing complexity, and daunting deadlines.

Believe it or not, we are joined at the hip. If people like me don't do our jobs well, engineers like you will fail miserably. But if you don't do your job well — I mean faster, more efficiently, and with a high level of innovation and differentiation — we're toast.

The first thing I want to know is, how many of you in the audience actually are engineers? Let's have a show of hands.

How many of you manage other engineers?

That's right. I'm an engineer myself, a EE. Last time I looked, I have in the neighborhood of 500 engineers around the world who report to somebody who reports to me.

And I'm here to tell you, the work life we engineers expected to have when we got out of school, even the one we had five years ago is nothing like the reality we live and work in now, especially in the embedded industry.

What's changed?

First of all, applications are increasing in complexity at an almost unbelievable rate. Today's average embedded application consists of a million lines of code. With increased market demands for security, connectivity and performance, application size is now doubling every two years. If there ever was a simple time when you got yourself a proprietary real time operating system and a few tools to use with it, it's gone for good.

There is nothing simple about the development you do.

And — forgive me for being candid — there's every indication that much of the time, we really don't do it very well.

• More than half of embedded designs are completed 3-4 months behind schedule
• A third of them don't meet basic performance requirements
• 24 percent — nearly a quarter — get cancelled
• Of the ones that actually make it to market, two thirds are over budget, often way over budget.

Believe me, that's the kind of statistic that gets a lot of attention in the board room — not the good kind, either.

The second factor that bears on your job security and job satisfaction is the market itself. While the desktop market stagnates, the embedded market is burgeoning. From a consumer point of view, devices that were once novelties are now necessities. And in other markets — industrial, network infrastructure, telematics, A&D — device software is expanding.

Five years from now, over fourteen billion intelligent devices will be connected in ways we can't even imagine. In terms of market opportunity, that's huge. But as the statistics I just cited show, in embedded development, there is no low hanging fruit.

On the one hand, huge opportunity. On the other, great inefficiency and complexity. Together, these add up to pressure — enormous pressure, for both the executive and the engineer.

Now, just to make things interesting, let's add the recession we've just been through. Even as we rebuild our businesses in the wake of the downturn, our engineering staffs are smaller than they were. Nortel, for example, is about 60 percent lighter in the engineering department than they used to be. Throughout the industry, we've experienced huge layoffs and hiring freezes in the last few years. Today we expect — no, we demand — that fewer developers do more, faster, with fewer resources.

In the industry at large, these pressures have moved us toward consolidation. We are no longer engaged in a war of midgets. It's no longer about proprietary mom and pop tools duking it out for a piece of a small, tactical market. To survive and to thrive today, companies like mine — and like yours — have taken decisions that impact productivity and cost away from the engineers and handed them over to guys with capital C's in their job titles — CEO, CFO, CTO.

These guys don't choose a chip because it's cool. They choose it because it's the cheapest one that will do the job. They don't want to buy a lot of different chips, they want the one chip that works for every project and every team. Same with boards.

The engineering team thinks about things in terms of the project at hand. The C-team thinks about the COGS, the ROI, the stock price, the bottom line.

From that perspective, several things become self evident.

• Standardization of tools and processes within and across projects is good.
• Being able to reuse IP and leverage assets is good.
• Being able to take advantage of open source and open standards is good.
• Being able to concentrate engineering brainpower at the application level is good.

The other thing about us C-guys is this — even though we're in an inherently risky business, we're fundamentally risk averse. Anything we can do to protect corporate investments and control outcomes, sign us up. Our jobs depend on it. And your jobs depend on ours.

We are in this together.

Fail to embrace these realities, my friends — and we're toast.

It's 2005. Is your job safe? Is it satisfying? Are you relevant?

Okay, now that I've got your attention, let me give you five simple suggestions about how to establish and maintain your viability in the workplace, how to avoid becoming one of those flat furry blobs left on the shoulder of the freeway as Monday morning traffic rushes by in the fast lane. How do you avoid becoming roadkill?

One. Get over Do It Yourself.

You're developers. I know that means you're problem solvers and pattern matchers. I know that means you love cooking up your own particular ways of doing things. You love thinking your code is better than somebody else's code. Given the choice between some COTS solution and one you thought up yourself — no contest, right?

Absolutely wrong.

The work you do today is simply much too complex and much too critical for you to spend precious bandwidth reinventing the wheel, much less keeping the wheel greased and balanced. You cannot afford to put your effort into one-off solutions that only you or your small group knows how to use.

They're too risky. They're too time consuming. They don't play well with others. They don't travel.

If you want to be a hero, concentrate your attention on innovating at the application layer. This is the level at which your company's product distinguishes itself from all the other, similar products in the marketplace- where it maintains it's competitive edge.

When you contribute to differentiated value, you're also differentiating yourself. You become visible and invaluable instead of out of date, cranky, quaint.

No more trying to do it all yourself.

Two: Share.

There's a romantic cultural myth about the engineer as loner.

Wrong again.

The ideal work environment is the engineering team as a neural network, where information, skills and tools are shared freely and not hoarded. This piece of advice is essential to your job satisfaction, to your individual productivity and to the success of your company. The days of Me and Mine are passing.

The Linux and Open Source communities are today's perfect expression of what I believe is the correct paradigm. While the key contributors may well be quintessential loner geeks, they are loner geeks who share. And that makes all the difference.

I believe in this profoundly. So does my company.

We believe in this so wholeheartedly that last night we announced that we will lead the Eclipse Device Software Development Platform Project.

This is the first project specifically for device software development within the Eclipse Foundation, a community committed to the implementation of a universal platform for tools integration.

We are collaborating on this initiative not only with partners, but also with some of our biggest competitors. Why? Because it's the right thing to do.

There is power in numbers. There is power in standardization. There is power in collaboration. What you build upon the work of others reaches higher than what you create all by yourself.

Share.

Three: Do not take change personally.

These are the days of hard realities and fundamental changes. A lot of things you once held dear may well try to bite you in the backside.

If you take these changes personally, you'll not only be really unhappy, you may well be looking for another job.

Instead of resisting operating system choice and commercialization of the middleware, say thank you and start differentiating.

Instead of being threatened by outsourcing, figure out what you can trust contractors to do and learn to manage them effectively.

Instead of being tribal with other developers, other teams, even other companies–be ecumenical.

Finally, don't think of yourself as an employee, think of yourself as an entrepreneur. Don't be passive aggressive. Be aggressive. Seize the opportunities that come your way.

By embracing your company's success, you will ensure your own.

Four: Manage up.

In a time of chronic and deliberate understaffing, too many engineers are working so hard, so constantly and so reactively that they have little or no blue-sky time. But every one of you needs time to think about what you're doing, what you want to do and how you could be doing things better.

When you do see something that's broken or potentially improves team productivity,

whether those arise at the level of tools, technologies or processes, you need to pass that information on up the food chain. If you see solutions, you need to propose them, gain support for them, help your managers sell and implement them with their superiors.

The people in the boardroom have one view and you have another. We have metrics that point to dysfunctions in the development process. You have insight into the accumulation of specific factors that create the dysfunctions.

Closing the information loop between the executive level and the engineering team makes it possible to identify and evaluate solutions. It helps you get the technology you need.

It helps us get the results we need.

It's true that we all need something to bitch about. That's human nature. But if you want to be successful today, bitch about the crappy GUI on the debugger, not about your manager. Him or her- you want to manage and make successful

Success is all about goals understood and shared, top down and bottom up.

Manage your managers.

Five. Just say yes.

If you tie your professional identity and your professional worth to a particular technology, I can guarantee you that the next bus in the carpool lane is going to run you down. Splat. End of story.

To be desirable, here's what you need to do:

Be flexible. Be plugged in. Be up to date. Be ready to jump to the next new thing.

When someone asks, can you move over to the Linux group? or the wireless group? or the device software management group? your answer should be yes, — without hesitation.

A desirable engineer knows how to learn. A desirable engineer knows how to effectively integrate new skills with past experience.

This appetite for growth and change is not only what keeps the job interesting, it's what makes you a strategic differentiator in your company, not a commodity.

Free yourself from technology loyalties, even from brand loyalties. Start to think of yourself as the unique hunk of intellectual property you really are.

Invest your energy and acumen in creating the applications that make your company's product stand head and shoulders above the competition.

In sum, my survival tips are these:

Stop doing it yourself. Share. Don't personalize change. Manage your managers. Just say yes.

If you do all these things most of the time, or most of them all the time, I believe you'll not only survive the big and tricky shifts taking place in our industry, you'll thrive in the new industry analysts are calling DSO.

Device Software Optimization.

Technology loves acronyms, right? But this one is particularly useful for naming the maturation of a technology market.

'Embedded' software is not only invisible, since it resides inside something else, it's incidental to the value of the product it lives inside.

Call it “device software,” though, and you're talking about the brains of the product, what makes it not just perform, but stand apart.

Analysts describe “embedded” as a $750M market with sluggish growth. The DSO market, by contrast, is headed toward 3 billion dollars a year — FAST. That market — exciting, burgeoning, ubiquitous — is the one where our shared future lies.

Optimization? Doing it better. Faster. At lower cost. With less pain. That, ultimately, is the goal of the three-legged race we're engaged in — me with my spreadsheet, you at the system viewer. We're trying to shape the future, not get run over by it.

If we work together, I believe we will prevail.

Enjoy your journey on the road to DSO

Thank you.

---

About the speaker — Ken Klein is president, CEO, and chairman of the board of Wind River Systems. Klein holds a B.S. in electrical engineering and biomedical engineering from the University of Southern California. He also serves on the board of Tumbleweed Communications and is a member of the USC, School of Engineering, Board of Councilors.

---

Talk back!

---

Do you have questions or comments about this article?

Talkback here!

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.