The Upside of Being Thrown Into the Fire

by 

| April 4, 2012 | in

During a recent one-on-one session, I had a discussion with one of our engineers about her role as “build master” for one of our companies. In this role, she was responsible for building the initial project architecture, and setting up and managing most of the TFS build definitions. But as various project components changed, she had to make sure that any affected aspects of the build process were also changed. We talked about how we might be able to transition that role to someone else, like a new hire. She mentioned that it should now be more manageable because the job was more about maintenance than development.

We went on to discuss the advantages and opportunities of having to deal with all of the pain of getting the build environment up and running instead of just maintaining an existing one. In short, this experience exposed her to all the aspects of the application, and she now has a greater working knowledge of this product than almost anyone else.

This is one of the things I love about being in an environment where these types of opportunities are available. Even if a person may not initially know how to accomplish something, they can give it their all and persevere with the tools and talents they already possess. And in the end, they come out with so much more knowledge than can be taught in a classroom. The kind of experience gained from being “thrown into the fire” can be priceless.

I first experienced this more than 20 years ago when I was working at McDonnell Douglas in St. Louis. As a senior weapons integration engineer on the F/A-18 project, I was assigned to be the lead engineer on a project to integrate the SLAM missile with the aircraft. The missile itself was brand new and this was the first attempt to integrate it with the F/A-18. When I got involved with the project, the software had been in development for about a year and was nowhere near ready for any sort of testing outside the lab. I spent a large part of the next year going back and forth from our testing labs to the software engineers fixing problems, diagnosing issues, making modifications to the design, etc.

After that first year of experience, I knew the missile, our software, and the F/A-18 stores management subsystem inside and out. When something came up during field testing, I almost always knew exactly where the problem was and what the likely fix would be. When I left that program, I handed off responsibility to a colleague. He never had the “opportunity” to troubleshoot the system to the breadth and level I had and, consequently, it took him a very long time to become comfortable with it. I frequently found myself answering questions on details of the system long after I had left the program.

There is no doubt in my mind that the fastest way to being a product platform “guru” is to be heavily involved in bringing a system from instability and chaos to stability and order. It will be exhausting, frustrating, stressful, and annoying, but you will likely learn in one month what will take years for others to acquire. You will also come out on the other end as a more versatile and valuable team member.