Leon Adato
Developer Relations Advocate, Itinerant I.T. tale-spinner
Cleveland, Ohio, United States
Actions
Leon Adato is a Developer Relations Advocate and has held multiple industry certifications over his 36 years in IT including Cisco, Microsoft, A+, and more. His experience spans financial, healthcare, food and beverage, and other industries.
Leon has been speaking, blogging, and creating content in the monitoring and observability space for almost a decade. His expertise in IT began in 1989 and has led him through roles in classroom training, desktop support, server support, network engineering and systems automation before landing in monitoring and observability over 27 years ago.
Area of Expertise
Topics
What Stan Lee taught me about working in tech
When learning a new so-called "hard" skill - whether it's coding, hardware, networking, or something even more esoteric - guidance is often plentiful and straightforward. There are docs, forums, videos, bootcamps, and more.
But when it comes to building our career in tech - including the way we navigate day to day interactions and challenges - things are rarely so simple. We're left struggling to find a how-to on surviving a rough day; a guide to become a good team member; or a primer on overcoming impostor syndrome?
But it turns out those lessons appear in lots of places, if you know where to look. Including comic books.
Whether they're leaping from the pages in a single bound or soaring off the screen like a bird or a plane, superhero stories have always contained deeper themes and more nuanced insights than one might expect given their spandex-and-cape-clad trappings.
If we take the time to really listen, we discover relevant and compelling examples of how to handle all types of real-world challenges, including the ones we face in tech.
In this talk, I'll unmask tech problems masquerading as two-dimensional comic book villains; unlock the x-ray vision to analyze their true nature; and unleash the inner strength needed to defeat them.
Getting Away from it All - Living an Unplugged Life as an IT Pro
Most IT professionals spend some of their weekend on work stuff. Check email, work on a design, do some research, or on a "fun" project.
After 25 yrs in IT I finally realized that rarely does this help me get ahead. Mostly it makes me feel crushed, rushed, and stretched to the limit.
Not too long ago I started disconnecting for one day every week - totally unplugging. Not just me, but my whole family. Unsurprisingly, doing this did not drive us to the brink of madness.
This is my story, and the lessons I've learned.
Looking back at a lifetime of poor tech choices
Working in tech is a never-ending stream of choices: from the language, platform, and framework we use to the vendors we put our trust (and money) in. Many of us live in fear that our next choice will turn sour, and will end up being a resume-generating event for us.
In reality, there is often a lot more good than you'd expect from those seemingly bad tech choices. In this session, I'll look back on several failed implementations, poor calls, and wasted weekends to see, with the benefit of hindsight, how they turned out to be decent decisions after all.
Technical Empathy
From software to sneakers to sofas, the best designs are executed from the point of view of the user, maintainer, or owner - NOT from the point of view of the designers themselves. The terms "usability", "intuitive", and even "innovation" are (or should be) inextricably linked with the perspective of the recipient, not the creator.
The ability to see things from this perspective is called "technical empathy". In this talk, I'll define what technical empathy is; describe how having technical empathy enhances our design choices, smooths the road to execution, and leads to better outcomes; and provide ideas on how developers and engineers can build technical empathy in themselves and foster it within teams.
As IT practitioners, we often focus on nailing the desired feature; creating small incremental changes rather than sweeping monolithic updates; by collecting metrics on usage and flow; and by maintaining a "fail fast" mentality where we can pivot quickly. But all that might miss a key point: do we understand how the intended beneficiary of our brilliance thinks? Do we know not only WHAT they want, but WHY they want it? Or how they want it?
Technical Empathy is what allows us to start from the right context, and maintain the right direction as we go.
"Network Observability" Overlooked, Underappreciated, more important than ever
Remember the network? Long before "infrastructure as code", container orchestration, cluster management, or death by 1,000 clicks in some labyrinthine cloud configuration console, the network was an essential layer (or 3) of IT operations. The fact is that the network - good old route, switch, packets, and flow networking - is alive and kicking and more important than ever to anyone who cares about the performance and availability of our applications.
More to the point, the network holds secrets you'll never find in the traces, events, metrics, and logs of typical application observability solutions. Secrets like:
- The very real performance issues that happen between the parts you control and the end user (and how to address them)
- Ways a content delivery network - something intended to speed up user experience - can fail silently but horrifically.
- Knowing not only how much data is flowing through the network, but what that flow is comprised of
- Updated versions of old but trusted techniques that actually work in modern networking contexts.
In this talk I'll reveal the observability secrets hiding in plain sight within your network; suggest ways to access that information; and highlight the insights and value you're missing if that data remains invisible, unused, or ignored.
Observability tools don't suck, you just have too many
If your company had 27 different payroll systems, each tailored to fit the needs of a distinct group of 5 individuals, would that be an issue? (Spoiler: Yes.). So why do so many companies end up with 27 (or more) observability solutions?
There are reasons for this. Granted, they're not great reasons, but they exist: , panic purchases during an emergency; Pet projects of privileged executives; Shadow DevOps; and more. Worse, sometimes new tools get in the door because key people don't know the capabilities they need are already present in other solutions.
In this talk, I share
- Steps you can take to articulate the problem to leadership
- Ways to work with management to make resolution a priority
- Intelligent (i.e. "good") design techniques for a robust and future-proofed observability ecosystem
- Stupid (i.e. "bad") design anti-patterns that often occur but are easily avoided.
The Case for Making Your Case
A famous saying teaches "...projects don't fail due to technology. They fail due to politics, budget, or compliance." Despite this painful reality, IT teams continue to propose new technologies, tools, and projects almost entirely on the basis of the technical merits; only for us to be frustrated when we're refused because of those 3 non-technical elements.
In addition to the challenge of explaining deeply complex technical elements in simple terms, making the case to the business requires IT folks learn about and speak to concepts like business justifications, RFP's, ROI, and more - which many of us are loath to do.
But the hard truth is this: if a request isn't made understandable and meaningful to business leaders, it's not going to get done. In this talk, I'll elaborate on why the business continues to ignore our compelling technical arguments, why IT practitioners need to be the ones to adapt, and how to present initiatives in a way the business will appreciate - all without compromising our identity as technical professionals in the process.
Alerts Don't Suck. YOUR Alerts Suck.
Nobody "likes" getting alerts. Best-case, you find out something went (or is going) wrong. Far more often, the alerts we receive are meaningless, trivial, or just plain wrong - a source of constant interruptions, false alarms, and noise.
While you might think this is the inherent nature of alerts, the truth is they can be not only better, but useful and even critically important. Well-crafted alerts based on insightful monitoring are a benefit to the business and a gift to IT practitioners, saving hours of investigation and thousands of dollars.
This talk will include a tour of the alerting hall of horrors, and then provide real-world, vendor-agnostic techniques to make alerts meaningful, effective, valuable, and actionable. By breaking a few bad habits; understanding how and why vendors put their tools together in particular ways; and learning a few new concepts, you'll have people emailing you to say "thank goodness I got that alert!".
Now there's something you probably don't hear every day.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top