Saturday, August 28, 2021

What I Learned at Smith Tool about Enterprise IT

This post continues my series looking back to lessons learned in my career, which started in 1974 at Macy’s headquarters in Manhattan and continued at TRW Credit Data in California in 1976. This post takes me to the next step of my journey.

As noted in the first post, my goal is not just talk about how technology has changed. Everyone knows that. As incredible as those changes have been over my nearly half-century in the business, it is also fascinating how many things have not changed. Many of the lessons learned still apply today. That’s my focus.

Getting Restless

Although TRW was a great learning experience, I only stayed there for about 18 months. I was getting bored with accounting systems, and I was looking for something where I could continue to develop new skills. I read in Computerworld that manufacturing systems were the next big thing, so in 1978 I started another job hunt.

One of my interviews was with Smith Tool, a division of Smith International, an oil tools manufacturer in Irvine and, at the time, the third-largest employer in Orange County1. They made me an offer, and I accepted. In addition to being able to break into manufacturing systems, the fact that I might be able to somehow apply my degree in geology was also attractive2.

Lesson Learned: Take Charge of Your Career. In the 1970s, our elders commonly advised us that the best way to get ahead was to settle down in a large company and stay for decades. Although that worked for some of my peers, it never resonated with me. I never waited for opportunities to come to me. I would rather be proactive and pursue new directions. For young people, today is no different. Always be thinking about what you need to continue your career development. If your current employer can give you that, great. If not, look elsewhere.

Thrown into the Deep End

The entire IT department at Smith Tool was about 30 people, with 15 of us in application development3. The company’s systems ran on two IBM mainframes. The manager of the applications group was Rodger Beard, and he assigned me to the supervisor of manufacturing systems, Ken Ruiz.

On my first day, Ken sat me down to give me a primer on manufacturing systems. I was totally clueless. Using a white board, he explained the concept of part masters, which defined inventory items—whether finished products, intermediate assemblies, or purchased parts. He also explained product structure records, which defined the relationship between part masters to form bills of material. The capabilities to manage these relationships required a special type of IBM database, known as BOMP (Bill of Materials Processor) and the newer DBOMP (Database Organization and Maintenance Processor). He then went on to explain work centers and routings, which define manufacturing processes.

Later that day we went out to lunch. I drove, with Ken and two other co-workers in the car chatting about something called “whip.” Finally, I asked, what is “whip?” Work-in-Process (WIP) was the answer. As I said, I was clueless4.

The next day, Ken gave me my first assignment—to customize and implement the MRP module of COPICS5, which was written in IBM assembly language. This was my first encounter with any type of packaged software, although it wasn’t much more than collection of assembler source code known as an IBM Field Developed Program, which just meant that an IBM-er wrote it for some customer and now it was available to others. The IBM engineer who wrote it just happened to be assigned to Smith Tool. His name was Roly White6.

My assembler skills were a bit rusty since I had only used them sporadically at Macy’s two years prior. But within a few weeks I had made the necessary modifications and even found a bug in Roly’s code.

I absolutely loved manufacturing systems. They were so much more interesting than accounting systems. I looked forward to going up into the plant mezzanine for meetings with users. I would don my Red Wing steel toed shoes, safety glasses, and ear plugs, and take my time getting to and from the meeting so I could stand and watch row after row of multi-axis milling machines or modern CNC machines throwing metal chips on the floor7.

Not Smith Tool, but similar, and much smaller. 
My crash course in manufacturing was not limited to on-the-job training. Within a few weeks, Ken mentioned the monthly dinner meetings of Orange County APICS, the American Production and Inventory Control Society (recently renamed as the Association for Supply Chain Management, ASCM). About half of our department would attend each month, and the dinner meetings drew several hundred people. The legendary George Plossl spoke at one meeting and visited us at Smith Tool the next day, where he fielded questions. (I remember one on how to plan capacity for a heat treat operation.) I also enrolled in a four-course series of APICS certification classes at night at Cal State Fullerton, where we learned principles of inventory management, MRP, master scheduling, statistical forecasting, and other basic concepts. My favorite class was the final one, taught by Nick Testa, which tied everything together. Nick went on to become President of APICS International in 2006 and the chair of the APICS international conference8.

Within two years, I was APICS-certified at the Fellow Level, a real accomplishment for someone who only two years prior didn’t know what MRP or WIP stood for.

Lesson Learned: Build Your Industry Experience. If you are going to be an expert in business applications, you need to build your industry credentials. For IT infrastructure, this is not as critical a requirement. But when it comes to applications, most employers favor those with industry specialization. This is even more critical for consultants. If you have experience in ERP systems for manufacturing companies, for example, that doesn’t translate to ERP in charitable organizations or hospitals. In the course of my career, I gained experience and credentials in several manufacturing sub-sectors, such as medical devices, pharmaceuticals, food manufacturing, and high-tech, among others. This doesn’t mean you can’t specialize in multiple industries, but don’t try to be a jack-of-all-trades.

Moving to the Front End of the Software Development Life-Cycle

SDM-70 Methodology Schematics
As noted in my earlier post, I was formally trained in software engineering during my time at TRW, mostly around system design, development, and testing. Soon after I arrived at Smith, the department standardized on an SDLC methodology called SDM/70. It consisted of about four feet of three-ring binders, with forms and instructions for each phase and step of the development process, from initial feasibility studies all the way to go-live and ongoing maintenance. Rodger made me the department coordinator.

I understood the system design and development phases, but what really interested me was the earlier stages, like system requirements and especially business requirements. I wanted to get involved earlier and earlier in new projects, even to the point of helping decide whether a new system was even feasible, or whether there was a business case for it.

Over the next five years, I led a number of interesting projects, with several important lessons learned—both positive and negative. But the most interesting project of all was a Bit Record Database system, where I led the development of a new system to track the current and historic downhole performance of drill bits in the field. This system would become a key focus of my career direction over the next eight years. And, as I recently discovered, it was a strategic initiative for the company at the highest levels.

Lesson Learned: Pick a Focus. When it comes to enterprise IT, figure out where your interests really lie. No one can specialize in every aspect. Some of my coworkers went deep into coding, others enjoyed project management, others pursued a management path, while others, like me, wanted to get close to the business. This was another indication of where my career would be headed in the coming years, which included my leaving Smith’s IT department altogether and moving into the business itself. More on that in a future post.

How I Almost Missed This Career Opportunity

My years at Smith Tool were my greatest period of professional development at this point in my career. But I came very close to missing out. Here’s the story. My first interview was with a low-level HR representative, who I arranged to screen me during my lunch hour. I was very eager to get past her and on to the hiring manager. Unfortunately, she kept me waiting for nearly an hour. When I finally got in to see her, my annoyance was visible and she decided not to pass me on for the next interview. After two or three weeks, my recruiter went back and somehow convinced the HR group to interview me again. This time, I behaved myself and got passed on to Rodger. I got the job. But, without this second chance, my career could have been much different.

Lesson Learned: Respect People at Every Level. Everyone deserves tolerance and respect, from the front desk receptionist, to the warehouse worker, to the CEO. Moreover, you never know who has influence, and who can make or break your career. And, as my wife, Dorothy, points out, this lesson applies in all areas of life, not just the workplace.

But now I have discovered there is another angle to this story. After reviewing the first draft of this post, Rodger gave me some new perspective from the other side of the desk, so to speak. He writes that his memory around how I was hired (or nearly not hired) is somewhat different than mine. He writes:

As was often the case, here HR used a simple checklist of buzzwords they didn’t understand to screen candidates, rather than understanding the basic job requirements….HR didn’t want to and/or just didn’t know how to screen for (1) brains, (2) energy level with track record, and (3) integrity—what I was specifically demanding. HR would provide me two stacks of resumes each week. Your resume was in the “wrong” stack because of the buzzword score. But HR had not provided enough candidates, so we decided to bring you back in anyway, regardless of the scoring. You then answered my questions and clearly demonstrated you met my three fundamental requirements. I was pretty sure that we could provide the on-the-job training needed to close the application experience gap. That said, in all candor, I never expected that you would take the initiative that you did to close the gap to the extent that you did, as rapidly as you did.
Lesson Learned: When Hiring for Key Positions, Understand What Really Matters. A job posting today can bring in hundreds if not thousands of job applications. Modern recruiting systems, in response, can sort through them and prioritize them into electronic piles, like Smith’s HR group did with paper 40 years ago. Although we need some way to prioritize applicants, the process has to start by thinking through what really matters in qualifying a candidate—not just picking buzzwords. Fortunately, for me, I had Rodger sitting on the other side of the desk.

A Bump in the Road

My employment at Smith continued until 1983, when it took a short detour due to the oil crisis and a massive layoff. I had been promoted into first-level IT management by that time. Although I was not part of the layoff, the head count reductions meant I needed to be demoted back to a systems analyst and project manager role. Even worse, that Bit Record Database project I was leading was put on hold due to the downturn. This was too much for me, so I reluctantly took a job offer from Gemco, a now-defunct membership department store, to go back to my retail industry roots. But I was only there for a few months when I got the call from Smith to come back to restart the Bit Record project. I agreed, but only if I could do so as an independent consultant. This launched my consulting career. More on this in a future post.

Update: For the next lesson learned from my Smith Tool days, see: What I Learned from a Waterfall Project Failure.  


1Smith Tool had an interesting history. The firm was founded in Southern California in 1902, a time when California rivaled Texas and Pennsylvania in the oil industry. (You can still see oil field pumps in parts of Orange and Los Angeles counties.) Smith started with fish tail bits but eventually began manufacturing three-cone rock bits, which had been invented by Howard Hughes, who founded Hughes Tool. In 1975, Smith tried to get two Hughes patents invalidated but lost the case in 1986 and was ordered to pay over $200M for patent infringement. Using my bit record database, I worked behind the scenes with Smith attorneys during that litigation, and my analysis was submitted in court. I may share more about this in a future post. Smith Tool, along with the rest of Smith International, was acquired by Schlumberger in 2010, and is now known as Smith Bits.

2In addition to the career opportunities, Smith Tool was only about five miles from our home in Irvine. With new baby Steve on the way and only one car, I bought a 10-speed and was able bike to work several days a week, which did wonders for my cardio-fitness.

3When I arrived, the IT environment at Smith Tool was two IBM 3033 mainframes running IBM’s Disk Operating System (DOS). Smith was reportedly IBM’s largest customer running this lower-end mainframe OS. The only commercial software in the portfolio was MSA for payroll and HR. Everything else was custom batch systems, which had been developed by Arthur Anderson (now Accenture) several years earlier. Most of them had a similar design. I also began developing online (CICS) applications around this time.

4In writing this post, it was hard for me to understand what Rodger saw in me. It must have been that the demand for manufacturing systems developers far exceeded the supply. They had no choice but to train them. I think it must have also been my academic credentials, along with my experience with both COBOL and assembly language (which would soon be needed). They were also interested in my experience at Macy’s with IBM’s DOS operating system and my experience at TRW with IBM’s high-end MVS operating system. In reviewing an early version of this post, Rodger confirms that all of these factors came into play and that my DOS/MVS experience was particularly attractive. Eventually, Rodger assigned me as the co-project manager for the company’s DOS to MVS migration. My co-PM was young systems programmer named Wayne Meriwether. Since then, Wayne and I have had many business relationships: He has been my client, we have been business partners at Strativa, and after he left Strativa, he came back as a subcontractor. He remains a friend and close associate.

5I am having difficulty tracking the history of COPICS. Some sources indicate the product was announced by IBM in 1979. But I was working on the MRP module in 1978, near the beginning of the “MRP Revolution.” So, it might be that this field-developed program, written or customized by Roly was incorporated into COPICS. If so, my bug fix would have become part of the commercial product.

6Even as a young man, Roly White was a remarkable character. When he would show up, we all stopped work to hear what he had to share. He was a short, wiry guy, with the standard-issue IBM white dress shirt—but always with an unbuttoned top button, his tie loose, and a cigarette dangling from his fingers. He became a pillar of the Orange County APICS community, where he served for many years. He passed away in 2016, and there is a scholarship fund in his name.

7The larger milling machines could produce much greater volumes of parts, but they took several days to set up for each job. If you understand the relationship between setup time and lot size, you know what this means for inventory levels. The CNC machines could combine multiple operations in one quick setup, but they only produced one part at a time. Understanding these relationships led in a few years to the lean manufacturing movement, which followed the MRP revolution. Contrary to the belief of some, the two are not conflicting theories.

8 Over the years, Nick Testa and I have had many business relationships. I have been his student, and after I got certified we went on to be co-teachers and co-developers of APICS curricula. Later we became co-workers running two system integration practices, and later he became a subcontractor to me at Strativa. He remains a friend to this day.
Photo Credits

1. Creator: Robert Yarnall Richie. Credit: DeGolyer Library. Via PICRYL. Note: the rock bit here is not a Smith Tool bit but that of a competitor, Reed. They are nearly indistinguishable.  This one is a milled tooth bit, in contrast to the higher-end tungsten-carbide insert bits. 

2. CNC Machine Facility, Wikimedia.

3. SDM2 Method, which is similar to that of SDM/70. Wikipedia.


Frank Scavo said...

By the way, if any of my old colleagues (we sometimes referred to ourselves as "The Smithereens") come across this post, please leave a comment!

Wayne Meriwether said...

What a great story! I enjoyed working with Frank at Smith Tool. I was the Senior Systems Programmer for the mainframe environment. We had to support all of the software and processes that the developers used. It was an exhilirating time in my career and I learned how to manage the technical gurus that kept it all working. Great job describing the environment and the challenges.

Holger Mueller said...

This was a really interesting and fun to read Frank thanks for sharing. Looking forward to the next episodes...

Frank Scavo said...

Thanks, Holger. I enjoyed writing it, and I have another short one coming soon from the same time period. It was too much to put in this post. Hope you are well