I remember a time in my career when I mistakenly thought I knew statistics—really knew statistics. It was before I met Yanling Zuo, Michelle Paret, Eduardo Santiago, and a whole host of other statistical experts. I was a quality engineer, and I’d been applying statistics for years. I assumed that the ability to design and run an experiment meant that I understood design of experiments. I assumed that years of process control meant that I understood control charting. I assumed that I’d use this knowledge to jump on the “fast track” to technical stardom.
It does not, and I did not.
I, in fact, knew a lot about the application of statistics and whole lot about quality engineering and testing. I knew those things well, and I brought that knowledge with me to Minitab. But theoretical statistics? Nope. That I needed to learn once I got here. And the career path I ended up on? Let’s not talk about it.
In the management world, this is not a unique situation. None of us are perfect—each team consists of people with individual strengths and weaknesses. In a well-managed world, we are placed in positions that build upon our strengths, and we are given opportunities to improve upon areas of weakness.
At Minitab, we try to take a strategic and thoughtful approach to employee development. In my case, I learned through mentoring, training sessions, Minitab's Quality Trainer e-learning course, and conferences.
I then balanced that with a series of ice-cold dives into the deep end. I learn best by “doing,” and one of my learning “opportunities” came in the form of a request by Yanling Zuo, a statistician and designer at Minitab. Yanling stopped by my office with a 25-plus page, hand-written derivation of an algorithm. Her request? Rederive it and ensure that it was accurate. She then dropped off a few textbooks to enable me to “brush up” on the subject matter. After a handful of expletives, I learned. A lot.
OK—I concede that some of my knowledge of statistics is the product of blunt force trauma. Perhaps it was strategic but definitely not thoughtful.
Fast-forward a few years, and I am a manager at Minitab. I am also an engineer. I am probably not unlike most technical managers: I chose (or was forced, however you want to look at it) to pursue the “management path,” but deep down I’m an engineer.
This means that I approach resource development just like I approach all things: analytically, and with a touch of social awkwardness.
For example, we’ve recently hired a statistical quality assurance analyst. When I sat down to consider her recruitment, employee training, and career path at Minitab, I treated it like any engineering project. I broke down the position into several attributes, and I assessed each one.
Let me head off the obvious criticism: I know that she is a person and not a widget. I suppose that I should discuss “soft skills” and that I should “feel” things. In the end, I don’t. I can’t be “de-engineered.” They’ve tried and failed. I was, in fact, born this way.
Hence, my engineering approach to career development:
Let’s start with the bottom two quadrants of figure 1, which represent the employee’s nontechnical skills. In my opinion, these skills are often overshadowed by their “technical skill” counterpart. We try to find the person with the greatest technical fit and often overlook the nontechnical skills. It always ends badly.
The truth is that nontechnical skills are often harder to develop. Give me a candidate with solid nontechnical skills, technical ability, and a few missing technical skills any day. So, when I’m interviewing someone, I look for some of these innate skills in the applicants.
In the case of our new analyst, the nontechnical skills were slam dunks. Her approach and communication skills were out-of-the-ballpark impressive. I can’t wait for the opportunity to work with her.
Her training plan for developing the nontechnical skills is simple: Give her opportunities. She will undoubtedly do the rest.
The top two quadrants of figure 1 represent technical skills. These are the nuts and bolts of the position. Can they test software? Do they know what a p-value is? Can they apply design of experiments in a manufacturing environment?
These are important. Or, should I say, the foundation and ability to learn these are important. But, while we want someone technical, we tend not to be overly concerned with exact languages or techniques. Unlike a person’s professional curiosity or innate ownership for her work, technical skills can often be learned.
For the top quadrants, she’s extremely strong in theoretical statistics but doesn’t have extensive experience in applied statistics. And she hasn’t tested software. Not a problem; she has great technical ability, and I know that she’ll learn anything and quickly be great at it.
Her technical training plan: Each new statistical analyst at Minitab uses Quality Trainer as either a refresher or precursor to in-depth statistical training. Trainer is a great way for our analysts to build a foundation for the statistics work.
I wish I’d had it during my manufacturing days, and not just because it enables me to learn without interacting with others.
Each new analyst also is assigned a mentor, who is a senior analyst in the group. The mentor provides:
• An overview of software development at Minitab
• Peer reviews of initial projects
• Guidance on tools and techniques
• Assistance in outlining further training
A substantial amount of training will come through being immersed in a software development environment. But to supplement that and provide a foundation, we’ll recommend books, articles, and training programs. This will provide a good balance of theory and application to support sound software development skills.
In the end, we’ll plan, do, check, and adjust throughout our careers. As our roles change, our skill set develops. In my case, I’m still an engineer. I will continue to try to be a better manager. I’ll probably succeed in some ways and fail in others. And I’ll adjust and keep going.
That might border on a feeling. I’d better stop while I’m ahead.