Gaining knowledge is the first step to wisdom. Sharing it is the first step to humanity.
— Unknown
I’m not planning to retire just yet. Another year. Maybe two. That notwithstanding, my boss recently asked me to arrange a series of knowledge transfer sessions with the rest of the team. KT, as it’s referred to in business speak, sounds simple enough. Write down, record, or demonstrate everything you know and do, so others will know it and can do it too. So they can be you, in some limited sense. A “brain dump” of sorts. In practice, it often amounts to little more than a box-ticking exercise. A few documents are created. A few KT sessions are held. Questions are asked and answered, or not. The tasks, processes, and responsibilities are handed over. The person moves on to other work, another team, or leaves the company. I didn’t — don’t — want my KT to be like that.
By way of context, I’m sixty-five years old. For the past thirty-two years I’ve worked in the I.T. industry. My current role is Associate I. T. Service Manager, whatever that means. I find it hard to relate the label to what I do on a day-to-day basis. In terms of paygrade I’m an HEO (Higher Executive Officer) which is one up from where I began. I work five days a week. Three from home and two in the office. I don’t support out of hours. I did for many years. The extra money was welcome but giving it up was the single best work-related decision I ever made. For more on my past and present work experience check out Getting a Living, Forgetting to Live: A Few Thoughts on My 30 Years Service, Do More of What You’re Good at and Keep Good People Close: What I’ve Learned about Prioritising Mental Health in the Workplace, and Making the Dream Work: Why Workplace Recognition Matters.
As perfunctory and inadequate as it often is, KT is a necessary part of any work environment. People leave for various reasons, sometimes unexpectedly. The work continues. An effective workplace is one which doesn’t grind to a halt because this person or that person is on vacation or maternity leave, poorly, or otherwise unavailable. The dilemma is captured in the outwardly paradoxical maxim, “Find the irreplaceable person in the organisation and fire them” as expressed in this short post by Mauricio Luiz Siriguti.
Probably in your company there is that person you admire or maybe not, in which it appears that person can never be fired. [...] Usually, this person has many years in the organization, knows everyone, knows how the gear works, is part of the culture of that company. Has anyone come into your head? Well, fire this person.
I don’t consider myself critical to the organisation that employs me. When I eventually retire, or if I was suddenly and seriously ill or died, my absence would leave gaps in the team’s ability to fulfil its obligations. But that would be temporary. The gaps would be filled. That said, I bring something to the workplace that is missing, and missed, when I’m not around. It’s neither my dry wit nor my sparkling personality. So what is it?
The first step in any KT process is to figure out what needs to be transferred. I’ve picked up plenty of technical skills, soft skills, and business and application knowledge over the years. Not all of that is relevant to my present role. That realisation is salutary in itself. So much of what I know relates to technologies and systems that have been retired or replaced. The IBM mainframe environment I worked in for most of those three decades. MVS. TSO. JCL. Rexx. IMS. DB2. FMS. BMSR. CCD. PACS. I can claim a degree of expertise in them all but it’s all redundant now. The same is true for the majority of the workplace relationships I built. Most of my former colleagues have moved on to other things, retired, or died. (Jill you are not forgotten.)
What’s left? My value to the team owes more to my general attitude and approach than to any specific skills or knowledge. I’m keen to learn new things, preferring to teach myself rather than attend formal training courses. Of the many courses I’ve endured over the years I can’t think of one that aligned with what I needed to know at the time or presented the subject matter in ways helpful to me. I have an ability to recognise patterns, and breaks in those patterns. An unexpected value. A change in the number of files, records, or fields. A misplaced comma or other typographic error. Something out of kilter that offers a starting point for further investigation. I also have an aptitude for seeing a path from A to B. (Or more realistically from A to E via B, C, Q, and D.)
The final string to my bow (the phrase originated with medieval archers who carried a spare bowstring in case their main string broke in the heat of battle) is an almost pathological urge to streamline and improve. If I have to do the same task five times a day, or even once a week, I’ll find the most straightforward and least error-prone way to do it. Browser favourites. Template chat and e-mail messages. Shell scripts, database queries, and more aliases than you can shake a stick at. Bill Gates would approve. He famously declared, “I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”
Lazy or not, this is what I bring to the table. How, though, to pass it on? My boss suggested I start by sharing my knowledge of, and approach to, coding the routines and shortcuts I’ve developed over the past few years. It made sense. These tools have streamlined many of the tasks we perform every day. I knew what I didn’t want to do. I didn’t want to teach my colleagues shell scripting or database queries. Firstly because I’m not competent to do so. I don’t know these technologies enough to teach them. I know them enough to use them and that’s not the same thing. Secondly, several of my teammates have already been trained in these disciplines. They’re more qualified in them than I am, at least on paper. At this stage in my career I’m not interested in training as a box-ticking exercise or as something to add to my resume. As I’ve told my boss on several occasions, if there’s something you need me to do that can’t do without going on a course, put my name down. Otherwise, give the place to someone who wants it.
What I wanted to pass on was not the syntax of this command or that command, this database query or that. That’s what Google and Copilot are for. I wanted to share how I approach a problem. What I see and how I think. I realised almost immediately that this is far harder to convey than how to code an if statement or globally change one text string to another. There’s a reason knowledge transfer is hard. Specific skills, experience, or knowledge aside, our brains work in different ways. What’s easy or obvious to one person may be utterly illogical or counterintuitive to another. The phenomenon is real enough to have an impressive name. It’s known as the Curse of Knowledge.
The curse of knowledge, also called the curse of expertise or expert’s curse, is a cognitive bias that occurs when a person who has specialized knowledge assumes that others share in that knowledge. For example, in a classroom setting, teachers may struggle if they cannot put themselves in the position of the student.
The curse manifests in many ways. Anyone who’s worked in a technical support role knows the frustration of handling issues caused by people not following procedure. Some people habitually skim instructions or ignore them entirely, but not all users or customers are idiots. As I had cause to point out at work recently, if instructions are being misconstrued in the same way by different people the instructions are poorly written, no matter how clear they appear to the person who wrote them. I’ve never been in a formal teaching role but I’m sure the same applies in educational settings. Wilful disinterest aside, if the student doesn’t understand what’s being taught the teacher might need to adjust their approach. In some cases there may be specific reasons for these differences. The term neurodivergent (sometimes abbreviated to ND) is used for people whose brains process information, learn, or behave differently from what is considered typical in a given setting. Not less than or wrongly, but differently. I’ve never been assessed for neurodivergence but I’m aware that the ways I approach challenges, situations, and other people tend to vary from the norm. One label I confidently self-assign — alexithymia — affects one in ten people in the general population and frequently overlaps with other conditions including autism spectrum disorder (ASD).
With all this in mind (pun intended) I drew up a plan to fulfill my boss’ request. In episode one of “Martin’s Marvellous World of Scripting” I outlined how I approach the technical challenges our team encounters. It’s very much a step-by-step approach. I code and test as I go, often a single command at a time. I described coding in terms of what I’m trying to achieve at each step because you have to decide what you want the next line of code to do before you can figure out the appropriate command and syntax. Examples include selecting a specific file or files based on filename or contents, selecting specific records from the files and specific parts of those records, and changing one value to another.
I included a real-world scenario in which the requirement was to identify all unique values that occur at a particular location in certain records in a set of files. The starting position was the set of files. The destination was the required list of values. To me the route from A to B was clear. Obvious. Intuitive. To others it might not be and I sought to explain my thinking at each step along the route. I did this in words first and then translated into code, demonstrating how each step moved us further towards our goal. The feedback and questions I received reassured me I was on the right track but I’m open to approaching future sessions differently. Ultimately, the test will be to what extent and how well my colleagues put the knowledge I’m sharing into practice.
It’s worth noting that KT benefits the person passing things on as much as it does the recipients. I’m finding the process fascinating in itself, as I explore what I know and do, how I do it, and what value I bring to the team and the wider organisation. A similarly experienced colleague suggested that at this stage in our careers we have a responsibility to pass on our knowledge and expertise. I smile at the idea of me as some sort of elder statesman or guru, although I was referred to as a legend not too long ago. (Thanks, Sophie!) It serves as a reminder to add value wherever and whenever I can. To make the most of the time I’m part of the team so that when I do retire I’ll be missed but not cursed for leaving. As a social media post I came across recently put it, “Nobody missed me the way I thought they would. That was the most freeing thing I ever learned.”
More fundamentally, the exercise has led me to think about my life outside the workplace and beyond my retirement. What value do I bring to my family and friends and the wider world? How might I best deploy my skills, knowledge, and experience in the time I have left to me? What might I pass on, to whom, and how? This deserves more thought and I may return to it as part of our series on end of life planning. And it’s not all about me! I have so much to learn from other people, not least the realisation that we all think, feel, apprehend the world, and act in our own ways. Our differences are to be acknowledged, valued, and celebrated. In the words of American science educator Bill Nye, “Everyone you will ever meet knows something you don’t.”
Illustration by Round Icons at Unsplash.
Comments
Post a Comment