Technical and Nontechnical Challenges of Being a Chief Engineer, a Candid Conversation with Two CEs (Part 2)
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.
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.
Sign up for the free monthly LPPD newsletter by creating a secure profile on the registration page. (Customer information has never been shared or sold and never will be.): https://www.lean.org/leanpd/
Advance your career and your organization’s transformation. Reserve your spot at the Virtual Lean Experience (VLX), a 10-week, in-depth course of study that begins September 14, 2020: https://www.lean.org/summit2020