What NASA Knows About Great UX Management

What NASA Knows About Great UX Management

In the 1970s, NASA undertook an assessment of airline pilot performance. They needed to understand why pilot error had become the leading cause of airline accidents. What they learned helped make commercial air travel one of the safest modes of transport in the U.S. today. Their research shed light on the importance of workload, leadership and communication — integral aspects of running successful UX engagements. What can we learn from this seminal research?

Balancing Workloads

Research found the best performing airline captains kept tabs on their crew’s workload. Interestingly, pilot error wasn’t typically due to lack of skill or knowledge of proper procedures. Instead, the important factor was how their skill and knowledge was applied. The best performing crews had captains who managed how many tasks each crew mate was asked to perform. When workload became an issue for anyone, they delegated, relieved or rebalanced everyone’s duties such that each crewmember could better concentrate and focus for optimal performance.

Captains who didn’t manage their crew’s workloads consequently had worse performance. The study found that when anyone had too many duties, they became overtaxed which lead to performance problems and finally to errors.

While errors in a UX project don’t have immediate life and death implications as they might in commercial aviation, they can have negative consequences. When people are overtasked, they cut corners, consciously or not. They can overlook or be blind to problems, they can experience delays identifying and handling problems, they can fall back on assumptions when objective data is available, and they can develop tunnel vision causing an inability to assess the entire project as a whole.

I’ve been witness to engagements where scope outstripped the ability of a project team to deliver the best work they could in the time allotted. In these cases, morale sank as individuals realized they couldn’t deliver the quality they expected (and which they knew they could provide). They left projects feeling the end result could have been better — sometimes in explicit terms when they knew gaps existed and sometimes with vagueness when they had a general feeling that problem definition, exploration or execution could have been pushed further.

Ensuring each contributor on a team has a manageable workload helps keep people engaged, performance and morale high, and stress at manageable levels. All of these characteristics contribute to fewer errors and, ultimately, less rework since time and effort are being used more effectively.

But how do we balance workloads effectively? As NASA’s research suggests, keeping tabs on workloads is one of the captain’s primary duties. If the captain assigns himself too many tasks, he essentially causes tunnel vision for himself, unable to judge his crew’s workload. The lesson is to have one teammate delegate enough tasks so they can effectively evaluate workloads and make decisions concerning them. Failure to do so jeopardizes overall performance and risks errors big and small.

Leadership

NASA found that during simulations of emergencies it wasn’t clear who was in control — the captain or co-pilot — during times when one or the other looked up information, communicated over the radio or discussed courses of action. This is in stark contrast to how captains typically lead in the 70s — which is to say they were authoritarian. As an Atlantic article put it, researchers found “…a culture dominated by authoritarian captains, many of them crusty old reactionaries who brooked no interference from their subordinates. In those cockpits, co-pilots were lucky if occasionally they were allowed to fly.” Also, “It all depended on the captains. A few were natural team leaders — and their crews acquitted themselves well. Most, however, were Clipper Skippers [authoritarians], whose crews fell into disarray under pressure and made dangerous mistakes.”

We in the user experience world would likely agree that the best outcomes don’t come from a strict hierarchical and authoritative environment, but one where collaboration is encouraged. In an environment like this, colleagues lend critical eyes, stakeholders provide context, and customers pass judgement via their attention and wallets. These feedback loops are meant and encouraged to pinpoint problems and signal possible solutions.

Authoritarianism, by definition, is counter to this culture. It doesn’t encourage teamwork, critical analysis and experimentation nor does it tap the wisdom of crowds. In a business world that increasingly sees UX as the critical difference between success and failure, authoritarianism will likely produce worse results. The era of the lone visionary (if, in fact, it ever existed) always loses ground to an active, diverse group. Our world changes too quickly and the Internet has largely removed the ability for any one person to take advantage of information asymmetry for long.

While an authoritarian approach proves to be problematic, NASA did find a need for clear decision making. While collaboration brings benefits, all projects will require decisive calls (typically from someONE) when multiple and equally good options exist. Teams need leadership, products need leadership and companies need leadership. The trick is to avoid dictatorship in preference for leadership flowing from a collaborative environment where all input is sincerely taken into account.

At Slice of Lime, we ask clients to provide a project owner (PO) — someone on the client side who can answer questions, prioritize workloads and make decisions quickly. The role requires authority and accountability, authoritarian characteristics to be sure, but tempered by the environment in which it exists. Our team gives recommendations, provides a reality check and influences the direction the team and project take. We push our clients, they push us and our client’s customers push everyone. The PO’s job within this dynamic is to weigh the work output and the insights from customer research against their internal culture, priorities, timelines, and budget. As a team, we all have the same goals, but since everyone’s contribution has a particular focus we can run into forks in the road where multiple paths forward appear. These paths may be relatively equal in terms of their chance for success. The PO, in this situation, is empowered to make a decision on behalf of the entire team.

This approach works without it degrading into a ‘do it my way’ mandate because the team worked to provide the options within a collaborative environment. If research proves the chosen direction to be poor, the team can course correct without finger pointing or ‘I told you so’s.’ The idea is not to empower the product owner to be a dictator, but to empower them to choose rationally knowing the tradeoffs and risks as surfaced by the team. The group acknowledges and supports the PO’s ability to make hard choices when needed because they are the source of those choices and will be full participants in any course corrections that may materialize.

On our side, we too have a team lead who acts in a similar vein to the PO although primarily being decision maker for our team. This role also weighs factors at hand in order to plot a course for our team’s efforts that will meet the needs of our client while also ensuring we are doing the best work we can. Again, it’s about making rational choices knowing the tradeoffs and risks at hand. Communicating these judgements and any recommendations from the team falls on the team lead’s shoulders while others move ahead with the next set of priorities. Because trust has been established through good communication, our recommendations will likely heavily influence the PO’s decision. In effect, we help guide the project even though the client retains decision making powers and the overall vision for the project.

Communication

As you probably already know, good communication is the key to the smooth choreography of a project and project team. NASA discovered “…that teamwork matters far more than individual piloting skill. This ran counter to long tradition in aviation but corresponded closely with the findings of another NASA group, which made a careful study of recent accidents and concluded that in almost all cases poor communication in the cockpit was to blame.”

Advising people and teams to ‘communicate better’ is certainly easier said than done, not to mention a bit lazy on my part. It masks a lot of dynamics that pose roadblocks (an article all its own), but the advice nevertheless stands. In our company, we work very hard to prioritize communication. We’ve adopted Agile as our preferred workflow and one of its principles is “individuals and interactions over processes and tools.” We apply this mantra both internally and externally.

For example, once a month, our entire company gathers to talk through issues good, bad and somewhere in between in a safe environment where open and honest conversation can be had. Action items spill out of these conversations and we work to improve as a group. Externally, we do the same. We hold regular meetings with clients to ensure the project is running smoothly and any brewing problems are dealt with before they become impediments or interpersonal baggage. We do other things as well, but you get the point. If you consciously make communication a priority, then it’ll be a priority. It’s that simple.

Putting It All Together

Many of the examples I’ve given from Slice of Lime have taken time to implement. We didn’t arrive at our current process overnight and I wouldn’t expect it from other companies. Tackling these topics will, I believe, result in positive change for you and your organization. Your priorities and culture will influence the end result however. I don’t wish to say that our way is the right way. It’s the right way for us at this time. Tomorrow is another day and we’ll evolve to meet the challenges and opportunities we encounter.

You will find what works and doesn’t through trial and error, as we have. We still find ourselves on rickety rails from time to time, but they don’t completely derail us. Our communication feedback loops help ensure we spot and deal with problems as early as possible.

You will also find that all three aspects discussed — leadership, workload and communication — work in tandem. A change to one affects the others. This is inevitable as all three blur into one another to some extent. Be cognizant of your organization’s particular links between these areas and be mindful of disruptions that may snowball from any one change. Again, an iterative and collaborative approach will help.

We find, for example, that our tight communication with clients builds trust. Trust enables workload issues like scope creep to stay in check. Our tight collaboration ensures that the client (and the PO in particular) is aware of the impact of new features, priority changes and insights from research. Since they ultimately have decision making power within the team dynamic over what to do and in what order, they are acutely aware of how scope change will affect the project. We inform them day to day on our progress and that, in turn, allows them to better manage workload within their cost and time constraints. And it’s all made possible by the importance we place on communication.

Has your organization found good tactics around these topics? If so, please leave your thoughts. I’d love to hear them.

 


 

William Langewiesche’s “The Human Factor” inspired this article. Highly recommended, especially if you’re an airplane junkie.

Photo by Steve Jurvetson, via Wikimedia Commons

-->