Welcome back, esteemed listener, to another episode of data
driven. In today's episode, we have the pleasure of delving into the mind
of Nicholas Means, the vice president of software development at
SIM. With a keen intellect and a propensity for
weaving together multifaceted concepts, Nick touches upon the
enthralling topic of shame and its relevance in our ever evolving software
industry. Prepare yourself for we shall ponder the
intricate connection between shame, vulnerability, and the
cultural shifts within the software engineering landscape.
As we explore the depths of these subjects, Nick leaves us curious and
yearning for more recommending a podcast episode that unravels the
intricacies of this enthralling topic. Now on with
the show.
Hello, and welcome to Data Driven, the podcast where we or the emerging fields of
data science, artificial intelligence, data
engineering, and occasionally, ever so occasionally,
IT operations and engineering. Today we welcome
Nicholas Means to the show. Nick is the VP of engineering at
STEM, Spelled s y m, not like the video game
kids, and it's an adaptive process tool built for
developers. He's been an engineering leader for more than a decade, focused
on helping teens build velocity through trust and autonomy.
He's also regular speakers at conferences around the world, teaching more
effective software development practices through stories of real world engineering
triumphs And failures. Welcome to the show, Nick.
Thanks so much for having me on, Frank. Excited to be here. Yeah. Awesome.
You know, and And we were kinda talking in the virtual green room is that
you're not really in the data space, but you are, I would say, dare I
say, distinguished software engineer, and There's a bunch of
us in the data space now that kinda started in this world, and and I
think one of the things that that, when your name came across my desk,
I was like, reading some papers lately about,
you know, technical debt in data systems.
Right? Mhmm. And I think that's kind of the big dirty secret,
and I think that there's a lot that we can learn from software engineering
practices, in this space as well.
Yeah. For sure. So what when you say autonomy,
you know, as an AI geek now, when I think autonomy, I think Something
completely different. Well, I'm I'm assuming you mean people
being autonomous from kinda that Dilbert type corner, you know, pointy haired boss
guy. Right? Yeah. Absolutely. So
you had a a pretty distinguishing
distinguished career. You probably have had worked for people like that, and probably
inspired you to kind of go in the other direction. Is that is that true?
That's part of it for sure. Yeah. I mean, I, You know, I I
think my my journey into engineering leadership kind of involved being
in, like, some locker room kind of cultures where the loudest voice won.
And and a lot of my motivation from shifting from writing code
to being on the other side of the business, being being a manager, Was
wondering if I could do better, wondering if I could could build teams that
functioned more humanely and actually empowered each other and and supported each
other in getting their work done. And the the last 10 years of my career
has kind of been a journey in that direction. So what was
that moment where you were like, I could do better?
Interestingly, it was an episode of the Ruby Rogues
podcast several several years ago, that that featured Alex Harms,
talking some about the work of Brene Brown, and shame
and vulnerability in the way that those concepts can inform the way that agile
teams communicate. And that was, like, when my eyes really kinda opened
to the idea that maybe the the thing that I was living through wasn't the
only way to do this and that that it didn't have to be this hard.
Interesting.
What does that mean shame in terms of, I mean, you you mentioned kind of
the the loudest voice in the room wins, the locker room mentality, kind of like,
you know, you know, it's like we're we're chimps back
in the savannah, Back mill 1000000 of years ago. Right? Like, we
like like, is that is that obviously,
obviously, at some point in history of The human species that might have worked,
but I don't think in software where 90% of it involves kind of the
prefrontal cortex, I think e I don't think that's gonna
work, and What what was
it about the Bray Brene Brown kinda concept of shame and vulnerability
that kinda, like, made you Connect the dots because Brene Brown exists in
kind of a different world than than your average, you know,
software. I'd like to know more about that podcast episode. We'll have to link the
to that episode That sounds interesting. Yeah. I mean, so for me, it
so so part of it is that loudest voice always wins, but one of the
effects that That almost always happens when you have one of those really loud
voices in the room is that it tends to silence other voices.
It tends to make People afraid to raise their hands, say I don't know, ask
things that feel like obvious questions to them. And all that's kinda
rooted in in shame And not wanting to be vulnerable and and not knowing
something or or feeling shame that you don't know something that you think should be
obvious to you. In reality, it's not. In reality, one of
the things that that distinguishes the best senior individual
contributors is willingness to say, I don't know, willingness to ask Questions when
something comes up in in a discussion that they don't know about, but it takes
a long time in your career to kinda build yourself up to that
point of confidence. We're saying I don't know is an easy thing for you to
do, unless you're in an environment that's that has high psychological
safety and where those questions are invited And and where the the
environment is very much set up to be oriented around growth and around making sure
that everybody is able to ask Those questions able to push back on
each other when they don't necessarily agree with the the direction something's taking.
Not in a allowed chest thumping kind of way, but more in a,
Let's talk about this. I I don't know that that's the best way to proceed,
but maybe there's something about your position that I'm missing and just that that sort
of curiosity. Interesting. How does
the how does shame relate to imposter syndrome?
Interestingly enough, my very first conference that I ever did was on
impostor syndrome, and that this was kinda this line of thinking is kinda what sent
me down that road and made me realize that was a thing that I was
dealing with. It's it it very much relates to it. Very
much the idea that it it's hard as a software engineer to
kinda get perspective on how Good or bad, you are as a software engineer. You're
really dependent on other people's feedback to do that. And that's
one of the key components of impostor syndrome is anytime you're in a
career Where something is subjectively judged, which code
quality subjectively judged. There's there's rules. There's best practices.
We don't agree on the rules and best practices, So that puts us squarely in
in the subjective side of the house. So it's really no different than than being
a professional musician or a ballerina or something like that.
You're being judged by the the quality of your work output, but it's a subjective
set of standards. And people in fields that are judged by subjective
standards are especially prone to impostor syndrome. Really? I
did not know that because, I I mean, it may make sense as you explain
it that way, because if you're a civil engineer. Right? The bridge is
either gonna stand up or it's not. Right? It's gonna shake too much
or it's not. Right? The wind, like, the Tacoma Narrows Bridge, right, the
wind's gonna hit the wrong way, Something's bad is gonna happen, or it doesn't. It's
it's it's a very real world thing. I I I've often kind of
wondered as software engineers, or even this applies to data
people too. Right? What we deal with is so abstract. Mhmm.
You know, that it is hard to kind of gauge that, and and I
I can't be the only one that thinks that Because it's subjective,
organizational politics plays a huge role
in how someone's judged. I'll share a story. I used to work at this
consulting firm. Actually, it's back when I met Andy, who's not here
today. But, This guy wrote
the most awful code. I don't wanna say his name for, you know,
lawsuit reasons, but his last name and the word code became a
synonym for garbage code. Right. But he was such a
politician. He would walk around, and, like, everyone loved this guy. No one wanted to
call him out on it even though he Wrote the most god
awful bits of code. Yeah. And and that was when you
know, I I wouldn't say it was an moment, but I was like I
was like, oh, he should be selling used cars. He should be kept away from
a keyboard. You know what I mean? Yeah. Yeah. Yeah. I mean, that gets into,
like, the Dunning Kruger effect, right, where Where the people the people that
often feel the worst at their job feel that way because they know what bits
of knowledge they're missing, and the people that feel the best at their job feel
that way because they have no idea what knowledge they're missing. They they just feel
very confident in the things that they do know, and they're not worried about the
rest of it. So it's sort of this idea that the more intelligent you
are the more you're gonna struggle with this stuff. Interesting. It's almost like,
the self reflection kind of Guess in the same recursive into
infinite loop and you kind of lose sight of it. Yeah. And
if you and if you do, if you are completely oblivious,
You're unaware. It's it's kind of like a a a cruel trick the mind plays.
Yeah. Absolutely. Interesting. So
How did you we were talking about physical
engine, engineering and things like that, like, what
obviously, you know,
a bridge falling down that happens. Right? What what can we learn
because it's subjective, it probably I don't I never say never
as a policy, usually. See I even qualify
that. What can we learn from
real I hate this this was always a thing because there's always,
like, there's real engineers. Right? Like, the people who build stuff and but I mean,
like, what can we learn from physical, engineering disciplines? Right?
Because this this has come up before, I I can imagine,
and What what can we learn from them? So the
fascinating thing about that is the the lessons that there are to learn in
physical engineering disasters are all still based in the human side of it
Because even though steel is steel is steel, and it behaves according to a set
of physical rules that we know, the people that work with steel still
make mistakes in how that steel is gonna behave. I've
done, you know, I've done a series of talks kind of on on connecting real
world engineering disasters to the software world. One of them
that the the steel metaphor brings to mind is the one I did on City
Corp Center in New York, which is the building that's sort of
built on stilts. It's It's built up on 4 legs. The legs are actually on
the the sides of the building, not in the corners, and that created some wind
loads that weren't accounted for in the original design. And then when it was actually
being erected, they changed the way that they fastened the
structural members together, thinking that the the original
designer structure had overprovisioned them, and that they didn't need that amount of string. They
could just do rivets and stuff, or they could do bolts instead of rivets. And
it turned out that it would've it was vulnerable to a 100 year storm, and
a 100 year storm could have actually blown that building over. And so it's
the the story kinda gets into Fill the Measure, the the engineer
that designed it, Basically raising his hand and going, hey, I
figured this thing out. Thanks to a comment from an engineering
student. We have to fix this building and, like like, sort of the
process of talking about what happened
himself, talking about the mistakes he had made in the design,
bringing it to the attention of people that could then do something about it. In
this case, the people that own the building, Citicorp, who financed
the work, who worked with insurance companies. The whole thing
is a story of, When you make a mistake, it's better to
raise your hand early than try to sweep it under the rug and try to
cover it up, because you'll end up making a bigger mess in in the process,
and the consequences usually aren't what you've built them up to be in your head.
So that's that's sort of an example that that kinda gets into the human side.
No. That's awesome. Like, there are there are things in my life that I if
I had learned that lesson sooner, would have been a lot easier. I I think
that's true for all of us, and that's one of the reasons that I I
find I mean, I'm I honestly, I kinda came into this line of of
conference speaking because I like to read about disasters a
lot. I I watch way too much Seconds from Disaster as a kid, and I've
always been infatuated with this stuff. And it's it's sort of a way for me
to Justify taking a really deep dive and learning a lot about
one of these things and getting something productive out at the other end of it
versus it just being a long Wikipedia Safari for its own sake.
But I but I you know, there's I think there's a lot that we can
learn from people that have been doing engineering longer than us because the the
human factors The the communication between people working
is still a a thing that existed in the physical engineering world, and that's been
going on far longer than we've been building software for computers. So there's absolutely things
that we can learn from those disciplines. Interesting. And in
regards to the Citibank building thing, I remember seeing something in the History Channel about
those. Apparently, like, overnight, like, they had
crews working in the middle of the night. And then is it true? I don't
remember all the details, but is it true they largely kept a hush-hush? Mhmm.
Yeah. They did. They would go in, and and they would build these welding shacks
around the the places where they needed to weld inside the building because all of
the all the cross members were exposed inside the building, and it just been drywalled
around them. So they would go in and build a little plywood shack, and knock
the drywall off, and and weld it. And there's pictures of the building where you
can see it lit up in the night with somebody welding on one of these
structural members. Wow. They didn't tell people what was what was
going on. It came very close to needing to order an evacuation because of a
tropical storm that was headed towards New York, and the storm ended up turning away
at Last minute. Wow. Wow. I do
remember the part about that 100 year storm was, basically,
almost happened. Yeah. Alright. Here's Andy.
And in all of our years of podcasting, it's the first time he has,
shown up late, so, kudos for him.
I will I will I will either leave this edit raw,
or, Or, kind of
include it, with the, the thing. So I'll
I'll I'll clue Andy in. Nick Means is the VP of software develop
this I will edit out. VP of software development at a place called
SIM, and he has connected,
he's done a lot of personal research out of his interest
in, disasters, and how those
lessons can be learned, in software engineering, where
software engineering, he can I can I can tell if I'm
paying attention, is that, you know, it's largely been this, you know, who
who can Pump their chest, the loudest type thing? And
it's not really been the there's a certain pecking order
that May have worked in ancient times, but works
terrible in software engineering. Is that about right? Yep.
Cool. Oh, wow. Okay. I'm gonna have to listen to the first part of this.
This reminds me of Spaceballs. This, like, Spaceballs. Let's go
to the instant machine own video. When will
then be now? Now. Just now. What is this?
This is now.
Well, what happened? Classic.
Never play that part again.
Alright. So now that we were on I'm sorry. What? I was gonna say it's
nice to meet you, Nick. And, You as well. Yeah. Yeah. Sorry Sorry,
I was late. I've it's a great problem as a consultant to
have being double booked and stuff, and usually, we're able to work this out,
but, I am experiencing too much
business. Again, great problem to have. Still a problem. Yeah. Great
problem. Especially right now, it's a great problem. Right? Yeah. Yeah.
So I'm very, very thankful and grateful for that. But, I know
Frank Frank did a wonderful job, and I'll just, I'll hush now,
and, we can get on with the show. Alright.
So we were talking, so so that's interesting. So
With software engineering, with with buildings and physical
things. Right? You know, the nuclear reactor can melt down. Right? The, The,
bridge can collapse, the Citibank building could almost tip over.
With software engineering, you got a lot of other problems too. Right? I mean,
Security breaches Mhmm. Come to mind. And and
in your in your, kinda, your your sheet, like, You mentioned something
called a blameless mindset. What what is a blameless mindset?
So, I mean, it's really the the orientation that anytime something happens, your
primary goal should be to learn from that thing, not to figure out whose fault
it is. It kinda gets into, if if you if you've done any
research into, like, safety 2 or or human factors. It gets into the work
of Sydney Decker and and what he calls forward accountability.
Kind kind of the idea is that nobody comes to work intending to do a
bad job. And if if they make a mistake that causes an outage
or causes a security breach, They probably already feel
pretty bad about it and don't really need you piling on most of the time
to learn their lesson. What they do need is a chance to tell their
story, so that they can kind of put the facts together
in their own mind. They can help other people learn from from what they just
did. And that that kinda gets into when
when something happens. It's often very tempting,
especially for for us pointy head pointy head boss types To point
the finger and and to find somebody on whose head the the blame for
this thing lays. But when you do that, when you focus on
establishing blame as as a primary Goal in one of these situations,
you prevent people from learning, and you prevent people from raising their hand when it
happens. You encourage people to sweep it under the rug. Kinda what we're talking about.
It's it's the thing if Phil Meacher had done this with Citicorp Center. Citicorp Center
probably would have fallen over at some point. And so having a
blameless mindset when something goes wrong encourages people to raise their
hand sooner, bring other people in on the solution, Let the whole organization
learn from the the mistake that they just made. And and, you know, it's kinda
rooted in a systems thinking mindset as well. You know, how can we Change the
system so that a a mistake that's shaped like this is more difficult to
make in the future. So here's a random question.
I noticed that GitHub has something called the blame tool. I think it's part of
Git. Mhmm. Is that is that a tongue in cheek
reference, or is that actually, Like, actually a
blame. Like, what are your thought? Well, I don't know the history of that,
so maybe maybe you could tell me. And then Yeah. I mean, it it is
from Git Self not from GitHub. It's something that just showed up in the in
the GitHub UI from from Git. I actually, on my own system, alias
it to get credit, so I don't have to type git blame. Oh, I like
that. Oh, that's awesome. And that's
I I it's definitely not my original idea. I know a lot of people that
do that as well, just because Get blame puts you in
sort of a certain frame of mind when you're reading code, and it's often not
a helpful or charitable frame of mind. Whereas get credit is more like,
okay. Who can I ask to hear this story of of why this line code
came to be? Yeah. That was because that
yeah. When you mentioned blameless mindset, and I was like but, I mean, I guess
that speaks to kinda, like, you know, like, you know, the origin story
of Git, I guess, Blame the blame tool or I don't I
don't know. Like, it just to me, it just seemed like there's gotta be more
to that story. Yeah. And when I first heard the tool, The guy I was
working with, he thought it was funny. Oh, they have a blame tool, so you
can always know who's to blame. And I was like I was like, that's kinda
mean, actually, you know. A little bit. A little bit. I mean and again, you
know, it gets into, like, the the prime directive of retrospectives if you've done spent
any time in the Agile world. This idea that everybody was doing the best that
they could at the time that they did it and made the best decision they
could with the information they had. Right.
What's interesting in as you see those That
agile processes kind of happen, right? There's there's
the theory, and then there's the practice. Mhmm. And
Its organizational culture tends to take all the
oxygen out of that room. Yeah. You know and and you're not
surprised so I guess that's that's a thing You know? I
I I like to and I forget who coined this distinction. It may
have been kept back, the idea of big a agile versus little a agile.
Yes. Big Agile, the idea that there's all all these off the
shelf methodologies that you can just pick up off the shelf and adopt in your
organization, and and suddenly the the heavens will part and will sound and you will
be more agile. You look at something like SAFe, the
scaled agile framework, and you can pretty clearly see that that's not the case. It's
just Waterfall in disguise at the organizational level.
Whereas more more little a agile is the actual principles, the
spirit of Of sort of the agile software movement where it is more
autonomous. It is more short planning cycles, getting feedback early,
shipping in small increments, that sort of thing. And it's really easy to pick up
an off the shelf agile methodology and not do any of that stuff.
Right. I I remember hearing an interview once, a podcast,
probably a decade ago where, someone referred
to their, their software development life cycle
as Scrum Bud. Mhmm. And so when we're doing
scrum, but and then, you know, something followed that wasn't
scrum. And it sounds a lot like what you're describing. Yep.
Absolutely. Yeah. One of the reasons I I tend to be more with my teams,
more Kanban inspired than Scrum inspired. And and the reason for that
is Because I've seen too many teams try to win the
sprint, and and it sort of creates this perverse incentive to just
get code across the line no matter what it takes. Yeah. I I like
the community aspect of Kanban, the swarming, and Mhmm. You know, I've
seen that work. I I actually learned that on a real live plant
floor. So, you know, I've got I I used to joke with
Frank that I've got about 8 more years of books I can write,
process engineering because I know where they're going. Yeah. And, you know,
and and what's interesting is we've reached that phase where I was in
manufacturing in the late, nineties, And we reached that
phase where we learned where it wouldn't work. Mhmm. For
instance, it didn't work in engineering.
So it's interesting that we're kinda getting to that maturity. I guess that
maturity would be a good description of it, where we're seeing in the context,
Especially if software engineering that is falling over some.
Mhmm. It works really, really well on the plant floor Mhmm. When you're
in a manufacturing environment, that quality goes through the roof.
Deming's methodologies are phenomenal. The,
And maybe you've already covered this, but the culture wherein a lot
of that, you know, from the manufacturing perspective was developed,
is a vastly different culture than we have today in the United States.
It wasn't even I mean, it was Japan. Right. You know? Coming
out of post World War 2, and That's that is a
different place. Mhmm. It's probably different than Japan today. I'm
sure it is. Yeah. You know? So That that has a lot to do with
it, and you did, I heard I heard the screed behind the
words about corporate culture. That's that's a huge driver.
Mhmm. It it just is. Alright. I'll show up. It's and it's, you know,
it's it's not it's really not any different than than what we're talking about about
off shelf agile methodologies. Right? Like, all of these things are tool are toolboxes.
There's useful things in all of them, and there's things that don't apply and don't
work On an organization by organization, team by team basis.
Absolutely. And the trick is you have to be able to have all of these
tools in your toolbox and then go up to a team and go, oh,
I know this shape problem, and I these are the things that we can try
that that will help make this better. Right. Right.
What's your, sorry, Anya cut your head. Go ahead. Go
ahead. How do how does, how
does a software engineering team
Change or leadership within software engineering change the the
the organizational culture, Because I think that's a
big problem. I think that software is eating the
world. I think that was a Mark Zuckerberg quote, and I think that, yeah,
Definitely since ChatGPT, I would say AI is
eating the world. Right? But but ultimately, I'm old enough to
remember when software people were those weird people that they they stuffed us in the
basement Mhmm. And did not wanna hear anything from us
Other than everything's working fine, everything's fine, they certainly
did not wanna hear, management philosophy of,
stump speeches from us. I imagine that's changed
a little, but how does how does
someone who's listening to this Wants to affect chains, wants to
kinda bring that blameless mindset into their organization. How do they
start? I know that's probably, like, a 3 hour talk,
but Where would they how
would they what's the first step? Yeah. I mean, what what a great
question. You know, I think step
1 is just learning and and kind of figuring out where this information
exists. So, like, reading some of the blog posts from John Alsbaugh when
he was When he was CTO at Etsy, reading some of the work
of Sydney Decker, that he's done on safety 2. I mean,
John John Osborn is still out on the speaking circuit doing talks a regular basis.
So there's there's plenty of material to learn from out there. I think it's
it's probably most at home in the SRE community right now.
That's that's where I see a lot of safety cultures and human factors research coming
out as in NSRE at the moment. It was it's still in the dev ops
movement as well. That's kinda where I got acquainted with it. So step
1's kind of learning and then just teaching, giving people the
opportunity to realize that There is a different way that some of the stuff can
be done. You know, as far as an engineering leader being able
to affect larger change in an in an organization, The
one advantage that an engineering leader has is that software
engineering salaries are usually one of an organization's biggest cost centers.
And so it's pretty easy to make a case that optimizations there will
pay off if you can make a A persuasive
case for the optimizations that you wanna make. And that's where some of the things
like getting into manufacturing theory and queuing theory and
systems thinking and being able to put together a very data driven
kind of case around some of the improvements that you're trying to affect and the
ways that you're trying to affect them. It it's funny. One
of one of the most common interventions that I found myself making over and over
again with engineering teams is putting WIP limits in place. Just
because when an engineering team is trying to work on too many things at the
same time, they end up spending so much of their time on context
shifting And and trying to load up new contexts and pick up a
project that's completely different than the one that they're currently working on so they can
provide effective code review, that sort of thing. And it's pretty
easy to kinda talk through the data of if we work on less,
we can get more done, but it's really counterintuitive on the
surface when you first hear that statement. Well, the whole drive
towards parallelism. Mhmm. You know, from a machine level right
through you know, it bleeds through. They're all leaky abstractions to throw out some
other Yep. Terms. But, you know, that that whole idea that if you
do things in parallel, you're gonna be able to accomplish more. And I've
seen, I'm gonna I can't remember the book. I was reading
reading a book by someone. It was maybe 2, 3, 4 years old,
and He was talking about just the exact opposite, and he had use
cases and it just you know, serialize it, and
you'll get more done. And it it it's exactly that context
You eliminate that. Human brains stink at constant
context switching. Awful at it. Yeah. Yeah. So
Great. Great point. Interesting.
So another thing that you you kinda
Mention is talking about compliance. Mhmm. And before everyone
kind of tunes off, turns off the the thing and stops,
stops listening. Bear with me. There's a point here, and I think it's
important. No one gets excited about compliance. I I know I know
that. My wife works in IT security compliance. No
one's happy to see her. I'm I'm happy to see her, but no one at
her job is happy to see her. Dear Roberta, you'll never
Alexa, order some flowers. The,
but With the rise of software
being more and more important, more critical to our, I was talking to somebody
else. It might have been in a preview, The another guest on
another completely random topic. I think
regulation is coming to the software industry whether we like
it or not, Because of its core kind
of nature to our, just economy and infrastructure. Mhmm. And I think that
compliance is gonna be one of those things where, You know, learn
it or, you know, learn it, love it, or, you know, leave the
industry. Yeah. Yeah. And and, Yeah. I'm
sorry. So so, like, how do you how does that it seems like
that would kinda dovetail into this. Right? The the the Learning from
mistakes and and meeting these compliance. I mean, certainly, we see it
in data and various data compliance schemes, but but how does he think this is
How does this gonna affect kind of software? Yeah. I mean, the the first thing
I was gonna say is you can you can already see some of this in
things like GDPR and the California privacy regulations, The the stuff the White
House has been doing lately on software bill of materials, we're starting to see it
kind of creep in in in the in the periphery of the things that we
work on. You know, it's
it's tempting to just look at it and go, this is dumb. This will never
work. It's not gonna make any difference. But there's a there's a There's a more
terrible way to look at it in that it's pointing at a thing that
actually is really important. You know, to to your point, s soft
reads the world as organizations hold on to more and more and more and more
data. That data's a liability, and
If if we're not taking steps to make sure that, a, we're only
holding the data we actually need to hold, and, b, we're doing it as
carefully as we can. We're putting as many walls around it as we can, and
still be able to do our job on on an ongoing basis.
You sort of have to put that responsibility hat on and and think about
it in terms of how can I be a good steward of the data
that people have entrusted to me in in this organization that our customers have given
us? Yeah. And and in that that perspective, when you're looking at it
from the Spirit of law versus the letter of the law. It makes some of
the controls that you need to put in place for some of these compliance regimes
a little bit easier to swallow, And it also gets you into sort
of a an outcome mindset because, you know,
it's really easy to go through and and comply with some of these regulations with
checkboxes. Just do the things they say and and not really
actually make any difference in the overall security of your organization.
But if you look at it from a perspective, this is actually a And and
we should actually be doing this, then you can go about it and put
meaningful controls in place that that don't make it harder to get work done.
They just make it safer to get work And that's ultimately that's ultimately the goal.
That's I mean, that's what we're working on at Sym. It's sort of the whole
point of the product. Yeah. It's a good segue. So
what is Sym? SYM. Not the
Sims. I'm sure that's not I know that's not the first
time you heard the joke today, but, You know? So It's it
is not the 1st time I've heard that joke for sure. What what is what
is Sym do? Like, what What
is the the product? It it's essentially at its core workflow
engine. It allows you to build simple workflows to
request and Orchestrate access to to
production systems. It's probably easiest to explain by just telling you
how we use the product at SEM. We have all of our production infrastructure behind
our own product. So when one of our engineers needs access to
a production system, they just they create a request in Slack, and
then anybody else on the engineering team can approve that request. So kind of a
a 2 keys to launch the rocket approach. And then in the back end,
there's some code that runs in AWS. We assume a role An
AWS that lets us escalate somebody into that
administrator access role or whatever permission set that they've requested
so they can go in and do their job. And then an hour later or
or 4 hours later, whatever time interval they've requested, that access expires.
So you don't end up over time accumulating that janitor's key ring of System access
that you don't actually need on a daily basis. Right.
That's cool. That is interesting.
Now and it it you said something, a a a little bit ago that
I thought was might have sound blasphemous to some of our listeners. Right?
The data is a liability. Yeah. But the more, like, you kinda unpack it,
oh, yeah, I mean, you're right. Like, you know, we're so conditioned to think of
data as an asset, and and asset only. Right?
That I think we will lose sight of reality. Right? Or the
risks of holding data. Right? And I was just thinking, like, you know, if I
had a company, and I had, let's just say, some kind of PII. Mhmm.
Right? And I, after so many
months, or once I'm done doing what I'm doing, I purge it. Right?
I probably would sleep better at night if if I heard,
about, like, there's a there's a breach or anything like that. Right? Like, it's kind
of like, I think I think that there's a, for lack of better term, data
hoarding happening in a lot of organizations. Yeah. And I understand it,
right, because there's this If we've been so conditioned to think data
is only an asset, right? Oh, well, why
not just store it? Store it is cheap, you know? Right? But if
you also think that it can also be a liability,
and obviously not all data types are created equal. Right. Yeah. Of course. And not
all liabilities are created equal. Mhmm. Then that becomes a pretty cold
calculation of, well, yeah, maybe we'll figure
out, you know, if they have an even or odd social security
number. If that means that they're more likely to buy our
product. Yeah. But I don't wanna even hold that stuff anymore. Right? Or
I'll collapse it into, you know, Flag 1, flag 2 based on
that. Right? So, you you know, I I I like that. I hadn't
really thought about that. Yeah. I mean, one of the interesting use cases, you know,
if you think of health care data, there's some of that that you have to
hold. Right. But HIPAA is pretty strict about who can access it and when they
can access it. So one of the workflows that we've seen set up is
is requesting approval to access a particular patient's
data with a reason for needing that access So that it's all audit logged.
It's all recorded, who requested it, who approved it, that there was an actual business
need to access that data, that it wasn't done willy nilly, or
that that you had the patient's permission to access that data.
You know, just creating that that simple little bit of
diligence to say, yeah, this data access happened for a reason.
Right. And that it's automatically documented, so then you don't have Some
tedious manual process where you have to fill out a form and and fax it
to headquarters and wait on them to contact somebody and, you know, the the typical
Byzantine Data access processes in health care.
Very cool. I I tweeted that. I didn't overheard.
Oh, I heard that more and more lately here, because during the pod
you know, the podcast recordings because, definitely trying
to tease season 7. And, yeah. It's
that's a that is a great a great line. It's it's got controversy
written all over it, Nicholas. Thank you. Absolutely. God, I can have
one. I totally agree with you, on on that. And
it's you know, I and I understand the drive to say data is
an asset Because for so long, people just looked at at data
as being something kinda neutral. You know? It was hanging around. Maybe they were,
Yeah. I was taking up space, filling up the sand Or byproduct. Or
byproduct. Right? Right. You know, I I always think of the story about I I
don't know exactly the chemical Or whatever, but apparently,
I guess steel mills used to produce, like, this kind of ash, and
it was useless until somebody figured out that it's Good for,
getting traction in snow or for car for for parking
lots or something like that. I I It's it's a bit late in the day.
It's been a long day, so I I don't forget exactly what it's about, but
I remember. So, you know, so the story goes is that, you know, whoever
figured that out, I mean, they the the
steel companies just, like, here, if you're willing to take our trash, go ahead. As
soon as they found out that this guy was making money off that, Suddenly, it
was no longer free. They charged, like, you know,
$5 a ton or something like that. It was just interesting how How,
you know, as the thing goes, 1 man's trash is another man's treasure, but as
soon as it becomes a treasure, then other people are gonna see
that. Yeah. I mean, at point in time example, Reddit's in the
process of making their API paid right now so that you have to pay to
train, like, large language models on it. Interesting.
I would shudder to think what a a large language model training that would
be. Little scary. You know, I don't wanna go to go down that
That's something I've been watching a lot lately, for
some for some playtime work I've been doing. And,
it dramatically dropped, The, the cost to
train because the large language models aren't as large any
Mhmm. At least the sets of tokens and such. Yeah. So it's gone
down to, like, less than $100. That that's on certainly less
than 1,000, but in some cases, like, you know, 30, $40 to train him
on. Yes. Which is a far cry from the 7 to 12,000,000 that
Right. Yeah. That some of the more popular ones have been on. So it's,
you know, and and and it it amuses me that, you know, you have countries
that are trying to ban chat gpt. Right? The the the
cat's out of the bag, genie's out, whatever, Genius on the bottle, like, you can't
stop the signal, you know, like, it's already out. And Great
reference, Frank. Yeah.
I was talking to somebody yesterday on a completely on nontechnology
related thing, and I said, you can't stop the signal. And he got the reference,
so which I thought was pretty funny.
But I'm sorry I cut you off, Nick. No. Oh, thought
I did. No. This is
a fascinating conversation. I think we can go on for hours, but we wanna be
respectful of your time and switch to our pre canned questions.
I will kick off number 1 because we have to change it slightly. How did
you find your way into technology? Did tech find you, or did that
Techlife, Where you found that Tech Life?
So I had an uncle that when I was,
gosh, 9 or 10, Had an old Amiga
computer, and that was the 1st computer I spent any significant time
with, and just sort of Really kinda fell in
love with it as a toy first. And then, you know, not long after
that, IBM PC's PC DOS came out.
Basic was everywhere. Went to a summer camp and learned how to program
in basic. And, the the first productive thing I ever did on a
computer was I wrote a 20 question quiz in Apple
2 Basic over Egyptian history for a
6th grade project. And I Nice. We didn't have a computer at home at the
time, so I stayed after school working on that Apple 2 to write that code.
And just I I obviously got a good grade on the assignment and just have
I've been infatuated with being able to make the the
magic blinking box kinda do what I want it to do ever since.
I like that description. Very cool. Our
second question is, what's your favorite part of your current gig?
My favorite part of my current gig is kinda it gets into what we were
talking about at The the top of the call, sort of
being able to really shape and and build a culture where the the people
on the engineering team are really able to thrive, and really able to support each
other. It's a really fun group of people
to get to work with, and and the way that they're able to support each
other in projects and in in growth and, learning new things is
really, really fulfilling for me from from a leadership perspective.
Interesting. So we have 3 complete the
sentence, questions. When I'm not working, I
enjoy blank. Trying to come up with 1 answer,
but this is really hard. I'm a huge soccer fan, so I'll say that. I
we have season tickets to Austin FC, watch a lot of EPL with my son.
My son plays. So Oh, cool. A a lot of a lot of 90
minute increments of my life are spent watching soccer matches.
Awesome. Our second is, I think the coolest thing in
technology today is Blank. That it's
becoming more humane. Like, the the conversation that we had at the
top of the call is one that is Far more common
today than it was 20 years ago when I started my career. And I think
it's only gonna get more that way, because As systems get
more complicated, we're gonna have more sophisticated and complicated discussions
about humans' roles and interacting with those systems. AI is a great
example. What part of jobs does this supplant? What part of jobs does
it augment? How do we do it in a safe way? How do we keep
it aligned with people? And at at at the root, Those are all questions about
how do humans interact with technology and with each other when technology's
in the room, and I think that's a really interesting bit of history to get
to live through. Interesting.
Our 3rd and final complete the sentence. I look forward to the day when I
can use technology to blank.
I just did my taxes, so autonomously do my taxes. That would
be nice.
Here's a moonshot goal. Have, some kind of large language model that can explain
the tax code in the United States. K. Good good luck with that one. It
would just Yeah. Yeah. Answers.
Oh, I thought of, like, 3 things to say, and I'm not gonna
say either of those things Because
We wanna keep our Itunes clean rating. I'm not gonna I'm not gonna
finish that segment. Yeah. Good segue to that. Share something different about
yourself. And do remember that we're a family show,
and we wanna keep that clean rating. Something different about
myself. I am really, really obsessively into To pour
over coffee. I spend an awful lot of time and
energy trying to dial in my daily cup because it's it's that just
Even the ritual of making coffee in the morning is sort of the thing that
mentally transitions me into work as someone who works from home. Uh-huh.
And, it it's one of those things that The more time I
spend on it, the more I learn about it, the more it rewards me with
a better cup of coffee. So you're doing the filter In
the kind of the ring, and you put the grounds in Mhmm. And then pour
the coffee through them. Yep. That's interesting.
So, yeah, I've I do a French press, but I've been doing that for I
don't know. It's way too long. But the, the I've
heard AeroPress. I've never I've had a lot of people recommend AeroPress. I've never
really tried it. It's great. So is it? It's a it's a really easy
way to get a really good cup of coffee. So what do you think the
big difference is then between AeroPress and pour over?
With AeroPress, Pressure is a component of how you're brewing. I mean, it's not
anything close to espresso. Yeah. But but you're generally going
to brew you're gonna grind a little bit Feiner for AeroPress, you're gonna
extract a little bit different notes out of the coffee with a little bit of
pressure that you add. So you kinda have to dial in the rest of things
to make sure you're extracting the part of the coffee that you wanna
drink. You said notes. Mhmm. So is that how you think about
it musically? Flavor notes. Flavor notes. So light. I
didn't understand. Yeah. I mean, you know, if you get into, like, the the one
of the easiest ones to taste in in lighter roast coffees is the difference between
a natural process and a washed processed coffee. So if
you get a single origin washed processed coffee, you're gonna get all kinds of citrus
notes from it. You're gonna get orange and lemon. If you get a natural
process, it's probably gonna be weighted more towards the berry side of the flavor
spectrum. So Interesting. A really good Ethiopian natural process
coffee Prepared well is gonna taste like blueberry pie in a way that you just
cannot miss. Wow. I've had really
I've had good coffee. I and I'm sitting here, like
Like, when I when I wake up in the morning, like, I am the only
thing I can functionally do is let the dogs outside
and Lift the Keurig machine, drop the kappa in, hit the button,
which I know is probably blasphemy, to
to to to To the purest out there, but I'm just incapable of doing.
However, if I am somewhere, and I can enjoy a good cup of coffee after
I've had my first couple of, cops to get conscious?
I do I do I have had that that type of Ethiopian single
source, and It's it's just very it's very strange.
Like, almost has, like, blueberry ish pie thing
going on. Like Like, what is in it? You know, like but and
then I think it was at some airport somewhere. It might have been Seattle where
they had, like they take coffee extremely seriously. And Mhmm. I was like, no.
No. No. That's just part of the thing. I was like, oh, that's interesting. So,
yeah, you had me at Blueberry. Now I got you at Blueberry. Yeah. I'm
a I'm a Blueberry fanatic. Nice. Awesome.
Alright. So Audible is a sponsor of Data Driven.
Do you do audiobooks and and do you recommend okay. Cool.
So, any particular lessons you would recommend to our,
listeners? I will give you 2. Right now, I'm listening to
John Scalzi's agent to the stars, narrated by Wil Wheaton, who is my
absolute favorite audiobook narrator. I actually pick audiobooks based on the
fact that he's the one that narrates them because he's just the the character
he brings to the book, the way he brings out the story, I just I
really enjoy. So that's a fun it's a really fun listen. And
then on the nonfiction side, my favorite management book of
all time is Turn the Ship Around by, admiral David Marche. It's about
a captain of a a nuclear submarine that sort of uses the same kind of
things we've been talking about to to turn around the performance of The
previously worst performing boat in the fleet. So kinda bucking
military hierarchical management traditions for for something that
gives the people on the boat more autonomy and ownership over over the thing that
they're in charge of on on the boat into some pretty spectacular results.
Nice. And it's it's very narrative, so it doesn't read like a business book. It's
a great audiobook listen. Yeah. Cool. Interesting.
So, if you go to the data driven book.com, you will get 1 free audiobook
on us, and then we get, Maybe enough to
get a a nice cup of blueberry pie. One of those blueberry pack office. I
was thinking the same thing if you sign up. If you sign up,
health support to show helps us, kinda grow, and we're already
in season 7, but we're recording us before season 7 launch. So hello,
future people. And then
finally, the final question is, where can
people learn more about you, Nick, and Sim?
So for me, all I've got a lot of blog posts and all of my
talks up at my personal website, nmeans.dev. And
then for Sim, you can visit our website sym0ps.com.
Sign up for a free tile trial, kick the tires. We'd love to get
feedback on it. So if any of your listeners try it, have questions about it,
feel free to to reach out to me or anybody at Sym. We'd love to
help you kinda get started on the platform. Excellent. Well, thank
you very much. Any parting words, Andy? No. I'm just really sorry
now after listening to the 2 answers that referred To the beginning of the
show. I'm really sorry I missed that. I'm gonna have to wait. Well, we can
use that that that machine from Spaceballs. You can go
back And then redo it so future Andy
will know how it all turned out.
Perfect. Perfect. I think Nick knows that we we, you know,
we we do a lot we do at lee there always ends up being at
least 1 movie reference, so we got that. Nice. Yeah.
Alright. Thank you, Nick. Any last thoughts? No. Thanks so much for having me on.
This has been a really fun conversation. Awesome. Thank you. We'll we'll let
Bailey finish the show. And that wraps up another
intriguing episode of data driven. We hope you
enjoyed our conversation with Nick Means, the VP of software
development at Sym. From exploring the concepts of
shame and vulnerability in the software industry Dri to diving into the
fascinating world of engineering disasters. This episode has been a
thought provoking journey. We delved into the importance of
being good stewards of data and the significance of compliance with
regulations, all while finding ways to balance security and
efficiency. As we wrap up, we encourage you to
reflect on the valuable insights and takeaways shared in this episode.
The path towards a blameless mindset, fostering stronger
organizational culture, and embracing the principles of little agile
are just some of the actionable steps we discussed.
Remember, mistakes happen, but it's how we learn from them and share
our experiences that truly makes a difference.
So let's continue to grow, adapt, and shape the software
industry into a more resilient space.