Teamwork & Socio-Technical Systems Engineering.
MIT System Design and Management (SDM) and University of Tokyo.
Show notes
- Interview with Bryan R. Moser – The nature of teamwork via the study and design of socio-technical systems: http://www.mit.edu/~bry/
- Academic Director and Sr. Lecturer, System Design and Management (SDM) @ MIT: https://sdm.mit.edu/
- Associate Director, Strategic Engineering Research Group @ MIT: http://strategic.mit.edu/
- Project Associate Professor, Graduate School of Frontier Sciences @ the University of Tokyo: https://www.k.u-tokyo.ac.jp/index.html.en
- Director, Global Teamwork Lab @ the University of Tokyo: https://gtl.edu.k.u-tokyo.ac.jp/home
- Founder of the company Global Project Design (GPD): http://www.teamport.com/
Time stamps
| 0:00:00 | Introduction |
| 0:00:57 | Bryan’s self introduction |
| 0:01:35 | Bryan’s mission |
| 0:02:00 | Bryan’s career |
| 0:02:32 | How to distribute the engineering? |
| 0:04:00 | Decomposition and design of a product |
| 0:05:12 | Teamwork |
| 0:06:50 | Steps of Bryan’s Career |
| 0:08:42 | Entrepreneurship journey |
| 0:10:35 | Transition to teaching and research |
| 0:12:00 | Advice to novices |
| 0:14:40 | The underlying physics of complex systems |
| 0:15:35 | Bad advice to ignore |
| 0:17:15 | Opportunities and Challenges |
| 0:18:15 | Failures to learn from |
| 0:20:15 | Conclusion |
Transcript
Joshua: Hi, Bryan. As part of these interviews I’m trying to offer guidance and encouragement for people looking at careers in designing, making, and maintaining systems from people who’ve already had successful careers in the industry. I wondered if you’d like to introduce yourself more formally and explain what you’re doing right now, and any kind of mission you’re on.
Bryan: Mission. My name is Bryan Moser, and I’m the Academic Director of the System Design and Management Program at MIT, and a senior lecturer there, and I’m an associate professor at the University of Tokyo. My mission is engineering teamwork in bottom line. I’ve had a career where I spent 25 years in industry. I was educated as a computer scientist, very interested in problem solving and AI, but in my case that interest became how do teams of people use computers and use analysis for dealing with complex challenges and problems. I found myself in industry always being part of large engineering projects.
I was an AI engineer at Nissan, and at Nissan I worked on introducing different kinds of knowledge-based neural network and other computer technologies into the product development process. Then I joined United Technologies and my job was to build a technology and research team where all of our projects were partnership-based. For UTC we worked on aircraft engines, helicopters, building systems including elevators, chillers and air conditioners. My work was trying to figure out how to distribute the engineering which is fundamentally a systems problem, and there’s a question of decomposition of both the function and technical form of the system, but also the choices, some limited choices around the distribution and roles of the engineering organization.
In order for me to solve that problem, I had to think simultaneously about system choices both on the technical and the social side, and I began thinking in an integrated way about engineering teamwork as a socio-technical system. What I’ve been trying to do more recently is to not only build new models and methods to support engineering teamwork, but to use these same platforms to explore the nature of teamwork itself. So now that we can see how teams interact, what they pay attention to, the decisions they make and so forth through these platforms, which are heavily sensor-based or instrumented, we now have a way for the first time to look for the underlying physics of teamwork to a very granular level.
Compared to 10 years ago where I was predominantly interested in engineering method and model-based reasoning, I’m now balancing that with a lot of empirical work based on these systems to understand what’s happening not only in the problem solution space but also in the social space. That’s my mission is to improve engineering teamwork.
Joshua: How do you sell the idea of using these empirical methods for looking at a lot of the teamwork? That’s quite different I think than a lot of engineers who are so focused on the decomposition of a product and designing a product.
Bryan: I was equally skeptical early on that what we often consider is being qualitative or soft issues could somehow be represented and handled and predicted, because obviously if we can’t forecast a phenomenon, we can’t design with it or for it. Then I began to realize that first we understand especially an experienced engineer that these issues are extremely relevant and significant, that a perfectly decomposed system with interfaces well defined, with requirements that are traceable, validation, all of these things done properly is not sufficient for good performance. There’s a lot of other things that occur too.
I realized we have, you know, as an experienced engineer we deal with it anyway, and we must deal with it on complex systems, but a second key idea became very important, which is that in fact we do represent these phenomenon. We often represent them with ad hoc mental models and gross oversimplifications or with the law of averages. For example, in something as simple as and looking at the influence of subsystem complexity on rework and the overlap of rework and team experience, if we don’t explicitly treat and consider this, our assumption may be that there is no rework, which is an absurd simplification and so on.
I really began to, and in talking to others as well, say that, well, by not explicitly dealing with these phenomenon while we know that they are critical, we are indeed making an assumption and a gross simplification which almost by definition is likely to lead to a far worse result.
Joshua: Yes, because with model-based systems engineering by trying to take tacit knowledge and explicitly model it, and if nobody’s looking at the team working aspects, …
Bryan: That’s right.
Joshua: … there’s just this vast amount of knowledge which we’re not capturing or processing.
Bryan: Well, that’s right. By the way, these social, structural, and elemental phenomenon don’t exist separately on their own. They are relevant with respect to the particular technical decomposition, technical elemental and topological complexity for the system at hand. For example, on the social side the roles and responsibilities, or structure of the organization, and the experience of teams with certain skills may or may not be relevant given the particular aircraft, new technology-readiness that they’re addressing, so we have to think and look at both.
Joshua: You alluded to various aspects of your career, coming from America, to Japan to Nissan, and then onto UTC. I wondered if you could take us through the steps of your career, because I think it is quite unique. You set up a company and now you’re a professor.
Bryan: Right. It’s funny. I suppose my expertise is planning and project management for engineering, and yet I can’t imagine anything I’ve done has been very planned over the last few decades. I think the first turn, a positive turn was that although I’m a computer scientist I was immediately in a factory as part of a product development and manufacturing organization, and growing up, like many of us, I love engineering. I love building things. My heart went pitter patter being close to the car. I fell in love with being part of teams that were building real things.
In that time and turning to UTC as well, the chance as a computer scientist to be involved in six month to two-year, real-world, cross-functional team product development projects was just, for me it’s just fun. Well, that for me in the period of time after I was at Nissan, at United Technologies, centered on the notion of globally distributed research, engineering, and product development, and how to treat that from a design point of view. For UTC I was based in Tokyo at the time, and I came to know through the ministries and the universities some of the different faculty including Professor Kimura at the University of Tokyo, who was in seimitsu kikai which is precision machinery engineering, and he became a real mentor.
He comes back into the story a little bit later, but as I was working at UTC, and it was clear probably from my UTC career I should come back to the US, which I did, I was still very, very interested in solving this problem deeply. I decided to set out on my own and to start a company that focused on both modeling and simulation using a combination of agent-based and some other simulation techniques to develop concrete methods for the design of global projects.
In ’99 I started GPD, Global Project Design, which has built a platform called TeamPort, and TeamPort is a project design platform that is meant specifically for cross-functional teams to model their project as a socio-technical system to be able to predict its outcomes, costs, schedule, and quality, and therefore to, in a model-based way, to iterate rapidly around different ways of organizing their work, and organizing their teams as part of it.
As an entrepreneur coming from a large company, you learn many, many different lessons about what it means to build a product, and again, over the next 15 years across hundreds of applications I was able to test these ideas in hard manufacturing, continuous processing, finance, telecom, aerospace, automotive, pure services. I was able to see in many countries around the world and in many contexts what aspects of my underlying TeamPort platform and method for project design, what were universal and useful, and it was like constant validation, and which were not. We’ve had a continuous improvement over that 15 or 20 years to do so.
Now, when I built that company, I built it in the United States because building a company in the US is a whole lot easier than in Japan, but now we have a corporation, a Kabushiki Gaisha (KK), in Japan for GPD and a corporation in the US. We’re starting a GmbH in Germany as well. To me I’m a professor now because Professor de Weck at MIT saw the work I was doing and asked me to come back and support the work in SDM. One of the amazing things about MIT is that we’re encouraged to keep a foot in the real world, and a lot of faculty have their own companies or are doing consulting work, or are working in …
Even though I’m a faculty member at University of Tokyo, and I’m directing the program at MIT, I’m still every year involved in real-world cases, and to me that balance is so much fun. The other part of the story is I mentioned Professor Kimura, so along the way I was supporting an international manufacturing, intelligent manufacturing program. He invited me to do research and then get a PhD at the University of Tokyo. I did that, and eventually transitioned as Professor Kimura retired to another Professor Yamato who’s in the Graduate School of Frontier Sciences, and when I received my PhD they asked me to be in the faculty.
As you know, at the University of Tokyo our work is more research-based. There’s less of a teaching obligation, although I do teach two classes at Tokyo. I’ve been able to build a laboratory called the Global Teamwork Lab to really begin to extend this systems thinking, model-based, and now empirical work on what happens when human teams in collaboration work on complex problems. At Tokyo, we’ve got the lab GTL, and at MIT I spend most of my time teaching and doing some research, and somehow I’ve been able to make it fit together. Again, none of this could have been or should have been planned. I would never have modeled and simulated my own trajectory over the last two decades.
Joshua: Thank you. If you were offering advice to a novice wanting to enter this field of systems design, systems making, systems maintenance, what would you give them either to yourself when you were younger or just someone right now?
Bryan: I think the most fundamental advice is to live project-by-project, that is the experience of a real system and the unique nature of uncertainties and trade-offs and where the interfaces lie, and all that building a portfolio of different kinds of complex systems against which one’s applying these skills is at the heart the most important advice. What that should encourage is more humility and less SysML, which is that the journey is not in fact to come up with a universal language and a way to optimize all this. I think that the more one deals with genuinely and naturally complex systems, actually humility should increase.
Now, at the same time the toolbox and the thinking that we’re developing and now the emergence of also a strong empirical part of this should continue. Given a core thread of a series of experience dealing with different types of complex systems, then one should debrief, one should interpret the experience, not interfere with the experience, but interpret the experience through the lens of theory. Going back and forth is actually very valuable. Whether it’s model-based reasoning, different classes of systems, ontology, understanding complexity science, information theory, and so forth is … I think where we are in the stage of this field is that we have yet to really uncover the first principles or the physics of engineering systems including humans in the loop.
I think one could get carried away. It’s quite easy, this is really intoxicating stuff theoretically, at least for me. I could really dive deeply in just thinking about the theory, and it’s fine, but the humility requires us to realize that we need to balance time spent admiring the problem in the field, experiencing and feeling the natural complexity and the dependencies in these systems, otherwise we are drawn into a black hole of abstraction and meta-theory, which can be very self-satisfying but doesn’t necessarily move us forward.
Joshua: Yes, and so balance that out. People have these overview theories or these very grand theories, it is very nice to be able to start to hang experiences one has had in the real world on them, and equally use them to choose what to do next.
Bryan: The frameworks serve a role to stimulate a dialogue, yet we should never confuse these frameworks with the answers, because they aren’t yet at least the … They aren’t indeed the underlying physics. They’re some sort of skeleton or approximation to try to help us explain hints. It also just tells us what our, in this generation, what our requirement is for moving the profession forward, which is to go beyond practices and methods, which gives us shadows of what we think might be there, and we really need to push to a genuine science of complex systems.
Joshua: What would be some bad advice you hear given, which you would recommend to ignore?
Bryan: Bad advice that’s given. Start with the objective function. How about that? That’s the first one. Kind of this notion that this is, in the end, about optimization, I think, is not quite right. In terms of career development, bad advice would be the belief that at least as industry stands today that system engineering at least is a career track. I think it is not. It is a capability. The application of systems thinking, methods, and tools should be recognized as useful in a range of functions of the firm or organization.
Now, and one of those functional roles is in fact sitting at a point of integration, which is at a system level, whether it’s in examining the needs and demand side, or in fact playing a role in the development of a solution, but that’s just one of many roles which need to understand and respect and practice systems approaches. In career development just because one happens to be for this phase of one’s life in, let’s say, marketing, or in manufacturing, or in supply chain, or something, that doesn’t mean that one is not practicing systems. In fact, just the opposite.
Likewise, if one is somehow anointed by title to be a systems engineer or integration lead, one should not somehow dismiss the necessary systems perspectives and contribution from the other functions around. That’s my advice.
Joshua: What would you see as the biggest opportunities or challenges in this space right now?
Bryan: For me it’s easy, I mentioned before how I’m now trying to move beyond modeling and simulation to balance it with empirical work. The opportunity is to back up what all of us think is true. We claim this is what happens in engineering, this is what we claim, this is what’s happening. It’s time for us to get empirical, and it’s time for us to … I don’t want to just simply do an experiment and have a one-shot regression, and look for what’s happening. I think we need to be able to understand in the moment in a real project based on what’s happening both in the problem space, the solution space, and in the social spaces what is the current health of this socio-technical system. I want to know what’s really going on, and I want to see at a level of granularity that allows us to really uncover the first laws of complexity as applied to human-in-the-loop complex systems.
Joshua: Yes. Very unique I think. Everyone has failures along their journey and their career. What would you say were some very important ones for you and what did you learn?
Bryan: Failures. Boy, let me count the ways. As you get older you realize they’re not really failures. I mean they’re things that were painful and they were not successful, but one general mode of failure that I exhibited too is that after my PhD, so I had built a particular modeling framework and simulation engine with agent-based stuff, and I was treating particular phenomenon in how engineering teams behave. Because when you do a PhD it becomes woven into your DNA. This is something that intuitively in your sleep you know what’s happening in the model and so forth.
I became so convinced that this was the best thing since sliced bread. When I started my company, especially in the first two to three years I always led with the solution. Because I was now, I thought, the expert in this stuff, people should just believe me, and that’s a huge mistake. This probably ties back to my prior comment on humility in the face of genuine, natural complexity is I probably delayed the success of my company at least a year, and that’s a lot of money in startup terms. It’s a lot of retirement gone, because of a stubbornness born of typical post-PhD arrogance.
I mean it’s not arrogance, but it’s just you’re too close to the solution and you forget to pay attention to what you would normally do when admiring a problem on the front end of work. That’s one thing. I think that’s probably the primary thing, because I’m thinking about your question in the context of systems-related careers. I can’t think of many mistakes because I don’t think, again, this … I think it would be a mistake had I stayed in one country, if I had stayed in one company, if I hadn’t been open to put myself in uncomfortable positions in different sectors or different problems. I allowed over time the thread of what I’m about today and the things that I care about and what my identity are to emerge. If I had tried to plan it, I probably would have screwed it up.
Joshua: Thank you very much.
Bryan: Thank you. It’s great. I’m going to look forward to talking some more.