Political savviness as a leadership tool

Back when he was still editing The American Scholar, Joseph Epstein used to remark that his responsibilities as editor involved little more than "opening the mail." What he meant was that the journal had acquired enough of a reputation that good writers regularly submitted solid and thoughtful pieces for publication with no prompting from his side. All he had to do—or so he claimed—was to open the mail, see what had come in this month, and then send it to the printer.

A blogger's job is rarely so easy, but I am always delighted when I find something I can share with you. This week it is a short video that I found posted on myASQ, ASQ's social media platform. Its title is "Political savviness as a leadership tool," and it was originally posted by Luigi Sille of ASQ's Human Development & Leadership Division. Mr. Sille and the HD&L Division retain all rights to this video, and I gratefully acknowledge their permission to share it here.

The central message of the video is a simple one: political skill is a fundamental leadership tool. It doesn't get the acclaim of talents like vision and strategy, but it is just as important. No matter how inspiring the vision or how brilliant the strategy, there will always be internal friction in any organization when you try to implement them—simply because there is always friction when people work together. Political skill is nothing more than the lubricant for that friction, the ability to work with others inside an organization in order to get things done. 

Many people hear the words "political skill" and think of something bad; they associate the concept with force or fraud, with coercion or manipulation. Of course sometimes those things do happen inside organizations, but they are dysfunctions and they are the exception. Most organizations get along fine without them. And associating political skill with those kinds of behaviors is like associating weather with hurricanes and tornadoes: sure, they are dramatic, but they aren't the whole story.

It's a good video, and it will cost you only a minute. I hope you enjoy it.

  

           

It's published! Now what?

Yesterday, September 16, after months of waiting and hype, the 2026 edition of the ISO 9001 quality management system standard was formally published. You can buy a copy from the ISO themselves, or wherever you normally acquire standards.

Great news! Now what?

Well, that depends. Overall there is a three-year transition period from the 2015 edition to the 2026 edition. But what you have to do during that time depends on how you interact with the standard.

• Do you work for a company that is certified to ISO 9001?
• Do you work for a Certifying Body (CB) that certifies other companies?
• Do you work for an Accrediting Body (AB), that accredits CBs so they can be allowed to certify companies?

In each case the requirements are a little different.

If you work for a regular company certified to ISO 9001—but not a CB or an AB—the requirement is that you need to acquire an updated certificate reflecting the new edition of the standard no later than September 30, 2029. The only way to get a new certificate is for your CB to conduct an audit to the new standard, either as part of your normal schedule or else as an extra, out-of-sequence audit. It will take your CB some time after conducting the audit to process the results and issue your certificate. So you would be well-advised to contact your CB, and ask how much time they need. Then schedule the transition audit early enough to give them more time than they asked for. Unexpected issues always come up towards the end of any transition period, and you don't want someone else's unrelated accident to jeopardize the timely issuance of your certificate.

What do you need to do on your side to get ready for the transition audit? Fortunately, not much. Several months ago I wrote about the changes that were planned for this edition, and not much has shifted between then and now. The consequence is that the updates in this edition are few, and they are mostly pretty intuitive. You shouldn't have to change much about your current management system in order to comply with them. Be sure to read the new edition, of course! Once you do, you'll find in many cases that your current system already meets the new requirements without the need for any change at all (except maybe in terminology). Explain that to your auditor, and you are done. If you do have to adjust something, then plan and implement the updates in a systematic way like you would do with any other changes. But you shouldn't find it a burden.

If you work for a CB or an AB, the requirements are a little more detailed. I'll summarize them here, but they have been compiled into a document published by the Global Accreditation Cooperation Incorporated (Global ACI), the international authority on the accreditation of laboratories, certification bodies, and others. You'll want to download the document for reference. (See links below.🡳🡳)   

In a nutshell, a CB has to develop and implement a transition plan, including communication with all existing clients. As part of their transition plan, they have to communicate with their AB and provide all documentation the AB might request. In the end, the CB must communicate to their AB no later than June 30, 2027 that they can certify companies to the new edition. Then the AB has three months (latest September 30, 2027) to decide whether the CB has made the transition adequately. After that decision, the AB must conduct at least one (preferably more) witness audit of the CB where the CB is auditing a client to ISO 9001:2026.

An AB, for their part, has to be ready to accredit CBs to the new edition no later than March 31, 2027. They too have to prepare a transition plan, and to communicate with both their CBs and Global ACI.

Any new or initial certification to ISO 9001 after March 31, 2028, must be to the 2026 edition.

For more details, please see the documents linked below.   

Global ACI transition requirements for ISO 9001:2026

Global ACI transition requirements for ISO 14001:2026

Global ACI downloadable transition requirements documents page

           

Writing a wiki

Last week, Johnathan Gonzalez of Worthington Enterprises posted a question on a myASQ discussion board, and it has gotten a lot of traffic. He asked, "When Quality depends on one person, do you really have a system?" Then he expanded the question with a little more detail.

Sometimes a process works because the process is strong. Sometimes it works because one person is really good at holding everything together.

Those two situations can look exactly the same until that person goes on vacation, changes roles, or leaves.

Most of us have probably worked with someone like that. They know the history behind a recurring issue. They know which supplier needs extra follow up. They know who to call when something goes sideways. They know which part of the process actually matters because they have seen what happens when it fails.

That experience is incredibly valuable.

The problem starts when that person's knowledge becomes the control. At that point, the organization may think it has a strong process when what it really has is a strong individual....

Where have you seen tribal knowledge become a real dependency in a process, and what actually helped transfer that knowledge to others?

Of course he is absolutely right that the two situations can look the same, and also that it is important to distinguish them. If your company depends critically on information that Tom and Larry carry in their heads, then—to put it gently—you are facing an important risk. And until you can get that knowledge spread across more people, you probably want to discourage Tom and Larry from taking up extreme sports or playing the lottery.

How do you spread their knowledge? Of course there are many ways. You can ask them to give talks over lunch. You can assign them to work on projects with junior colleagues, so that the junior colleagues rub shoulders with them and learn by doing. You can ask them to write procedure documents, though that kind of task is often postponed till the last minute because it's not very exciting.

Another approach is to create a wiki. The advantage of a wiki is that you can build it incrementally, a little bit at a time. But how do you remember all the different bits and bobs of topics that have to be included?

I once knew an engineering manager I've called Franz, who solved that exact problem. His organization had, at the tijme, some very senior engineers with decades of experience, and some new graduates who were just starting out. Naturally the new hires often asked the older engineers for advice, particularly around the design and architecture of the company's product line.

Franz introduced the following rule: "Whenever you ask a question, do it in email. And whenever someone asks you a question, don't just reply! Instead, add that question to the wiki. Write your answer in the wiki. Then reply to the original question by sending a link to your answer."

That was the protocol. It was simple. Everyone understood it. And over time it allowed the wiki to capture most of the tribal knowledge that the senior engineers had accumulated throughout their careers.

No single approach does everything. If you have to collect tribal knowledge, use multiple approaches at the same time, each supporting the others. But I have always liked Franz's protocol for filling up the local wiki with the knowledge everyone needed.   

           

Interviewing for flexibility

How do you meet conflicting requirements in your daily work? I don't know any rule of thumb, but it happens all the time so you have to watch for it.

How do you select employees so that they can meet conflicting requirements? How do you build a department that can handle muddled or conflicting inputs and still perform? Now that's an interesting question! And back in the day, I had some experience with it.

Years ago, I ran the documentation group in a small tech startup. On the one hand, we had strict procedures to follow when it was time to release a new design. On the other hand, we came at the very end of the design cycle, so by the time a project got to us it was usually late. It seemed like we never had the time we needed to execute our strict procedures.

In principle I should have pushed back against the organization, and to some extent I did. But I also recognized that this is what life is like in tech startups. To some extent, my department had to adapt to fit the organization, rather than demanding that the organization adapt to us. We had to work together to find a productive middle ground.

So whenever I hired someone new, I leaned into this dynamic during the interview. Over time, I found that one of my most useful questions was: "What do you do when you have to choose between Doing-It-Right and Doing-It-On-Time?" 

I call that a useful question because I got so many wrong answers. In this context, a "wrong" answer means an answer that told me clearly, This candidate will never thrive in this particular environment, so they are not the right match for the job. Keep looking. Among the wrong answers that I got to this question were comments like the following:

• "I ask my manager." Sorry, but you are going to encounter some version of this conflict every week, maybe every day. You have to be able to work it out for yourself.
• "That's never happened to me." I don't know where you worked before, but that condition is a way of life here. I doubt you'll like it.
• "Always do it right. No matter what." My gosh, I wish I could agree with you, really I do. But that's just not possible. Most projects will be late, and we have to work with them somehow. 

Well then, what were the right answers? There actually wasn't a single "right answer" that I was looking for. What I wanted was to listen to a candidate think through the problem. Successful candidates often started by asking me questions. What's the nature of the process hold-up? What's the priority behind the release? Can we change any of the parameters, so that the conflict disappears? Can we change the process, so it doesn't take so long? All of these were answers that gave me some confidence the candidate could make a sound decision in real life.

One of my favorite answers came from a local engineering student at UCSB, who was applying for a part-time internship. His last position had been working on the UCSB grounds crew over the summer, but he wanted a part-time job that aligned better with his studies. And when I asked him about Doing-It-Right versus Doing-It-On-Time, he gave me a concrete example.

Part of his job on the grounds crew was to trim the hedges. Now, UCSB has a large campus, so unless you have an army of hedge-trimmers you can't trim the hedges all at once. You start with this hedge here; but when you finish it and go to trim that hedge over there, the one you just finished starts growing some more and pretty soon it looks ragged again.

For most of the summer that's no big deal. There was a plan for what to trim when, and he cycled through the plan. But at the end of summer, the school holds festivities for the beginning of classes. All the students return; and in many cases, their parents come too. The campus has to look spotless for the parents.

But he just explained that's impossible! What did he do?

The key is that the parents never go all over campus. Throughout the festivities, the parents are pretty much confined to a few specific places. So the priority at the end of summer was to make sure that every line-of-sight from a spot where parents would visit had to look flawless. That priority was absolute, but it represented only a small percentage of the total campus. For all the rest, the crew did the best they could but didn't worry if it was a little ragged around the edges.

The reasoning was solid. The priority was clear. And it was obvious to me that he understood what I was asking. I hired him.  

So yes, you can select your employees for the ability to reason their way through conflicting requirements. Of course, they'll do the very same thing when those conflicting requirements all come from you. 😀 But in the bigger piucture that's really what you want, isn't it?