Alt+Ctrl+Start

Have a read of this previous post https://infotechmentor.com/2024/10/23/the-10-rule/. It provides an example of how to document extra information from issues and problems. This is to show you how other functions and features work outside your subject matter expertise.

• What is the 10% you say?
  • It’s my version of learning more than your subject matter expertise (sme)
  • For example, you’re a car mechanic and you know how to service cars (i.e. engine, gearbox, suspension etc). But what about trying to service trucks or buses?
    • Is there a difference?
  • In technology we have developers, ops engineers, sysadmins, project managers, middle managers, leads etc etc
    • All these users partake in the IT industry in some form or another
    • Once one of these users don’t have a specific knowledge they will ask a colleague for this information
      • Even simple things like what’s the url to this service, or how do I log into this website etc
    • The thing with these questions is that they we’re asked probably 10’s or even 100’s of times in the past, yet no one was proactive enough to document and store this information
      • And once one obtains this information they might document it but then the document gets lost or people forget about it 🙁
    • You have a rinse and repeat of asking the same questions / requests over and over
  • The 10% rule is about observing, absorbing, documenting, reviewing (and then storing and remembering 🙂 )
  • Another example I can provide about the 10% rule is performing your actual tech/IT job
    • At first you might be asked to log tickets/jobs, put descriptions, put summaries, put titles, describe the issue etc etc, and then press done
      • Then what!?
    • That’s it log the job and then move to the next one?
      • Rinse and repeat? :/
      • You wonder why people get bored quickly in the tech industry, doing the same thing over and over. They contemplate maybe switching industries or roles (which isn’t a bad thing, but most people contemplate this before even mastering what’s infant of them)
    • After logging this ticket/job, find out who looks after these tickets/jobs.
      • Is it a developer, a dev ops engineer, a sysadmin etc?
    • Find out what they do, ask the manager if you can spend some time with them, to see what they do.
      • Actually ask them (your other team mates) to show you the screens, where the tickets land, how they resolve, what meetings they conduct etc etc
    • You’ll find out there’s a bigger system out there, than yourself sitting on the front desk
  • The argument here you might say, is I have to do more work
    • Sure it’s a little extra, hence why I call it the 10% rule
    • You commit 100% to your role and there’s an extra 10% you need to put on top of that
    • The rebuttal to the argument about doing extra should be seen as knowledge building
      • By knowing other systems, tools, programs, ways of working, you observe other parts of the system
      • You will see a larger view of how the organisation works
      • You will see bottle necks and understand why nothing gets done 🙂
        • These bottle necks will be common across all tech industries / companies
          • Even your social media companies you use. Remember they have outages as well
          • Do you remember the last time we had a major technology outage?
            • Crowdstrike (2023-24 (I don’t remember the exact date 🙂 ) and AWS (2025)
          • Or how about a project that was meant to get delivered on a specific date, but twenty past for weeks and months?
      • More importantly you might be shown a part of the system which you might want to move into?
        • I.e. Moving into a 2nd level role, another role like sysad, ops, dev ops, dev etc
  • All this extra work you add to your job description/resume/kpi, you can then dot point these extra tasks/duties
    • These can then form part of your yearly ‘key performance indicator’ (kpi)
    • You can then show your manager
      • Hey ‘X’, I documented these test urls to help the devs out since they always ask me the same thing over and over, I helped the dev ops team on arranging the deployment schedule because they’re not familiar with the production systems, I was woken up at 5am to help a prod issue; I showed the audience the document I created on this prod issue that I would know would reappear etc etc
    • All these things I’ve documented a little wins
    • The types of wins that will see you get more recognised, get some more (small) promotions and get considered for bigger and better things

Summary:

• Adding a little bit more knowledge from your surroundings will enhance your overall appreciation for the systems you manage / partake in
  • You will see the challenges and bottlenecks
  • You will understand why things get delayed and postponed
    • You will then be able to apply this to other things you read or hear in the tech industry
• Observe, absorb, document, review the duties/jobs/tasks around you role
  • (And more importantly make sure you know where to Store and Remember the 4 steps above)
• For those who want to stay and do the ‘status quo’ (I.e. Just do the bare minimum)
  • That’s ok too
  • Just be prepared others around you will move past your
    • I assume that’s what you’ve accepted 🙂
    • Carry on