The Flight Risk of GenX Engineers

This series of posts covers a number of issues related to the differences in generations specifically in engineering organizations. Today’s post looks at the mindset of Gen X’ers and puts it into the context of today’s engineering organizations. The conclusion is that, without some HR changes, the Gen X engineer may become a rare natural resource in the workforce.

Remember when the term ‘Gen X’ was coined? For me, I first remember hearing about it when the grunge music scene was emerging from Seattle in the early 90’s. As part of that generation, I remember we were young and cool. But over the past twenty years, lots has changed.

To get some perspective on what the Gen X mindset looks like in a professional environment, I’m going to turn back to Tammy Erickson at the Harvard Business Review (HBR) again. Across a lot of blog posts and publications, things aren’t so mixed bag for Gen X. They’re sandwiched between two much larger (in terms of volume) generational cohorts, the Boomers and Gen Y, leading to a lot of dissatisfaction. However, they exhibit the sort of characteristics that engineering organizations need the most right now to bolster economic recovery through new product development. Here’s a quick excerpt from one post, Career Advice for Generation X, that puts it pretty succinctly.

The dissatisfaction is easy to see. You stepped out of university when the economy was slow, and the Boomers already had a death grip on all the good positions before your job search even started. Now, just as Boomers are preparing to retire (to second careers, most likely) and the top slots seemed poised to open up, the economy is weak again. Not to mention, you’re facing competition from the very people you’re managing–Gen Y workers outnumber you, seem to enjoy better mentoring relationships with your Boomer supervisors, and frustrate you with their penchant for playing loose and fast with protocol and company norms.

But corporations really do need you. Your skills, passions, and talents are well-suited to the challenges of business today. As a generation of latch-key kids, you bring self-reliance, resourcefulness, and a certain measure of seriousness to the table. As the children of civil and women’s rights protesters, you are sensitive to multicultural issues and tolerant of diversity. As the consumers and creators of the DIY ethic (punk and alternative music and art), you are entrepreneurial and unconventional — traits that are critical for growing organizations.

For those of you wanting more context from Tammy at HBR, here’s more posts related to Gen X and their plight: Thanks to Gen Xers for the Reality Check, Why Generation X Has the Leaders We Need Now and Stuck in the Middle: How Generation X Can Survive the Boomer- Gen Y Love Fest, 10 Reasons Gen Xers Are Unhappy at Work.

Now you might ask yourself: so what? How is this related to engineering? Well, here’s the problem. If you remember from the last post in this series on The Braindrain Threat from Boomer Engineer Retirement, there’s already a going to be a shortage of senior engineering staff when the Boomers do eventually decide to retire. Sooner or later, even though they are the smallest generational cohort in engineering, those from Gen X will be the senior technical leaders in your engineering organization. High levels of dissatisfaction lead to edgy employees looking for the first real opportunity to leave the organization. I’ve actually heard it first hand time and time again. And with the economy officially over and some other engineering organizations looking to hire again, that opportunity might be more available than you think. Combine the dissatisfaction with new job opportunities related to the recovery and you might lose the most senior engineers that are queued up behind the boomers. Suddenly, you could find that the most senior engineering staff in the company are Gen Y engineers or new hire Gen X engineers you just desperately hired yourself. That’s the last thing you need to drive a recovery off new product development.

What do you do about it? In addition to good context, Tammy Erickson offers some good advice too (Career Decisions and Generation X). But it’s the touchy-feely stuff that is infrequently associated with engineering organizations. But I’d advise serious consideration of changes just like these to hold on to what might well become a rare natural resource in the workforce: the Gen X engineer.

Take care. Talk soon. And thanks for reading.

The ‘Value-Add Qualifier’ Principle

How much of your day is spent adding engineering value to your development projects? Think about it for a minute. All that email. That huge list of issues you track in a spreadsheet. Running across the office with those forms because you heard the engineering director finally came out of that meeting. Let’s face it, there’s a lot of non-value added work that goes on every day in the engineering office. In our last post on the hero work of an engineer, we talked about how to use the ‘Get It Right the First Time’ principle to avoid letting product issues get downstream, where they come back as firedrills to blow up your desk. In this post though, we’re going to focus on how to identify non-value add work and then how to avoid it if at all possible. To what end? Well, if you can cut down on the product issues that get downstream and eliminate some of the non-value added work, then your work day can get a lot more normal. To start off, what do I mean by non-value added activities in engineering? First, let me outline the different types of activities in the engineering organization during the design phase of the development cycle.

  • Authoring: This group of activities covers the creation of traditional engineering deliverables such as specifications, drawings and models.
  • Decision Making: This category of activities addresses meetings and discussions amongst the team or individuals to make engineering decisions.
  • Issue Resolution: This set of activities includes the myriad of product issues that arise during the design process that must be resolved to move forward.
  • Governance and Oversight: These activities provide visibility into the status of the development project so corrective action can be taken as necessary to stay on-budget and on-schedule.

So are any of these categories of activities non-value added? My answer is a definitive ‘no’. These types of activities are necessary to run a successful development project. However, the depth to which you go in each of these categories can be too far, thereby expending time and effort on activities that are not absolutely necessary. Another area to consider is the effort required to track and monitor these activities. For example, one could track product issues in spreadsheets amongst a team or in a centralized system that acts as a source of truth. The manual effort required to reconcile and propagate change in the spreadsheets in the team is unnecessary compared the use of an centralized system where change is automatically managed. To wrap for today, I think there’s two questions to consider.

  1. What other areas of non-value activities have you seen in your engineering organization?
  2. What steps do you take to avoid them?

I’ll be back next week to summarize the discussion and add some final thoughts. Take care. Talk soon. And thanks for reading.

General / Books

What is ‘The Goal’ for Engineering?

Cleaning out the closet the other day, I came across an old favorite book of mine called The Goal (wikipedia entry). I read it a couple of years after coming out of engineering school to get a little perspective on the business side of manufacturing.

Now there’s a lot to this book, but fundamentally I remember it for something the author, Dr. Eliyahu Goldratt coined as the Theory of Constraints (wikipedia entry). Here’s an excerpt from the wikipedia definition.

Theory of Constraints (TOC) is an overall management philosophy introduced by Dr. Eliyahu M. Goldratt in his 1984 book titled The Goal, that is geared to help organizations continually achieve their goal. The title comes from the contention that any manageable system is limited in achieving more of its goal by a very small number of constraints, and that there is always at least one constraint. The TOC process seeks to identify the constraint and restructure the rest of the organization around it, through the use of the Five Focusing Steps.

Sounds dry, I know. But the brilliant context of the book is that the protagonist, Alex Rogo, is trying to figure out how to keep the plant he runs for a fictional company UniCo Manufacturing from closing. In the case of the plant, the goal of the plant was increased profits. The constraints to that goal were bottlenecks in production as well as sales volumes. Alex ends up tweaking and twisting those bottlenecks to up production as well as bring in more sales at lower margins but huge volumes.

Besides bringing back memories of years ago, I have to admit, this book got me thinking. What’s the analogue of the plant’s goal and constraints in engineering?

I think we all know what engineering does, whether it’s digital or on paper. I think we all know a good amount about the difficulties that the engineering organization faces with layoffs with no falloff in workload. We know a lot about the trends in the engineering organization like globalization and the recession. But finding the analogue of the plant’s goal and constraints might not be as easy as you might think. It certainly wasn’t easy for Alex in the book. At that time, there were all sorts of long-standing and well-known trends and initiatives in manufacturing. However Alex didn’t figure out that profitability was the goal of the plant until halfway through the book. He didn’t figure out that production bottlenecks and sales volumes were constraints until not long after he recognized the goal. So let’s pose the same questions here.

What is the goal of the engineering organization?

What are the constraints limiting the engineering organization from achieving that goal?

What do you think? I’ll post my thoughts in a follow up post next week.

Take care. Talk soon. And thanks for reading.

The ‘Get It Right The First Time’ Principle

Last week, in the post about the engineering minefield and unplanned work, I promised some principles to help with avoiding the 15 hour engineering emergency that blows up your week. The ghist coming out of that discussion was that product issues that proceed downstream eventually make their way back to engineering as unplanned work. That’s when the firedrill lands on your desk. So how do you minimize the firedrills, the unplanned work and the product issues that get downstream?

Get it right the first time.

For those unfamiliar with the concept, the idea is to do things differently prior to design release so product issues never get downstream. As a result, those errors, change orders and issues never turn into firedrills in the first place. Furthermore, it saves other organizations in the company too. Those are errors and change orders that purchasing, quality, manufacturing and legal never spend time on.

Now I know you’ve probably heard about this concept many, many, many times before. It’s been cited so frequently by software providers in the context of their engineering software tools that it’s hard to associate it with anything else. But while technology can be part of the answer, it’s far more than that. What else does it involve?

  • Take More Time Up Front: I know schedules are ridiculously tight. I know you’ve probably got more work than you can handle. But the fundamental concept behind a get it right the first time principle is that you take more time up front to save even more time later. You can’t simply keep the same schedule up front and expect to reap the rewards downstream. That has to be a mantra time and again to management.
  • Procedural / Process Changes and Measurements: Also realize, however, that just doing the same thing slower will only incrementally improve things under a get it right the first time initiative. If you want to catch more product issues before they get downstream, you to change your activities so they can affect that goal in a measurable way.
  • Software is an Enabler, not THE Answer: Engineering software applications and system can go a long way towards enabling this principle. But plugging in a new tool into the same old problematic process won’t result in the changes you want. Don’t get me wrong. Software helps. But it’s an enabler with other changes. Not the endgame answer by itself.

A get it right the first time principle can help a lot. But there are other things you can also do to address problems associated with the engineering hero work issue. Next time, we’ll take a look at non-value-added tasks and how to deal with them.

Take care. Talk soon. And thanks for reading.