Michael Hunter
Hello!
Welcome to Uncommon Leadership.
Ray Myers 0:03
Hi! I’m Ray.
Michael 0:07
This is Ray.
I’m Michael Hunter with Uncommon Teams.
Today I’m talking with Ray. Ray Myers, who is Tech Lead of Chaos Engineering at indeed.com and host of Craft versus Cruft on YouTube.
Welcome to the show, Ray.
Ray 0:25
Thank you for having me, Michael.
Michael 0:28
I’m happy to have you here.
In your journey to seeing people as people and leveraging the unique gifts that each person brings, when did you first recognize this might be a valuable approach?
Ray 0:42
One of my earliest memories of this, at least in my professional career, was in my first job.
There was a member of my team that I looked up to a whole lot because they were very fast.
They could comprehend the advanced data structures, they were everything that I thought a good coder was.
And they were, by all the measures. They were a great software engineer.
But, I noticed that not everyone felt about them the way that I did.
They were seen as this thing called a knowledge silo.
The team became overly dependent on them.
Then, there were some people, they didn’t have maybe so much patience with people who couldn’t keep up with them.
They liked me because I could keep up with them.
But not everyone could.
I noticed this disparity where management—I wouldn’t say they had a problem with him, but they didn’t like the situation where there was this knowledge silo and the team was overly dependent on everything going through them, because they just understood the system so well.
And then, other people not getting along with them as well.
That’s when I realized there were more angles to this person, that I thought I wanted to be like them, they didn’t have some of the angles covered, some of the more social aspects of the work.
That started me down a journey of broadening my perspective of what is it that makes someone who’s maximally impactful, and how might you be holding yourself back by ignoring some of the skills.
Michael 2:42
And what have you found? What’s your current definition of someone who is maximally impactful?
Ray 2:50
It’s situational.
If you’re going to be maximally impactful, you have to be curious.
You have to be able to understand the leverage points in your situation.
That may mean you need to learn how to write all of the code.
That’s something that we do that can create impact.
But it may also mean you need to recognize when we don’t have a coding problem.
They’ve asked for some code.
But what really is the issue is that these two teams never talk to each other.
All the code in the world won’t fix that.
Being more impactful has been a journey of being more holistically curious about the ins and outs of the situation. What’s really making the problem tick. What is the problem, not just the ask.
Michael 3:55
How do you engender that curiosity in yourself and in others?
Ray 4:08
I’ll always encourage asking why as a simple way.
If I start to brainstorm a solution, I’m being asked for something.
Recently someone asked me, “Hey, I’m looking to scrape the GitHub API so we can create some productivity metrics. We’re trying to get started with some of those.”
I start down the line of, “The DORA metrics are pretty good, usually, except for this one.”
Then I catch myself.
Wait. I didn’t ask, “What are you actually trying to do? Because you’ve asked me for some metrics. Metrics are not a deliverable in and of themselves. Knowing the numbers are not going to be valuable, independent of what you do with them. So, what are you actually trying to do?” is the follow up to understand that.
Where’s it coming from?
Oftentimes, you’re being asked by someone who wasn’t even the original asker and they might not even know why.
When that happens, keep the curiosity.
Realize you may need to chase this for a little bit to find out where this is even coming from in a larger organization.
That’s where I start.
Michael 5:35
When the curiosity is shut down and they tell you, “Just give me the metrics,” what do you do with that?
Ray 5:43
You learn a mental model of who you’re dealing with and what they care about.
What are their anxieties and interests.
They’ve asked me to do something.
I want to know what the ultimate purpose is.
Perhaps they’re not interested in what the purpose is.
If I care about making them happy, then I better figure out what they do care about.
I find that people aren’t always good with subtlety and balance.
I do believe very strongly in my own professional judgment.
That I have something to bring to the question of, what is actually useful work, what is the responsible work.
I also very strongly recognize I exist in a system with people with their own motivations.
If I get resistance, it’s because I’m talking to someone about something they don’t care about.
I need to find out what they do care about.
Michael 6:50
How do you do that?
Ray 6:56
It depends on who they are.
When I’m, as I often am in the last few years, functioning as a cross-team reliability consultant—I have gone into a specialty of Site Reliability Engineering—you’ll often be drafted to talk to a group of developers who don’t have a dedicated SRE (Site Reliability Engineer), you’re on consult.
I don’t know about their world.
I’ve got a whole bunch of great reliability practices in my backpack.
But what do they, if I just come up, “Hey, the most important thing is SLOs and defect rate or whatever,” without knowing what their day-to-day experience is, I’m not likely to say something that’s relevant to them.
So I look for….
Either I listen.
Or, If I’m in the position where I get to ask a question, I will try to ask something very open ended.
I used to start with, “What are your biggest areas of pain and anxiety?”
If you get a roomful of people to each give you individual answers to what their particular sources of pain and anxiety are like, that’s so much meat.
I love getting information like that.
You may have to be more subtle than that.
You may not be in such a setting, if you’re talking to your manager, or if you just have met them recently, maybe you don’t feel comfortable asking outright.
But you’re listening for, people will get around to the things they care about.
If they say, to one of your suggestions, “We can’t focus on, that’s not a priority right now,” perfect segue.
“What is? That’s not interesting right now? What is interesting right now?”
People ought to respond well.
Michael 8:58
Have you found any cases where they didn’t respond to that? Or they were actively not telling you?
Ray 9:10
I think so.
I’m an individual contributor, even having been at some higher levels of that.
I’ve only seldom been in management track.
Usually, I dabble in higher-level individual contributor roles.
The amount that you are not told is huge.
You don’t always know the size of that.
You hope that you’re going to be told the useful things.
There’s some abstraction beyond which is all this stuff that’s not relevant to you.
I have actually developed a greater suspicion that large amounts of things I care deeply about in terms of how I’m going to prioritize my work are actually hidden from me.
So that’s, what I’m saying is that what you’re asking is a huge issue and underrated.
I underrated it for most of my career.
The biggest time it will happen is when you just don’t have a lot of screen time with someone.
If you and I don’t talk very often, we might not get to me sharing the things that I thought were just my problem.
I’m not really opening up on how I think, where my asks are coming from.
So, understand who you have a rapport with, who you have developed that with, to where you can really, they’re going to present you their model the world.
And then who do you have a more passing relationship with? Who’s more of a wildcard?
Know where your unknowns are.
Michael 10:51
Do you have tools or techniques that you pull out when you’re working with someone where you don’t have that depth of background to help you identify what they’re not telling you that is really going to help?
Ray 11:11
I do like looking for pain.
Your sources of pain and anxiety.
Even if I’m not asking, “What’s pain?” I’m listening for pain.
That’s how I got started.
I didn’t know initially in my career to look for this.
But I would listen to someone indicate that they were in pain somehow and get really curious about that, and find maybe some innovative solutions to that.
You start to do that you do that—even in the smallest degree—you start to win people over.
You start to come into their fold.
Find small inroads.
A technique that I’ve been learning about recently that I want to try more is Theory of Constraints, which is a little more grounded.
I’ve been giving you things that are more like, “Well, just feel around, ask questions, find something interesting, follow your nose.”
Something more deductive and concrete is the techniques in Theory of Constraints, which are all about, what is our actual goal and what is getting in the way of it? How do we surface the various hidden assumptions that are causing things to go wrong? It’s very good at surfacing organizational blind spots.
Michael 12:48
That sounds like it would work well everywhere on the spectrum from clear, hard, technical problems to super squishy, uncomfortable, people problems.
Ray 13:03
Yeah, there are those who would say that Theory of Constraints is almost universally applicable.
I’ll see what I think about it in a few years of trying to actually use it.
On paper, it’s brilliant, in terms of just using deductive logic in a way that is designed to surface, “The reason we never addressed this is because so-and-so’s in a different department than such-and-such. They’ve got these artificial incentives that stopped them from cooperating on this, but if we look at what we’re really trying to achieve, that doesn’t make any sense.”
It’s things of that nature that it’s really good at reading down.
Not all problems can be solved with deductive logic.
But a fair amount.
Michael 13:58
Do you have an example of a problem that didn’t yield to deductive reasoning?
Ray 14:09
I would come at it in the angle of safety culture, but you probably, in your leadership practice, have similar things, where things aren’t just going to fit into, “A causes B causes C” kind of a box.
I believe in Theory of Constraints, which includes deductive logic and cause and effect reasoning, but I also am a site reliability engineer and I believe that there is no such thing as a root cause.
And that even seems in contradiction.
Without going into the whole shift in safety science from safety one to safety two, there is a shift in thinking of, “What can we blame some particular event on?” to “What is it to make a safer system? What is moving safety in a positive direction instead of just avoiding the negative mean?”
It has a lot to do with, people are active promoters of safety. They’re not merely the source of deviations from procedures.
Getting better looks like improving their situation in a lot of really subtle ways.
Going around talking to people, interviewing them, like I mentioned.
These things don’t always have the really hard science answers that you would expect in deductive logic, like what makes a system more resilient?
It’s how the people work together and adapt and reflect and are they in an ergonomic safe situation?
It’s very mushy.
Michael 16:06
Yes, Jerry Weinberg would always say every technical problem is really a people problem. And people problems are always squishy, that’s what makes people problems the hard problems. There’s always a solution that is more or less reasonable, that we can get to if we find the right algorithm or approach. With people problems, that is also usually true and often not nearly as clear or as easy to get to.
Ray 16:49
And once you have a system that is being used or developed by more than one person, you have more people problems than you might think.
Michael 17:00
Absolutely.
Do you have a favorite story of when those people problems exploded in some spectacular or interesting way?
Ray 17:26
One that was formative for me, and I think enough time has passed that this one I’m comfortable talking about, is when I was at Carfax long ago.
This was my first job, and it was one of those moments where someone reveals their source of pain.
This was before I was learning to go around asking, but I was listening.
These were the people, we thought of them as our customers. They weren’t the business’s customers. These were internal business analysts that told us what to build.
We discovered that they, at some point, someone was saying, “How do you find these vehicles, these bins, that exhibited these particular characteristics that you were able to tell us we need to change some system to respond differently to. How are you finding these? Because these are rare. These are really precious to us, these test cases.”
And they said, “We have no, there’s no answer to how I’m finding them. We just are running hundreds of reports by hand. And that’s how we have them is because, just by brute force, we found them.”
I was shuttered.
I don’t know if any other developers in the meeting reacted that way.
That’s terrible, that a person is sitting there, one by one, running these things, hoping they’re going to find this scenario.
I ended up roping in that gifted developer I mentioned earlier, that was a little senior, was able to take my idea of, “Let’s have their life suck less by giving them,” what ended up becoming the, as far as anyone knows, the first vehicle history search engine that has ever been created.
Just for internal use, to find these cars that had particular quirks of history.
This radically changed how they did their operation, in terms of how our business analysts were able to find cases and problems and submit us scenarios.
It had a huge impact.
It’s not that it was that hard to do.
But, we were not the people who needed it.
They were the people who we do their bidding.
They were our requesters.
But they weren’t used to requesting things for them.
They were only used to requesting things that were for the consumer.
So, by opportunistically listening to, “This seems like it’s a massive inefficiency in the process, this ought to change. Regardless of what our backlog looks like, this is wrong.” It was one of the huge early successes of my career.
Michael 20:35
It’s a great example of how when we solve problems that we’re encountering ourselves, we often end up solving problems that our customers are having as well. Sometimes, such as in your case, giving them a quantum leap in capability.
What do you do when you’re not able to listen to what’s going on?
Ray 21:11
I’ve learned to get nervous when I don’t have ears on the ground.
I’ve learned to trust hearsay a lot less.
I used to think, “Surely, what they think about what the situation is,”—I did not give credit to the amount of information that can be lost through team boundaries, through, especially, our hierarchy.
I find a way to get there.
Ideally, can I talk directly to them?
Can I get some artifact?
If not, when I was at my last job, which was an online pharmacy, there were a number of teams that I came on.
First thing, I’m meeting with one of them, “What are your sources of pain and anxiety?”
They mentioned a few systems, which I hadn’t heard of, but I quickly learned I needed to research them.
But another thing I did, because I wasn’t talking immediately to every team, is I said, “Where are the retro notes?”
Or I talked to the Scrum masters.
Maybe I can’t get time with the whole team, but the Scrum master’s in every meeting. So they immediately are able to give me some summary. “Oh, yeah, this is an issue. This is an issue.”
Give me some exploration.
Find people that have more exposure than I do.
And, whichever people happen to be available.
When I was at Morningstar, I’d find an intern that seems particularly to know what’s going on.
I have trouble getting time with the leads, but the interns always have time for my little questions.
They’re always happy to see me.
So, you find where the availability is.
Someone who’s available will usually have more of an insight than you do.
Michael 23:19
So the information is always there somewhere. Even if it’s a bit of a detective hunt to find it, there are clues leading us there.
Ray 23:31
It’s clues that will tell me who knows more.
And maybe the person that I found in the wiki doc is merely just a person who knows who I should ask next.
But, you know, taking all the sources in, and I’m talking, of course, about problems that exist within one institution.
If I had to go around in the world, maybe it’s a little different.
But there’s usually a surprisingly rich breadcrumb trail within an institution.
Michael 24:01
How do you tell, what’s your specific signals that you’ve found the person?
Ray 24:15
Finding the person. Let’s think about what that means.
When I think I’ve found the person, it’s not that I found the person who knows the most about the topic.
It’s that I have found a person who will talk to me, who knows enough about the topic, and ideally is a little open-minded.
They care about it enough that they may be interested to try some things new.
And they have enough free time their calendar isn’t booked solid.
If I find that the expert, that they’re booked solid, I’m going to ask them—maybe not in so many words—”Who should I ask? I understand your time is precious. Who should I ask?”
The right person is someone who’s open-minded and has enough time to talk to me.
Michael 25:20
You’re going after that curiosity again?
Ray 25:23
Yeah. Who will indulge my curiosity and hopefully share it?
Michael 25:31
Is that your primary metric for your own success? The level your curiosity is at?
Ray 25:44
I don’t consider anything a success until things have shipped.
It might not be literally shipping software.
But until some positive change has been released into the world.
Until then, it’s all potential.
But, my curiosity is a big driver of my radar.
I’ve got like, “This seems interesting. Seems like there might be some value over there.”
But I don’t consider anything a success until it’s made it out.
If a week goes by and no value has escaped into the world, I get really antsy.
Michael 26:28
What do you do when that happens?
Ray 26:33
I look for, goes back to the Theory of Constraints.
I look for the bottlenecks.
Oftentimes, it’s because the organization has a habit of batching up these really big ideas and really big bets.
Maybe I have to buck the system a little bit and say, “The best way to get your big idea is for us to find the most important little sliver and ship it at once.”
I try to bring everything I’ve learned to bear about how we can make batch sizes smaller.
To think in smaller bets, smaller experiments.
Sometimes you get some institutional resistance on that.
Michael 27:21
If you were starting over now, back in that first job, what would be the most important shift you would make?
Ray 27:38
Well, on my channel, the first two episodes are called “Ship value.” And the second one is “Software engineering is social.”
I told you about the software engineering is social, one of the early lessons on that one, and we were just talking about shipping value, always be shipping value, always be testing your assumptions. So those would certainly be up there.
One of the next things that comes to mind is, technical strategy cannot exist independently from business strategy.
If you think you know where the technical system needs to go, but you don’t know where the business is trying to go, then you don’t know anything about what the technology should be doing.
That one’s really hard, because people go to great lengths to hide business strategy from developers, maybe without even realizing that’s what they’re doing.
Michael 28:39
If that’s important to the work you do, how do you spy that out?
Ray 28:50
I mentioned asking why.
That finds a thread to pull.
But the answer is different everywhere.
It’s finding the right person in the ways that I talked about.
Someone who could be the right person and being available and curious with you.
As it pertains to the business strategy, that’s its own journey in every environment.
But it’s a lot of, look at your sources of signal.
Sometimes they’re KPIs, OKRs, the various official channels of communication.
But then to have an almost obstinate level of distrust is unfortunately what I’ve learned the hard way.
There’s the signal that you’re getting as to what the priorities are.
Then, that might be right.
It might not be.
Do I really understand the chain of assumptions, all the cause-and-effect relationships that are supposed to go from the thing? These alleged priorities that are ten degrees away from where an actual strategy session happened somewhere? What are all the assumptions that are stacked up into, “That becomes money”?
If I don’t understand them all?
I don’t really trust any action I can take based on them if I don’t understand that whole tree.
Seeing more of the picture is a journey.
I don’t guarantee that I can see it all now.
Michael 30:46
So, you deploy your curiosity, find the right person who will indulge that curiosity, and go from there.
It’s been a great conversation today, Ray. What else should I ask you?
Ray 31:04
We could talk a little bit about the mender.ai project, perhaps.
Michael 31:13
Sounds great. That leads right into the next question. Tell us about that.
Ray 31:20
This is something you can check out now, though it’ll grow over time.
You can probably tell I’m very interested in meeting situations where they are and trying to understand the ins and outs, rather than trying to picture the most perfect way they can be and being frustrated that it’s not that.
That goes to my approach with code as well.
I am a big legacy code enthusiast.
Most of the value that we’re going to get is out of legacy code.
Bringing this around to AI (artificial intelligence), this is where I found a big flaw in the way people are talking about AI and its impact on software development.
They’re talking about that it can write new code.
We can already write new code as fast as we need to.
That is the most efficient thing that we can do in the software industry.
What we’re very bad at is maintaining large amounts of legacy code for long periods of time.
And guess what, that’s the code that’s making all the money.
If we make some new greenfield project tomorrow, based on some great idea, and it’s one of the ones of our ten new ideas that wins, it’s gonna immediately become more legacy code.
So, if we can’t manage legacy code, then we’re still screwed.
My push with mender.ai is, the label on the website to promote that mentality is, if AI is going to help software, it needs to help us own the code we have. It needs to help us fix things, mend things. We need to figure out what works and what doesn’t, and, and start putting that together.
Michael 33:20
Absolutely. If there’s one thing that’s certain besides death and taxes, it’s that there’s more legacy code today than there was yesterday. And even more tomorrow.
If people want to follow up with you on mender.ai, or any of the other things we’ve discussed today, what’s the best way for them to do that?
Ray 33:46
The easiest ways to reach me right now would be Twitter, @lambdapocalypse. And on LinkedIn, using cadrlife is the LinkedIn alias, but it’ll probably be in the show notes here. And on YouTube, my YouTube channel is Craft Versus Cruft.
Michael 34:09
Great.
What would you like to leave our audience with today?
Ray 34:20
The way I end every episode of Craft Versus Cruft, but I’ll give more of an explanation.
The quote I always end on is, as Laozi said in the Dao De Jing, “With patience, the most tangled cord may be undone.”
What I will exclusively tell you is that the reason I say that is because everything that I’ve been talking to you about this curiosity and finding pain and finding the opportunities, it’s all part of a, I’ve been trying to codify it, trying to figure out why I think I have something that works better than some other people that try to be change agents and run into more walls.
It’s an untangler outlook of, the string is hopelessly tangled up, but there is one spot somewhere that is ready to loosen just a little bit.
And I just have to find it.
I just have to find the change that’s ready to happen and have an open mind.
It might not be the change that I feel I most want to make, but it’s the one that’s ready to happen.
And that’s why this is like untangling the cord.
Michael 35:43
It’s a great analogy. Thank you for that.
Audience, thank you for being here with us today. Let us know: what did you like? What resonated with you? Or did we perplex you? Help us help you. Contact Ray, contact myself, and have a great day.
Ray 36:08
Thank you, Michael.
Michael 36:09
Thanks, Ray!
Thanks for joining us on Uncommon Leadership today.
If you found these stories interesting, inspiring, and illuminating, sign up for my newsletter.
Use the form at the top of this page.
You’ll be the first to know about every new episode of Uncommon Leadership.
You’ll also discover how you can build uncommon teams.
Thanks so much!