Agile

How to Teach Others Small Simple Tasks

Classroom showing students being taught

We have all been there, either on the receiving end or the giving end. You may be in a zoom meeting watching a coworker’s screen and see them perform a task, or struggle to perform a task, that has a really easy shortcut. It could be just a small task that can be made infinitely easier with that shortcut, but the person performing the task takes the long and harder way to do it.

These may be tricks or shortcuts learned over years of experience, or they could be simple things picked up due to the newness of the technology where an older worker may not be aware of its existence. These small simple tasks could also be methods that are perhaps more correct than other methods, and they could expand well beyond using a computer. You may find a coworker inefficiently packing a manufactured product in a box, or using a metal file wrong (Yes, there is a correct way – don’t stroke back and forth, you will dull the file). The results can be nothing more than some wasted time, or result in extra work effort to correct if not performing them causes a problem.

A few examples might be:

  • Highlighting/selecting an entire document to paste it somewhere else
  • Right-clicking and choosing copy/paste
  • Capturing screen shots inefficiently
  • Writing Excel or G Sheet formulas
  • Putting thread tape on wrong (you could do this a hundred times and never have an issue, but you will remember it the first time it goes wrong)
  • More efficient code, or failing to account for some common issues in code – mistakes even 20 year veterans make

These issues can sometimes be a minefield, triggering disagreement or tension between coworkers when they are addressed. The only thing worse than a know-it-all telling everyone else how to do their job is the know-it-all who can’t take constructive criticism in how they do their job; but no one really likes being called out for doing something the “Wrong” way. Is their way even really wrong? Perhaps sometimes.

How you handle these issues can either help you earn the respect of your colleagues, or it can make you into the person they dread talking to. What is your advice on handling these types of scenarios?

Joshua: This brings to mind the time I was in a call and a non-technical person wrote “sequel” in their notes shown onscreen. I, like a jerk, immediately said, “It’s spelled S-Q-L.” As soon as I said it, I believed I had made a mistake. That was the wrong way to handle it in my opinion. For one thing, the end results really didn’t matter. Every technical person in the world could probably figure out that it meant SQL (it’s often pronounced sequel).

I am not perfect, and blurting it out that way – correcting them immediately – potentially shouted to the world, or at least that meeting, that I believed I was perfect and never made a mistake. I have been on the receiving end of this before, often typing notes up quickly while they are onscreen with someone making spelling or grammar corrections as I type. It can be annoying if it is ongoing, especially when it comes to typing up some quick notes that no one else but me will read again.

So how could I have handled that better? That can certainly depend on the specific scenario, but in the case I described above that person didn’t have a strong need to know or be corrected. They were non-technical and it was just their notes. If I really wanted to save them from making that mistake in the future, I should have done so privately or at least in a less confrontational manner. That should be a rule to follow – Weigh the importance of whether you should even address the issue and how you are going to address the issue.

What do you think Pedro? How would you have handled that situation?

Pedro: Well, that is an interesting approach, which actually in my case happens on both sides of the scenario and in multiple possibilities. In a board or investors meeting it happens a lot, again, in both ways (e.g. for me it’s often I have no clue on some financing simulations, for them it’s always about the techy part). This goes in reverse, on my tech meetings, it’s common that everybody is more familiar on technology then me and sometimes I mix up the terms or the relations. As a common example, web technology like React works node as a Back-End or Front-End application, there are a lot of things that sometimes I get confused on when it comes to the fine details. If they just add new APIs, frameworks, or anything else that I haven’t heard of it…well, I feel real dumb on the meetings, of course.

However, there is no right way for this, Josh. What I prefer to implement in my leadership ecosystem is to let my internal stakeholders know to be prepared to explain or to accept a lack of knowledge, no matter the emotive state we have. We are not robots and we have feelings, but we can also understand that most of the time someone is just telling us something important, teaching us. Even if he or she looks upset, we have to considerer that.

I actually prefer to be corrected on my profound state of ignorance, even if the other person looks very angry shouting at me. I will just calm him and say “Sorry, I’ll try to do better next time, just don’t mind telling me twice in case I forget.”

I can add a learning point to your case described above. In Portugal we never say “sequel.” We always say “S-Q-L” as “Éss kay Él.” So I probably, if I was at a meeting as new guy and heard this called “sequel,” I might right down “sequel” and have no idea what that means or even think it was a new database system like a NoSql or something.

Joshua: As usual, you enlighten me to some cultural implications I hadn’t considered. I think most of my teams are in India or the United States. More recently I am working with a bunch from South America. In that case, it could be worth it to have the discussion openly or at least take the cultural makeup of the team into the equation.

I also suppose an argument could be made whereby explaining the proper spelling to the group they can all learn, but everyone in that room was technical except for the note taker. That may not apply to the specific scenario I described.

But this brings me to my number one rule here – Don’t assume a person doesn’t know the correct method or how to perform the simple task. It may very well be that they do know it, but they are nervous because you are sitting around watching them. They may also have no need to perform the task on a regular basis. To cite an example from above, I rarely need to copy a whole document and I never think of pressing CTRL + A when I do. Equally speaking, I rarely need to utilize finding anything within a spreadsheet or web page. CTRL + F is not something that would come to me right away, despite knowing both of those keypresses exist.

Pedro: This is definitely more a culture issue than a technical one. Yes, people are hired for their skills so our assumptions of thinking is that they should know what we know. This is wrong. Everybody has their own knowledge and it’s an expression of our way of being that we should construct a culture with new people and enrich the environment instead of marking a position in the “wolf pack”. If the person is honest with themselves with what they know how to perform, it shouldn’t be an issue to try to help. If the person gets uncomfortable with what we are saying or offering, we need to try and understand how can we help without causing any constraints with the person.

I have an example on this, which has nothing to do with business or work, but on running or jogging. There are lots of guys that when running with girls, they like to give some advice to the girls. This seems to assume the girl is not used to sports just because she runs less then the guy. This often creates a major constraint on the girl, causing her to feel uncomfortable. But the guy may feel he is actually trying to protect her by giving her these suggestions. This is a typical case of two different perspectives and both think they are acting correctly. Who is correct? I don’t know, I am going to answer that here.

Joshua: Recently I encountered an issue where someone sent me a photo of a software error taken with their phone. To keep the story short, I was fully aware that within that application the screen shot button was disabled but the snipping tool worked. This was the test environment for the application, so the screenshots were not violating any sort of data sensitivity requirements. This person was asked for a screenshot of the error from technical support. I was sort of the intermediary there.

As soon as I noticed it was taken with a phone camera, I thought I might know of a way to help them in the future. So when I sent a message back, I wanted to make it clear that I didn’t know if they knew of an easier solution. I explained to them why I thought they may want the tip, and that they were free to disregard my suggestion.

I didn’t want to say, “Hey, why did you send me a picture from your phone when the snipping tool will do it better and easier?” Phrasing it that way makes an assumption about what they may or may not know and it can immediately make them defensive. As with the above example I gave, it also implies that I am perfect and have never made a quick call on how to do something to just get it done.

This brings me to my second rule – How you word or phrase things matters. You need to keep your language as neutral as possible and avoid words or phrasing that may make the person believe they are being challenged for not doing things exactly the way you would do them. Unless there is a need to do it in a precise way to prevent damage or stay within security requirements, your method should not be taken as the only way to do things. Recognize that it may just be your perception that makes it better, but also try to remember what life was like before you knew this better way.

Pedro: How words are pronounced matters everywhere! On the job, with friends or at home with our family. The most difficult thing in life for human beings is to listen though, not necessarily to what they say. From my point of view, since I’m normally in a director or manager position, I am concerned a lot with my team being always ready to understand and listen to each other. This is not an easy thing since it can’t be forced. We need certain ways to deal with people, even with our family. A bad action, sometimes not even one word, addressed to a kid can be crucial to his/her growth or ethical decisions. But we can’t always keep on thinking what should we say or not say, sometimes we have to do the best we can and move forward.

We can in fact think about and monitor the reaction to what we say and adjust as needed. There are people who are more emotional and others are too stoic or rational. Independently of what we actually say, which of course should be important, the following reactions to what we said should be our main concern. Like, life is a continuous learning adventure and we don’t always choose the people we work with. We definitely don’t choose the kids we get, so we evolve with personalities around us, like stakeholders in our lives. On project management, we know we normally have shorter cycles and sometimes a very specific scope in an iteration (or sometimes not… but that is for another post). It should be easy, but it also gives us the ability to make a fresh start every time a new cycle comes around. We can learn from our mistakes. We have the possibility to discuss on project closures these issues (or not… a lot of companies tend to skip it, claiming they have too much to do… but well, we cant talk about this another time too).

Summary

The issue here, as a conclusion, would be that everybody needs to learn how to communicate and not have the wrong (or preconceived) assumption that everyone you meet knows everything you do. Because nobody knows all and surely “Mr. perfect conversationalist” exists in La La Land, but not in the typical business world. The way we handle it, determines our capacity to grow. We need to listen and observe our actions and the resulting reactions, daily, no matter our position on the company. Mistakes will happen, and we need to be open enough with ourselves to learn from those mistakes and to adjust our behavior accordingly.

As always, be “project” oriented, be well, and under scope

Sources:

Cover Photo by Katerina Holmes from Pexels

Child Photo by Monstera from Pexels

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.