Leadership in IT - Part 3 of 3

Time to get to the hard part...

Part 3 – now let’s introduce regulation

First part of this stage, is let’s define “regulation” in context. Specifically, I’m referring to ISO 13485, EU medical devices (GxP, or “Good [insert term] Practice”), and FDA medical device standards.

Let’s also be clear, these aren’t just “guidelines” (insert Barbarossa quote here), they’re law.

As law, what is their purpose? The goal of this regulation is to make certain that the products made by manufacturers are safe, effective, consistent and unadulterated. As a result, this means that they end up being implemented in such a way as to minimize mistakes and errors, and reduce or eliminate contamination where such can occur. Consumers as the beneficiaries of the regulation are guaranteed a high level of security that the products and devices they are exposed to do the job they are supposed to in a way that is not dangerous to them.

It is also worth noting here that as law, violations can result in steep fines, product recalls, and potentially even jail time. This is serious stuff.

That means you, as a leader, have the responsibility to implement compliance measures, and to ensure that your IT and Software groups understand and follow the measures you put in.

The requirements of regulation can result in direct opposition to some of the activities your group performs. Quite often a software group will be operating on an “Agile” methodology, with possibly scrum sprints and so forth – and these methods are oriented towards speed.

Regulatory requirements will impair that speed and that slowdown will appear to be simply “getting in the way” of work. Persons unfamiliar with the need for regulation will see it as unduly burdensome – indeed, I can quote a peer who totally missed the mark of what those regs were for: “No one cares anyway, these are just here to make it look good.”

Needless to say, he didn’t last long. Sadly, many developers – including most who come directly from university – have no experience with such regulation and will view them as unnecessary impediments. I myself, as a software developer many years ago, left a contract that I felt overly constraining to me because it was operating under FDA medical devices regulation, and I didn’t appreciate why it took six months to get from proposing a spelling change to final deployment of the release containing the correction.

These requirements make progress feel very plodding and restrictive, particularly for those junior members of your team. And they never end. They are part of the job, every single day. It isn’t just something you do once, qualify for, and then amble merrily forward – these actions and activities go into the job and become part of the fabric of how you operate.

What can good leadership do in such a conflict? What is to be done here, and how can we exert good leadership in this environment?

Let’s examine the conflict first. There are a few sources of conflict here:

• Requirements for thorough examination of work products and the preparation for creating them can seem like an attack on the respect for an IT professional’s work.

• The burdensome nature of documentation and preparation in advance of work can create a very tedious work environment, making it hard to feel like you want to go in.

• Effects of both of the above and other impacts of regulation can fray the nerves a bit, and place demands on your mediation skills that you didn’t expect.

Needless to say, rising to the occasion here requires a lot of patience and discipline. It also needs a great communicator, which I’ll get to in a moment.

Let’s begin with organization.

A lot of what you do, whether it is network infrastructure or software development, will require up-front planning – and most importantly, documentation of that planning, in order to provide an audit trail. Whether you’re aiming to be compliant with ISO, GMP, or FDA, there’s a key question that you have to ask before you begin an operation:

Will my action, or any effect of my action, have direct impact on our final product?

For some things, the answer will of course be “no” – for example, establishing a new backup plan for your email server. Regardless, before you begin, that question has to be asked and the answer documented. For most regulation, that documentation ends when the answer is “no.”

However, what if the answer is “yes”? In that case, you have to assess what you are doing, why you are doing it, why you think doing it will satisfy the original stated need, what are the risks, plan mitigation for those risks, and have your rollout staged to assess success or fail conditions at every milestone. This entire process is generally called “validation”.

In my own context, I created a form that enabled myself and others on my team to ask that question, and then to lay out the long set of considerations on changes to hardware and software in the IT group. That form went into our Confluence server, and could be linked from there to Jira tickets created to represent the progress of the tasks being tracked. For your own use, in whichever issue-tracking system you use (I refer to Jira here, just because it’s so common and it’s the one I’m most familiar with), you can put a field in your issues asking the very question about impacting the final product. Then you link it to a new issue page with the content required for the “yes” answer.

And once filled out, the page may need to be locked in read-only status (GMP and FDA requirements both demand that no editing or deletion be available after finalization). As well, things have to be tracked to any individual who lays hands on the change, as well as the date any change is made. All this information has to be logged and the logs stored in such a way that prevents confusion and preserves the log for time periods measured in decades.

This satisfies the regulatory requirement, and the organization provides your team with clear addenda to the original requirements.

The need for organization (and communication, below) requires your Commitment. Not just commitment to the team, but commitment to the mission of the company and the production of whatever products require the regulatory oversight. Your IT / development group are key players in delivery of solid product to market. If the commitment isn’t there, the team will know and it’ll show in how you deliver.

Next step we should look at is communication.

Quite possibly, this should be your first consideration, but I wrote it second here and we’ll leave it at that.

In your team, from day one of a person’s start or day one of implementing compliance, communication of the compliance effort will be key to making sure everyone stays on board with it.

I’ve found in both software development and network architecture that the most important factor in keeping the team aligned is making sure everyone knows and is clear about the answer to the question: “Why are we doing this?” Knowing why gives us all not only a common ground and a team unifier, it also helps us all determine potentially better solutions than we could with just a team head knowing the why and issuing directives to meet it.

This also applies to ensuring the team gets on board, and stays on board, with compliance efforts. They have to see the broadest picture of how the regulations help the business. If your company manufactures widgets used in surgeries, your team needs to be reminded (perhaps even daily) that what you do helps people safely undergo and survive life-saving operations. Their actions, every one of them, can potentially impact how well a widget works after manufacture.

In a lot of ways, this means that what you’re doing is linking the following of the regulation with the provision of a quality product, and instilling a culture of quality that goes into the tiniest details of everything your team does.

Which, when you think about it, is generally needed for a company to become great, isn’t it?

I make it sound easy, but it isn’t. You have to beat this drum every day, and you yourself, as the leader, need to be its biggest evangelist. Your Personality and Knowledge (see Part 1) tie in here, and are key factors in enabling this – you have to be able to be positive about the requirement of regulation and knowledgeable about its execution. There will be days when you are tired, and simply don’t want to deal with it. But remember – those widgets depend on you. They depend on your team. And the people undergoing surgery depend on you all.

Finally let’s talk expectations

I don’t’ want to really call this a “final” topic, because there’s an enormous quantity of factors that can affect this topic. But I only have so many hours of the day, and I’m calling these my top three items for being a successfully leader in this environment.

Setting expectations of stakeholders and team members for the execution of projects and tasks is a key element of all work, whether it’s regulated or not. Telling your boss how long project Y will take, and getting good estimates from your staff on how long tasks A, B, and C will take are key to that. Regulations increase workload, there’s no two ways about that. They also slow down progress. But they do enhance quality. They benefit consistency in the product(s) your company makes. Knowing what features are being prepared and what to expect in each release, as well as knowing what steps are being taken to mitigate the risks involved will put everyone more at ease (and will ensure no interruption or disruption in production).

Linking the goals of the regulation with the production of a quality product falls directly into your skills of Motivation for your team. Getting the team’s buy-in by involving them in the setting of proper expectations is the way to ensure the best possible motivation for success.

Making sure your team knows to take into account the added burden of the regulatory requirements will get you a good ways towards ensuring that you don’t have overblown demands on your team. It also involves them all along the way to ensure they retain respect and participate in their own work environment. This really applies to all environments, but it deserves special attention in a situation where a great deal of up-front and ongoing efforts require such detail.

Is there some magic bullet here?

Well, no. Obviously there’s no “silver bullet” answer to anything in IT, but there are some very cool tools that can help you along the way. I’ve mentioned Jira and Confluence already, and these are insanely useful in establishing organization, team communication, and helping to set expectations. Really if I were setting up practically any environment, these tools would be first on my list.

There are also document management systems which enable GMP/FDA-compliant protection of docs, which might be required. When these enter the picture, I generally advise that one keeps only what is absolutely necessary in such a DMS, and the rest in Confluence.

Additionally, Jira or other issue-management systems can be tailored to monitor risks and mitigation efforts, as well as validation efforts. The reporting capabilities of these systems can make scrum meetings much simpler, as well as providing outgoing communication to non-IT stakeholders in the form of expected- versus delivered-work estimates, etc.

In Summary

Gathering this up, a regulatory environment heightens the need for a clear communication path as well as requiring a more organized IT department. The company’s, and really the market’s, expectations of your firm’s output puts an additional burden of caution on your IT staff. This may not be suitable for all tech people, and there’s no shame in recognizing that you might not be one of those people for whom this is a good working environment.

If you’re comfortable with it, though, you’ll find that your skills in communication and organization are being called upon considerably more strongly than in a “normal” non-regulated situation. You’ll still be responsible for aiding in motivation, commitment, and the rest, but GMP and FDA regs put you in a special situation where you have to be stronger in certain areas to enable your team to succeed.

Leadership in its raw form doesn’t change – but different aspects of it are called upon more strongly in a regulated environment, and you need to be prepared to engage appropriately.

Part 1

Part 2

(All content here, outside of those elements attributed otherwise, is copyright (2025-) Thomas Theobald. With the exception of AI training, personal use with attribution is granted.)