How a Failure in Engineering Leadership Caused the Deep Horizon Oil Spill [Elizabeth J. Agnew]

Mike Williams survived the blowout on The Deepwater Horizon and he shared his story on 60 Minutes in May. What I found fascinating, in addition to how he survived, was his description of a catalyzing moment in the board room, just one of the many leadership mistakes that led to the disaster.

The rig had been working for seven years, and was just finishing up the largest drilling project to have ever been completed. The crew was preparing to close the cap of the oil well. Managers from BP were on site to celebrate a successful completion.

Here’s an excerpt from the 60 Minutes interview explaining what happened the morning of the accident:

Williams says, that during a safety meeting, the manager for the rig owner, Transocean, was explaining how they were going to close the well when the manager from BP interrupted.

"I had the BP company man sitting directly beside me. And he literally perked up and said 'Well my process is different. And I think we're gonna do it this way.' And they kind of lined out how he thought it should go that day. So there was short of a chest-bumping kind of deal. The communication seemed to break down as to who was ultimately in charge," Williams said.

The largest environmental disaster in US history starts because of chest bumping! This may not be surprising, but it certainly is ridiculous, disappointing, and embarrassing.

This highlights the importance of communication in the engineering world. I was told that the technical communications course I took senior year at Cornell would be the most important course I took. And I’ve found that to be true. What if there was a way (and there is) for those two men to have seen themselves on the same team, to have put their different ideas in a pile, then agreed on a way discuss the project that would result in the best all-around process? What if they were trained in how to maintain sight on the bigger picture, on all the forces at play, and not just on being “right”? What if the system was set up so that “being right” was the same thing as “finding the right answer together”?

Later in the segment we learn that if BP hadn’t won the argument, there probably wouldn’t have been a blowout:

In finishing the well, the plan was to … place three concrete plugs, like corks, in the column. The Transocean manager wanted to do this with the column full of heavy drilling fluid - what drillers call "mud" - to keep the pressure down below contained. But the BP manager wanted to begin to remove the "mud" before the last plug was set. That would reduce the pressure controlling the well before the plugs were finished.

"If the 'mud' had been left in the column, would there have been a blowout?" Pelley [the CBS interviewer] asked.

"It doesn't look like it," Bea [the expert; a UC Berkeley engineering professor] replied.

In all the cleanup work and ongoing efforts to stop the leaking, let’s not forget how this clusterf*** started. The way we’re working together IS. NOT. WORKING.

We need to:

1. Bring real leadership and communication training to all ruff-n-tuff engineering leaders out there


2. Teach leaders how to deepen their identity to Self so they get their egos out of the damn way when solving technical problems that have widespread, multifaceted implications.


3. Provide technical tools and processes for the skill of communicating so that when differing ideas are put on the table there is a reliable, impersonal way to choose the best one.

We NEED to change the way we solve problems together if we are ever going to a) avoid the next mega-disaster and b) fix all the mega-disasters that are already ruining our planet.

Source: http://www.cbsnews.com/stories/2010/05/16/60minutes/main6490197.shtml

About: Elizabeth J. "Liz" Agnew works with individuals and teams of technical professionals on leadership development, collaboration, and strategic planning.  She offers complimentary consultations with no obligation.  Visit www.integrative-leadership.com or email liz@integrative-leadership.com to learn more.
More...

The Strong Boss [Matt Schlegel]

One of my clients is a strong leader. She is a strategic thinker and as smart as they come. She guides herself and her team to deliver consistently great results. Yet, she complains to me that her team fails to think for themselves. As such, she has to maintain a hands-on approach and monitor the team continuously. She finds this tiring and aggravating and wishes she could delegate more. What is happening here?

As I began to interact with my client’s team, I discovered that the team was very good at reacting to direction from the boss. The team understood that the boss highly valued action; therefore, they took direction from the boss and turned that into action as quickly as possible. There was very little need to highlight problems since the boss set the agenda on the important problems to address. Also, the team minimized analysis and planning activities since these activities took time and slowed progress toward action-oriented results.



The figure illustrates the problem-solving dynamics of this organization. The leadership style of the boss created a strong tendency towards action – Git ‘er Done (step 7). The team members attracted to this type of organization are those that respond well to that leadership style. For instance, once the boss set the direction, the team found little need for further conversation about the problem (step 1). By moving directly to step 2, people would organize and figure out how they would respond to the boss’s direction. Ideas would be generated (step 3), but the team would find there was little value in analyzing the ideas (step 4) and building plans (step 5) around those ideas. Rather, the team would present a promising idea (step 6) to the boss for review and approval. The boss, being the smart strategic person that she is, would be able to quickly assess the idea and approve it, modify it or send the team back to the drawing board. In that way, the team would quickly move into the Execution Phase (step 7.)

This action-oriented problem-solving style is very effective in that it produces results quickly. One way to characterize this method is as an iterative method. Another description is “Fail Fast.” This is a great methodology to try different approaches and quickly iterate to a successful solution. And, because the leader in this case was as talented as she is, the probability was high that the ideas she directed the team to pursue would be successful. The cost of this approach is that she had to spend a tremendous amount of energy setting direction, reviewing ideas and monitoring results.

In working with this team, I found that I had to start at the end with the neglected Debrief Step (step 8), reviewing with the team how they solve problems, and determine what was working well and what not so well. Out of this discussion came a list of potential problems (step 1) that the team considered important to address. Reviewing this list with the strong leader, we quickly came into agreement on the important problems. The big difference was that the problems were now the team’s problems, not the boss’s problems – the team was highly vested in solving these problems.

Working with the team, I had them spend more time on analyzing different ideas for solutions and putting together a well-thought-out plan before presenting the plan to the boss. The team put together a terrific proposal in which they genuinely held pride. They presented that to the boss who was equally pleased and gave the team permission to move forward, which the team did with considerable enthusiasm.

The strong boss learned how her personal leadership style was impacting the performance of the team. The problems she experienced with her team were as much the result of her own behavior as that of her team. By allowing the team some say in choosing the problems to solve, the team delivered great results and took far less oversight from the boss, which made the strong boss happy.


-------------------------------------------------------------------
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.
More...

Automate As Much As You Can [Rino Jose]

Automation is the ultimate delegation

One of the classic traits of an effective leader and manager is that they delegate work. They find ways to offload work to others so that they can focus on activities that have higher value to the organization. If the work that's delegated is challenging because it requires intelligence and insight, then this provides junior executives and managers with an opportunity to develop their skills. If, on the other hand, the work is doesn't require insight and thought, it becomes a distraction that prevents people from working on things that matter more. When this happens, the work should be delegated further.

Of course, the ultimate delegation is to simply automate the work. If you can automate any of your work, you should. Having people do work that can be done for them is a waste of time, effort, and money..

Capture what you've learned

Automation enables you to capture and use what you've learned. It's a way of documenting the lessons your team and organization have learned over time. It lets you leverage your project retrospectives, postmortems, and brainstorming meetings. It helps puts into practice what you've decided to do.

People are overloaded today. It's hard to find anyone who has the spare time to shepherd change through an organization. If, however, change can be automated -- at least in part -- the effort of realizing change can be greatly reduced.

Don't keep reinventing the wheel

If you haven't automated how you do typical tasks or how you collect status or how you manage projects, then your organization will reinvent these things differently each time. If you have multiple teams within your organization, each team will develop their own way of doing things. There won't be consistency in how anything is done.

Not only will people be wasting their time reinventing new ways for doing the same thing, but they will multiply the effort it takes you to understand the status of anything. You won't know where your team is at any given time. You won't have a clear view of where projects will land or where the bottlenecks are. Some people will give you spreadsheets. Some people will give you subjective reports with lots of handwaving. You'll have information fragments that don't fit together. When things go wrong, you'll be surprised. When you ask why, people will externalize blame. It might not be anyone's fault -- lacking consistency is really to blame.

Automate to get into a rhythm

Stop doing things differently each time. Use templates for your meetings. Document your workflows (more in an upcoming post). Use tools to automate as much as you can.

Automation helps you get into a rhythm. It provides the infrastructure for your work. It enables you to apply your skills and insight directly to your problems instead of wasting effort on figuring out how to apply them.

When you automate things, people know what to expect. Each time you perform a certain type of work, it becomes easier to do. Every team starts executing consistently. Your teams will find their rhythm and their pace. Your teams will develop organizational momentum.

Keep questioning what you automate

Building organizational momentum is great. Teams are more effective. People have greater impact. Everything runs better. However, don't forget to question what you automate.

When we learn new lessons or when the environment in which we work changes, we need to ask if we're still automating the right things. If something is no longer necessary, we should drop it. If we're missing something, we should add it. If what we're automating isn't working, we need to fix it.

We automate to make ourselves more effective, not to stop thinking. It's ok to create and use cogs to make our jobs easier; it's not ok to become one.

(originally posted on Management Revolution)

_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.
More...

All in the Family [Matt Schlegel]

One of my clients is a small-sized, innovative technology company that has been in business for over 20 years. It is a self-funded, privately held company with no venture backing. The company is like a family; it is not uncommon for an employee to say they have been with the company over 15 years. At no other technology company have I felt that the company is as much a family as it is a corporation. Working with such a close-knit group can be a double-edged sword. That is why they asked me to help.

People who work together for many years come to know each other’s strengths and weaknesses very well. They come to accept one another and resolve to work with each other through any situation. This resolution often requires being sensitive to other’s feelings and needs and taking an approach that minimizes conflict and drama in order to keep focused on getting the job done. The downside of this approach is that people will tend to downplay problems for the sake of maintaining group harmony.

My client is a group of some of the kindest, most helpful people I have ever had the pleasure to work with. Some of the adjectives that I would use to describe this group are helpful, creative, analytical, cautious and enthusiastic. Two adjectives that I would not use to describe this group are perfectionist and assertive. Yes, this group appears to have weeded out anyone who would be unwilling to put up with the problems of others and anyone who would be assertive to the point of ruffling feathers. Not that this does not happen from time to time, but this is the exception rather than the rule.

The figure shows the problem-solving dynamic that tends to occur at the company. First, there is a great reluctance to acknowledge that there is a problem in the first place. There are no systems in place to identify and report problems to the group in a systematic way. As such, most problems are raised via the squeaky-wheel method. (Cliché: Squeaky wheel gets the grease.) Once someone has a big enough problem and shares that with the right person at the company, the helpful nature of the team kicks in. They want to solve the problem for that person. The company has great strength in creativity and analysis. They bend over backwards and find a creative solution to solve that particular problem. The team will get the thrill of moving towards solving the problem. If the problem is easy enough, it will get addressed. However, if solving the problem requires any transformative change to the way the team has historically worked, there is no one there assertive enough to move the team through that transformation. The problem is addressed to the point that the squeak stops, and the team moves on to the next squeak.

With this client, my two main jobs have been to fill the role of the perfectionist and the asserter. I have helped the company put in place the tools for collecting data, analyzing the data and reporting problems. As the data reveal the problems, the helpful nature of the team kicks in and moves the team smoothly through the problem-solving process. Then, it is my role to serve as the asserter to nudge the team through any transformative changes that will help them resolve their longer term, systematic problems.

This problem-solving framework gives me the tools to understand both the steps of effective problem solving and the interpersonal dynamics that will influence the team’s progression through those steps. It also gives me the tools to explain to my client what may be missing in their skill set that is impeding them from becoming effective problem solvers.

---------------
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.
More...

Meetings as Performance [Rino Jose]

When you view meetings as a performance, you're practicing something similar to servant-leadership. Instead of demanding people's attention, you earn it. Instead of holding court, you're on stage. It's still your show, but you want people to enjoy it.

When your meeting is a performance, you'll approach it differently. You'll spend time preparing for it. You'll work to make sure everyone's engaged. You'll discuss things that matter. You'll become more animated. You'll think through what you're going to say. Your meetings will have life and energy. Your meetings will have an arc and a story. Your meetings will have a point.

When you play the role of someone on stage, the attendees play the role of the audience. Certain expectations are established naturally. You are there to inspire, entertain, elucidate; they are there to watch, listen, participate -- no cell phones or e-mail during the performance. When you perform well, no one will be bored, and people (including yourself) will look forward to each meeting.

Looking at meetings this way gives you a chance to hone your presentation skills and to practice public speaking. Weekly meetings, in particular, give you a great venue to experiment with different styles and approaches. Vary what you do each week. See what works best for you. Build up your repertoire.

Another benefit to viewing meetings as a performance: it helps you lead change. When you deliver a solid performance, you connect with your audience at an emotional level. You'll find it easier to deliver tough messages and convince people to try something new. When people decide to change, it's usually based on emotion first and then rationalized afterwards. If you can get people to laugh, you can get them to change.

(originally posted on Management Revolution)

_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.
More...

Bumps and Dips on the Path to Solving your Problem [Matt Schlegel]

In past blogs I have described a problem-solving process. When I describe it, it is a nice smooth process flowing from one step to the next. Funny thing is, when you use the process in practice, it may not be so smooth. What if we could look down the path to anticipate likely bumps and dips in the process. We may not be able to avoid those obstacles, but we can brace ourselves to move through them. In this blog I will describe a method to let my fellow problem solvers identify in advance those bumps and dips.

People tend to play to their strengths and avoid their weaknesses. Your problem-solving team is comprised of people and their various strengths and weaknesses. Depending on where you are in the problem-solving process, your team members will resonate or not with the phase at hand. If the phase requires a strength that is absent in your team, the team can get stuck and have trouble moving to the next phase. If the team is overrepresented by a particular strength, again the team can get stuck or repeatedly go back to the overrepresented step.

The figure illustrates a team that is generally well represented by team members with various strengths, but has an underrepresentation in the Get It Done Step (step 7) and over representation in the Identify the Problem Step (step 1). What can happen in this case is that team would move around the process to the point of underrepresentation, get stuck, and then move back to the overrepresented step, a discussion about what is wrong, without ever taking the action to solve the problem.



This is just one example. You can see that depending on your team make-up, there can be any number of bumps and dips encountered as you move around the process. It is important for the facilitator of process to understand the team make-up, anticipate the trouble spots, and ensure that the team can move through the obstacle. In the example above, the facilitator needs to clearly identify the Driver role in step 7 and ensure that that role is filled with a willing and able team member. Also, when the team restarts the discussion about the problem, the facilitator needs pull the team back on track by reminding the team that a problem statement already exists.

As I work with teams and see how the strengths and weaknesses influence progress, I realize that there are many well-known clichés that describe these bumps and dips. To name a few: paralysis by analysis, half baked idea, heart in the right place, look before you leap, etc. On your problem-solving teams, what bumps and dips have you encountered and what clichés have come to mind?


_______________________________________________________
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.

More...

The Knowing-Doing Gap [Kimberly Wiefling]

If knowing “HOW” to do something were enough we’d all be rich and thin. There’s always some reason why well-intentioned, educated, experienced professionals are doing the opposite of what they know makes sense. Frequently it’s because they are really busy, and can’t possibly do what needs to be done until someone ELSE changes first, usually their boss, or someone in a different department. “If only” someone or something else would change then THEY would be able to do what they need to do to accomplish the goals.

A whole book on “The Knowing-Doing Gap” was written on this by two professors of Stanford University when they realized that their colleagues at the Stanford Business School didn’t follow the principles that they taught when they themselves were leading companies. It happens in engineering teams, too. If you want an example of the knowing-doing gap in engineering teams, just consider numerous studies that indicate that the top reason that teams fail is for lack of clear goals. What could possibly be more important for an engineering manager than clarifying goals and communicating them to the team?

Alas, common sense is NOT common practice. What is the source of the Knowing-Doing Gap?
FAIL – The 4 legs on the stool causing the knowing-doing gap and preventing people from crossing it are:

· Fear of Failure – If you’re not allowed to fail you must be careful what you start!
· Aversion to Planning – Studies have proven that, given a choice, people prefer not to plan. At the same time, we also know that planning dramatically improves results.
· Instinct for Competition – The win-lose frame is the first assumption for many people in any situation involving another person. Fear of losing, tied into #1, prevents people from even playing the game.
· Learned Helplessness – “It’s not my fault!”, and “They are doing it to me” thinking. The research on this is absolutely shocking.

The difference between someone occupying an engineering leadership position and a true engineering leader is that the pros do what is required whether they feel like it or not, whether they think they have time or not – no excuses! Winston Churchill is one of my favorite leadership role models and he said “Sometimes doing your best is not enough. Sometimes you must do what is required!” Yeah, that’s right, Winston.

Cross posted at www.SVProjectManagement.net
_________________________________________
Kimberly Wiefling specializes in enabling people to achieve what seems impossible, but is merely difficult. She is the author of one of the top project management books in the US, “Scrappy Project Management - The 12 Predictable and Avoidable Pitfalls Every Project Faces”, growing in popularity around the world, and published in Japanese by Nikkei Business Press. The founder of Wiefling Consulting, LLC, she consults to global business leaders. She spends about half of her time working with high-potential leaders in Japanese companies, facilitating leadership, innovation and execution excellence workshops to enable Japanese companies to solve global problems profitably.

More...