How to retain IT talent with goal alignment

Back in 1990, I was hired by the principals of a start-up company (Pages Software) to build an engineering team from scratch to create a new product: a design-oriented word processor. For more than a year and a half, I acted both as head of engineering and as chief software architect — a dual role that I have recommended against ever since, because it kept me from doing either as well as I would have liked.

It didn’t help that I hired the brightest engineers I could find, since I had to deal with the resulting clashes of egos. I’m not sure that the team would have held together very long were it not for one of the engineers, Rick Gessner, who had training in conflict management.

At my request, Rick held a series of meetings to teach the team how to talk with, and disagree with, one another without getting personal and hostile. For the most part, it worked. Once we landed venture funding, we hired an outstanding vice president of engineering, Jim Hamerly, who took the project management burden off my shoulders.

But that’s not what this column is about.

You see, once Rick had put out that first fire, I had another one to fight, albeit a fire that smoldered more slowly. This was the early 1990s, and the tech industry was starting to heat up again after the First Tech Crash of 1988-1989. I had hired eight or so hand-picked software engineers to build a software product from scratch; the majority of them had relocated from elsewhere to San Diego, where the firm was located.

It was the start of what would be a three-year grind to bring the product to market. The question was: How could Jim and I hold onto these engineers throughout the long, tough development period, particularly when they started getting offers to go elsewhere?

Well, there were a lot of things we did, many of which are common industry practice. But there’s one thing that we did that I haven’t seen elsewhere, so I think it’s worth bringing up.

I took the software engineers to a day-long off-site meeting at a coastal hotel. It was a comfortable setting, away from the office and the rest of the Pages employees. It was also the first substantial discussion we had about our personal goals, that is, what each of us hoped to gain or achieve personally by working at Pages.

The answers covered a broad range: from professional curiosity, to working on a cool project, to having a steady (if demanding) job, to hoping to strike it rich with a major IPO. We listed the answers on a large whiteboard and kept at it until everyone felt that his or her goals were fairly represented.

Our next discussion was about what goals we should have as an engineering team to support all those personal goals. This was the longest and perhaps the most interesting discussion for a couple of reasons. First, it allowed the engineers to actually develop the team’s goals, rather than simply have them mandated by me, Jim, or our CEO Larry Spelhaug.

Second, it allowed us to shape those team goals to support all our personal goals. In other words, each of us could see a direct correlation between his or her personal goals and the agreed-upon team goals. Conversely, by committing as a team to these goals, we were also committing to help each engineer with his or her personal goals.

Our subsequent discussion covered what the existing Pages company-wide objectives were and how they tied into our team goals. In other words, why is our company’s success important for achieving both our team goals and our personal goals? Identifying this question was, I think, the most critical step.

It is easy — particularly during a long, hard development effort — for IT engineers to begin to view upper management and the rest of the company as adversaries. But, now, all the engineers could see a direct path from their personal goals to the team goals to the company goals.

We repeated this exercise each year until Pages closed its doors. It is, I think, a major reason why we had zero voluntary turnover among our software engineers during the five years of Pages’ existence.

Too many organizations think of IT engineers as interchangeable parts, not realizing just how much technical knowledge and expertise specific to the organization is lost when an experienced engineer departs. If too many of your best engineers leave, then you risk having your IT department succumb to the Dead Sea Effect, that is, being left primarily with the least talented and least effective engineers. It is worth expending a relatively small amount of time and effort to work with your IT engineers in order to discover how to align their personal goals with your IT and organizational goals.

[Adapted from an article originally written for the online version of Baseline.]

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.