Three Sigma Leadership – Steven R. Hirshorn (highlights)

Here are my highlights from Three Sigma Leadership by Stephen R. Hirshorn. Hirshorn was Chief Engineer at NASA and this book is written as a guide and inspiration for other Chief Engineers at NASA. All the content and examples are geared towards projects and engineering within NASA. But a lot of it is applicable on a much broader scale. Especially within the tech industry and software development. But also more broadly as general leadership advice.

It is freely available from NASA’s website here: Three Sigma Leadership so you can read it for yourself or you can read through my notes below and perhaps gain an insight into its content.

There is wide anecdotal evidence that more projects fail not because of technical shortcomings but from organizational failings, from the inability of leaders to ensure the excellence and potential of their team.

An inescapable fact is that it is immeasurably more difficult dealing with people than it is with the systems and vehicles we develop. You cannot insult a vehicle. You cannot irritate a vehicle. Vehicles don’t need to be motivated.An inescapable fact is that it is immeasurably more difficult dealing with people than it is with the systems and vehicles we develop. You cannot insult a vehicle. You cannot irritate a vehicle. Vehicles don’t need to be motivated. They simply perform as designed and operate within their capabilities and certifications.

Emotional intelligence is undervalued as a dominant and requisite skill for leaders in engineering.

History has noted that more projects fail because of organizational dysfunction or lack of effective leadership than due to hardware exceeding certification tolerances or operating outside of the expected environment.

It’s easy, in fact, to perform rigorous testing to ensure operational hardware and software performance meets requirements and to repeat that testing to provide confidence in the results, but it is very difficult to test an organization’s personnel performance and that performance may not always be repeatable. Organizations and people are highly non-deterministic.

When someone yells and gets red in the face, we know they are angry. That’s not so subtle. But when someone is hesitant, or somewhat fearful or uncomfortable, their style of communication is much subtler. Pay attention to that. Pay attention to where they point their gaze, to the cadence of their voice, to the use of or lack of hand gestures. All of those indications are giveaways to a person’s emotional state and windows into their true feelings.

Utilizing emotional intelligence is critical in decision-making. Data gives us a wonderful window into technical performance, but data doesn’t incorporate experience and wisdom. People do, though—and we as leaders must pay attention to the people as strongly as we do to the data.

My sense walking into that meeting was that the topics we had lined up for discussion that day were irrelevant and that what we needed to do was to just talk, as a group, expressing our feelings and being heard.My sense walking into that meeting was that the topics we had lined up for discussion that day were irrelevant and that what we needed to do was to just talk, as a group, expressing our feelings and being heard. Had we just pressed on with the topics at hand, I was sure the conversation would be half-hearted, if even that, and while we may have made decisions, they would likely have been poor decisions at best. But more important, on this day, this group of dedicated career engineers and managers did not care about the planned topics. What they wanted to do that day wasMy sense walking into that meeting was that the topics we had lined up for discussion that day were irrelevant and that what we needed to do was to just talk, as a group, expressing our feelings and being heard. Had we just pressed on with the topics at hand, I was sure the conversation would be half-hearted, if even that, and while we may have made decisions, they would likely have been poor decisions at best. But more important, on this day, this group of dedicated career engineers and managers did not care about the planned topics. What they wanted to do that day was talk, and that’s exactly what I let happen.

Be mindful of not just what they are saying but how they are saying it. Body language speaks volumes.

Second, get out and talk with your team. If you don’t do this much and rely on scheduled meetings to interact with them, do it more.

Think about what they are not saying, what they may be vague on or seem hesitant to discuss. Pay attention to their eyes and where they are directed.

Third, get to know yourself and what triggers your emotional responses. This may take some deep introspection. But the benefits of knowing yourself is incalculable to understanding how and why you react to things and to controlling those reactions if they are negative. You can monitor yourself and the signs you manifest when having an emotional response in just the same ways that you can monitor others. Look for subtle clues, physical reactions, and other ways that might indicate why you are experiencing your feelings. Pay attention to yourself and your reactions, give them consideration after the event has passed, and a deeper understanding of yourself will be illuminated.

You are a voice of one but represent the voices of many.

I raised these concerns during our team discussions, and we had good, vigorous debate, but in the end, I allowed the team to determine what we proposed and what we didn’t. And at the EMB, it was my task to advocate for those changes, regardless of whether I thought they were good or bad. I was the voice of the team.

I’ve learned that I am comfortable in that role even if it results in negative perceptions of me, because the job advocating for those who cannot speak is a vitally important one.

Dissenting Opinion at its essence allows for concerns with technical decisions that affect safety and/or mission success to be elevated to a higher level so that they can be reconsidered.

Have you ever been in an organization where opinion was quashed, where voices were bottled up and prevented from being expressed? I have, and the dysfunction in those organizations tends to run much deeper than stifled opinions alone.

When people are frustrated, they stop contributing and when people feel resentment, they no longer wish to advance the organization’s mission.

In my experience, when those maintaining the alternate perspective feel they have been heard, they are almost always willing to accommodate the majority position. Sometimes, just being heard is all it takes.

Another point—When you are the voice of many, it is still incumbent upon you to understand what you are stating. You don’t have to be an expert on the subject, but you do have to have sufficient understanding to be an effective advocate.

With the box top, you know what the system (in this case a jigsaw puzzle) will look like when it’s assembled. To complete the analogy with respect to NASA, Robert would say that leaders need to be the box top of their program or project.

But there are few if any beyond the leaders responsible for the box top, for ensuring that all the pieces come together to produce the desired system, ensuring that both the system is designed right and that the team is designing the right systemBut there are few if any beyond the leaders responsible for the box top, for ensuring that all the pieces come together to produce the desired system, ensuring that both the system is designed right and that the team is designing the right system. The technical team’s leader, the Chief Engineer, has to be able to maintain sight of the box top, focus on the big picture, at all times.

Producing an aircraft that met all TPMs but that failed in its primary function (reduced sonic boom) would have been a defeat. He got it!

But the connection to me between mentoring and counseling is that both aren’t responsible for providing answers, but instead for assisting recipients in finding their own answers.

Even if you don’t find a mentor, I cannot recommend more strongly finding a role model for yourself. This can be a person, an organization, or even a concept that represents who you want to be and helps guide you in terms of how you want to act.Even if you don’t find a mentor, I cannot recommend more strongly finding a role model for yourself. This can be a person, an organization, or even a concept that represents who you want to be and helps guide you in terms of how you want to act. Having a role model sets a bar against which you can continuously compare yourself and see if you’re measuring up.

Systems engineering within NASA is codified in NPR 7123.1B, NASA Systems Engineering Processes and Requirements.

Or a Chief Engineer needs to understand the basic difference between verification (Did I get the system right?) and validation (Did I get the right system?).

And those responsible for ensuring effective systems engineering in our projects, our Chief Engineers and Lead Systems Engineers, are also the projects’ technical leaders. They are team builders, negotiators, decision makers, and this necessitate all the same leadership skills as our project managers.

And what’s more, as former NASA Chief Engineer David Mobley put it to me, “I had written on my white board in my office the principle of ‘P to the 5th power’: Poor Planning Perpetuates Poor Performance.”4

Passion, when applied constructively, is assuredly a tool in the leader’s toolbox. A leader who never shows passion is one whose team will be apt not to follow.

Furthermore, during meetings I also have to actively monitor the room for escaping passion and note it before it gets out of hand. Controlling the temperature of the room is a necessary skill. Being able to recognize that intervention is necessary to prevent spirits from boiling over is normally the function of the person sitting at the head of the table. (Write this down—that’s you!)

When passion does boil over, what do you do? Some would prefer to run away and get out of the line of fire. Believe me, I definitely understand the desire. But, as Chief Engineer, you really can’t do that. Rather, you have to get folks to sit down, stop shouting, pocket their daggers, and get back to the work and solve the problem at hand. It’s a tactful skill to get people to stop throttling each other and one that requires practice. It necessitates empathy, understanding, and competence in human psychology, something that doesn’t come intuitively to many of us engineers. But focusing on the importance of the work at hand and the need of the team to forge solutions is something that does resonate with many engineers.

Being the adult in the room is about being a peacemaker, a negotiator, a decision maker and a diplomat. It’s about being a technical expert, a responsible system owner, a risk manager, and a design thinker. It’s about being a bartender, a psychologist, a sociologist, and a human behaviorist. But ultimately, it is about being an example for the entire team of maturity and teamwork.

You can’t fit the pieces together if you don’t know what the final product is to look like.

To integrate, much of your time will be spent talking with people—with engineers and discipline subject matter experts (SMEs), with stakeholders and customers, with flight and ground operators, with hardware suppliers and vendors—so that you can stay abreast of the multitude of hardware requirements and idiosyncrasies that may prevent integration.

There is really no other way around this—broad communication is mandatory to acting as an integrator.

Most Chief Engineers get together with their technical staff on a weekly basis, whether that be a Chief Engineers’ tag up, a more formal Engineering Review Board, or other meetings depending on the size and complexity of the project. It doesn’t matter very much what forum you select or even if you do this outside of a forum, but what does matter is that you stay connected with your team and understand the needs of the individual disciplines and the challenges and hurdles they are facing.

Many of these arguments and demands will have very strong defenders who believe adamantly in their particular position. Remember, these folks are not being disruptive because they enjoy conflict but are just as dedicated as you are to the success of the project. It’s just that they may have a particular vision or past experience that points them in one direction. They may have seen a similar issue arise in a previous project and learned the hard way that their solution works well.

As you negotiate, try to avoid doubting people’s intentions, it’s normally not very productive.

If required to make tie-breaking decisions on technical matters, you most likely have the authority.

Realize that you may ruffle some feathers in the process. Not intentionally or with antagonism toward any of the parties, but it’s unavoidable that your decision has the potential to breed dissatisfaction.

But back to negotiating. What are some best practices for a Chief Engineer to negotiate a technical solution on a NASA project? Let’s say, for example, the discussion surrounds the application of margin being applied to the performance of an attitude control thruster for an Earth-observing satellite. The thruster will be designed to meet a defined performance specification, but given the past history and reliability of the selected thruster the design team feels it’s necessary to certify the thruster to margins above the spec. One camp on the team feels that 5 percent margin above spec will be sufficient. Another camp believes 5 percent is insufficient given the importance of the thruster to the spacecraft’s mission and is strongly advocating for additional margin, say 10 percent above spec. And lastly, the test team will have to make modifications to their test fixture to test at any level above the spec at all and is against adding any additional margin at all. What follows is a look at how the process breaks down.

The Technical Issue: First, understand the problem as much as you can using all the data you have available. No technical decision can be made without a thorough understanding of the situation. Have as much information as you can gather on the thruster, its design, its pedigree and history and its past performance. Have a thorough understanding of the criticality of this thruster to the spacecraft’s mission, the levels of fault tolerance and/or redundancy available, and the impacts on the mission should the thruster fail to perform as specified. Data is your friend and the lack of it will only lead to guesswork. While the decision you’ll eventually make may need to accept risk, don’t accept any more risk than necessary by obfuscating it with insufficient data. If time is short or insufficient information available, get more of both if you can.

The Decision: Understand the criticality of needing a decision right now. What is the driver for having to make this decision at this time? Question whether this is driving a decision appropriately or forcing a decision prematurely. If the time is right and the data is available, then have the discussion.

Importantly, though, when a decision is required, ensure that it actually gets made. Having an hours-long discussion on a technical trade that leads to no decision is the bane of most engineers. Make a decision. After you’ve heard all the data and once the decision is made, be confident in that decision so that you and the team can move past it and on to whatever the next discussion calls for. TheImportantly, though, when a decision is required, ensure that it actually gets made. Having an hours-long discussion on a technical trade that leads to no decision is the bane of most engineers. Make a decision. After you’ve heard all the data and once the decision is made, be confident in that decision so that you and the team can move past it and on to whatever the next discussion calls for.

First, during the discussion, hear both sides equally. If one side of a debate has been given time to make their argument, give the other side an equal amount of time. That doesn’t mean giving both sides as much time as they want—you can control how much or how little time is given, but at least give it equally. Perceptions of favoritism, whether deserved or not, can cause harm to a team’s cohesiveness.

Once a decision is made, remain empathetic to the side that “loses.” While happiness and satisfaction are not a guarantee when bringing forward a technical issue for decision, it does not benefit the team to recriminate, belittle, or otherwise demean those whose decision did not go their way.Once a decision is made, remain empathetic to the side that “loses.” While happiness and satisfaction are not a guarantee when bringing forward a technical issue for decision, it does not benefit the team to recriminate, belittle, or otherwise demean those whose decision did not go their way. They brought forward a position with as much professionalism and desire for the project to succeed as did those who “won” their desired decision and bringing it forward in the first place may actually have been an act of courage on their part.

Compliment both sides for raising the issue, give credit to all for a good debate, and remain cognizant that some may be disappointed with the result. The thing that I try to remember is that a disappointed engineer who has a management team willing to listen and who is treated respectfully is an engineer who will be willing to bring issues forward in the future.

They began by cutting out all redundancy, starting with zero fault tolerance on critical functions and eliminating all noncritical components, leaving only the critical functionality necessary to do the job. Would they ever fly such a vehicle? No, but their strategy was to make everything in the spacecraft single string and use this configuration to establish a baseline, a “zero mass” configuration, if you like.

And heed the words of former NASA HQ Chief Engineer David Mobley—the first solution you hear may not always be the best one for the task: “I have told some folks in the past that ‘I appreciate your input and the work required to develop that input, but while it is a very elegant solution I need the second-best solution with the impacts of not accepting your first solution.’ Almost always the first solution is the most elegant and most costly. It’s amazing how many times the second-best solution is the one agreed to.”

Change is ever-present. It’ll be your constant companion. In the same way that entropy is inevitable, you’ll have to face the headwinds continuously and develop strategies to prevent change from causing your project irreparable harm.

So how do you as Chief Engineer stay on top of all of this change? Well, as mentioned, configuration-controlled baselines are an obvious solution, but one that only can be part of the answer. You can establish a technical baseline, a schedule baseline, a cost baseline, whatever; it doesn’t matter. What does matter is that at some point you establish a fixed configuration and then track and control changes to that configuration.

In their desire to “stay Green,” they lost sight of the baseline as a management tool. Instead it became a façade for a charade. My advice: don’t do this! It’s not only bad form (and it is that!), but these tools are put into place to help us achieve success and if we don’t use them properly then our success is handicapped.

An off-ramp solution can come in the form of a heritage, proven, flown, off-the-shelf technology, previously certified and able to fulfill the primary function of the new technology but perhaps not at the same resolution, performance, or other desirable attribute that the new technology would have provided.An off-ramp solution can come in the form of a heritage, proven, flown, off-the-shelf technology, previously certified and able to fulfill the primary function of the new technology but perhaps not at the same resolution, performance, or other desirable attribute that the new technology would have provided. Should the new technology not pan out, the project can cease its development and insert the proven technology in its place, thereby maintaining the critical path.

Change also can be beneficial early in a project’s life, as allowing the trade space to stay open can allow for the identification of potentially better ways of achieving a function. New technologies get invented all the time, and old technologies are evolved and updated continuously. You wouldn’t want to lock in a design for a radiation-hardened microprocessor too early, for example, as a better, faster, more lightweight, or more reliable computer may be just a few months from being introduced and made available.

Last, take the opportunity to celebrate successes, even small successes.

To quote Ralph Waldo Emerson, “Nothing great was ever achieved without enthusiasm.”

As we mature, a number of us stretch beyond that discipline knowledge and learn how to interface with other disciplines. In the process we get exposed to design principles, standards and best practices beyond our field of expertise. We learn more about what works and what doesn’t and why.

It takes a lifetime to become an exemplary Chief Engineer, and even then we can still learn more.

Learning is a lifelong activity. Don’t stop. Ever.

Taken collectively there is an ocean (maybe a galaxy?) of learning opportunities out there. You’ll never run out of opportunities and new one gets added all the time. But you have to make an effort to seek them out, reach towards that available knowledge, and become a better and more experienced engineer and manager.Taken collectively there is an ocean (maybe a galaxy?) of learning opportunities out there. You’ll never run out of opportunities and new one gets added all the time. But you have to make an effort to seek them out, reach towards that available knowledge, and become a better and more experienced engineer and manager. If you stop learning, you stop improving.

Just as you would shepherd a hard-working team member out the door after a long day so that they can get some dinner and enjoy quality time with their family, you might equally need to herd a team member toward a learning activity. This small act not only matures your team but also shows them that you care about their development. These are no small acts of empathy.

Sharing information increases a group’s corporate knowledge, and it keeps the team thinking about new ideas and flexing that most important muscle in the human body (i.e., the brain!). This is the genesis of the idea of Pause and Learn, or PAL, used widely in the corporate world.

You might think removing people from the all-heads-down focus our work demands so that they can learn would be disruptive, but it isn’t. It’s easy to integrate learning into the cadence of your team’s day-to-day work.

It was the perception of inviolability, the belief that “it hasn’t hurt us in the past so therefore we’re OK,” that truly prevented Columbia and her crew from returning home.

Before STS-107, technical teams reported through programmatic chains, through the program manager. After STS-107, NASA created Technical Authorities to ensure a separate path of reporting for issues of safety and mission success.

What does it mean to be fair? When members of your team come to you with recommendations, you are open to their ideas and give them full consideration based on the merit of those ideas, limiting any biases you might have that would impede impartiality. When negotiating between two solutions you actively listen to both sides and allow each adequate time to make their case. When your superiors give you an action that you decide to delegate, you hand that action off responsibly and without motivation of retribution or favoritism. When you are praised and you want to focus that praise on your team, you find ways to recognize the entire team. When you act, you act in an equitable fashion based on what is good for the project, the team, and the system under development.

Fairness is a critical (maybe the most critical) component in building and maintaining functional and high-performing teams.

If you always hand high priority tasks to the same person because they’re your drinking buddy and you want constant recognition to come their way, you are not being fair. If you avoid handing a high priority task to someone who annoys you, you are not being fair. If you give the task to someone who clearly communicated to you that they are struggling to keep up with their present workload because that person is friends with the guy who annoys you, you are not being

How fair is your decision-making process? Have you ever thought about it?

Finally, when ready to declare your decision, lay out the rationale so that others can understand it.

If your team sees you are not (or cannot) take care of yourself, they may question how you can stay on top of all the responsibilities incumbent in taking care of the them. Which, in fact, they will want you to do. In this case it’s not the need to establish a firm foundation that could erode from below, but the need to place a strong horse at the front of the wagon who knows the way.

They know who they are, their strengths and weaknesses, and when they may be pushing themselves too hard (or conversely, may need to turn up the gain). They know when they are dressing nicely or dressing sloppily and when either is appropriate. They know when they are in good health or when they are as sick as a leaking battery under load.They know who they are, their strengths and weaknesses, and when they may be pushing themselves too hard (or conversely, may need to turn up the gain). They know when they are dressing nicely or dressing sloppily and when either is appropriate. They know when they are in good health or when they are as sick as a leaking battery under load. And they are aware of when they can handle a situation or when they need help (and they ask for it).

When you ascend to leadership, the expectations of maintaining basic functions is elevated, even when events in your life would normally prevent taking care of fundamentals.When you ascend to leadership, the expectations of maintaining basic functions is elevated, even when events in your life would normally prevent taking care of fundamentals. Team members want their leaders to be the embodiment of good practices. They want their leaders to personify exemplary behaviors. Leaders are expected to set the example, to go above and beyond, and to be the exemplar of what each team member should be. Unfair? Well, unfair or not, it’s a reality. Welcome to the role of Chief Engineer!

The Chief Engineer here was thinking both sides of the coin: 1) How do I fix what’s going on? and 2) If I can’t fix it what options do I have to keep the project on track? That frame of mind is exactly what a Chief Engineer needs

If you got selected as a Chief Engineer to a project after it was already formulated, you missed a fabulous opportunity to experience strategic thinking. The entire formulation process, especially during the very early stages such as pre-Phase A, revolves around developing a concept, finding advocates and selling the idea to those who might fund it. At this point in a project’s life there is little discussion on how to execute the project, but rather on what the project should be about and perhaps even why NASA should have such a project.

I have observed that scientists and researchers naturally abhor process, paperwork, and policy. Their primary desire is to conduct their research and the associated project wrapped around it is just a means for them to do that. The prescription of 1) Give them resources and funding, 2) leave them to do their work, and 3) come back when they are done makes for a happy scientist/researcher. Of course, the world doesn’t work that way and responsible managers want to see progress and evidence of their investment.

Sorry, I hate to be so negative, but it never ceases to amaze me that this concept is so often broken by poor leaders. Promises are easy to make and making them is compelling because we all want to be liked. But if you make a promise then you simply have to keep it if you want to build trust, develop relationships, and lead. If you don’t, well, then you lose trust, destroy relationships, and how can anyone do that and be a leader?

If you say something that requires action, do it. If you promise something, keep that promise. If you claim something, substantiate that claim with data or proof. Do the things that make your word the gold standard. Think about it from the opposite direction. If you exaggerate, you’ll find it hard to remain accountable. If you accuse unjustly, same thing. If you make unattainable promises, accountability goes out the window. And once accountability leaves the building, you cannot be effective as a Chief Engineer.

These commitments to yourself are no less important than those you make to others.

But back to the title of this chapter. Being a master of risk means two things. It means mastering the inherent process that goes into risk management—looking out for and identifying risks (the hardest part), categorizing and prioritizing them, determining mitigations and enacting them when able, monitoring the mitigations’ effectiveness and making changes when required, and determining when mitigation is no longer required.

Second, being a master of risk implies something larger: that you are the master of the risks and the risks do not master you. You control them, not the other way around. You see them before they show up. You minimize them before they damage your project.

This technology could be placed on your opportunity matrix. You can assess the likelihood of the technology’s being matured to the point that it could be incorporated into your design and you could assess the benefit it would provide if that were to happen.

Not many people or projects give a lot of thought to opportunities because they are spending so much time trying to ward off the risks. That’s true. And it’s probably unlikely that opportunity management would share equal time with risk management. Nor should it. But spending a little time on it, every once in a while, could help your project get ahead of the curve in substantial ways.

One of the ways I found to help keep a risk or an opportunity is to build into the mitigation plan a decision point (usually one or more are required anyway) with a date for reaching this decision. This greatly helps to keep the risk to my attention and obviously the need for a “new” direction in the mitigation plan.

Innovation enables. Innovation revitalizes. Innovation allows doors to open and identifies new navigable paths to solutions.

When that happens, when available technology won’t fit the bill, or system complexity mandates new methodologies, your team will have to innovate. The ability to innovate, which you’ll find is effortless for some but difficult for others, can be assisted and more easily enabled if there is an environment that promotes innovation within the team. Environments that promote innovation allow for and encourage alternate solutions to be proposed and implemented, help facilitate out-of-the-box thinking and experimentation, and avoid discouragement by detractors shooting down suggestions simply because they are new or untried.When that happens, when available technology won’t fit the bill, or system complexity mandates new methodologies, your team will have to innovate. The ability to innovate, which you’ll find is effortless for some but difficult for others, can be assisted and more easily enabled if there is an environment that promotes innovation within the team. Environments that promote innovation allow for and encourage alternate solutions to be proposed and implemented, help facilitate out-of-the-box thinking and experimentation, and avoid discouragement by detractors shooting down suggestions simply because they are new or untried. Open innovation environments reward entrepreneurial experimentation and free thinking.

Risk-averse Culture—Management/workforce conservatism and oversight bodies drive costs and create more incremental steps.

Short-term Focus—Immediate mission needs (for example, meeting-level requirements) often must take short-term priority over the development of future capabilities.

Instability—Changes in decisions and direction set by external stakeholders as well as tactical decisions have dried up the innovation pipeline and led to a cycle of technology start/stops.

Process Overload—Excessive administrative burdens can stagnate innovators; process owners have become gatekeepers instead of enablers.

Organizational Inertia—Cultural tendency to stay the course and a lack of trust often portray innovation as a threat; need to balance the risk with reward.

Risk-adverse cultures generally discourage even trying new ideas because of the fear of failure. Innovation doesn’t mean taking gratuitous risk, sometimes all it means is thinking about your problem from a different angle. When even that can’t happen, you may have a risk-adverse culture in your team.

Short-term focus is common as managers and leaders keep their team’s heads down, addressing only the most immediate problems with tactical solutions.

Looking at the world through only a day-to-day lens is likely to produce band-aid solutions, and innovation can’t get a foothold.

Frequent course corrections, leadership changes, and rebaselines can contribute to instability, resulting in cycles of innovative ideas being started and then stopped. Good ideas are attempted and pursued but are quickly terminated due to the change occurring within the project around them.

An innovative team discusses solutions within itself but also is liberally exposed to ideas from outside itself.

Familiarity gives a sense of security for some folks and anything unfamiliar breeds fear.

Plus ça change, plus c’est la même chose. “The more things change, the more they stay the same.”

Change the environment and evolution no longer produces efficiencyChange the environment and evolution no longer produces efficiency. So even if the flight control team structure had evolved to its highest form and had attained that form for some years, that evolution was only relevant as long as the environment around it also remained the same.

As Chief Engineer you have the latitude, even the responsibility, to push back on change that you see as short-sighted or detrimental to the project.

Resisting change because the change is troublesome, ill-timed, or otherwise disruptive just wastes time, doesn’t perform any useful work, solve a problem, or move the project forward.Resisting change because the change is troublesome, ill-timed, or otherwise disruptive just wastes time, doesn’t perform any useful work, solve a problem, or move the project forward. When it happens, accept it and focus on what is required to make it happen. Attitude, here, is the start of successful resolution.

Personal Accountability: The memo explains that each individual is responsible for the success of the mission. Each person, regardless of position, contributes to success and every component must work for the Agency to be successful. Personal responsibility includes the need to possess the knowledge and confidence to speak up when something is amiss in their area of responsibility.