In a survey of communication problems across 34 Engineering and IT projects the following five categories accounted for practically all of the communication breakdowns and confusions that affected project delivery schedules or costs.   Do any of these sound familiar from your experience?

• Assurances Problems
• Meanings of Goals Poorly Defined
• Hidden Information
• Micro Management / Under Feedback
• Why don’t they care like I do?

In the previous post in this series we learned a couple of questions that help you explore and possibly challenge rules and standards that may keep your work from being a productive as it should be.   Of course, there are often good reasons for rules.  And standards are the heart and foundation for great leadership.  But you must understand them with perfect clarity to make sure your team is really doing the right thing for the right reasons.

In this post, we tackle another of the most common leadership problems that people making the transition from individual contributor to leader so often make — over-management and under-management.  It is important to use the right approach at the right time.

The quality of the results your team will produce depends upon the quality of your communication, both your communications with others and your communication within yourself.  If you miscommunicate with others it will obviously create problems.  But if you miscommunicate with yourself these mistakes can be even harder to recognize.

The most common form of miscommunication with yourself occurs when you confuse the “what” of a project with the “how.”

Let me explain.  To accomplish any goal, a team needs to understand both what they are trying to achieve and how to perform the activities that will create those results.  Taking various resources from some “current state” at the beginning of the process to the “desired goal state” at the end of the process constitutes a set of procedures for transforming resources into a finished work-product.

Engineering leaders often assume that it is obvious to their junior team members how to best accomplish this transformation.  But it may not be obvious to the rookie team member.

The opposite assumption is is perhaps even more dangerous.

New leaders commonly make the mistake of assuming that their team members do not know how to create the appropriate transformation in the most efficient manner.  The manager may think, “I know how to do this, it would be easier if I just did the work myself.”  But that would be a mistake because a leader is no longer being paid for his or her individual performance, rather his leadership role calls for him to coordinate other people’s  efforts.  If a manager did all the work herself, she could never accomplish everything her team should be able to accomplish.

But presuming to tell your people how to do their work is insulting, disempowering, and demotivating if they already know how to accomplish those tasks in a way that produces at at least the minimally acceptable level of quality in a reasonable amount of time, with an acceptable level of materials and at an acceptable level of waste.   So managers must walk a fine balance between telling a subordinate too much about how to do their work and not explaining to them in enough detail exactly what will constitute acceptable accomplishment of work-product requirements.

Number 2:  What vs How      

Engineering, Science, and IT project leaders do not always recognize when it is appropriate to define the process, the “how things should be done,” that will move the project from current state to desired state versus when to only define the target work-product or goal, the “what should be done.”

This issue creates communication problems either by the team not getting enough feedback on a regular enough basis, or conversely, by the leader tending to overly micromanage their staff which generates hard feelings that create ego issues that disrupt clean communication across the team.

Recommended Solutions:  Leaders must assess the capability and maturity of their team members by chunking the project into very small sub-tasks that are less critical, and then assigning these with early deadlines to see how well staff can handle them.

This also provides the advantage that team members get to practice working together quickly and repeatedly on pieces that are typically not yet on the critical path.  This is one foundation of the latest iterative development approaches like Scrum and Agile project strategies in software development.   But they are generally applicable to many types of engineering projects.  To use this strategy effectively, you will have to build in ramp-up time to make this happen, which means you must be able to negotiate these time requirements with your customers and management.

The basic strategy is that your most highly capable staff should be facilitated to define and review the target work-product deliverables, the “what,” in detail.  But rookie staff can benefit from defining both the end goal work-product, the “what,” as well as the process by which they will move from current state to desired state, the “how.”

Review cycle timing for work-products should be defined according to the capability maturity of the individual, not based upon a single standard for the whole team.  Otherwise junior staff will never get the feedback that they need to learn how to be their best.  Additionally, mature staff who are over managed will tend to begin to disengage from controlling their own efforts and provide only the minimal production and quality that they can get away with.

The guiding principle is to over manage beginners.  Then as they prove their capability and responsibility to manage themselves, move toward less management control and more autonomy.  It seems obvious, but many new leaders who come to management from technical, science, and engineering often don’t remember to differentiate between the how and the what of work tasks.

Next time, in the final installment of this series, we will look at how miscommunication can lead you to believe that everybody else around you doesn’t care as much as you do.  Why can’t people just be more committed, like you are?  Then wouldn’t everything work a lot better?

 

Previous In Series  ◄     ►  Next in the Series