At the center of a Lean Product and Process Development effort is a single responsible leader called the chief engineer who heads a dedicated 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 skills are nontechnical. To discuss that and other facets of the job, LEI Communications Director Chet Marchwinski talked with two chief engineers from TechnipFMC at last year’s Designing the Future Summit.
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 project and product development groups. First, they discuss how their responsibilities for managing and leading product development teams changed as CEs. Then, they discuss the evolution of the critical obeya process, centered around a war room for sharing information visually. This story originally appeared on the Lean Post as a two-part video Q&A.
Q: Alan, you’re the first overall CE and Alison is a CE on a critical system of Subsea 2.0, a major product. What were the key challenges for each of you in these roles as chief engineers?
Alan: We heard a lot about “You need to lead without authority.” What does that mean? My role was very challenging because [Subsea 2.0] is a very large system and we always expect the chief engineer to be somebody extremely technically knowledgeable about the product. But when we assembled this whole team together, most of the time, I would think, “I am the least knowledgeable guy in the room because we have experts for every subject.” For instance, Alison is an expert on Christmas trees.
For me, it was really hard to get this thing about leadership without authority. It started to gel once I could convey to the team what was the vision I had for the future of the company and how this product should transform the whole company. It was high level but broader that would touch every product consistently, so they all share the same single vision. That’s when we started to gel. Then we needed to have mutual respect for what each one of us was bringing to the project.
Q: Allison, I’d like to get your opinion on your role. But give viewers a little background on what the product is.
Allison: A Christmas tree’s function is to effectively control the flow of oil and gas from the wellhead, which goes into the ground, out to what we call a flow line jumper. Within the product, we have a number of components that are shared across the system. We have subsea manifolds that share the same valves as my tree, for example. So that’s one area of the program that was a challenge, but also an opportunity to use those common components to standardize the product line and make the entire system configurable and simple.
Q: And as a CE what were your challenges?
Allison: The way it was explained to me was, “You’re in charge of developing this product and its value stream.” My biggest challenge was wrapping my mind around what that means; what is the value stream of a tree. And do I understand everything about that flow. As Alan was saying, you have to lean on the experts around the organization. We knew how to get things to a strong technical state, but then we would pass these other process developments to the rest of the organization historically. So being able to tap into that knowledge for supply chain and sourcing or manufacturing processes and things like that has been one of my biggest challenges as a chief engineer.
Q: You’re both experienced managers and leaders, but as CE’s what changed about the ways you managed and led?
Allison: Being given responsibility for a product changed the way I cared for how development succeeded. Historically, you’re graded on meeting schedule and budget, for example. But having the product be the center of your development was a shift. It changed the way that I lead and communicated that vision back to my team to make sure that we are all product-focused and that the decisions we made were the best thing for the product and not the best thing for short-term gains, schedule, and budget. The long-term effects of what we were doing were so substantial that having that foresight early on was important.
The other thing that changed was we wanted to expose problems and be transparent about them. When you ask that of your team, it’s important that you don’t just ask for people to tell you problems, but you work with them to solve problems. That takes a lot more time and energy. It’s a give-and-take and it’s developing trust with your team so when they tell you a problem, you have to really be by their side and help them solve it.
Q: Alan, how about you? What was different about the way you managed and led?
Alan: Allison touched on it; the chief engineer needs to deliver a new value stream for the company. Before we were doing engineering for a project, so it’s short term. When you think about what it means to deliver a value stream, it’s connected to the sustainability of the business, to the strategy of the company. So at the beginning of the project, we were talking about the sustainability of the industry. What we wanted to do is change the industry.
So in the chief engineer role, we go from what we want the product to look like, to the details of how does it perform, how we are going to manufacture it, are the clients going to buy, how you are going to do the marketing, how are you going to service it in the future?
You need to rely on the experts in every discipline to make it happen. So it’s a big task on engaging everybody to align on that vision and leading, as they say, without authority. How do you promote this leadership? I think it’s conveying the vision with passion. You need to have passion for the product, for what we’re trying to do, and this passion has to permeate the organization.
Q: It’s no longer “just do it” because I said so.
Alan: Yes, because the engineers, they are amazing. I never did what I was told to do. We are rebels. I hope my boss doesn’t watch this, but I always did what I wanted and I think everybody will always do what they want. You can only get what you want with alignment. So product development pulls the alignment and the tool is passion — passion for the outcome, for the vision. Passion for the product is an extremely important skill for a chief engineer, not only to have it but also to convey it.
Q: How did the obeya process begin and evolve over time? Did it change as you learned?
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 in order for you 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 more into bringing together the procurement and engineering teams to come together and release parts, get prototypes made, and be able to test things to know if they worked or didn’t work against our knowledge gaps.
Q: It’s a good idea to have engineering and purchasing collaborate upfront like that then.
Allison: If you don’t, you lose so much time that you gain by just talking and communicating daily. 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 and had no idea what was the biggest part on the bill of materials. By being able to see parts, 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.
Q: Were the models to scale?
Allison: Some but not all. Some of these fixtures were fairly large. But by giving procurement an indication of what you’re buying, they can quickly tell you what they need from you first. That way you can really work together.
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.
Q: Alan, how about your experience with obeya? How did it evolve over time?
Alan: When we started obeya, it was very traumatic because we didn’t know what to do. We just knew that we get had to have everybody standing up in a room looking at a wall and solving problems. So, there was a lot of discussions and people arguing. I don’t know if it was Brazilian Latin blood that got aggressive, but over time we learned more about surfacing problems and getting 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’s going to 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. Once you have co-location, 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 the 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 are very poor. They put papers on the wall. We put everything on the computer. We know exactly how long everything is going to take.” And then, 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 the thing vanished. It faded away by itself.
Q: Allison, how did your team react to the obeya the first time?
Allison: Some, immediately were excited that there was something that gave engineers accountability back because they wanted that change. But most sat crossed 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, in my mind. 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.
