Alt+Ctrl+Start

This post is aimed at L1 and L2 operational / engineering / helpdesk users. Being in L1 or L2 role. These roles tend to be more technically directed rather than meeting based. Meetings shouldn’t take up a large chunk of your day. In my 13+ years in the workforce I’ve been to countless meetings. Some meetings are useful and meaningful, but most are usually not. There are colleagues and users that just arrange meetings for the sake of it. Depending on the complexity of the topic, subject or issue, users may need to arrange a meeting to collaborate and discuss ideas. In my time in the workforce trying to resolve the topic, subject, issue and obtaining answers prior to the meeting helps prevent the need to arrange a meeting in the first place. Sometimes the users arranging the meeting are looking for quick one-line answers but feel the need to arrange a meeting because that is how they’ve been instructed and taught. I’ve provided below tips to minimise meeting times.

• Prior to attending the meeting ask the mediator the purpose of the meeting
  • I ask the mediator beforehand what the meeting is about
• If the meeting title isn’t clear, ask the mediator what the meeting relates to
  • E.g. a current, previous issue, future development?
• Ask the mediator what they are looking or seeking
  • Most of the time the mediator is looking for a quick answer and is arranging a meeting with several people because they don’t know who to reach out to
    • This is where extra knowledge outside what you’re supporting will be useful
      • I mentioned a similar learning item on the blog post “be a sponge”, under “what should I learn today (IT admin skills)? Pt 2”
    • If you do have extra knowledge and know how to answer the mediator’s concerns, provide it to them.
      • E.g. “No sorry the issue you need addressing is being looked after by Team ABC. Please speak to their team lead to address your issue.”
    • If you are not 100% sure but may have some idea on how to address the mediator’s issue you can advise the following
      • E.g. “Hmm not 100% sure on your issue, but I do know Team ABC looks after part of that system that involves your issue. Reach out to their team lead and see if they are able to advise.”
  • If you are not 100% at all on what the mediator needs, do your team members or working groups around you know the purpose of the meeting?
    • Who on the invite is also involved in the meeting. If this person is known in your working circles, reach out to them asking for their input.
      • It may reveal clues on what the mediator needs.
• Who else needs to be part of this meeting
  • If you are the Snr SME most likely someone gave your name to the mediator for you to attend the meeting
  • Get other team members involved in this meeting, so the knowledge or discussion is spread across other team members. Otherwise, if only one person is across this meeting it means that one individual (or you) will bear the responsibility for that meeting.
    • This will be a burden and a frustration later as you are the only one attending this meeting and others don’t attend.
    • At the very least forward the meeting to other users on your team so they are aware.
• After obtaining details from the mediator, if you are unable to provide anything meaningful and don’t know the issue you will probably need to attend the meeting.
  • During the meeting it’s important to take down notes from the meeting for yourself.
    • Don’t rely on the mediator or a scribe to record notes. Be proactive and write notes for yourself.
      • You can then upload these notes into a directory or work collaboration space.
    • If after the meeting you have nothing to write, then you have nothing to write. But just be ready to document and write down anything that sounds important
      • E.g. I have attended quite a few ‘Major incident meetings’ to discuss root causes and solutions. These meetings tend to be technical in nature. These meetings involve users from networks, devops, SME’s support customer / business applications and snr stakeholders.
        • These meetings may cover specific commands to run in Windows or Linux CLI to gather outputs for different systems, process’ flows on who talks to who when an issue arises, screen sharing and demoing how certain applications work etc.
      • If you come across something in the meeting that appears to be meaningful for you, write that item down. Also take note of the time you recorded that item. Since that person who communicated that item in the meeting probably won’t remember.
        • E.g. “Approximately 20 minutes in the meeting, you mentioned the accounting and customer systems had an issue. Can you explain to me the part where the accounting system talks to the customer system. Are you able to advise who looks after both of these systems just for my fyi.”
  • Post-personal summary of the meeting
    • Did I learn anything new in this meeting?
      • If so, I should document it for my own reference
    • Did my team learn anything new in this meeting
      • A quick discussion with colleagues about what the meeting was about should take place. No more than 5-10 mins.
    • If the meeting didn’t answer or address the topic, is there going to be another meeting? Can I get ahead of this meeting, obtain the answer and address the topic or issue prior.

Summary:

• Can I provide the answer or address the query by the mediator prior to the meeting.
• If the meeting is to go ahead, find out what it’s about beforehand to give yourself time to prepare and get understanding.
• There will be an opportunity to learn or absorb something new in the meeting. Make sure you’re ready to document those new items for your own personal development and knowledge.
• Make sure others are involved in the meeting, provided the meeting is not directed to you.
• Discuss with your colleagues if there are any concerns or discuss any topics of interest that came from that meeting.