Since 1978, Seagate Technology has been creating precision-engineered data storage technologies that deliver superior capacity, speed, safety, and performance. Teh joined Segate in 1992, since then he has held several leadership roles in Global Sales, Marketing & Sales Operation, and more than anything he has a vivid interest in Storage, Data Science, IoT, and AI.

As a project manager, I am expected to lead and motivate a team, stay two steps ahead and break down barriers. I must position myself at the center of the project and be the go-to person for answers. I need to be the leader who gains and maintains control of the project team. If I were on a stage, the spotlight should be shining on me.

This view of the project manager as a ruler is attractive and oftentimes expected because all too many technology project teams face what Edward Yourdan, a pioneer in software engineering methodology, called “the project death march.” In short, many technology projects are destined to fail because of unrealistic expectations in schedule and scope. Who is better to lead a project team on a death march than a ruler?

 A truly successful technology project manager is not one who can lead on a death march but one who, through early team engagement, avoids that trap.

A project manager should indeed put himself at the center of the project, but that center spot is not that of the lead actor; it is that of the lead communicator. A more precise description might be the stage manager who knows where and when to point the spotlight and turn up the microphone for the right player at the right time.

For project managers, the instinct to grab the ruler position frequently starts even before a project is awarded. It is standard practice for a project manager and a sales person to have many conversations with a customer about a new project, long before any other team members, who will actually do the work, hear anything about the project.

The customer, excited about the prospect of having key business challenges solved with this project, is willing to wax eloquently for long periods and discuss the challenges, stakeholders, competitors and required features.

After several of these conversations, the customer, thinking they have told everything there is to know, abruptly shifts the conversation and asks, “Ok, how long is it going to take and how much will it cost?” Then you, the project manager, and your sales colleague agree to get back to the customer in a ridiculously short period of time with a proposal.

At this point, with a good chance the project is going to turn into reality and with the sales person thinking about their next prospect, it is on you. You are now being relied upon to deliver, and the project team, the people who actually do the work, are still on the sidelines. It is time to gear up for a long march.

Project management leadership is about paving the way early for the talents and expertise of your team to be seen by the customer, and for your team to directly hear the customer’s challenges and really understand what they are trying to achieve. It is your role to setup and manage the environment so these high-value interactions, which can make or break a team’s understanding of a project, take place early and often. You are the stage manager for your team and they are the talented players.

Imagine a conversation between just you and your customer where they are sharing an idea to significantly improve the functionality of their app. As you both think about the possibilities, neither of you consider the need to set up a complex, automated testing environment in order to ensure quality at launch. You leave your customer excited about the new functionality without any idea of the testing required at the back end to make it a reality. Several months into the project when QA really gets moving, you then tell the customer about the complicated testing required. They are less than pleased.

Instead, picture this-your customer is telling your project team about their app upgrade idea. After the customer completes their thought, a normally quiet QA engineer clearly restates the enhancement idea and also points out all the testing scenarios it will lead to. Instead of being surprised and upset by the complicated testing because they learned about it at the end of the project, the customer is pleased with the engineer’s foresight, and expectations are properly set before one line of code is written. Your customer understood the implications early because your team member had a voice early.

By giving your QA engineer that voice, you are giving your customer faith in your team’s ability, uncovering hidden requirements that could lead to a death march later and also ensuring your QA engineer has some skin in the game. That engineer, who is now known and respected by the customer will have much more incentive to work hard and succeed. Their good idea was recognized publicly by the customer and team. They won’t fail.

The right way to lead your project is not as a ruler taking your team on a march, but instead by setting up a collaborative environment where clients can witness the expertise of your team. It is your job to ensure your team hears directly from the client about what they are trying to achieve. This type of collaboration gives your client more insight, faith and trust in the team and it puts both parties on a path toward success, not a march toward failure.