RailsConf 2014 - How to be a Boss Without the B-S by Jessie Link

JESSIE LINK: So hello everyone.

I hope you're having a fantastic RailsConf.

Welcome to day four. My name's Jessie Link

and I'll be talking to you today

about how to be a boss without the B-S.

When you take the B-S out of boss,

you're left with the OS, which I like to think

to think stands for outstanding sauce,

which this dog is clearly fully of,

and hopefully you will be full of as well.

So let's get right into it. What are the

things we're gonna cover today?

We're basically gonna go

over the five W's.

Why you should consider management,

moving into that track. Who makes a good boss.

The skills you need to cultivate to be an

effective manager and boss and leader of men.
When

and how to make that jump into the management

track. And then finally, where you can find
some

resources.

And when I do a talk like this I

also like to cover the things that this talk

is explicitly not about. The abstract only
gave us

a very short amount of characters, so I want

to make sure that this is the talk you

actually want to be in. This is explicitly
not

about how to found a startup or how to

get VC financing. There are other folks here
who

can help you with that. I'm sure they'll be

happy to talk with you. I won't really be

covering that topic.

This is also not how to make your employees

obey you. We will only be covering light-side
Jedi

mind tricks. There are no shortcuts or tricks
that

are gonna, I can tell you to make your

employees obey you. You can only work on the

skills that we talk about today and try to

cultivate your leadership skills that way.

So, first, a little bit about me. Why am

I qualified to talk to you about being a

boss? My company made me get a head shot

for our corporate website. This is the head
shot

here. My mother loves this picture because
she thinks

I look like a fancy professional lady. I like

this head shot because she doesn't know I'm
wearing

shorts and flip-flops. So take that mom.

So, all business up top. Party on the bottom.

Don't worry. So, I've actually served in a
variety

of leadership roles. I actually served in
the U.S.

Air force for six years. I was a captain,

which is an O-3 for those of you who

know that rank. When I came out, I transitioned

into civilian software development world and
have been doing

that since about the year 2000. I also have

a computer science background. And I've been
in civilian

leadership since about 2010.

Over the course of that time, I've studied
leadership

principles for over eighteen years now. The
military is

very big on training you on that sort of

stuff, so I've tried to keep up that practice.

I'm currently the director of engineering
at a company

called Looking Glass Ciber Solutions. We're
a ciber security

company based out of Baltimore. Look us up.
We're

pretty great.

And I have some letters after my name there.

So I'm a certified SCRUM master and I also

have a project management professional certification.
Which sounds more

impressive than it really is.

So, why make the leap? Why be a boss?

Don't worry, it's not all TPS reports. I think

a lot of people have a misconception about
what

it means to move into a formal management
role.

They think it's all paperwork. It's all drudgery.
It's

about being the enemy. It's about, you know,
being,

can you come in on Saturday?

But management is about more than that. So
let's

talk about why you might want to make that

leap. Because, make no mistake, this is not
a

job change. This is a career change. So let's

say you're a founder. You started a business.
Fantastic.

So we know you can start a business. It's

in the title. But can you grow your business?

Can you finish? Can you exit startup mode.

To start, all you need is a great idea

and some coding ability. To sustain a business,
you

need to have management skills. You need to
know

how to sustain your business and lead your
people

and take your company to the next level of

great success. Even if you haven't started
a startup,

you may decide you've hit your ceiling in
the

technical track. You may not be interested
in moving

into a Chief Architect role. You may be bored,

frankly. Maybe the challenges you're taking
on aren't that

exciting anymore. That's OK, because moving
into the management

track means taking on new and exciting challenges.

Being a boss is very, very, very challenging.
Now,

I know what you might be thinking. How hard

can this possibly be? My boss is an idiot.

He doesn't know what he's talking about. I
don't

know what she does all day. So let me

amend my statement.

Being a bad boss is very, very easy. Being

a good boss is very hard. Most importantly,
when

you move into the management track, you get
to

be in the driver's seat. Now, again, if you're

that founder, that's your baby. You have a
vision

you want to drive towards with that company.
If

you don't want to take on management responsibility,
that's

OK. But what that means is you're seeding
control

to someone else who is gonna come in and

run your business for you. And you might not

like the direction they take you in.

So if you want to make and maintain control

over that thing that you started, take it
to

the finish line, you need to cultivate those
management

skills. Same thing if you're a senior developer.
You

may find yourself saying, you know, I don't
really

care for the decisions they're making. I think
I

can do better. Then go do better. Prove it.

To me, the fifth bullet is the most important

one. It's why I moved into the management
track

and it's why I stay in it and it's

why I feel fulfilled every day when I come

to work. When you move into a formal management

role, you get to have an impact on the

career of your employees. You really get to
help

mold and make them into the people they're
gonna

be tomorrow. And that is tremendously rewarding.
There is

nothing better than seeing a junior developer
blossom into

the big, beautiful senior engineer butterflies
they were always

meant to be. And you're a big part about

taking them on that journey.

Finally, you get to see the business from
a

new perspective. Again, part of your boredom
might be

only sort of staying in this very narrow engineering

track. As you move into a management role,
you

get a chance to touch other parts of the

business. You get to see how marketing works,
how

sales work, financing. How you deal with customers.
What

happens at the C-Suite level. So you get to

see how the sausage is made from a new

perspective. And that can be tremendously
rewarding as well.

So as a boss, you take on a bunch

of new responsibilities other than just writing
code and

developing systems. You're responsible for
people, schedule, budget, and

scope. So who makes a good boss? What are

the characteristics of a person who can move
into

this track and have success?

Number one, you should like people. You're
gonna have

to deal with people in your job. Now this

does not mean you need to be an extrovert.

You can be an introvert and succeed at being

a boss. It just means you can't be anti-social.

If you hate people, that's OK. Keep doing
your

thing. Maybe management isn't for you. You
should really

care about the people you're gonna lead. You
should

care about the people you're gonna interact
with. You

have to care about your customers. So that's
sort

of a key component.

You can't fear conflict. There are people
out there

who are conflict averse. That's OK. The management
track

probably isn't for you. If you are not willing

to confront conflict head on, it will overwhelm
you

and your team. So you have to be ready

to get a little spicy sometimes. Get a little

scrappy.

Adaptability is probably one of the most important
traits.

I don't think I've ever had a project go

smoothly an according to plan. I think many
of

you have probably never worked on a project
that's

gone a hundred percent perfect and according
to plan.

And if you can't be adaptable when the things

go wrong, you're really gonna struggle and
you're really

gonna drag your team down.

You have to be confident. Confidence is contagious.
So

is lack of confidence. If you don't believe
in

what you're doing, if you don't believe in
the

game plan you have, your people are gonna
sense

that and they're not gonna believe in what
they're

doing. You also have to have the confidence
to,

once you set that game plan, move forward
with

it.

Having said that, you have to be humble. There

is nothing worse than a boss who knows it

all. Maybe some of you have worked for that

kind of person. You can't tell them anything.
Their

opinion's always right. There's nothing you
can, there's nothing

you can teach them. They're the boss. They're,
they're

so much better than you. You have to have

a sense of humility. You have to understand
that

you're not a perfect person and that you may

make mistakes. And you have to have the humility

to listen to your team and let them tell

you when you're wrong.

You have to be empathetic. If you can't understand

people, you can't lead them. If you cannot
truly

get where people are coming from, there's
no way

you're going to be able to communicate effectively
or

lead them. Leadership is about understanding
peoples' motivations. Their

desires, their drives. And then letting them
move forward

and embrace those things in a productive way.

Lastly, you have to have integrity. As you
move

into the manager track, you're going to be
imbued

with certain powers. Certain responsibilities.
With great power comes

great responsibility. You have to be trustworthy
to do

that right thing. You're going to be trusted
with

budget. With firing decisions. Hiring decisions.
Promotion decisions. If

you are not an honest person, your team's
really

gonna suffer and your business may suffer.

So up til now, you've been cultivating your
technical

skills. You're at RailsConf, probably, to
continue to grow

those technical skills. And that's fantastic.
But, again, this

is a career change. A career change requires
a

whole new different set of skills that you
need

to start cultivating alongside those technical
skills.

First and foremost is the communication skill.
So communication

encompasses a lot of different things. It's
verbal. It's

being able to speak to people. It's also non-verbal.

Seventy percent of the communication we have
with each

other is actually non-verbal. So understanding
how non-verbal works,

and how you leverage that when you're dealing
with

someone who's remote, dealing with someone
on a web

cam, not in person. Understanding how that
works is

very important. Understanding how to write.
How to articulate

your thoughts on the written paper and in
email.

We're in the industry right now where a lot

of communication happens asynchronously. Pull
requests. Formal emails. Memos.

This is the most important ability you must
have.

You cannot execute the other skills if you
do

not have this one. You will see the theme

of communication echo throughout my following
slides. Communication knows,

it means, knowing how to tune your message
to

your audience. It's not just what you say,
it's

how you say it. Understand how to tune your

message when you're communicating downwards.
When you're talking to

your employees. How do you communicate laterally
when you're

dealing with peers of the company? Other managers?
How

do you communicate upward with the C-Suite
executives? Do

you know how to manage upwards? How do you

communicate with customers? How do you deal
with the

other business units? These are all things
you really

need to understand.

You I think as, as people who attend something

like RailsConf, we pride ourselves on being
polyglots. We

speak many languages. We're not just Ruby
developers. We

speak JavaScript. We do different frameworks
like Ember. We

do CSS, html, Java, the list goes on and

on and on. The same principle actually applies
when

you begin communicating at the management
level.

When we're talking about communication, as
you move into

the management track, I'm talking about domain
specific languages.

So, the terms that a salesman uses may be

very different than the term an engineer uses.
Same

thing with marketing. Same thing with your
customers. Understanding

how to communicate with those different domain
specific languages,

how to mold your message so that it speaks

to that person that you're talking to and
it

really resonates with them, is a really important
skill

to cultivate.

Now, communication is way too broad for me
to

cover in just one slide. I could probably
give

a talk just about this slide. So, I won't

be able to cover the whole, the whole span

of what it really means to communicate. I
will

start with a couple of key skills, though,
that

I think are the foundation to moving along
as

you improve your communication. And that's
the principle right

here, which is communication is a two-way
street.

So when you start learning how to communicate
and

you start analyzing your own communication
style, you should

really be thinking, am I an active listener?
Have

you ever had a conversation with someone,
and you

can tell they're not listening to what you're
saying?

They're listening because they're waiting
for the break in

the conversation when it's their turn to talk.

Don't be that person. That person is not an

active listener. They don't really care what
you're saying.

They just want their turn to put their opinion

out in the world. Part of being an active

listener and dealing with folks is really
being respectful

to their opinion. You don't have to agree
with

them. But, again, it goes back to that empathy

trait. Understand where they're coming from.
Hear what they're

saying. And only then do you respond. It's
the

difference between being a reactive listener
and an active

listener.

Delegation. As you start to grow your team,
as

you start to get more and more folks, this

is a critical, critical skill. And this is
a

skill that I think many young managers struggle
with.

Your job is to make sure the team gets

the work done. Your job is not to do

the work yourself anymore. You're just one
person. You

may have twelve people working for you. You
cannot

outpace the output of your team.

When you learn to delegate, you have to set

direction - and again, communication, coming
back already in

the next slide. You have to communicate what
needs

to be done in a clear fashion. Are your

objectives clear? Does the person understand
what they need

to get done? And this is really hard, because

this requires trust. I think another misconception
people have

is, you know what, I get the term manager

in front of my name, and I have unlimited

power. Just like the emperor. I control the
world.

I am the queen of everything.

The most important thing to understand, as
you learn

to delegate, as you learn to be a manager,

is that you do not have control. Control is

a lie. You are responsible for the ultimate
success

of the project, but you can't do the work

on your own anymore. You don't have that control.

You cannot make success. You can only put
in

place the conditions to allow it to happen.
And

that's what delegation is really about, is
learning to

become zen about letting go a little.

Managers who cannot do this are often referred
to

as micro managers. You have probably worked
for some

of them. Don't be a micro manager. It's very

disruptive to the team. You will not be very

productive.

This is a reason many micro managers fail
to

lead their team successfully. Again, part
of losing control

is accepting that sometimes they're not gonna
get it

right. And that last bullet, to me, is very

important. You cannot fear failure. You have
to let

your employees fail on their own. I have learned

more from the one time that I have misplaced

a semi colon somewhere in my code than all

the hundreds of times I have put the semi

colon in the right place. Failure can be tremendously

valuable as a learning experience for your
people, so

you cannot be afraid to let them fail a

little bit on your own.

Now, again, you're gonna have to balance that
out.

If you're crashing in a fiery mess, there's
going

to be a time to go in and rescue

them. But you have to let them kind of

work it out. Get through those difficult spots
on

their own. And again, that's something a lot
of

folks really struggle with.

Another skill, when you move into management,
is the

skill of coaching. So the man in this slide

here is Vince Lombardi. He's one of the greats,

great minds in the history of football. I
should

say American football. I know we have some
international

folks here who are probably thinking, that
doesn't look

like a soccer play.

So, Vince Lombardi is a legend in the American

football industry. He is enshrined in Canton.
And he

is famous not only for his acumen at football,

that strategy as you can see on the board

behind him, but also his ability to lead and

inspire forty grown men who don't have to
say,

who don't have to do what he says to

do. If you get a chance to Google Vince

Lombardi quotes, he is a treasure trove of
wisdom

and insight on how to lead teams effectively.

So what is coaching? Coaching is about making
sure

your people continue to grow. Going back to
that

previous slide, why do we delegate? We delegate
because

it's our responsibility to grow the leaders
of tomorrow

and to continue to grow the junior devs into

the senior devs of tomorrow. I once interviewed
a

technical team lead, and I was asking him,
well,

tell me about how you manage your folks. I

see you have some people working for you.
How

do you delegate work out?

He said, well, you know, I give them, I

give them sort of the grunt work and, and

they get to run the metrics, and they turn

the results over to me, and then I go

do the rest of it. He got to do

all the fun stuff. His guys got all the

grunt work. Do you think the people on his

team ever grew out of their junior dev roles,

when all that he gave them was grunt work?

So you have to be willing to let your

people grow, even though it means taking a
back

seat sometimes. Instead, what you should be
focusing on

is inspiring and motivating the people underneath
you to

be the best that they can be.

Vince Limbardi once said, practice doesn't
make perfect. Only

perfect practice makes perfect. So, at some
point, again,

your folks are going to fail. They're going
to

do the wrong thing. Your job as a coach

is to correct that bad behavior, right. To
correct

the things they're doing wrong, to teach them
how

to do things better. And there's a real skill

and a real art in terms of communicating and

coaching folks so that they can receive that
constructive

criticism in a way that builds them up that

doesn't tear them down.

There is nothing worse than seeing someone
wilt under

unrelenting criticism from a boss. That is
the best

way to make sure someone quits, to make sure

they, the impostor syndrome never lets go
of their

little hearts, you know. So it's very important
that

you build them up, not tear them down.

Coaching is about having the confidence to
set a

game plan and then empower the team to execute

on it. So, again, empowering is a really important

word in that statement, and it goes back to

that delegation idea. Vince Limbardi was a
brilliant football

mind, but regardless of how brilliant he was
at

football, he did not run onto the field and

throw the ball himself. He didn't run onto
the

field and tackle the other player. I'm sure
he

wanted to sometimes. But coaching is really
about having

confidence in your game plan and empowering
the team

to execute on it.

Like I said, learning to trust can be very

hard, but it's a lot easier to trust and

delegate if you have faith in the game plan

you've put together. If you have a good coaching

regimen that ensures that your people have
learned to

do it the right way, then it's a lot

easier to let go and let them go do,

let them go win that championship.

This is a quote I like. It's from General

Dwight Eisenhower. And he said, "Leadership
is the art

of getting someone else to do something you
want

done because he wants to do it."

When you communicate, as you move into the
management

ranks, you're gonna be imbued with a lot of

formal responsibility. I like to call that
hard power.

Hard power is, do it because I say so.

I can fire you if I want. I do

not recommend you use a lot of hard power.

No one had more hard power than General Dwight

Eisenhower. He was a five star general. There
was

literally not another person in the military
who could

tell him what to do.

So I think the fact that he made this

quote here is very, very provocative. Because
he's not

talking about hard power. It's not saying,
just get

enough stars on your chest and you can make

them do what you want to do. I mean,

he could literally put people in jail if they

didn't follow his commands. What he's talking
about here

is actually the art of applying soft power.

Soft power is being able to communicate and
convince

folks to really buy into what you want to

do as a team, what you want to do

as a company, without the threat of the hard

power. Even if you have it. Just because you

have a stick doesn't mean you need to wield

it.

Understanding how to wield soft power is very,
very,

very important. Lazy bosses, bad bosses go
back to

the hard power stick because they have no
other

tools in their regimen. If you're really understanding
the

concept of soft power and how to apply that

is important. And, again, there is no idea
more

powerful than an idea that someone feels is
their

own. So help them, help them understand the
idea.

Help them understand what you want done. And
then

help them understand why they want to do it.

Courage. Another important skill. Is it a
skill? I

would argue it is. Because it's really about
knowing

how to stick to your guns but still get

stuff done. Again, with great power comes
great responsibility.

As you delegate out the work, the work might

not get done. But the buck still stops with

you. It's still your ultimate responsibility
when things don't

go right. Having the courage to own that failure

is really, really difficult. It takes a lot
of

guts, believe it or not, to say, you know

what? That's my bad.

A bad boss who does not understand this concept

will throw people under the bus. We didn't
get

it done because this other team failed to
give

me something I needed. Oh, well, this employee
isn't

doing a good job. He failed on it. I'll

be disciplining him later. Potentially firing
him. But it's

not my fault.

So having the courage to understand where
your responsibility

lies and how to embrace that is really important.

Saying no can be very, very difficult. Just
because

you have a little bit of hard power as

you move up in the rank doesn't mean you're

the only one with power, unless maybe you're
Emperor

Palpatine. But.

There will be other managers that have power.
There's

going to be people above you have more power.

Your boss is gonna come down and ask you

to do things you may not be comfortable with.

And it's your job to understand how to say

no. And I, this is actually a skill that

a lot of folks struggle with. I've had developers

on my teams actually come to me and say,

I feel very uncomfortable with what's being
asked of

me by this other manager, but I don't know

what to do. And often I say, do you

want me to tell them no for you? And

they say, yes.

And that's hard. That's that conflict that
we talked

about. You can't fear it. There's gonna be
a

time when you have to have integrity and learn

how to say no. Now that does not mean

just being contrary. That does not mean saying
no

and then walking away and flouncing out away
from

the argument. Again, it really means leveraging
your communication

skills that you hone so that you can say

no in a productive way. That you can move

past those disagreements. That you're willing
to yield if

you're not actually right. So balancing out
how to

say no, the art of saying no is very,

very tricky. And it requires a lot of courage.

When you start to set direction, your employees
may

not always buy in right away. Some people
may

fear not being liked, right. Sometimes you're
gonna have

to do uncomfortable things as a team. You
have

to have a vision. You have to believe in

it. You have to believe you're going the right

way.

A boss who does not have courage, who does

not have vision and does not believe in where

they're going will change with the wind. They
will

change coarse at every, every minor difficulty
that comes

up. They'll be like, you know what, this isn't

working. We'll just change frameworks. We'll
just hire more

people. You've probably worked for folks like
that. That's

not a very productive way to go. People want

to believe their leads know what they're doing.
So

you have to have vision and you have to

believe in it.

And having said that, you have to know the

difference between a bump in the road and
a

chasm around the corner. If there's a chasm
around

the corner, do not fear change. A lot of

folks fear change. They don't want to change
their

game plan. They get nervous because, well,
we've always

done it this way. I don't know, you know.

When we do it this new way, I don't

know that it's gonna be successful. Change
is very

scary. Bringing in new ideas, new thoughts,
new processes,

can be very, very difficult. So you have to

embrace change. You have to be an agent of

change. You have to be adaptable.

This last one. Always embrace the truth, even
when

it's unpleasant. People will tell their bosses
what they

think their bosses want to hear. It's natural.
It's

very important that you cultivate a culture
where honesty

is rewarded and treasured. Even when it's
unpleasant. Even

when you're hearing things you don't want
to hear.

I have had devs come to me many times

and say, so. About that production server.

You have to have an environment where it's
a

safe space to talk about what's really going
on.

Similarly, don't be that person to your boss.
Your

job is to communicate up to your boss and

give them the facts at all times. That goes

back to integrity. Sometimes your boss isn't
gonna like

it. Sometimes you're gonna look bad, because
it's going

to be a sign of a failure. But you

have to embrace the truth at all times.

So we've been talking a lot about people skills.

The art of managing people. And, again, that
is

a discipline all in, all encompassing on itself.
But

what about the project management skills,
right? What about

managing the work itself.

So, when you move into project management,
what does

it really mean? It means tracking work, measuring
the

work, tracking it, managing risk, and knowing
how to

report status. That second bullet is really
important. Again,

along the lines of, of not fearing failure,
your

job is not to be perfect. There's going to

be times where you're gonna make decisions
and you

don't like the outcome. Your job is to understand

the art of risk management. There are whole
classes

just on how to do risk management.

What you're really trying to do is make the

best decision with the facts that you have
at

the time, and then continue to measure that
and

stay on top of it and say, all right.

How does our risk look today? How does our

risk look today? Your job is not to do

the perfect job for your boss. Your job is

to let him manage risk. To give him an

informed choice. And, again, people who are
afraid to

tell the truth, who are afraid to communicate
upwards

what's really going on, those are the projects
that

burst into flames. Everyone's surprised. So
risk management's very

important.

To do these things, there are many techniques
you'd

apply and many frameworks. So you have to
like

process. You have to be a student of process.

There are a lot of different project management
frameworks

you can use. You've probably heard of them
before.

Waterfall, Spiral, Conbom, XP. Agile's all
the hotness. You

can do SCRUM. It's important that you respect
and

study all of them. And that's that last bullet

there. You have to like it but you can't

love it.

You can't be so in love with one framework

that you try to apply it in all situations.

Don't be dogmatic about the frameworks you
put into

place. There is nothing worse than an agile
person,

sometimes, cause they've, it's agile at all
costs no

matter what, even when it makes no sense.
It's

also very fashionable to poo poo things like
waterfall.

Waterfall has a place. It's very important
that you

understand how to assess the project that's
been given

to you, the people that have been given to

you, and then pick the framework that actually
fits

that situation.

It's really about picking the right tool for
the

job. When you have a hammer, every problem
looks

like a nail.

So, again, even if you don't use a framework

- like, I don't use Waterfall a lot, but

I still study it. I still look up books

on an occasion. I still read articles. I educate

myself about the different techniques that
are out there.

I want to know what tools are available to

me, even if I don't use them. So when

I see a problem that actually looks like a

screw, not a nail, I say, you know what?

I'm gonna try that screw-driver.

There are some administrative and financial
things that are

gonna affect how you manage. And, again, it
depends

where you are in the management chain how
much

influence you're gonna have over this. If
you're doing

a startup in particular, budgeting is going
to be

very important. You understand the concept
of colors of

money. That is basically money that is earmarked
for

a specific purpose. It cannot be used for
other

purposes.

So, again, if you have green dollars that
are

allocated for infrastructure, you may not
actually legally be

able to ship that money over. I used to

work in government contracting, and that's
something very important

that comes up in that, which is if the

government gives you a hundred thousand dollars
to buy

servers, you can't say, well, you know what,
I'm

a little short and I want to pay some

bonuses to my folks, so I just won't buy

the servers.

So you have to understand how budgeting works.
How

do you project a budget? How do you do

quarterly reports? What is the impact of your
outcome,

your income? How does salary work? How do
you,

how does salary affect how you project?

So those are really important things. That's
a hard

skill. That's something I struggle with. That's
not something

you're gonna be exposed to in your day-to-day
life

as an engineer until you move over. So understanding

how budget works, how money flows at your
company

is critically important.

We talked about the hard power you're imbued
with.

Hiring folks, retention and firing. It is
incredibly expensive

to hire folks, which is why retention is so

important. There were actually some tremendous
talks on Wednesday.

I recommend you go watch the videos on how

to onboard folks, how to set up a training

plan. Retaining talent once you get in the
door

is really important because hiring is so expensive.

Having said that, there will be times when
the

person is not a fit, and if you have

to fire them, you have to understand the implications

of that decision. Each state has different
right-to-work laws.

So you need to understand the process for
both

hiring and firing folks. That's gonna be very
important.

So making sure you work with your HR folks

and get educated on the various laws is very

important.

I know I said that it wasn't all TPS

reports, but it is at times. I don't even

know what a TPS report is. I just use

that as shorthand for the mandatory documents
that seem

like no fun but you have to do them.

And that's a thing. You do have to do

them. It's your responsibility to understand
what regulations are

in place, what documents have to be done.
Now,

sometimes these are mandated from the, the
corporate overlords

and I've done that before.

But there are other legal documents that may
come

in depending on the industry you're in. I
am

in ciber security. Privacy laws are very important
to

us. Understanding privacy laws. You're taking
in peoples' data,

you better understand what you're supposed
to do with

it. If you work in healthcare, HIPPA's gonna
come

into play.

So really making sure that you're educating
yourself on

the legal and regulatory documents that you
need to

be aware of is very important as you move

into management. But it's kind of fun, because
this

is the part that you probably won't get exposed

to a lot, and I actually kind of enjoy

seeing these different things, these different
areas that I

didn't, that I didn't really get a sense of

when I was just an engineer. A lot of

this stuff is really the guts of what makes

a company go.

OK.

So, hopefully you're tempted now. You're like,
oh, you

know what, management doesn't sound so terrible.
Maybe it's

pretty good. Maybe I've got some of those
skills.

Maybe I'd like to work on them. I'm ready

to make the leap.

So let's talk about when and how to do

that.

Moving into management. Number one, find a
mentor. Find

a safe person to help teach you the ways,

a Jedi master that you can go to. I

have several mentors who are senior leaders
that I

like to talk to to kind of bounce ideas

off of. Again, you're not perfect. So find
someone

who can help you with that.

Try before you buy. Many of you are already

in leadership roles. You may not have formal
powers

of hiring and firing, but you're starting
to lead

people. So look for those opportunities. If
you're interested

in this, try it out. Say, you know what,

I see this project's coming up. I'd love to

lead it. Or hey, you know, these two guys,

I'd love to take them under my wing. Mentor

them. Maybe be part of the review process.
That's

a great way to sort of try it out,

see if it's a fit for you. It's not

for everyone. But you may be surprised how
much

you really find it rewarding. I love working
with

people. I was, that's how I ended up in

management. I was doing an informal leadership
role and

I really enjoyed it and I wanted to continue

down that track.

Learn to think company wide. Again, there
are other

areas of the business you need to be aware

of. So go on a sales call. Go to

a conference and help the marketing guys run
a,

be a booth babe. I've done that before. It's

actually a lot of fun. It's a different perspective.

Understand how to court your customers. Go
help the

ops guys. Go sit in the customer support center

for awhile and take calls for them and understand

what happens in the rest of the company.

And mostly, have an idea of what kind of

leadership style you have. There is no one
prescriptive

way to do it. There's no one way to

lead people. Everyone's different. We're all,
we're all different,

unique snowflakes. The people we manage are
different snowflakes.

They may require different types of leadership
style. So

think about what kind of leader you want to

be and then practice the skills to do that.

So some of the big questions that came up

as I was starting to prepare this talk and

talk to some of my peers. I think this

is one that's on a lot of folks' mind.

If it's a career change, I'm leaving the technical

track. Do I still get to write code? And

the answer is yes. Sort of.

I've actually talked to a lot of folks about

this in the last couple of weeks and I've

met some people who say, you know what, I

can code eighty-five percent of the time and
manage

fifteen percent of the time. And that's fantastic
if

you can do that. It's really gonna depend
on

the needs of your company and the size of

your company. It is absolutely your job to
stay

technical. You are supervising technical people.
You need to

know what they're talking about.

Having said that, your priority is no longer
writing

code. That's your team's job. You might be
the

only person on the team who can go brief

the executives. You're the only one, I've
had to

take an hour out of my day to look

at everyone's expense reports. That's not
exactly more fun

than writing code, but those expense reports
matter to

the people who are waiting on that money.
So

you're gonna have other priorities that are
gonna come

up on that code.

So usually I like to give a little bit

of advice. If you want to stay involved in

the code, a couple of things you can do:

So, number one, participate in code reviews.
I do

a lot of code reviews these days. I don't

write a lot of code from scratch, but I

do at least stay involved in the code by

being part of the review process, downloading
it, poking

it, running the tests and that kind of stuff,

and it's a great way to continue to learn

and stay involved.

It's very important that if you decide a part

of your day job should still involve working
on

code, I would recommend not working on critical
path

items. Because, again, there may be some management
crisis

that comes up that only you can work on.

And it would suck to hold the whole team

up just because you haven't finished your
chunk of

the code. So look for opportunities of maybe
some,

some low-hanging fruit, some quick wins. I
actually, just

the other day, picked up some code and successfully

merged to master because I was working some
defects

that weren't on the critical path. But they
got

in and it was nice and I still got

to, to exercise my code writing skills.

Also, maybe work on some side projects. That's
usually

how I try to stay in, involved with things

that are going on in technology. You just
might

not have a lot of time during your day

job to write code anymore. So your mileage
is

gonna vary. I left my last job because I

knew at that job, to continue up the management

chain meant I could no longer write code,
period.

And I didn't want that. So I went to

a smaller company, and I still have about
ten

percent of my day where I get to be

in the code in one way or the other.

So I feel pretty good about that.

Can I still be friends with my employees?
This

is a tricky one. The answer is yes, sort

of. Again, many of you may be promoted out

of the very ranks where your friends are.
Yet,

we're all fellow engineers. We're, we're,
we hang out,

we go to beers. Now I'm their boss. This

is a very sensitive topic. So, if you want

to be friends with your employees, that's,
that's completely

fine, but it is very important that you have

a system of firewalls in place so that you're

separating your personal relationship from
your professional relationship. And

you have to think very hard about the impact

of your friendship and how public you are
with

your friendship on the rest of the company.

If Jeff the engineer hangs out with Jane the

manager all the time and he's at her house

and their spouses are best friends and, you
know

they're doing things every weekend and, and
their kids

play together, and then Jeff wins engineer
of the

quarter. How does that come across to the
rest

of the team? He might actually be worthy of

engineer of the quarter, but perception is
reality. So

you have to be very, very sensitive to the

realities of that if you're going to maintain
those

friendships.

It can also go the other way. I actually

had a boss where I worked with, who was

a very good friend of mine. He brought me

onto his team. And we have a very saucy

relationship. He'll tell no, eff you, and
I'll say

eff you and then we hug and have a

beer and it's fine. And that's fine. But he

actually said that to me in the work place

once. And he said it in front of other

co-workers. And he was very incapable, ultimately,
of separating

how we spoke to each other as friends at

the bar, from how we spoke to each in

the work place, and it actually caused a lot

of problems on our team. And it actually upset

me a lot, because I would never allow a

boss to say that to me. And he couldn't

put his boss hat on and put his friend

hat aside, so I had, I ended up leaving

that team and he's still one of my best

friends and I will never work for him again.

He's actually a good guy. He's a good boss

if you're not his friend. So be very sensitive

to the, to the impact of this. This is

a, this is a, this is a tricky one.

You can be friendly, but, but be careful.

Lastly, do I need to have a PMP certification?

Project manager professional certification
or something like that. And

the answer is absolutely not. And, again,
it's gonna

depend on the kind of company you're at. If

you're a small company, you may never need
this.

Having said that, the PMP can be nice. It's

nice to have. It's a box checked on your

resume. I've actually had people pick my resume
and

say, oh good, you have a PMP. But I

don't think it's gonna exclude you from jobs.
The

only exception might be if you go into a

very, very large company.

The government act- the reason I have my PMP

is the government decided they wouldn't allow
program managers

that didn't have a PMP certification, so away
I

went to class. That's why I'm not in government

contracting anymore, for many reasons.

A few final thoughts. It's important that
you self-examine

all the time. Think about the type of leader

you want to be versus the kind of leader

you're actually being. So I kind of wanted
to

close out here by sharing a few key leadership

principles and thoughts that guide me personally,
just to

let you know what kind of leader I actually

am. I hope. On a good day.

That last bullet is very important to me.
Leaders

eat last. Goes back to that concept I told

you about with the, the team leader who took

all the best work for himself and left his

leavings for the minions. He was eating first.

I had a boss once who, we said, you

know what, we want to go to training. We

put together a training plan for him. We said,

this is the course. This is the location.
These

are the people we think should go. He looked

at it and he said, that looks pretty good.

And then he sent himself to training. He went

to the training himself. And we said well,
why

did you do that? And he said, well, I

wanted to make sure the training was appropriate
for

you. That was a really informative moment
for me.

I've learned a lot from my bad bosses believe

it or not. I've taken a lot of notes.

And I saw how devastating that impact was
on

the team. Not only because he was eating first

and taking training before anyone else in
his team,

but also the lack of trust that that implied.

He didn't trust you to go to training and

come back and give him an assessment of whether

or not he should send other folks. So it's

very important that you put your team first.
Your

teams' needs come first at all times.

Lead from the front. What does that mean?
It

means don't do, don't ask them to do anything

you are not willing to do yourself. If you

don't want to work weekends, why should they?
They,

you don't want to do the unfun work. You

don't want to do QA. QA is unfun sometimes,

but I do it because I expect them to

do it. Leading from the front is the difference

between being on the top picture and being
on

the bottom picture.

Along similar lines, it's not your employees'
job to

feel your pain. There's nothing worse than
a boss

who complains down and expects their employees
to make

sure that their job is happy. Your job is

to make their job happy. That's what your
job

is. If you want to complain about your pain,

that's what your boss is for. It flows uphill.

It doesn't go down. A lot of bosses cannot

maintain that separation, particularly if
they're friends with their

employees. So nobody cares what you want.
Your job

is to make sure the work gets done. Their

job is to execute on that work. Not stop

what they're doing to console you or make
you

feel better about your day.

I believe a high-performing team will always
be greater

than the sum of its parts. The ten x

engineers are great, they're great to have
on your

team. I believe a team of average engineers
truly

working together will always outperform that
one engineer. I

like to cult. So, everything I do, every moment

of my day is really about, am I establishing

a team environment? Am I establishing the
kind of

culture where team comes first? And, again,
trying to

be selfless is a great way to start if

you want to cultivate that kind of environment.

Finally, you're never done learning. Another
quote from Vince

Lambardi. Leaders are not born, they are made,
and

they are made just like anything else: through
hard

work. And that's the price we'll have to pay

to achieve that goal, or any goal. I've been

studying this for eighteen years. I'm gonna
study it

for the rest of my life. I will always

continue to improve, hopefully. I'm always
trying to learn

new things, talk to other leaders, read books.
I

may do this presentation in a year. It may

be completely different, cause maybe, I hope,
I hope

it's different. Cause I hope I've learned
something new

and amazing about leadership that I can share.

Lastly, I'd like to leave with a quote on,

from Admiral Grace Hopper, a pioneer in the
computer

science industry, great military leader. He
said, you manage

things. You lead people. The key to being
a

good boss is really understand the nuance
of that.

You manage things. You lead people. You use
things.

You don't use people. Understanding the difference
between those

concepts is really the key to leadership.

I said I'd tell you where to find resources

so I'm gonna put this up right here. I

will share on the next slide, there's going
to

be a, a link to my deck, so don't

feel you have to write this down right now.

Very quickly, if you're tr- if your company
will

pay for training, take advantage of it. It
may

sound dorky to go to a week-long communication
class.

There's a lot you can learn if you're humble

enough to admit you have something to learn.
There's

a lot of free resources on the internet. TED

talks. There's a lot of talks about leadership
there.

There's other videos I'm sure you can go out

and seek it. There's a lot of videos of

notable speakers.

PMI is the Project Management Institute. If
you have

your PMP certification, they have free resources.
Webinars, dinners

you can go to. History is a really important

one. We're at RailsConf thinking, like, oh
my god,

Rails is ten years old. We're so old. Leadership

has been around since the dawn of man. Since

one caveman turned to another and said, you
know

what, if we got some guys together, we could

kill that mammoth.

That's project management right there. You
stab the left

side. That's your job. And I'm gonna stab
the

right side. And our success criteria will
be the

mammoth is dead.

So don't be afraid to look. Obviously management,
leadership

is an evolving art, and yet some of the

fundamental things that drive people are,
have remained the

same over thousands of years. Sun Su's Art
of

War is still studied by military leaders today.
Abraham

Lincoln, the great sixteenth American President
has so much

to teach us about how to apply hard power

versus soft power. See the movie Lincoln.
I am

the President of the United States clothed
in immense

power and I will have this bill. That's hard

power. But then the other scene where he's
talking

to Tom Lee Jones, the senator, and he's convincing

him. Cause that guy doesn't have to listen
to

him. He said, let me tell you a story.

Let me show you an analogy about why you

need to do this. Let me convince you. Soft

power.

So study great leaders in history. Church
Hill, Steve

Jobs. Go as far back as you want. I'm

a reader. I like books. I looked up management

on Amazon. I got back 900,000 hits, so there

are plenty of books out there. I will quote

DHH a little bit here and say beware of

books that are diet-esque, in other words,
this management

style will change your life in fifteen minutes.
So

take it with a grain of salt.

These are three books I recommend. I just
read

them. And, again, going back to that learning
from

people in history, Dale Carnegie wrote a tremendous
book

called How to Make Friends and Influence People,
which

is really about the art of communication.
How to

write criticism without crushing people. How
to, how to,

how to basically influence, influence folks
in a positive

way. He wrote that in 1935 and it still

resonates today. It's still one of the twelve
most

influential business books I think in some,
some article

by Business Inc. Warren Buffet said that book
changed

his life. And he's a billionaire, so maybe
he

knows some stuff.

And then, finally, again, studying frameworks.
Agile Samurai is

a great touch point if you want to get

into learning about Agile frameworks. And
I finished right

on time, so go me. If you want to

find me on Twitter at mad_typist. Learn from
the

leaders around you as well. I'm happy to talk

to you about my thoughts on leadership at
any

time. If you want to see my terrible public

code, it's right there on GitHub. You can
actually

look at my commit record and you know when

releases are happening, cause it goes stark
white because

I have no time to code because I'm putting

out a thousand fires. And lastly, you can
get

these slides on speakerdeck. That's the link
there.

Thank you guys so much for coming. I think

I've got maybe a minute or two for questions.

Or you can clap first.