Five business lessons for engineers

At this year's TI:GER workshop, the most directly relevant talk was that by Ikhlaq Sidhu of UC Berkeley’s College of Engineering. Dr. Sidhu is an adjunct professor in the industrial engineering department and Director of the Center for Entrepreneurship & Technology.

Like most of the speakers, he talked about what his school has done in technology management education — in this case, 900 students taking 9 courses and/or involved in the VentureLab program. (The previous speaker, Ted Sichelman of the Berkeley law school, had enumerated the various interdisciplinary technology efforts across seven colleges at Cal).

As Sidhu explained his program, one figure jumped out at me — the supporting cast of 600 Silicon Valley professionals that get involved in the center’s programs. With names like Judy Estrin (former CTO of Cisco), such a supply would be impossible to find (let alone engage) anywhere outside Berkeley or Stanford (or maybe MIT or Harvard).

However, what I found most remarkable (i.e. worth remarking on) in his talk was a recap from the presentation he developed for last year’s workshop. Specifically, he identified five skills that today’s engineers need:

1. To know what problem is worth solving
2. To know how to acquire resources
3. To be able to communicate
4. To know how to work within and build global virtual teams
5. To be leaders in a global economy — not commoditized contributors.

This list is now driving Berkeley’s vision of how it trains engineers.

I personally found the list compelling for three reasons. First, all five relate directly or indirectly to business issues, not the technical side of engineering. That these are hard problems is exactly why I became a business professor (rather than taking the shorter path into C.S.)

Second, the list resonates with my 15 years at Palomar Software. While global teams are recent (and a bit of a fad), the other four are the issues that my cofounder and I — two engineers in a garage — confronted when running our software company 20 years ago. Neil and I were both above average communicators, but the accuracy, precision and completeness of communication by our staff was an ongoing challenge. While Palomar eventually found problems worth solving (that were not commoditized until 2001), during the first 7 years our choices were severely constrained by lack of resources.

(In 2000-2002, when we were working with HP and its other onshore and offshore printer driver development partners, we had to confront the global teams issue, complete with 8 p.m. PST teleconferences to Bangalore).

Finally, commoditization is an issue that’s been a central theme of my Silicon Valley-oriented blog. If technology is a commodity, it will be done in India, China, or wherever the cheapest location is this year: the only economic reason to train and employ American engineers is to create value that can’t be created elsewhere.