The Machiavellian Engineer

Sometimes it takes more than technical prowess to get the job done

3 min read

I set up the meeting in order to set up Ron.

It was a rare time in my career when I intentionally used power and politics to solve a problem—a Machiavellian approach I didn’t learn in engineering school. Ron, my coproject manager, was jeopardizing the project. He was uninterested, his time was divided among the other things on his plate, he wasn’t getting his tasks done. He had to go.

The project involved showing information and entertainment on TV monitors viewed by passengers awaiting departures at New York and New Jersey airports. As a business concession, it proved very popular, like airport stores and food services. The team assigned to the project was responsible for installing TV monitors in the terminals, overseeing the programming, and accounting for advertising revenues from the three busy airports in our domain.

In my role in the business development area, I initiated and launched the project as part of a larger network of airports around the United States, and I was ready to lead the operation. However, our customer services division naturally wanted one of its managers to play an equal role. To avoid a turf battle over boundaries and credit, the heads of our departments decided to have Ron and I be comanagers for the first year.

Over the course of that first year, I produced monthly reports with grudging input from Ron. I would itemize the growing number of installations and the revenues received. Time and again, Ron’s deliverables, such as current passenger levels and other information specific to our airports, were delayed. These delays were noted to management, to the point where Ron wanted to stop doing reports on a monthly basis.

As we neared the one-year mark, I told my manager we needed to address this problem in the working relationship. I was willing to run the entire program—which was the original intent—but Ron was not agreeable, and my manager didn’t want to confront the problem directly: ”Can’t you just get along?” So I took matters into my own hands.

Step one: I asked Ron’s manager, Joan, if she’d like a briefing on first-year operations. She welcomed this, so I set up a meeting for just the three of us, to minimize the number of people who had to learn of Ron’s shortcomings.

Step two: I prepared a simple agenda that Ron approved. I would go first, presenting my areas—the overall administration of the business agreement and installation of the TV monitors, both of which were going well. Then Ron would discuss his areas. The last item on the agenda was to identify any issues that needed to be resolved.

Step three: We held the informal meeting in Joan’s office. I gave my briefing and answered her several questions. Then it was Ron’s turn. Despite the passage of a year, several key items he was responsible for were still delayed. Not all the delays were his fault, but they seemed to surprise Joan—and managers don’t like surprises. She asked Ron increasingly pointed questions: ”Why was this being delayed?” Why didn’t you tell me there was a problem?” She was not happy with his excuses. I sat quietly. Joan finally turned to me and said, ”Carl, I think Ron and I need to talk about this, so if you’ll excuse us, I’ll get back to you.”

The very next day my manager and I got a short e-mail from Joan asking me to take over the project with their continued support. Ron stayed involved and was more effective in his limited support role.

Projects usually run better that way. Sometimes it makes sense for two people to share leadership—if the responsibilities neatly divide into two areas that don’t overlap, for example, or if neither person has the time or resources to take full charge. But often it doesn’t work—especially, as in this case, when a bureaucracy simply wants to protect or extend its turf. At times like that, it takes politics and power, as well as technical expertise, to get things done. Do what you have to do. To paraphrase Machiavelli, you don’t avoid such a war; you merely postpone it to your own disadvantage.

This article is for IEEE members only. Join IEEE to access our full archive.

Join the world’s largest professional organization devoted to engineering and applied sciences and get access to all of Spectrum’s articles, podcasts, and special reports. Learn more →

If you're already an IEEE member, please sign in to continue reading.

Membership includes:

  • Get unlimited access to IEEE Spectrum content
  • Follow your favorite topics to create a personalized feed of IEEE Spectrum content
  • Save Spectrum articles to read later
  • Network with other technology professionals
  • Establish a professional profile
  • Create a group to share and collaborate on projects
  • Discover IEEE events and activities
  • Join and participate in discussions