In this episode, we have a fascinating conversation with Nickolas Means, the VP of software development at Sym. Nickolas shares his insights on software engineering, data liability, and of course, good coffee.

Nickolas starts off by sharing his love for audiobooks, particularly those narrated by the talented Wil Wheaton. He also recommends a management book called "Turn the Ship Around" by Admiral David Marche, which explores the importance of autonomy and ownership in improving performance.

The conversation then turns to the topic of shame in the software engineering industry. Nickolas emphasizes the impact of shame on silencing voices and discouraging vulnerability within teams. They discuss imposter syndrome and the subjective nature of judging someone's skills, delving into the Dunning Kruger effect.

Drawing lessons from physical engineering disasters, Nickolas shares the importance of early recognition and admission of mistakes, highlighting the need for a blameless mindset in software engineering. They also explore the impact of organizational culture on agile processes and the value of implementing meaningful controls for compliance.

In addition to his expertise in software engineering, Nickolas shares his passion for pour-over coffee and reveals his obsession with perfecting his daily cup. So grab your favorite brew and join us for this engaging conversation on software engineering, data liability, and the pursuit of excellence.

Let's dive into another thought-provoking episode of Data Driven!

Show Notes

[00:00:00] Nick Means discusses shame and software engineering.

[00:04:46] Loud voices silence others; vulnerability is key.

[00:09:16] What can we learn from physical engineering?

[00:10:01] Engineering disasters teach human error in steel.

[00:13:58] VP of software development interested in disasters.

[00:16:37] Learn, not blame. Safety 2 perspective.

[00:20:16] Big Agile vs. little a Agile explained.

[00:25:39] DevOps leads to improved engineering efficiencies and cost savings.

[00:29:25] Emergence of data regulations in government and industry.

[00:30:33] Spirit of law makes compliance easier, safer.

[00:35:51] Useless ash turned profitable by steel mills.

[00:38:34] Uncle's Amiga sparked love for computers.

[00:40:44] Increasingly humane tech interaction; a historic shift.

[00:45:35] Favorite narrators and management book recommendations.

[00:48:12] Intriguing episode of data-driven with Nick Means.

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.