We learn through experience. This was the main concept that stuck with me after completing the INCOSE Institute for Technical Leadership. And as I look back at my first job and the environment in which I worked, I realize that it was those early experiences that developed me into the systems engineer I am today.
My boss gave us problems, not tasks
At my first engineering job, I worked for a small company where we primarily focused our efforts on the delivery of prototype systems. It was always interesting because you never knew what was coming next. The boss would come to you and present problems like, “Create a user interface for this process controller,” “Create a stepper motor driver to control the water brake on this dynamometer,” or “Create a device that converts these outputs from the exhaust gas analyzer to a time graph display on the PC.” The problems were always general, with little specification. You were left to figure it out. My boss gave us problems, not tasks.
When I was presented with the first problem, I just created a solution. Come to find out, I had done so with no idea of what the boss really wanted. That first solution did not hit the target, and I learned quickly to ask a lot more questions. After going through this a couple of times, I began to realize that I needed to present concepts of solutions that contained much more thought and detail. I started to think like the user. What were they trying to accomplish? How would they use this? What other ways might they use it? What had they not thought of?
As I crafted solutions to the problems, I started to develop a methodology. It started with defining what and how the solution interfaced with the environment in which it was going to operate. From there, the process progressed to thinking about functions and what the solution should do under different operating conditions. This method led me down a path of breaking up functions into small steps and sequencing them from inputs to outputs until I had a relatively complete plan of how I was going to approach a solution.
Implementation took the most time, but I always had an idea of what the solution was supposed to do and could test it along the way. The tasks of putting the solution together became more like putting together a jigsaw puzzle than work. The focus became the challenge of getting the solution to do what we wanted it to do. This became the fun, driving force to get things done.
After a period of time, the problems stopped coming from my boss. This is because he knew that by that point, I had developed to where I’d have fully fleshed out ideas about the way things might be. I started to present problems to my boss such as, “Let’s change our communications standard from RS-232 to CAN,” “Let’s reduce the size of our products by switching from through-hole components to surface-mount components on the printed circuit boards,” or “Let’s add computer-aided testing to the manufacturing process,” etc.
The beauty of this environment was that not only were we granted the freedom to explore these and many other ideas, but we also supported one another in the exploration. When ideas came up, we built on each other’s thinking, tossing the ideas back and forth. As issues arose, we were there for one another to help resolve them even if we were working late into the night. We gathered differing views from the front office, manufacturing, mechanics—every part of our operation. We were excited about what we were doing because we were all part of it, and that led to a true interest in developing solutions that better matched the need.
Understanding interactions and relationships enabled the development of the best solutions
While I did not realize it at the time, all the activities I was doing were in line with systems engineering principles.
I was developing and validating requirements through problem definition and elicitation activities, and working them back and forth between abstract and specific. I was architecting solutions into functions, interfaces, and components, all the while considering decomposition and aggregation. I was performing verification of the solution at many different levels and in many different ways as I went along.
I was thinking systemically. Considering multiple viewpoints made me more aware of people’s needs. I was able to construct definitions around these needs and present opportunities for consideration. Identifying emergent behavior before we got to implementation prevented a number of major issues. Maintaining the understanding of the whole as I architected up and down into the pieces allowed me to develop flexible solutions to work across many problem spaces. Understanding interactions and relationships enabled the development of the best solutions.
I developed all of these skills as a result of the opportunities presented to me in that environment.
A work place where one solved the problems of features, functions, needs, and behaviors—not tasks
I remember giving a demonstration of a process controller and its user interface to our customer. I was super nervous. It had to work. I did not want to let my boss down. To my amazement, it went well. Everyone was happy and had big smiles on their faces. We even had a little celebratory drink.
When we got in the car to return to the office, my boss congratulated me and let me know he was truly happy with what I had done. The discussion quickly turned from celebration to brainstorming. He posed the question, “What are we going to do to top that next time?” He threw out an idea and I responded with another. The conversation continued this way until we got back to the office.
I quickly went in and started writing the ideas down, creating concepts, and building on ideas. It was intense. I remember not getting home until very late, and I was back in the office early the next morning. I couldn’t wait to get started on developing the next feature.
The environment at that company was unique. It was a work place where one solved the problems of features, functions, needs, and behaviors—not tasks. You were encouraged to explore. People were supported and encouraged to build on one another’s ideas. You had a hard time leaving at the end of the day and couldn’t wait to get there in the morning. It was such an environment that created this systems engineer.
I believe that just such an environment—of direct experiential learning, gentle guidance while trusting one’s employees to innovate in the problem space, fostering collaboration among employees, and encouraging young employees to take initiative—is the best training for a systems engineer. What do you think?
If you would like to find out more about systems, systems engineering, models, or model-based systems engineering, download a free electronic copy of A Primer for Model-Based Systems Engineering.
