Welcome to Episode 180 of the Killing Podcast with special guest host Nadia Karatsoreos!
Nadia has assisted channel partners and customers in building their businesses by adopting best practices and resources that are proven to accelerate success and deliver an exceptional experience to the businesses they serve.
A results-oriented professional who puts partners first, Nadia has many years of experience in business development, community and channel relations. Her career in the MSP space started with Level Platforms in 2010 and since then she has held various roles at other vendors like GFI, Datto, NetApp and now Malwarebytes. She has also served on Executive Councils for CompTIA’s Managed Services, Cloud and Future Leaders Communities.
Nadia has been recognized by CRN as one of the Top Women of the Channel for multiple years (including 2022) and one of the Top 100 People You Don’t Know but Should in 2016.
Topic 1: Do we need an AI “Accountability” board?
“Governments should protect residents from the harms of artificial intelligence and provide means of redress, according to researchers at the University of California, Berkeley.
In a white paper from Berkeley’s Center for Long-Term Cybersecurity, the researchers said that anyone who has been harmed or damaged from the deployment of AI should have the right to complain to an agency or department that has oversight of that AI-driven system or be able to take legal action.”
https://cltc.berkeley.edu/wp-content/uploads/2022/08/AIs_Redress_Problem.pdf
Topic 2: Quietly Quitting – The Hot New Fad – without an agreed-upon definition
Some articles describe Quietly Quitting as taking back work/life balance. Other describe it as doing the bare minimum.
We speculate on what it is, and what it might mean.
https://finance.yahoo.com/news/quiet-quitting-workplace-trend-just-120000048.html
Is QQ a natural consequence of employers’ push to get employees back in the office at any cost?
https://finance.yahoo.com/news/jpmorgan-ceo-jamie-dimon-rips-062715020.html?guccounter=1
The real question is: can you sincerely create engagement and community without being in the same office location 5 days a week? (Short answer: yes.)
Topic 3: Do you have the right to repair . . . your tractor?
Wired magazine discusses “jailbreaking” your John Deere.
Seriously: This will affect the larger right to repair debate.
https://www.wired.com/story/gadget-lab-podcast-562/
Sponsor Memo: Linode
Linode – a top Infrastructure as a Service provider has resources specifically for helping MSPs explore the alternative cloud. Discover this growing market: one of the best-kept secrets in building a scalable, thriving, modern Managed Service Provider business. Learn about the cloud provider landscape, improving KPIs, security, and more in Linode’s free ebook, The MSP’s Guide to Modern Cloud Infrastructure, available now.
This resource and more at http://linode.com/mspradio
I really have a problem with Right to Fix within the MSP world. We strut around like cocks-of-the-walk and “protect” our profitablity by not giving out the Right to Fix. But in reality, we cannot guarentee that we are going to be able to fix every issue within a smal time frame. Especially with all of the complexity and changes we see with Microsoft and other vendors. It might seem strange, but we should probably be straight with the clients and tell them that we have a working system right now that might be broken in 5 minutes due to an “update” from the manufacturer that neither of us can control. And that maybe the best position to take is a partnership with the clients that says that it is “both of us against the vendor” and to do that you should probably agree to let us deal with the technical issues. That in an imperfect world, it is in your best interest to leave the bashing about to us.
Good point, Denis! We need to be honest with clients. But they also need to admit that the IT professional is more likely to be more successful with the maintenance and fixing.
Thanks for listening!
Excellent point … the question of “right to repair” is not a one-way street. While a client might wish to have the freedom to update / change / repair their systems as they see fit (whether or not they are actually qualified to do so), the vendor also maintains a responsibility to maintain their own products within the bounds of a “standard” configuration. It is very common for customers to make changes they believe are “better” than the original configuration (it’s literally the definition of customization) only to learn that when a regular product update happens the vendor has either undone the work of the client or actually created new dependencies that render the customization completely non-functional.
I agree wholeheartedly with the core of your position: just because a client wants the right to repair their systems has absolutely nothing to do with whether they are qualified to do it without actually breaking things. I know that’s certainly true for me and every single person I have ever known who took the time to repair their own car or washing machine or other home appliance. Sometimes we get it right … sometimes we realize we’ve only made it worse and we should have left the work to the professionals. And that’s precisely the point: the “right” to repair goes hand-in-hand with the “responsibility” for having made changes. As the old saying goes, “you broke it … you bought it.”
But therein lies the absolutely essential premise for the existence of the IT channel … or, frankly, the value-added service / support channel in every industry that has ever existed. If the system in question is relatively simple … a customer should have the choice to repair their own purchased product. But if the system is complex the right can still belong to the customer in principle … to be delegated to a “certified” technician who is expressly NOT the vendor. In a nutshell, that’s why a channel even exists … and when vendors restrict that transfer of rights by preventing customers from “owning” the right to repair, they actively eliminate the premise for a support channel.
Bottom line: a valid service / support channel partner exists to align with / advocate for the interests of the customer … not the interests of the vendor. That’s the difference between an agent and a partner — much more than merely semantics.