A Medical Device product development manager faces a tough challenge when trying to attract software talent and in gauging whether the available candidates have the appropriate skills. It’s rare to find that a candidate that has just the right mix of familiarity with device technologies, the QSR, formal process, software tools, programming languages and software engineering methodology. Plus, in the current economy, many obviously smart and experienced people are coming into the employment market who developed their experience in commercial systems, but who are accustomed to different imperatives than our medical device requirements.

Software for Medical Devices is not the same as software for e-business, business intelligence, decision support, desktop applications, or most other things. Who you hire and what they know – even how they view the latest theory on software engineering, or the latest programming practice – will be subtly different than their colleagues in many other fields.

During my 16 years as managing partner of a software engineering and systems consulting firm, over 15 years as management and technical resource in a large medical device company, and two more years as a medical device R&D consultant, I saw literally dozens of management styles and organizations. I managed a significant fraction of those environments. I can honestly say that I’ve interviewed and/or hired hundreds of employee and contract software professionals.

Don’t forget: I write these posts because people I’ve worked with asked me to begin setting down some of the things that might be useful to them, and so my disclaimer about the informality applies at full strength (see It’s Just A Blog, You Know, packaged with the What Is This? button shown in the blog’s toolbar, at the bottom of your browser window). If you have questions or comments, use the comments link at the bottom of each post – there’s a reminder about how to do it, which you’ll find by hovering your mouse over the What Is This? button.

Special disclaimer about only being human and how this is just a blog: I started this particular post to help a friend understand about recruiting and hiring software folks (see more of his story below), and it turned into a pretty big job. I built the description grid embedded below in one (count it, one) draft. By the time I was done, I had carpal tunnel syndrome, migraines, allergies, two charlie horses and a bad haircut. The point is that the entries in the grid are general descriptions that try to impart something valuable for each dimension, but you have to remember that every organization, product, and approach will have its own flavors of these roles. The names and descriptions are right off the top of my head, without any analysis – zap! – right thru my fingers and onto the Internet. So, if you have debate or commentary, please click away at the comments link.

If you have questions about some of the acronyms and terms, you might like to look at the “Links” section at the bottom.

Here are the sections in this post:

My Buddy Had A Problem, So I Explained How Things Work

Ideas For Candidates Who Have Transferrable Skills

Summary Of Skill Sets

Summary Of Roles and Scopes

A Giant Table That Relates Roles And Skill Sets – Sort Of A Grid Of Abbreviated Job Descriptions

Reference Links, Instead Of A Glossary

My Buddy Had A Problem, So I Explained How Things Work

The reason I stepped into this post is that a friend described his software problems to me – his company is getting ready to write its own system, instead of using a purchased one – and then told me he didn’t know where to find a manager who had the right programming skills. This guy is an R&D director with serious chops in a field other than software. After a few questions, I learned that my friend’s company is suffering from the belief that software managers should program, and programmers should manage. Also, they had a primitive requirements engineering capability, poor traceability and no real understanding of systems engineering or decision support. What blew me away is the system they make is amazingly complex. They built the first one by having a team of really smart people. Now that they’ve built more than a couple of units (they’re manufacturing them now) they can’t keep up.

The results of this conviction – that software is only about programming – are:

· they can’t meet any schedules (too many last minute defects)

· they don’t have a strategic direction and can’t decide on what new products to design

· they’re having problems with daily chaos

· the company is up to its ears in recalls and field actions – because they don’t have the capability maturity to find their problems very quickly after they causing them (sort of the purpose of all this Quality System stuff – everybody makes mistakes); they have to delegate their “customer testers” to find and describe many of their mistakes

· their payroll is high, so they’re expecting budget cuts and a layoff, which will set them back even farther on their remedies to design flaws

If the commute to this company was tenable for me, I would have loved to jump all over this problem. Failing that, however, one bit of help I could provide to this poor guy was to explain a little about how a software team works and what kinds of jobs have to be done. The result turned into this post.

In rewriting this for a blog, I’ve tried to keep it as generally applicable as possible. One thing to keep in mind is that different schools of software lifecycle and project management thought will use different names for identical or similar jobs. I’ve tried to write these lists and the accompanying grid so that it’s not dependent on a particular lifecycle, engineering approach, operating system, programming language, or other religious affiliation.

Ideas For Candidates Who Have Transferrable Skills

If you can find people who know about your particular product or technology, then good for you! If you can’t find those folks, however, then there are other fields in which practitioners have to comply with requirements similar to those in the Quality System Regulation, including these:

· Avionics folks follow MISRA-C, and have to get their products certified by the FAA. Sound familiar?

· Aerospace folks use the CMMI (A wiki: http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration) and various DoD standards.

There are also some industries where practitioners need similar technical skills as we Medical Device folks, although they don’t have a Quality System standard to follow, such as:

· Telecommunications

· Semiconductors

Some hiring managers harbor a prejudice against aerospace practitioners because of the idea that they only know how to work in large, cumbersome, bureaucratized environments. I think this is a mistake. While it’s true that aerospace companies tend to be large and execute big projects, many engineers from revenue-driven aerospace divisions or workgroups are pragmatic souls (I’ve known many in my time) and can tell the difference between necessary and unnecessary process complexity. I’ve also heard an engineering manager – who I felt was sort of a cowboy, without a good working perspective on how to document a complex system – say that an aerospace candidate would be unable to function as a systems engineer because he needed an “overly complex” documentation plan.

My view of that manager’s situation was that his company’s list of recalls was proof his group didn’t understand its products well enough. A more complete set of systems-engineering-oriented documents would have cost a few tens of thousands of dollars, and a couple of months, and would have saved millions of bucks in error remedies. So, I think it’s smart not to overlook the aerospace folks. Their practices are actually the original source of the FDA’s views on Design Control, so they’re nearly compatible when the walk in off the street. Plus, they’re used to working on complex systems that utilize multiple technologies, and in working inside a well-organized process.

Semiconductor people are another group that have a bad rap among some medical device people. It used to be true that the big vendors would ship whatever they had and let the customer take the brunt of the defect burden. In the last decade, however, they’ve been maturing their practices to increase control and decrease error. The good news about semiconductor engineers is that they tend to know a lot about multi-technology systems, and they tend to be familiar with companies that do manufacturing.

Summary Of Skill Sets

In order to find the right people, you need to identify the software skills sets you’ll need. This requires definition of a several skills dimensions. Here’s a fairly useful list of dimensions to assess:

· Programming theory and practice (part of software engineering)

· Software Development Lifecycle (another part of software engineering)

· Software Engineering (more than programming)

· Process familiarity and work habits

· Leadership, followership, and teamworking attributes

· Operating systems theory and practice

· Toolkit familiarity or theoretical knowledge

· Management theory, skills and toolkits

· Product Development Process knowledge beyond software

Summary Of Roles and Scopes

You also need to understand what kind of people will do which kinds of jobs, and what each person’s scope should be. Depending on the size of the organization and the complexity of the product, you may require one person to assume several roles, or you may require a role to be shared among several people. In a very large organization, there may be several people sharing a particular role, maybe even a hierarchy of people. In a small organization, such as a startup, the whole list might be accommodated by 5 people.

Here’s how I think of the roles:

· Director or functional manager

· Project manager

· Technical Lead

· System architect

· Requirements engineer

· Subsystem designer or architect

· Systems programmer

· Application programmer

· Test Manager

· Test Lead

· Functional tester

· Structural tester

· Software Quality Assurance Director or Functional manager

· Software Quality Assurance engineer or specialist

· Configuration manager

· Configuration management engineer

A Giant Table That Relates Roles And Skill Sets – Sort Of A Grid Of Abbreviated Job Descriptions

This table shows a row for each role and columns for the skill sets, with a remark in each cell. It’s too darn wide for the display format of this blog, but it’s reasonably viewable as a letter-size landscape display. What I’ve done, therefore, is to create some PDF images in legal and 11×17 formats, so that you can view or print the material in the way that’s best for you.

Here’s the table in landscaped legal size: grid-sw-roles-vs-skills-legal-size-090121

Here’s the table in landscaped tabloid size: grid-sw-roles-vs-skills-090121-11×171

Reference Links, Instead Of A Glossary

Project management tools wiki: http://en.wikipedia.org/wiki/List_of_project_management_software

Functional requirements for software engineering wiki: http://en.wikipedia.org/wiki/Functional_requirements

UML wiki: http://en.wikipedia.org/wiki/Unified_Modeling_Language

UML group: http://www.uml.org/

Upper CASE wiki: http://en.wikipedia.org/wiki/Computer-aided_software_engineering

IDE wiki: http://en.wikipedia.org/wiki/Integrated_development_environment

PSM (Practical Software Measurement) site: http://www.psmsc.com/

About the QSR (Quality System Regulation, 21CFR820): http://www.fda.gov/CDRH/DEVADVICE/32.html

Development Model Links:

Iterative development model: http://en.wikipedia.org/wiki/Iterative_and_incremental_development

Agile development wiki: http://en.wikipedia.org/wiki/Agile_software_development

Waterfall development wiki: http://en.wikipedia.org/wiki/Waterfall_model

Spiral development wiki: http://en.wikipedia.org/wiki/Spiral_model

Vee Model software development: http://en.wikipedia.org/wiki/V-Model_(software_development)

Dual Vee Model for systems development wiki: http://en.wikipedia.org/wiki/Dual_Vee_Model