Laws for the Practical Technician

By  
Mendy Green
July 5, 2024
20 min read
Share this post

Over the years of training and assisting various technicians, I've formed a set of guidelines that I've been known to drill constantly. The other day while talking to a newer technician and working with them I realized that I now have the time I didn't have before to actually write down what I've been ranting about for 14 years. I've dubbed them as the Laws for the Practical Technician.

  1. Keep an open mind when approaching the problem and avoid falling back into the "End User" mindset
  2. Read and explore everything on the screen! Pay attention to what's being done and what its telling you
  3. Understand the problem at least as well as the person asking you for help
  4. Be intentional in your troubleshooting, closing your eyes and throwing darts at the wall is not helpful
  5. Question everything you think you know and are being told
  6. Always have a way out, make sure you can undo anything you do

There's a lot of nuance in each "law" so now that we got the TLDR version out of the way let's dive into the specifics. Note for the purposes of this post, each law has been given a title.

1. The "Technician" Mindset

Keep an open mind when approaching the problem and avoid falling back into the "End User" mindset

If you run around with your eyes closed expecting nothing to get in your way, you're bound to smack into a wall (or something) and fall down.  If you keep your eyes open and aware of your surroundings you can navigate the obstacles and overcome them.

End users typically expect systems to work seamlessly and view issues as problems needing external help. Technicians, on the other hand, approach systems with the expectation that things might not work and are prepared to "figure it out" each time.

Key Points:

  • Expect Issues: Approach every situation with the mindset that things might not work as expected. This keeps it fresh in your mind and allows you to figure out what should or should not be happening each time, and usually during that process you'll identify the disconnect that's causing the issue.
  • Problem-Solving Approach: View issues as challenges to be solved rather than insurmountable problems. This proactive mindset helps in finding creative solutions.
  • Context Matters: The difference in mindset is less about the person and more about the context! Everyone (for the most part) handles their own problems for their personal lives daily. The moment it becomes a work or tech issue suddenly its hands-off. Be aware of the context you're in, this affects Clients escalating to IT and IT escalating to a higher tier! Don't fall into the trap.

Example: When dealing with a software bug, an end user might see it as "broken" and wait for a fix. A technician, however, will explore various angles—checking logs, considering recent changes, and testing different scenarios to identify the root cause, or find a viable workaround

2. Read the Entire Screen

Read and explore everything on the screen! Pay attention to what's being done and what its telling you

Computers and software are designed to be used, (it's actually the only way they make money!). Therefore, the information needed to operate or troubleshoot them is generally available on the screen or in logs, (although the language can be context-specific for the industry). To effectively identify and solve issues, it's crucial to explore the interface and ask questions. Thoroughly reading on-screen messages and prompts can provide insights into what might be wrong and how to address it.

When encountering an error message or unexpected behavior, don’t rush to conclusions, AND DO NOT SKIP IT! 

Instead, read all the details provided. Error codes, system messages, and even seemingly minor details can offer significant clues. For instance, a message that seems obscure at first glance might make sense when considered within the context of the application or system you're working on. Even comparing against a computer that is working, looking for differences in behavior, or order of operations, screen activity, and so on, can provide clues (for example an error that takes a while to appear is likely caused by a timeout, vs an error that appears immediately is likely caused by an immediate rejection).

Example: If a user reports an issue with a software application crashing, instead of just noting "application crashes," you should read any error messages, logs, or system prompts that appear when the crash occurs. These details can guide you towards understanding the root cause and potential fixes.

3. Understand the Problem

Understand the problem at least as well as the person asking you for help

To effectively troubleshoot, ensure you can recreate the problem and understand its significance. Start by asking the person reporting the issue why it's a problem and why it's important to solve it. Gather as much information as possible to understand all sides of the issue. You should be able to understand the problem at least as well as the person reporting it to you, otherwise how do you expect to fix it? Or even explain it to the next escalation point if you have to reach out for help?

Here are some ways you can work to understand the problem.

  • Recreate the Problem: Attempt to replicate the issue in your environment. This step is the best option because it allows you to see the problem firsthand and understand its nuances, at the same time as testing to see if its a problem with their computer only or a wider issue. You can also choose to recreate the problem on a different system, if it requires specific applications or files you don't have on your computer directly.
  • Understand the Impact: Determine why the issue is significant. Is it causing data loss, preventing critical operations, or just a minor inconvenience? Understanding the impact helps prioritize the issue and communicate its importance to others.
  • Gather Detailed Information: Ask the user detailed questions about the problem. When did it start? What were they doing when it occurred? Has anything changed recently (e.g., new software, updates, hardware changes)? What's normally supposed to happen?
  • Prepare for Escalation: If you cannot resolve the issue, you might need to escalate it to a vendor or higher-level support. Having detailed information and a clear understanding of the problem will make this process smoother and more effective.

Example: If a user cannot access a shared network drive, ask them about any recent changes to their system, any specific error messages they receive, and how critical this access is to their work. Look at what the shared drive is mapped to, and if other people have access to it that are working. Identify the network the user who is complaining about is on and if it has connectivity to the shared drive host. This comprehensive understanding allows you to troubleshoot more effectively and escalate if needed.

4. Be Intentional

Be intentional in your troubleshooting, closing your eyes and throwing darts at the wall is not helpful

Being intentional in your actions means making deliberate, thoughtful decisions rather than taking random stabs at fixing an issue. This approach prevents exacerbating the problem and leads to more efficient troubleshooting. Most technicians below Tier 3 will perform troubleshooting by way of "trying different thing to see what works", this is essentially closing your eyes and trying to pin the tail on the donkey, make sure you understand what is going on, and the logical reason why what you're attempting will affect (either negatively or positively) the current outcome so that you can make progress with every step.

Expand on This:

  • Map out the "Attack" Chain: Before diving into fixing an issue, outline the Chain that exists to allow the system you're troubleshooting to work during normal behavior. What are the potential areas for disconnect? What steps will you take to test that the chain is working throughout?
  • Progress is Progress (both good and bad): Any change in outcome is desired, as it'll help provide information about the underlying behavior that we don't have visibility into. Look for error messages, success messages, timers, lags and so on. No detail is too small.
  • Evaluate and Adjust: After each step, evaluate whether it has brought you closer to resolving the issue. Adjust your approach based on these evaluations.

Example: If a printer isn’t working, don’t randomly try different fixes like restarting the printer, reinstalling drivers, or changing settings. Instead, follow a logical sequence—check for error messages to help point you towards a connection issue or a driver issue.

5. Question Assumptions

Question everything you think you know and are being told.

Always be prepared to reassess what you know. Technology and systems evolve, and what was true yesterday might not hold today. Keeping an open mind and questioning assumptions can lead to discovering the true cause of an issue.

Expand on This:

  • Expect to be wrong all the time: When you're right about something there's no reason to go back and check because you know you're right. If you're wrong about something then you'll be looking to validate that you are wrong, or what the right answer is. This mindset helps keep your knowledge fresh and reminds you to double check everything you think you know or are being told.
  • Seek Out Information: Be proactive in seeking out new information and learning from others. Forums, user groups, and official documentation can offer insights you might not have considered. Often times all it takes to help find the answer is asking the question, not to the person next to you, but even to yourself! Use the Rubber Duck method if you need to.

Example: If a network issue arises, don’t assume it’s due to the same cause as last time. Reevaluate the situation - start the troubleshooting process from scratch everytime until you've identified the root cause to the be the same as last time.

6. Never Do Something You Can't Undo

Always have a way out, make sure you can undo anything you do

Always have a contingency plan before making changes. Ensure that any action you take can be reversed if it doesn’t resolve the issue or causes new problems.

Expand on This:

  • Backup First: Before making destructive changes, find a way to keep a good copy of what you're changing. This ensures that you can revert back if needed.
  • Test Changes: Where possible, test changes in a controlled environment before applying them to the live system.
  • Document Reversible Steps: Ensure that every action you take can be undone. Document the steps if necessary so you can revert configurations and settings.

Example: Before modifying a system registry, backup the registry or export the key in question. Rename something instead of deleting it, or cut/paste it somewhere else. This way, if the change has unintended consequences, you can easily revert to the previous state.

----

Edit 2024/11/13 | This article has been presented and recorded at The IT Nation Connect 2024 in Orlando, Florida! You can watch it here: https://youtu.be/ZJqhT48pnLU

Share this post
Mendy Green

I'm passionate about IT, driven by a dual love for solving complex problems and a commitment to transforming the stereotype of technical support into a positive and enjoyable user experience. For over 13 years, I've been deeply involved in the MSPGeek community, lending my expertise to various Managed Service Providers (MSPs), while also serving as the CTO at IntelliComp Technologies.

My journey in the tech world is fueled by a passion for teaching others. I find great satisfaction in imparting problem-solving and critical thinking skills, and offering practical guidance during the troubleshooting process. It's this enthusiasm for mentorship and improvement that led me to my current venture.

Today, as the founder of Rising Tide, I'm focusing on the MSP industry, dedicating my time to coaching and assisting both individuals and businesses. At Rising Tide, we're not just about providing solutions; we're about nurturing growth, fostering innovation, and building a community where everyone can rise together. Whether it's through hands-on problem solving or strategic planning, my goal is to make the IT experience not just efficient, but also empowering and enjoyable

See some more of our most recent posts...
November 11, 2025
8 min read

By the [run]Book: Episode 11

Episode 11 breaks down the most impactful upgrades across v2.202 and v2.204 — from smarter controls to new AI capabilities every MSP should know.
Read post

In Episode 11 of By the [run]Book, Connor and Mendy wrap up v2.202 and move into v2.204, highlighting a mix of compliance tools, smarter ticketing controls, and powerful new AI foundations. They cover everything from audit log redaction and agent cost history tracking to Halo’s new MCP server, plus practical integration updates MSPs can use right away. It’s a fast, insight-packed walkthrough of the latest improvements shaping daily MSP workflows.

Watch Now: By the [run]Book: Episode 11
For easier tracking, check out haloreleases.remmy.dev to filter and search HaloPSA updates by ID, version, and keyword.

Added the setting 'Allow admins to redact Ticket audit logs' | v2.202 #817350 | 2:33

A new compliance-driven option allowing admins to redact specific audit log entries.

  • Redactions are themselves logged
  • Ideal for removing accidentally captured sensitive information
  • Could be automated for retention policies

Added advanced settings per ticket type to disable the problem/resolution finder for agents and users | v2.202 #795561 | 4:29

More precise control of when Halo’s Resolution Finder appears.

  • Disable for admin/maintenance workflows
  • Keep enabled for user-facing support
  • Improves workflow relevancy + reduces noise

Added the ability to use custom filter profiles on the Self Service Portal | v2.202 #768823 | 7:54

You can now surface custom ticket views directly to clients.

  • Great for “All Tasks,” project dashboards, or simplified overviews
  • Can be access-controlled so agents don’t see them
  • Major enhancement for client-side transparency

Added Subscriptions and Software Licences to SQL Import Integration | v2.202 #737247 | 12:18

Allows software licensing data to be imported through SQL Integrator.

  • Requires consistent identifiers
  • Supports license type mapping + customer matching
  • Bridges on-prem systems with Halo licensing

Added Agent cost history tracking | v2.202 #735577 | 15:30

A major improvement for profitability accuracy.

  • Stores cost by time period
  • Supports multi-currency
  • Prevents old tickets from recalculating using new rates
  • Essential for contract margin analysis

MSP Tip: Enable this before your next billing cycle.

Added Opensearch as a vector search database option for AI searching | v2.202 #650351 | 22:23

Halo now supports Opensearch for AI semantic search.

  • Better AI matching & contextual understanding
  • Powers more accurate AI triage & article suggestions

Entering v2.204

Halo Remote MCP Server for AI integrations now available | v2.204 #979569 | 24:37

Halo’s MCP server enables AI systems to take real action via the Halo API.

  • Requires tight guardrails
  • Future update adds bearer tokens for stable authentication
  • Enables smarter Halobot and AI-driven automation

Improvements to the Dynamics Business Central integration | v2.204 #882737 | 30:36

Improvements to the Addigy integration | v2.204 #787185 | 30:48

A setting has been added… to disable asynchronous search | v2.204 #1005031 | 32:54

Allows fallback to synchronous sequential search.

  • Use cautiously — unclear scenarios for enabling

Custom Tag Category mapping via ID or "~" for N-Central | v2.204 #1004123 | 34:15

Changes to the "Allow actions to be translated…" | v2.204 #1003051 | 35:22

Better translation toggles for multi-language communication.

New "Get Report Data" custom function for MCP & Virtual Agents | v2.204 #1003042 | 37:19

Allow Sales Opportunities to be invoiced | v2.204 #1002257 | 37:44

IT Glue Location Sync | v2.204 #1000835 | 40:55

Ticket Sources can be disabled | v2.204 #1000775 | 41:21

Edit Prepay time allocated to an action | v2.204 #1000603 | 41:38

Expense review process improvements | v2.204 #1000311 | 45:02

  • Bulk actions
  • Clearer UI
  • Better handling for reimbursement flows

Quotes & Orders default sorting fix | v2.204 #999825 | 47:11

Allow items to be added to approved POs from Sales Orders | v2.204 #999609 | 50:45

Add Additional Agents as Attendees on Appointment creation | v2.204 #999225 | 51:40

Rich Text Custom Fields will now populate the $ variables on PDFs & Emails | v2.204 #998883 | 53:38

November 19, 2025
8 min read

Chapter-by-Chapter Discussion Questions for The Go-Giver by Bob Burg: Chapter Seven - Rachel

In this chapter guide to “Rachel” from The Go-Giver, we explore what great coffee, storytelling, and human needs have in common. From “survive, save, serve” to Maslow and “meat computers,” this piece invites MSP leaders and service pros to rethink how they scale excellence without burning people...or the beans!
Read post

About this Series

This discussion guide is part of Rising Tide’s Fall 2025 book club, where we’re reading The Go-Giver by Bob Burg and John David Mann.

If you’re just joining us, here are a few pages you’ll likely benefit from:

Chapter Summary

In Chapter 7, "Rachel," we learn more about Rachel and about the characteristics that Pindar finds valuable.

Discussion Questions

Use these open-ended prompts to guide reflection and conversation. Remember, there are no right answers!

  • How do you feel about the commentary about Pindar’s age? Do you know people who are younger than they seem? What characteristics contribute to that perception?
  • Can you relate to Rachel? Is her story believable? What do you think the authors seek to elucidate about her? What about Pindar’s view of her?
  • We’re yet again hearing Pindar described as a storyteller. What does that make you think the authors are trying to say about Pindar’s skill set?
  • Survive, save, and serve. Where do you find yourself landing? Where would you like to invest more?
  • What do you think is Rachel’s “secret” to good coffee? The author describes many aspects of her craft, surely it’s not just because she’s one-eighth Colombian!  

Rising Tide Input for your Consideration

  • Making coffee well is an interesting metaphor! There is so much care, precision, and repetition in making coffee, it’s as much a science as it can be considered an art.
    • Consider Starbucks beans: to produce a consistent product at a scale, they roast their beans very hard, eliminating the unique characteristics of a specific variety of coffee bean in lieu of a product that will hold up to their regularly heavy-flavored and sugared drinks. (See: Why Starbucks Coffee Has That Burnt Taste) Is it possible to truly scale excellence with care? Is there a limit?
    • As you're growing YOUR business, which parts of your business are you burning off as you clarify your mission and vision? If you're not burning with care and wisdom, you can burn off exactly what makes you and your team special, and you can even deter your ideal clients because of a lack of care, precision, and intention.  
  • Maslow’s Hierarchy of Needs suggests humans must have their basic needs met before they have the space to pursue “more advanced” needs.
    • If that’s too academic, El gave a talk at MSPGeekCon about how we’re all basically meat computers with Hardware, Software, and Networking built into us. Does that perspective change how you can handle other humans and even take care of yourself? (Watch part 1 of “The Care and Feeding of Meat Computers” here: https://youtu.be/yRcs5XYI8LQ?si=J3Q_VGenSHaKutOR)

About Rising Tide and our Book Club

Rising Tide helps MSPs and service-focused teams build better systems: the kind that align people with purpose.

Every Friday at 9:30 AM ET, we host Rising Tide Fridays as an open conversation for MSP owners, consultants, and service professionals who want to grow both professionally, technically, and emotionally. In Fall/Winter 2025, we’re walking through The Go-Giver, chapter by chapter.

If that sounds like your kind of crowd, reach out to partners@risingtidegroup.net for the Teams link.
Bring your coffee and curiosity…no prep required.

October 13, 2025
8 min read

Chapter-by-Chapter Discussion Questions for The Go-Giver by Bob Burg: Chapter One - The Go-Getter

At Rising Tide, we use book clubs not to read—but to listen, question, and practice curiosity. Join us as we unpack Chapter One of The Go-Giver by Bob Burg and John David Mann, using open-ended prompts to reflect on ambition, connection, and growth. Perfect for service-minded teams who want to slow down and think differently.
Read post

About this Series

If you’ve already read Book Clubs, Conversations, and Curiosity, you know that at Rising Tide, we don’t host book clubs for the sake of reading. We use them as an excuse to talk, to listen, and to practice curiosity together.

The Go-Giver by Bob Burg and John David Mann is the first book that we've chosen to explore together in this way. Each week, we’re reading one short chapter together and using a few open-ended questions to spark real conversation: no lectures, no wrong answers, just reflection.

Below are our discussion prompts for Chapter One: “The Go-Getter.”

They’re written for teams like ours: busy, service-minded, sometimes too practical for their own good...who want to slow down long enough to notice what these stories have to teach.

How this guide is different from others you'll find online: We keep it chapter-focused. Every set of questions focuses only on the current chapter so there is no foreshadowing, no jumping ahead, no “we’ll get to that in Chapter 7.” The goal is to slow down and savor the smaller ideas that get lost when you rush to the big themes, and we're going to make sure that team members that are "behind" have enough data points to connect the dots and contribute even if they're not caught up to the current reading.

Use them however you like. Whether you’re reading along with us or just looking for a fresh team conversation starter, we hope these questions help you stretch a little, think differently, and see something new in yourself or your work.

Some Tips on how to use this Guide

  1. Keep it simple. No slides. No structured lessons. Read a question aloud, give a solid 10-second pause, sometimes you have to let the awkwardness of silence drive the conversation.
  2. Honor the one-chapter rule. No spoilers, no summaries! Stay inside the chapter or assigned reading. If someone raises a later theme, park it in a “Next Chapters” list and keep today focused. Similarly, don’t try to solve the book. Ask what this chapter made people notice or feel—nothing more.
  3. Actively include people who didn’t read and make space for quieter voices. Use prompts like, “From this idea alone, what stands out?” Curiosity doesn’t require homework. Explicitly ask: “Anyone who hasn’t shared want to weigh in?” Intentionally invite two voices before anyone speaks twice
  4. Time-box it. 15–30 minutes. One good discussion beats five rushed questions.
  5. Close with a single takeaway. Each person names one sentence, idea, or action they’re taking into the week. Log it. Revisit next time.

If you tweak or add questions, tell us at partners@risingtidegroup.net. We’ll keep improving this tool for other MSP teams.

Chapter One Discussion Questions and Observations

Chapter One Summary

In this chapter, we meet Joe, a go-getter who doesn't seem to be getting what he's going for. We are also introduced to his coworkers: Melanie and Gus, who help connect him with Pindar, or the Chairman, who agrees to tell Joe the huge trade secret that will surely be his key to success.

Chapter One Questions

  • How would you describe or define a go-getter?
  • Is it a good or bad thing? Why?
  • Do you consider yourself a go-getter?
  • Do you know people like Joe, Gus, or Melanie? What do you think of them as people or colleagues?
  • Why do you think the authors chose the name Pindar for the Chairman?
  • What do you think Pindar's conditions are going to be?

Chapter One Observations from the Rising Tide Team

  • Being a Go-Getter isn’t a bad thing!
  • It’s important to remember that the authors of this book are likely flattening the depth of characters into caricatures to more cleanly get the point of their story across. This is important to remember because rarely in life will the humans you interact with be the fulfillment of the assumptions you make about them.
  • Pindar is the name of a Greek poet who wrote odes of Victory. https://en.wikipedia.org/wiki/Pindar. Does this mean we can expect victory for Joe?
Creatures of a day! What is anyone?
What is anyone not? A dream of a shadow
Is our mortal being. But when there comes to men
A gleam of splendour given of heaven,
Then rests on them a light of glory
And blessed are their days. (Pindar, Pythian 8)

Join the Conversation

Want to hang out in these conversations with the Rising Tide team? We meet Fridays at 9:30 AM ET to talk through important business, technological, and communal developments, and for the next 14ish weeks, The Go-Giver! If you’re an MSP owner, consultant, or service professional who wants to grow your team’s emotional intelligence alongside your technical skill, you’re welcome here.

Reach out to partners@risingtidegroup.net for the Rising Tide Fridays Teams link. Bring your coffee and curiosity: no prep required.