[Laughter]
thank you I thank you so much for having
me here
you know the organizers in Kevin Tucker
had let me know that there was a you
know a great conference happening here
and this is my first time at the dojo
and really enjoying seeing seeing the
ambiance and the the the serve workshop
atmosphere here so I've titled my talk
something kind of tongue-in-cheek a
little provocative everything you know
is wrong how computering will while
leading people a beer and during
challenge and a lot of this is some of
my thoughts and and kind of war stories
from over the last five years or so I've
been working in Silicon Valley for 20
years started out my crew my technical
career debugging t1 and t3 lines for a
ISP that was in a basement
non-air-conditioned basement in San
Francisco and was hands-on for about 15
years working my way through all the
various parts of the stack and spending
a good long time doing a system
administration and site reliability
engineering the last five years I ended
up going into management at first
kicking and screaming but then
eventually learning to embrace the but
the power and the the joy of being able
to lead others and other teams to
fulfill necessary necessary things that
had to happen in security as well as
helped to grow themselves but what I
wanted to talk about today a little bit
is how a lot of the things that you
start out and eventually learn to become
a proficient engineer need to be either
turned on their head or reformulated
when you move into trying to lead people
it is a very obvious thing of course but
it's a hard thing to shake off those
habits once you're once you're well into
your profession I took this I took this
quote from Oliver Wendell Holmes who was
one of our early Supreme Court jurors
I'm saying that the young man
the rules but the old man knows the
exceptions and have found that I'm
probably on a certain a certain side of
the line now at this point okay so uh
just grabbing some notes from here but
I'm I'm gonna start with one of the one
of the kind of precepts behind being a
great engineer was which is that you're
showing your work not just telling it a
lot of times one of the things that I
appreciated most about my first mentor
was that we were constantly being asked
to prove what we had done and to show it
in an almost very mathematical way and I
took that capability or that mindset
into every single job I took afterwards
and it worked well up to that point and
you know this idea of having to being
able to just show your work and being
able to demand that others also rise up
to that same level of technical language
and technical proof was very easy when I
was working around people who had the
same kind of mindset or maybe the same
appetite for learning it as as we all
did but it didn't always work when we
were working with folks who were coming
from a different company or a different
company culture shall I say so this idea
of telling your story and being more
verbose or having to go out and set a
narrative was almost I felt almost
allergic to and I first started going
into management but then realized that
it was completely completely essential
in some ways you can see a lot of how
that plays out and the political sphere
and any kind of cause that you care
about the facts are one thing and the
experts know something but the
capability to tell a story that
resonates with people who do not know
the same things that you know is really
really important and it's really
important that people who are experts
and understand the facts are the ones
who are helping to steer that narrative
so I definitely encourage you to you
know look at the full full picture on
these things
I mean when I'm thinking about examples
of what you know where this comes up a
lot you know even in the world of
open-source tools you know the
prevalence of Linux and and how that
emerged you know in in competition in
collaboration with say BSD
right you know I think that's one
example of you know something achieving
a great deal of community mind sure even
while BSD had a great reputation within
the technical community how important it
is to get that kind of ecosystem
footprint and how how much it can
determine the end the end result in the
line of the line of systems that I
specialized in DevOps and the DevOps ech
world a lot of the configuration
management tools such as you know puppet
and chef and cfengine
there's a there were a lot of there was
a lot of sort of flag waving around
which ones were the better ones during
the time and you know it may come down
to which has a better set of templates
or which one is in the language that
everyone likes right Ruby was very very
popular for a certain period of time and
then eventually that conversation moves
to the virtualization and container
worlds and at the end of the day a lot
of the fundamentals never really changed
especially in terms of how you're
incorporating security into those layers
of the stack are you looking at the are
you looking at the change where it
originally happened are you looking at
it at each place at which is being
deployed to a new environment are you
tracking where it's actually where it's
actually triggering an event in your
production site and those kinds of
things those fundamentals didn't really
change but a lot of the layers in
between did and how people were able to
seer and get buy-in and enthusiasm can
often dictate whether or not technology
wins or loses not just the merit of the
technology itself you know in the world
of security and privacy right you know
security has become such such an
essential and hot topic now but I think
that in some ways this is because for
years so much of what security and site
reliability professionals did was
somewhat undervalued and now that the
external world is feeling the impact is
now catching up to understand okay what
is this really how much is this really
hurting us and what do I need to
understand to navigate now so I think
that you know being able to tell that
story and tell it the right way or early
on made a difference also in certain
aspects of
fashion being being a little bit
undervalued here's another one that we'd
like to talk about a lot in technical
circles right don't repeat yourself you
know incorporate whatever logical change
you're doing in one you know in one
central place and from there on things
should be extending or leveraging those
things don't be repetitive and looking
at that compared to you know what a lot
of managers and a lot of leaders end up
doing which is you know telling that
story and repeating it and repeating it
in different ways I was reading there
was a quote by Jack Welch in one of his
books about leadership saying that you
know you have to be able to provide a
vision and you're gonna be telling your
vision until you're ready to gag on the
words and I thought that was just that
just sounded terrible but you know you
know thinking about it more you know the
amount of times it takes for people who
are doing something different than you
to really understand and and just you
know what's important there is it's it
takes a while and it takes there's a
psychological journey people have to go
on along the way you know while I was
doing a little research for this
presentation there was a book written
back in 1855 about advertising
I think the fellows name was I think the
fellows name was Tom Smith and he said
something on the lines of it will take
your customer 20 times to hear something
before they're ready to buy it so in a
lot of ways you know coming in and
trying to be really concise and terse
and not being to not being too
repetitive you have to know what you
have to know what venue it you're in and
what you're trying to accomplish
sometimes you're going to have to turn
some of this logic on its face because
you're trying to reach a new audience
you're trying to bring someone along for
a ride and they're not quite ready yet
and you have to start figuring out how
to break it down so that they can start
hearing really hearing what the benefit
is going to be to them and that's that
takes work on both sides in my own
professional journey what brought me
into the DevOps and DevOps suck sort of
communities and circles after some
initial resistance was realizing that I
was going to company after company
giving the same presentation about
DevOps and configs management and change
management and why was this the same
problem each time
and then I realized the thing that I had
been looking at for more than a decade
and that seems so obvious to me was not
going to be obvious to other people
because they hadn't been subject to the
exact same problems or the same the same
experience and so you know at that point
I realized that I had to I had to change
my own perspective on it in terms of
stepping up to communicate another
aspect I think of you know moving around
from managing a technology problem
versus working with people is in
especially in small startups we
prioritize speed and just getting it
done you know the result at any cost
even if it means burning the midnight
oil or burning through your team's
efforts because at the end you know
getting there and winning the result is
more important than anything else in
larger companies and also companies with
a longer ramp you're going to be looking
more at the journey and the destination
because you want to be creating a
situation where people can sustain and
the the rules and the the processes can
sustain beyond just that one project and
so you know moving between there's two
worlds of you know the folks who are
like really really fast movers and fast
thinkers and maybe a little bit rough
around the edges and then into this
environment where hey actually it's not
always going to be to your benefit to
win every single time what's really
important is also that we're bringing
along certain groups or that we're
bringing other departments along for
this this ride was was also a different
kind of inflection point on what what is
important when when you're making a when
you're trying to where you're trying to
move the needle on these things in a lot
of in a lot of ways you know thinking
back on my last few my last few
important initiatives for companies
usually uniting compliance and security
problems and doing a lot of technical
debt catch up I always always made it a
priority for us to make sure we got to
that finish line in terms of whether it
was PCI or IPO readiness or you know
making sure we got through that Sox
problem but looking back you know I
think that part of what we sometimes
missed in the urgency for a done line
was that piece about could people be
working at a sustainable pace were we
building things in in such a way that
the organization
and the rest of the rest of the
technology could continue to do the work
after we had maybe moved on to another
project would we be able to would we be
show that you know the relationships and
the organization actually got better not
worse because of it and a lot of that
comes back to being able to talk with
people as you're going along on a tough
project and bringing them to bringing
them to understand why it as a priority
and why why they're going to why they're
gonna benefit from it it wasn't enough
just to win and to get the result at the
end of the day it was just as important
to make sure that people understood why
now this ended up being both like for
people's own quality of life and I'll
even say in being able to make sure that
the right people and right departments
got credit for the work if it was not
well understood what was the root
problem in an organization or what was
the root problem why we weren't able to
get vulnerabilities addressed at a
quicker pace or why were people
repeating the same problems over and
over it became very very easy for folks
and other departments to you know assign
reasons or cause that may be more
debatable so I think that it is it is
very much important to to know that the
facts alone aren't always going to be
enough another another nice aphorism
that ended up having to flip on its head
was that idea that a premature
optimization was the root of all evil
and I think that was a credit to Donald
Knuth and networking in engineering
spheres I think we have all experienced
that you know experience that need to
focus and make sure that we're not
working on the wrong thing that we're
not loading code and creating additional
dependencies or security liabilities
where they don't need to be and you know
being able to have that laser focus once
started working more with people and the
organization and the teams that mindset
didn't necessarily work as well because
it there is definitely a complete truth
to the idea that you have to build the
relationship before something is needed
from it people are more like people are
growing entities right they need to be
felt feel taken care of and fed and
watered beyond just what I need for this
particular transaction
this moment and I think in the work
world sometimes especially with a lot of
urgent deadlines this can become very
easy to forget and I think some of the
some of the things that people look at
in terms of what you know they consider
a waste of time in terms of you know
there's meeting without an agenda or you
know I'm having to you know form these
relationships with all these folks that
you know I don't know why yet
especially in organizations where you're
trying to you're trying to get security
to be proactive not just reactive this
becomes extra important you know being
curious and interested in knowing why
are the problems occurring where they're
occurring why are there some unexpected
things happening in certain places and
why do some people have certain concerns
that pop up in in places that you just
wouldn't expect all of these things
become very very relevant down the line
as you're trying to either troubleshoot
a major issue or sometimes things that
become become unexpected issues down the
road and of course I think one of my one
of my favorite lessons from having
worked at the large retailers was
something that one of my mentors told me
when we were discussing why was it so
hard to get the different departments to
coordinate why was it so hard to get
silos you know to reach apart in terms
of the development and operation piece I
think on the engineering side of course
we get very very used to making sure
that we can prove everything that we're
saying and that we were empirically
right but the fundamental point that
that I think that was the takeaway for
me was not to force logic into emotion
and this idea that it is a different
dimension of problem at that point and
when I saw that I realized like when we
would have get into an argument with
such and such team because they were
they didn't want us to let's say for
example that it was we were moving into
an area where we were doing more asset
management which I would think would be
a plus for the organization maybe
another organization would be not that
happy about it and we'd under in a
conversation and I wouldn't understand
initially why it was so charged once I
stepped away from it for a little while
I realized it's not about enough
thoroughly the logical win-win in front
of them there is a reaction to something
some perception of something being taken
away that needs to be addressed even
before we can have a really rational
discussion about how best to make this
problem solved for the company and when
when I backed off of that that concept
that we had to we had to approach it
completely on that side of hey you know
we just need to put this in terms of an
argument the other side is going to
understand and try stuff into like okay
what are the things that this group are
reacting against and that where there
might be a little bit of there might be
a little bit of history there that
changed the equation in a lot of ways in
terms of being able to work beyond just
the just what was the immediate problem
at the time yeah that's right yes sure
sure so I think you know the I'm a
believer that the the roots of a
solution are in the the seeds to a
solution er and the roots of the problem
so what you just described okay so I'm
talking to a developer and saying hey
you know you've got a really high
proportion of these kinds of bugs and
they're getting offended understanding
okay this person has like they want to
believe that either they don't make that
many they don't make that many bugs or
that they are having someone else bring
it to them is an issue and so I think
that you know part of it is part of it
in that kind of situation is to let them
know that hey this is not this is not
that unusual necessarily and so
therefore this is just part of part of
what we're doing as a development this
is just part of being an engineer
needing to be better you don't have to
take it personally but I think when
you're seeing someone react let's say
with ego first right you know I think
it's stepping back to say like okay is
this something that we can work with
here and this is where you have to use
all of your both relationship and and EQ
skills about like is this something we
can work with in terms of getting them
to understand this is you
just something you can get better at you
know like our former speaker who was up
here with saying the knowledge piece can
be taught right if it's something where
it's maybe a little bit more entrenched
and you know I've encountered that as
well sometimes I took two approaches
right let's say for an instance we were
we were having issues getting a getting
a remote manager to agree to some things
that we all knew that the company needed
and I you know and I could see that
there was a lot of there was a lot of
investment in this idea that you know
the way that this person wanted to do it
was a higher standard than everybody
else's so therefore he had totally dug
in his heels about not not bending on
that standard we had to approach it from
the perspective of from a managerial
standpoint there was we definitely had
to work with his manager as well and
have a recent conversation about hey you
know here's our alternatives you know
help us pick which one is going to be
the best here and also picking the
battles kind of aspect like I don't have
any kind of illusion that there's going
to be perfect results to this it's just
people trying to grow and grow the org
at the same time as you go but I think
you do yeah that's right
that's right yeah
make them part of the solution that's
always a little bit better and I totally
you know his manager as well was there
to say like hey you know if we don't
make a choice that's unacceptable so we
must make a choice you know so I think
that combination of things kind of
helped get us around the bend on that
particular issue but you know definitely
there's you know it's yeah yeah that's
right that's right I mean absolutely if
he takes pride in the quality of his
coding it takes pride in being let's say
you know the best developer one of the
most professional developers in that
work helped give him more tools to be
that person right and I think especially
the security being so interesting and so
critical nowadays there's a lot of ways
to bring people into the fold in that
respect you know more and more in these
days you know and you all probably
experienced this too you know people
approaching our our teams myself asking
how to get into security what should
they be learning about and this and that
and so I think in that way you know the
folks who the folks who you're actually
engaging with and you can get a reaction
from you have you have a chance they're
the problems are like where you have
like silos or no response you know I
think if you can at least get a reaction
from someone because they have some kind
of they have some kind of investment in
it there's a shot
so I I kind of a put put the slide here
at the end because one of the things
that I found when you know kind of
switching back and forth between the
technical and the the people aspect of
it is sometimes just having too refined
footing because you know turning those
those ideas of like whatever it was that
you I felt made me a good engineer into
something else I would have to come back
and say okay like where am I on this and
where you know what's the situation and
I I think what the message I want to
give is that there is a path through in
terms of finding finding a center you
know finding a place that you can work
from that still is has integrity to you
as an engineer but allows you to grow
other people but it does require
constantly adjusting constantly being on
your toes and knowing who you're working
with and so I think bringing that into
the fold and understanding that there's
a progression to how everyone is is
learning as as engineers and as other
managers that they gradually become more
informed they gradually became more
flexible kind of helps that process
along and those are the the major the
major kind of points that I wanted to
talk about today in terms of you know
what I felt had to be changed between
those between those worlds if if anybody
has any other questions or any kinds of
stories they'd like to share from their
own experiences I'd I'd welcome hearing
them sure depends on the the area right
like so for the DevOps and
infrastructure and tooling and all that
kind of stuff I do like all their DevOps
groups and DevOps Enterprise has been
has been a great contact source as well
I think you know you go in there and
what's great is you know you can go in
with a problem and then as you're as
you're working with other folks who have
the same problems you guys can come up
with the solutions together too
state the obvious but you know you start
out with you start out with a little bit
of uncertainty and then end up moving
moving into late into better places for
application security of course the OWASP
the Hoth stuff is a good place to start
I really like some of the stuff that I'm
seeing with that a was the secure
developer and you know Shannon Lee it's
over it intuitive been talking about
adversary focused application of
security as opposed to just the captain
which are obviously very important also
I think those two things plus like a
good knowledge of threat modeling and
internal actual internal you know
threats and weaknesses would be a decent
way to go about that
and you know I obviously you know Bruce
Schneier is vlog is always a good one to
resource I try to like find I try to
find where I think the most most
specific experts are oh I didn't say
that but that's a it is a good thought
[Laughter]
yeah
I would say most of my career has been
focused on the blue team side of it
coming up from infrastructure and all
that and so that's been that's been the
aspect