Ask, Don’t Tell; Listen, Don’t Direct

Good leadership requires a balance between getting today’s work done and developing a team’s ability to solve tomorrow’s problems. In this series of practical anecdotes, SMA Principal Associate Dan Harrison draws on decades of engineering, program management, and leadership experience to show how asking the right questions, listening carefully, and resisting the temptation to prescribe every answer can help teams solve difficult problems for themselves. From organizational alignment and cross-functional conflict to risk management, schedule recovery, cost account management, employee development, and competitive benchmarking, the examples share a common theme: leaders still provide direction, but the most effective direction often begins by creating the conditions in which people can understand the problem, take ownership, and act.

1. What Is Meant by “Don’t Tell” and “Don’t Direct”?

As a manager and business leader, of course you will give direction. The point of “Ask, Don’t Tell; Listen, Don’t Direct” is not that leaders should become passive. Leadership requires decisions, priorities, accountability, and direction. It also requires developing employees so they become better able to make decisions and solve problems themselves.

The challenge is finding the right balance. A leader can often get an immediate task completed simply by telling someone exactly what to do. That may be appropriate when circumstances demand it, but it can also deprive the employee of the opportunity to understand the problem, develop judgment, and take ownership of the solution. Asking questions and listening first can expose information the leader does not have, improve the eventual decision, and help the employee grow.

The anecdotes that follow illustrate that balance in very different circumstances. Sometimes management direction is explicit. Just as often, progress comes from asking a question, listening to the answer, bringing the right people together, or helping a team see its problem differently. Recognizing which approach a situation requires is part of the continuing struggle of good leadership.

2. Organizational Alignment

At one of my previous employers, a sister organization in Washington, DC, was having difficulty defining its program tasking and organizational alignment for the coming year. My Models and Simulation Internal Research and Development laboratory had analysis tools that might help, but the connection between our capabilities and their needs was not obvious.

I began with my radar lead engineer. Rather than telling him what support to offer, I asked whether he had spoken with his counterparts in Washington and what tools they might actually be able to use. He had not, so I suggested that he contact them. He returned with a short list of interests but still did not know how our laboratory could support their objectives.

We worked through the list by asking what the sister organization needed to accomplish and what kinds of tools would make that work possible. That forced the discussion away from the products that interested us and toward the problems they needed to solve. The engineer then dug into both organizations’ engineering work and identified areas in which existing or emerging tools could provide useful support.

The result went beyond finding applications for our technology. Together, the organizations defined most of the sister office’s projects for the following year. My lead engineer learned to think beyond his immediate technical responsibilities, the other organization gained clearer objectives, and our laboratory gained opportunities for feedback on new products. Just as important, a previously tense relationship between the two organizations became productive because we now had shared objectives and a practical reason to work together.

3. Is “Cross-functional Teamwork” an Oxymoron?

Teamwork can be highly productive when team members share a work environment and similar business values. Cross-functional teams are more difficult because the people involved may be doing fundamentally different kinds of work and may therefore be rewarded for different behaviors. What appears to be a personality conflict may actually be a collision between legitimate functional objectives.

Conflict

In working with troubled cross-functional teams, I learned to listen carefully and reduce a conflict to the two or three individuals most directly involved. Their differences frequently reflected the objectives of the functions they represented. Engineering, manufacturing, quality, program management, finance, and other organizations may all be trying to help the enterprise succeed, but their responsibilities cause them to value different things.

Competing Values

One useful way to understand these differences is to consider competing work values. Some functions emphasize organizational maintenance, process, internal focus, long timelines, stability, and control. Others emphasize delivery, goals, external customers, shorter timelines, flexibility, and action. Neither set of values is inherently better. Organizations need both, but the differences can create predictable friction.

Robert E. Quinn’s Competing Values Framework provides a way to visualize these tendencies. Mapping functions according to internal versus external focus and flexibility versus stability can help explain why people in different parts of an organization view the same problem so differently.

Reframing

Once the source of a conflict is understood, it can sometimes be reframed around a value the parties share. On one troubled research and development program, Engineering and Manufacturing blamed each other for delays following repeated field-test failures. Manufacturing complained about the quantity and quality of engineering change documentation, while Engineering regarded the objections as needless detail. Investigation showed that Quality Assurance was enforcing contractual requirements and was therefore a central party to the conflict.

Escalating the dispute through management might have forced short-term compliance, but it would not have resolved the underlying attitudes. The more durable solution required understanding the values driving the participants, gaining personal commitment, and reframing the problem around a common objective: getting a viable product successfully through build and test. Cross-functional conflict is not an oxymoron to be endured; it is a leadership problem that becomes more manageable when we understand where the other person’s position comes from.

4. Why Call for an Ordnance Summit? Risk Management

Risk management is particularly important on complex development programs where a late discovery can create schedule delays, cost growth, or performance failure. While leading development of an in-space attitude control module for an Aegis Readiness Assessment Vehicle target, our team faced a launch date tied to a Navy fleet exercise. That date could not simply move if our development slipped.

An engineer at Johns Hopkins University suggested an “Ordnance Summit.” Initial reactions were predictable: the interfaces were already understood, everything was taken care of, and a meeting would waste time. Rather than accept those assurances, I discussed the idea with my Navy counterpart and organized a working session that brought together the organizations responsible for the attitude control module, solid stages, launch, staging, and destruct ordnance.

The purpose was not to direct each organization’s work. It was to put the complete configuration and its interfaces in front of the people who collectively understood the system and ask whether anything had been missed. The meeting generated action items that took months to resolve. Several of them would otherwise have produced significant delays late in the design.

The program met the required launch date. The lesson was not that every program needs a summit; it was that effective risk management sometimes means challenging confident assurances and creating a forum where the right experts can expose risks before those risks become problems.

5. What Does/Can a CAM Do?

After leaving the US Air Force, I became a system engineer with a defense contractor and was assigned as Control Account Manager (CAM) for the autopilot design of an air-to-ground cruise missile. The program had recently experienced flight-test failures and then failed accelerated life-cycle vibration testing because of an autopilot problem.

The autopilot design engineer, Andy, came to me exhausted and unsure what to do next. Instead of beginning with instructions, I listened. I asked him to list everything on his plate, without worrying initially about order or priority. When we reached near-term items such as manufacturing hardware for ground and flight tests, I began asking why the builds were being held up.

The trail led to engineering orders that Manufacturing resisted because a new process was poorly understood on both sides of the engineering-manufacturing interface. By speaking with the people who touched the engineering orders and hardware, I found that no one had followed the process end to end. Much of the problem could be solved simply by translating between groups and bringing two or three people together at a time to work through specific issues.

The process became clearer, the people involved learned whom to contact when problems arose, and Quality ultimately took a useful stewardship role. Andy and I continued meeting to develop a realistic schedule while he recovered from burnout. The development program was completed and entered production.

A CAM’s value is therefore not limited to maintaining cost and schedule data. A good CAM can help people see priorities, remove barriers across organizational interfaces, facilitate communication, and create the conditions in which technical work can move forward.

6. Schedule Recovery

A manager I had worked with previously asked me to attend a meeting concerning software preparations for the Ground-based Missile Defense program’s second Integrated Ground Test. The presentations painted a discouraging picture: the work was behind schedule and the presenters saw little hope of recovery.

I listened and wrote down the milestones each presenter identified. By the end of the presentations, I had begun arranging the delinquent and on-schedule milestones into a network. When asked whether I had anything to add, I suggested putting that network on a whiteboard.

Once the milestones, relationships, and decision points were visible, we added dates. The dates initially conflicted, so instead of arguing about the forecasts already on the slides, I suggested starting with the required Integrated Ground Test date and working backward. We iterated until the team had reasonable dates for every milestone and decision point. We then assigned an owner to each one.

There was resistance. Some people later asked whether the dates were really expected to be met. But the important difference was that the team had participated in constructing the recovery network and had agreed to the dates and responsibilities before leaving the room.

The program met the test date and achieved a successful test. When a schedule appears unrecoverable, telling each function to “work harder” is rarely enough. Listening to the individual commitments, making dependencies visible, working backward from the required outcome, and establishing clear ownership can turn a collection of late activities into a recovery plan.

7. A “Shaming”

As Programs Manager for a small company, I inherited development of a scanner for a joint-service chemical-agent detector. The project had sat largely untouched for a year after a contested government award. When I reviewed the proposal, I found that the motor we had proposed appeared too small to achieve the required scan times.

Analysis confirmed that a larger motor would be required, with consequences for power, heat, cooling, weight, and the rest of the design. We needed to choose an available commercial motor quickly so that the redesign, schedule, bases of estimate, and customer kickoff preparations could proceed.

I turned to a newly assigned project engineer, Ralph. He had returned to the company after a difficult experience elsewhere and was reluctant to take responsibility for design work. I could have assigned him a motor and told him to incorporate it. Instead, after we discussed the alternatives, I asked a simple question: “Do you really want your Program Manager to pick your motor for this redesign?”

He took ownership of the decision. The redesign was accepted by the customer, and the systems-engineering approach used to develop it was well received. Ralph later became the company’s Chief Engineer.

Was the question a form of “shaming”? Perhaps. But its purpose was not humiliation. It reminded a capable engineer that the technical decision belonged with him and gave him room to step back into that responsibility. Sometimes leadership means knowing when a carefully chosen question can restore confidence more effectively than an instruction.

8. Benchmarking with Competitors

My machine shop had produced aircraft repair parts for decades without much need for competitive cost estimates. Some equipment was old and inefficient, and newer CNC equipment had demonstrated substantial savings, but we lacked a consistent basis-of-estimate process for machine-shop work.

Two events forced the issue. I was directed to justify a reduction in the number of machine-shop form-modelers, and our proposal organization asked us to develop a large bid for overflow parts for an early Boeing 777 effort through Lockheed Martin. Rather than hide the staffing issue from the workforce and union, I discussed it openly. Employees themselves acknowledged that there was not enough work to sustain the existing staffing level, but we still needed an objective basis for decisions.

At the same time, the proposal exposed weaknesses in our estimating process. I suggested benchmarking local machine shops. The obvious objection was that these companies were competitors. But because our own shop could not produce the full quantity of parts contemplated by the opportunity, outside shops could also become suppliers.

Several agreed to prepare bids and bases of estimate for selected parts. By studying their approaches, equipment, and costs, we learned how our capabilities compared and developed a repeatable estimating method built around the cuts, manufacturing processes, test processes, and materials required for each part.

That process proved consistent and credible when our team later prepared bids on-site at Lockheed Martin. Although Boeing did not proceed with that version of the aircraft, the benchmarking effort produced lasting improvements. Production Planning & Control adopted the estimating process, relationships with the union improved through openness, and management learned additional ways to deploy workers more efficiently. Benchmarking ceased to be an embarrassing comparison with competitors and became a practical tool for improving performance.

---

Dan Harrison is an SMA Principal Associate in our Technical Management & Engineering Support Practice and has more than 35 years of experience in aerospace engineering. We thank Dan for his leadership contributions to our Professional Insights series.

If you’re building a team and have positions you can’t fill, use SMA Talent On Demand (TOD®). With TOD®, you can find experienced professionals matched to your needs, whether you need one individual or an entire team.