Missed part one, watch and listen here.
At the center of a Lean Product and Process Development effort is a single responsible leader called the chief engineer who heads a team that creates the new product or service concept, develops the business case, conducts the technical design, manages the development process and takes it into production, coordinating the effort with production engineering, sales, and marketing.
Chief engineers typically have strong technical skills to effectively lead and manage the work of engineers, designers, and other developers. But perhaps their greatest talent needs to be nontechnical, an observation that emerged in this interview with two chief engineers from TechnipFMC, conducted by LEI Communications Director Chet Marchwinski at last year’s Designing the Future Summit. The interview was edited for length. Read the full version here.
Alan Labes is chief engineer of the Subsea 2.0 platform and the company’s first-ever chief engineer. He has held leadership roles in product development, engineering, and systems engineering. Allison Weber is the chief product developer of the Subsea 2.0 “tree” product lines. She has held leadership roles in several subsea tree projects and product development groups. In the first Q&A, they discussed how their responsibilities for managing and leading product development teams changed as CEs. Today, they discuss the evolution of the critical obeya process, which is centered in a war room for sharing information visually.
Q: How did the obeya process begin and evolve?
Allison: The obeya definitely changes with time. As you transform between different phases of your program, your obeya should change and transform along with it to communicate the latest problems or bring the right people together to solve problems. For example, in the beginning, when you’re in heavy conceptual development, trying to figure out what your vision or what your targets are going to be, you’re going to see a lot more theoretical concepts, you’re going to see a lot more trade-off curves being developed and knowledge gaps being communicated.
As we worked to close those knowledge gaps, we had our obeya change into bringing the procurement and engineering teams to work together and release parts, get prototypes made, and be able to test against our knowledge gaps. We used models or pictures of our fixtures with all the different parts on them so the procurement team could physically see what they were buying. Before, they just got a list of parts. By being able to see them, they could quickly point at something and say, “That’s going to take us six weeks to get.” That’s your critical item to get released first.
The other big thing in the obeya was the way we managed our schedule. When I set it up, I had it the way I thought was best, but the team just took it over and made it their own. It’s just so much better now. It’s what they want it to be, it’s what they use and they take a lot more accountability for their tasks that way as well.“If you go to an obeya and you see the same handwriting on the entire wall, it’s failing because it’s not being used by everyone. When you walk up to our wall, I’m very proud because there’s really clean handwriting and really messy handwriting. You can just tell that the entire team is contributing.”
Q: Alan, how about your experience with obeya? How did it evolve?
Alan: When we started obeya, it was very traumatic because we didn’t know what to do. We just knew that we had to have everybody standing up in a room looking at a wall and solving problems. So, there were a lot of discussions and people arguing but over time we learned to surface problems and work together to solve them.
Leadership behavior is extremely important at this time because if a problem is surfaced and you slap someone’s hands instead of offering help, then the problem will not be surfaced again. But eventually, it will come back to get you. So, the obeya is our tool to detect normal from abnormal to get back on track.
One other thing that we do is have the team work inside the obeya. We believe strongly in the power of team co-location. So the obeya is not just the location where you go to meet but also where you work. Having the team work together is extremely powerful. The information flow is faster. You can work on multiple product elements together; you can see if one component interferes with another. For complex systems, the more you can collocate the better. The challenge is you can’t do that on a project that has 200 people as on Subsea 2.0.
Q: Do you use video conferencing to bring in people from the outside for an obeya meeting?
Alan: We have something we call the magic table in many of our obeyas. It’s nothing more than a big table made of glass that you draw on to project the drawing. It’s a really good tool because engineers love to draw. Once somebody sits at the table, other users sit around and they suddenly start discussing problems and sharing them with others. We use a lot of video communications tools, but they are not as effective as being present. The more I can put people at the same location, the better. It minimizes interfaces, and it’s better for the project as well.
Q: You’re building a product that sits at the bottom of the ocean and working with engineers in a highly sophisticated environment. How did they react when you told them we’re going to start putting paper on the wall, and we’re going to use stickies. How did that go over at first?
Alan: There’s an interesting story about that. We started to look at some other companies with the Lean Institute in Brazil helping us. We sent an engineering systems manager to visit Embraer, which is an aircraft manufacturer. And they are very advanced on lean processes and tools.
Our director asked this guy, “What did you like? What didn’t you like? How are they?” And he said, “They were very good except at scheduling. They put papers on the wall. We put everything on the computer. We know exactly how long everything is going to take.” Our director said, “But we suck at delivering on time and these guys are much better so maybe there’s something there.”
We started to experiment, but it took us a very long time to only rely on the paper schedule on the obeya wall. We duplicated the computer plan on the wall, but we were doubling our effort because we had to fix the wall schedule and the computer schedule when they would not match. Eventually, nobody was looking at the computer anyway, so it faded away by itself.
Q: Allison, how did your team react to the obeya the first time?
Allison: Some were excited immediately that there was something to give back accountability to engineers because they wanted that change. But most sat cross-armed, stared at the wall, and just went with it because we were telling them this is the new way we’re going to work.
The way we used to work as Alan said, was you’d have a schedule in the software program made by a planner based on a historical schedule that we’d copy and use for the next project. So, many people never had to think through their tasks. They were only told what was the next thing they were going to do.
When you shifted the expectations to say, “We have this vision for our next big goal for the team. Can you please plan out what you want to do and be accountable for that.” I think there was just a knowledge gap. People weren’t trained or ready to start thinking like that.
Doing the paper schedule with sticky notes has developed people so much. You can just see how much stronger people have become — not just engineers, but designers, and analysts. They could all interact in the daily meetings to more clearly understand how their work affects the next person. On a previous project where I was lead engineer, everything had to go through me to get delegated. Now I’m noticing that the designer and the analyst will work directly together, looking at the model. It’s taken out that wasteful step of having to go back through certain people to finish a task. That’s been one of the biggest successes.
I always remembered, [Lean Product and Process Development Coach] Eric Ethington saying that if you go to an obeya and you see the same handwriting on the entire wall, it’s failing because it’s not being used by everyone. When you walk up to our wall, I’m very proud because there’s really clean handwriting and really messy handwriting. You can just tell that the entire team is contributing.
Designing the Future
An Introduction to Lean Product and Process Development.
