The #RisingTide LevelUp Challenge

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.

‍

‍

In any business where you’re not billing Time and Materials, the amount of time you spend on a project directly correlates to how profitable you are. In an MSP, this applies even more. MSP Businesses were designed years ahead of their time, bringing into practice concepts such as recurring revenue, outsourcing, efficient resources, and more; before people even realized the value. It’s the reason that today the MSP Businesses are blowing up with everyone you meet starting their own. Unfortunately, there’s a complex side to the framework of an MSP that is very often overlooked, especially by those just starting out.

Let’s discuss how the MSP business model is built. MSPs pitch to their prospective clients that they can provide the same level (or often times better) IT Services to their organization than they themselves can find if they go with someone internally. They ask for less money, and offer a bigger team with greater experience. These same MSPs then have to turn around and hire the same people that would have been hired directly, and not just one, but two or three or more depending on the size of the MSP.

MSPs have to pay the same salary with a smaller budget. How can these numbers possibly work?

This is where efficient resources come in; an MSP needs to stack multiple clients reusing the same resources for each client so that together all the clients combined pay enough money for the MSP to pay the technicians salary and make a profit. The income also needs to cover all base expenses of the MSP which includes infrastructure such as an RMM, PSA, Email, Phones, over-night team for emergencies and so on.

With an internal IT resource, that resource would be solely focused on the business they were working for and getting paid a full salary of say $52k/year, now the same resource at an MSP is getting paid $52k/year and needs to  stay on top of not one company IT needs, but actually 3 or 4 (or more depending on the contract size of each). This kind of expectation is unreasonable and when maintained results in high-stress work environments and eventual burn out for the technician. The saying “trial by fire” is very applicable to the technicians who work at an MSP. They are under constant barrage of tickets and stress, jumping from company to company each ticket wildly different from the next. This makes them unusually skilled and also rapidly exposes them to a wide range of experience they may not have received working for just one company. A good MSP technician of the lowest tier can easily go head to head in ability (if not knowledge) to a mid-tier internal IT resource.

Now keep in mind that when MSPs started we were a new phenomenon. There was no standard to follow, no existing business to copy, except for the existing internal IT department within a Company. We didn’t know what kind of pay structure was fair to offer a Tier 1 or Tier 2 technician because there was no “average pay” metric. The only thing we did know is that we are building a business with a stress on smaller dollar amounts per client, and more total clients. This means what we paid our technicians had to be less too, or that we keep the MSP as lean as possible with only the amount of technicians truly needed. Following the 80/20 rule we determined that 80% of the time with our clients running smoothly we would be fine and only 20% of the time when some kind “perfect storm” would occur we would need to motivate our technicians to put in more effort (or what was generally called “figure something out”).

What’s being described is not a sustainable long term plan. Simon Sinek likes to stress that business is an Infinite Game and that those who are not playing by those rules are doomed to failure eventually. The only way to stay in the game is by having resources, and the will to keep playing. We’ve already established that MSPs do not have the same pockets as a normal business, not without drastically imposing upon “will”, our employees, making them work in stressful environments and constantly being battered by the next broken issue.

The fix for this is easy, and its an iteration of what we already started. Efficient use of resources. Efficiency can help us spend less time per ticket, less time per client, and improve our technicians stress in the environment. There are two side to the efficient use of resources, one of which we already started (Sharing resources among companies) but the other is often overlooked “Work load management”. If we can make our work load efficient we can easily improve upon all the issues we just brought up. Here are some ideas that can be used to help facilitate the efficient workload.

Efficient resources is way more than just sharing resources. Making your workload efficient is just as important. Remember how profitable you are directly correlates to how efficient you can be

• Proactively addressing age of client equipment
• Proactively addressing ticket trends over time to help improve underlying issues
• End User technology training for better understanding of the tools they use
• Breaking Client’s business vertical into separate teams to allow for familiarity of Line of Business applications and setup
• Building an MSP supported technical standard as your “stack” to ensure familiarity with technical infrastructure
• Establishing formalized business processes for your MSP Teams so they know where to find information and how to proceed
• Building an Automation First environment allowing you to offload work from your team to your technology decreasing the amount of time spent on tickets.

Remember, in the MSP business time isn’t a loss of potential profit, its actual profit lost as your contracted rate is the same every month. Automation and bulk actions are extremely important as the less time you spend doing something the more your Per Hour amount goes up.

The butterfly effect is a term used to reference a scenario where, if you were to go back in time 1000 years and step on a butterfly and then return to your current time, you would find that everything has been changed. Potentially even you would no longer exist. This is explained as being caused by the fact that everything in the world is connected (as being part of the same ecosystem) and therefore given enough time the effects of a tiny butterfly being squashed can exponentially grow into an event where the Germans won World War II, or your parents never met.

In a world today where we are too busy to look beyond the face value, the lesson is pretty clear. If you go back in time, make sure you don’t step on any butterflies. If we were to stop and look beyond the face value, the lesson hits far closer to home. Scientists use this to explain that even a small change in a complex system can have a huge impact, but even they distill the true lesson down to its practical use for themselves.

Have you ever watched a Wave roll through the stadium audience, proud to join the hundreds raising their hands but jealous you weren’t the one who started it? What did the other person have that you don’t? Why couldn’t you be the source of this impressive movement visible throughout the entire stadium? The answer is honestly, nothing. Just the courage to go first, and be the leader, influencing others around you and creating an impact that spreads.

You have been created in order that you might make a difference. You have within you the power to change the world. – Andy Anderson

The Rising Tide Consulting Group is movement looking to start the waves, creating the tide, that will subsequently create larger waves, and larger waves, eventually rising higher and elevating everyone within the ecosystem. Let’s go back to the Wave in the stadium, can you imagine if the first person lifted their hands to create the Wave and the person next to them watched, acknowledged it was cool, and did nothing? The only reason why the Wave works is because the second person who follows, then the third, and the fourth and so-on. This is why at Rising Tide we are hyper-focused not on your business, but on your people. If we do your work for you, there is no impact, and we are left deciding if we should keep raising our hands to make up for the effort of those who aren’t joining or give up! If we can influence you doing your work, we can be the start of a massive wave that will spread not only throughout your entire business, but to your clients, and your vendors, raising the level of partnerships and quality of service being delivered to you, and by you.

The Rising Tide LevelUp Challenge is our ‘Audience in the Stadium Wave’. A movement started by our mentor Mendy Green on LinkedIn, where you take three stories, or analogies, and you pull out a lesson learned from each one (similar to how we did it with The Butterfly Effect mentioned above). After your three lessons you call out three new people to partake in the challenge and post their own. The lessons can be repeated, but the analogies or stories must be different.

In every situation, scenario, or story, there’s always a lesson to be learned. The scientists knew that when they framed the Butterfly Effect to teach their lesson, but each person will look at these stories and lessons through a colored lens filtered for their specific use case! It’s up to each individual as they hear these to take a lesson that relates to them. In fact, it is with Elizabeth Copeland’s lesson from the challenge (“Sometimes you need to stop and take in the view”) that we can examine analogies and situations and pull out a lesson from each one relevant to us to help us grow; the difference between taking something at face value or looking for that deeper meaning.

You can find her lesson and more by looking for the tags #RisingTideChallenge or #RisingTide on LinkedIn.