Podcast: Play in new window | Download

Subscribe: Apple Podcasts | RSS

In this episode of The Engineering Commons, we discuss the lessons we learned during our first two or three years of working as engineering professionals.

• Adam considers himself a fast learner, although he finds that pain occasionally increases the rapidity of his learning.
• In this episode, Adam, Brian, Carmen, and Jeff discuss lessons learned early in their engineering careers. (The raspy voice belongs to Carmen!)
• Carmen learned that organizational change comes slowly, and requires a consistent and concerted effort to alter behaviors and attitudes.
• It was news to Jeff that technical issues of great concern to him individually could be of such little concern to his employing organization.
• Although Jeff felt he was given a great deal of technical autonomy early in his career, Adam found that his activities were a bit more tightly controlled until he acquired his professional engineering license.
• Carmen discovered his job is largely troubleshooting and experimenting, as he is expected to sort out unexpected system behaviors.
• Robert Erickson’s book, Fundamentals of Power Electronics, is a bit too theoretical for Carmen’s taste.
• Jeff recalls learning that upper-level managers have to make semi-educated guesses about critical business issues such as market size, customer demand, and resource availability.
• Survivorship bias can cause us to overlook conditions and situations that may lead to organizational failure.
• HexBright was a programmable open-source flashlight design that seemed to be a good idea, but was unable to survive long-term as an ongoing business.
• Brian was a fan of the Zune media player, despite its lack of market success.
• One of the best ways to learn quickly, Brian reports, is to chat with others who have substantial experience dealing the technical issues you are trying to understand.
• Jeff discovered that vendors are willing to supply technical information, but they expect reciprocity when purchasing decisions are being made.
• There can be multiple distributors for a particular product in a given region, and Jeff has irritated a few salespeople by buying goods from the “wrong” distributor.
• When meeting with someone who is typically pressed for time, it’s good practice to ask about their availability as soon as your “brief” conversation looks like it might drag out longer than you originally anticipated.
• Be cautious about sharing technical problems, Brian notes, as rumor and fear can quickly spread if technical concerns are evaluated outside of their intended context.
• Whether you like it or not, says Adam, you have to be aware of (and frequently participate in) the political games of your employing organization.
• Jeff notes that answers are rarely found at one’s desk; if you want to learn about a problem, go to the manufacturing floor, or the machine shop, or a customer’s site.
• Brian suggests that, whenever possible, engineers should avoid sending emails. On the other hand, Adam finds email a useful tool for documenting agreements with others.
• Adam finds meetings to be a particularly effective means for arriving at a decision when multiple people need to participate in the process.
• Jeff recommends that young engineers not promise too much, as the desire to please must be balanced by an ability to deliver.
• Loading tests on the Boeing 777 wings illustrate delivering exactly what was promised, says Brian.
• Brian and Adam mention the “rule of pi” for estimating the time and cost of first-time projects, as discussed in this podcast’s very first episode.

Thanks to Pete for the photo titled “Project 366 #233: 200812 A Sense Of Direction.” Podcast theme music by Paul Stevenson.