My Journey to Understanding Technical Leadership

kevin is happy that means we all can be

happy all right hi so this talk is

called understanding technical

leadership this is a newer talk of mine

something I kind of threw together this

is dedicated to those that are in

service the whole point is really about

service ok during the talk I present

various experiences that I've had things

that I've learned different concepts

it's kind of all over the place and like

any good Drupal community member

I took directly to Twitter to ask

different folks for their own thoughts

and feedback on the topic so you will

get some nice little tweets on the

screen my name is nerd Steen otherwise I

go as adverts ting I am the vice

president of engineering at hook 42 we

are a very very awesome company very

cool spot great people and we do a ton

of work in the community feel free to

look us up or ask me if you have any

questions you want to learn more about

foot 42 or anything and I really

appreciate being here I'm very honored I

love this camp it's a nice spot so

really like to be able to present so

before we get started on the topic at

hand I want to kind of just do a quick

level set a reminder events like this

truly sustain the community that we are

all apart of it sustains it through

innovation through the exchange of ideas

the networking opportunities that we get

to talk to one another and see each

other in the flesh right these things

are really really critical mid camp is

extremely critical it is a vital part of

the community this year was a very clear

reminder that events like this are not

free they come at a cost

this is a responsibility that we as an

entire community need to be accountable

for so I want to thank all of the

organizers everyone who sponsored the

event and for the entire community who

really stepped up to make sure that

everyone can be here today

so thank you very much so what's a

little rough outline of what we're gonna

talk about first I want to start by

asking a question what is a technical

year

want to begin there the next thing we'll

review some different characteristics or

traits or qualities maybe like better

and now we'll get into some lessons

learned that's gonna be the fun part

probably I'll do my best to give some

relevant examples throughout though so

what is a technical leader what is it I

want to just state for the record and

from my own personal experience

firsthand the best technical leaders are

ones that they have experienced they

fail they have insight but they're not

necessarily the best technical person

right you don't have to be technically

brilliant to be an awesome leader period

it's not a position it's not a job title

it's a presence it's a state of mind

every single person is capable of being

a leader regardless of your role it's

who you are it's what you do right so

one of the things in this talk I wanted

to share is this is a choice the reason

why I think I wanted to do this talk is

I wanted to share how you could make

that choice you're able to use your

experience in an effort to make the

entire world better not just you know

being super awesome technically right

every interaction that you have every

code review every conversation every

co-working session these are all

day-to-day minute-to-minute

opportunities that you have to strut

your stuff first Twitter posting

Matthew Donadio I think is his how you

pronounce his last name just saw him in

New Jersey I think most tech leadership

doesn't relate to the actual tech skills

it's being a good example while being in

a technical role there was a quote back

from 1930 this is really even long

before computing became a thing so it's

clearly relevant right the task of

leadership is not to put greatness into

humanity for the greatness or but to

elicit it for the greatness is already

there I love that close I thought it was

perfect a leader is capable of bringing

out the best in other people you have to

be selfless you need to recognize the

importance of just being a leader you

need to remove your ego because at the

end of the day it's not about you I like

to consider my mission in the world is

creating rockstars that term has taken

some weird turns in recent months there

was a couple blog posts of some pretty

toxic stuff but in general I like to

view my mission as making in creating

rock stars you need to empower others to

be great

that is the function need to look at

every single individuals strengths and

weaknesses and then put them in a

position to succeed

that I think is the real thing Heather

Rodriguez former co-worker of mine a

good technical leader makes team members

feel comfortable asking questions and

admitting they don't know something

pleasure a good tech leader is a mentor

and offers help and advice so others can

grow to because if it's not about you

should be about making sure other people

are capable of getting to where they

need to be mark Schwartz anybody hurt

here oh yeah dude sharp really really

awesome dude he's written two cool books

one of the books he and he's a new

author actually his both of his books

just came out in last couple years so

mark wrote a book called a seat at the

table

and he really kind of positioned a whole

new view on IT leadership and this new

fresh new perspective really was around

leadership and team empowerment bridging

things like agile and DevOps and the

actual service behind it and it's

phenomenal both of his books are really

really great but there's a couple key

points that are very relevant to this

talk the first one to acknowledge is

that all grassroots innovation comes up

through your team right that it can

happen from any team member it can

happen from any rank any physician any

role these people are the experts in

what they do they're the experts in the

technology they're the experts in the

subject area they are doing the work

every single day right

and it's extremely hard to project

success I think that's the thing he

talks about a lot in the book is like

how do you measure this how do you have

data around this but the one one thing

that he claims is it is the role of a

technical leader or someone that's in a

leadership position to incentivize the

courage for the team members to bring

and raise their ideas to help harness

that and nurture the idea is to grow and

make the team stronger shorts claims

that it's not the role of IT leadership

to command and control

that's a phrasing that he uses but that

is a pretty typical or pretty standard

management style that sometimes people

use in IT and in general his position in

the book is basically stating that you

can harness all the ideas of the team

that you can proceed in a very

methodical and calculated and cautious

way by measuring progress limiting big

investments and trying to prove

different hypotheses that might exist so

that's a great way to harness ideas but

also to minimize risk right if the risk

is quantified you can avoid major

mistakes because even smaller risks can

present major opportunities for people

to grow and for the team to grow so

what's the the old adage right fail fast

and experiment rapidly right he's

leveraging that idea within leadership

so that sets the stage of what the basis

in my mind is for a good technical

leader when we talk a little bit about

some characteristics so there are some

things I've learned both through

observation and by participation and by

screwing up a couple hundred thousand

times because you know hey I'm standing

up here but I'll tell you what I think

I've learned through hard knocks like

this is not this is a a story from the

trenches not not someone who does

everything perfectly and I it feels a

little weird you know giving a talk like

this but you know I just wanted to share

some of these ideas I guess so all right

servant leadership I feel like this is

something that people are really

starting to become and understand in the

broader space so your job really is to

serve it doesn't matter if you're in a

leadership position or if you're an

engineer or a QA person or a designer

anything like that you're serving

something or someone or a purpose I

think to be to demonstrate your

leadership qualities you have to

understand what it is and who it is that

you're actually serving it starts there

right you have to actually have that

clarity and you need to solve impactful

and meaningful problems for those people

for your users or your customers or

anything like that right so there's a

whole space and UX and all this stuff

about user personas and crafting

experiences and user testing and all of

this stuff right it's the exact same

thing but you take it up a level right

you know this applies to everything that

we do in every role you also may be in a

position that instead of just serving a

client or a customer or you know people

that are viewing a website you may also

be representing a team and that team

could be technologists it could be any

any people doing work your priority as a

technical leader needs to be on serving

all of those

people it's like a juggling act right

but you need to understand it

Larry Spears had identified these 12

principles of servant leadership I'm not

going to get into all of them because

you know probably could have a whole

talk on all of these specific things but

I'll just read them listening empathy

healing awareness persuasion

[Music]

conceptualization that was a good one

foresight stewardship growth building

community calling and nurturing the

spirit this is pretty well-rounded right

embodying these principles can truly in

my mind help technical leaders with

situational awareness right if you look

at framing your view of the world

through these lenses it could be a good

way to to grow or evolve hi Steve Kinney

on Twitter at goal of the Twitter's

right

he stated senior developers unblocking

and being a force multiplier to the

junior developers on your team is

literally the most important thing you

can and should be doing with your time

if you're crushing code while members of

your team are stuck you're actively

hurting the team

I agree if you are serving other people

imagine how much impact that you are

capable of having if you commit to

bringing out the best in other people

not just yourself as an example I have

found personally data is always better

to help coach people or Co work with

them to help them produce the results

that they want to have that is for me to

dive in and do the work and push the

commitment right in the past I have

pushed the commits for people but you

know in stating I'll handle this I

actually was reducing the opportunity

for them to grow as individuals

empathy this was in the list so I guess

it's fair game but I think this is

probably the most important one for one

of them so we all need to acknowledge

that every single person in this room

and those that you interact with are all

in some state of learning in their

career and their journey it doesn't

matter what title they have some will

have more knowledge about a certain area

or have more knowledge in something

versus another thing and we're all

different

right we're bringing all these unique

perspectives constantly but one thing

that I've learned is that when people

make mistakes they often didn't want to

that wasn't like their intent like I've

never really seen someone wake up and

saying I want to screw up royally today

right so let's look at some practical

examples you know someone might

misunderstand the requirements of a

ticket they might end up developing the

wrong solution because of that these are

all coachable things and these things

happen all the time right as as leaders

and you know in the space we have to be

promoting empathy we need to focus on

these opportunities as teaching moments

we need to allow people to fail that's

like a big thing for me is letting

things happen giving the keynote Chris

talked about safe spaces or like the

trapeze safety next yeah that's what I

was looking for it's kind of the same

idea right people need to have

opportunities that they are allowed to

fail without feeling like they're gonna

get you know major retribution or

something right and when they fall down

it's all of our responsibilities to pick

them back up

right because you were there once -

there's a concept called blameless

retrospectives and I think that that's a

great tool for achieving shared

understanding in situations when things

go sideways and they help to promote

empathy they allow people to talk and to

share what happened and what their

experience was and that's a really good

tool that you can use in your own

day-to-day practice Daniel Rose

responded to my secret Twitter thread

super amazing awesome Twitter cred

having patience and being able to

empathize and mentor newer team members

was his point about what a good

technical leader does now most of you

have probably seen this diagram and it

is probably the least empathetic thing

that we have that exists in the wild

you've all seen it I've witnessed both

empathy and a lack of empathy around

cover views but at the end of the day we

need to treat other people the way that

we want to be treated - engineers

especially invest a lot of time into the

work that they do it's it's like a

mental drain and a very you know it's

taxing and they you know the

deliverables and their work they've

often overcome significant challenges

and fought through problems and looked

at different ways of doing things right

and those might be known those might

even be unknown but they're doing it

naturally all the time the code review

is a chance to get feedback on that work

but it should maintain a tone a very

positive tone good feedback thank the

person for the work that they've done

recognize their effort acknowledge it

they probably did a lot and if you treat

the code review as an opportunity to

help someone learn

from you it has a whole new perspective

right it's an opportunity and then allow

things to iterate and move on to the

next problem

so if you're doing things right you're

really trying to facilitate an

environment where there is continuous

learning there should be constant flow

of information and growth and help and

support for one another you should

always be learning and you should be an

advocate for making sure others are

learning to as technical leaders I think

it's pretty critical to contribute

everything that you learn in some way

shape or form hi I write blog posts I

give demonstrations to my team or other

people when they need it I give

presentations at camps and conferences

can't see that a funny side story I

learned that one of my blog posts has

now taken a term called the nerd steam

method for doing a component based

design that was hilarious by the way so

you could see these things actually do

have a way of trickling to people they

have impacted I was astonished but they

write allowing people not just yourself

right because it's not about your ego to

share their learnings with others there

needs to be a pipeline for the entire

team to share their feedback and grow

and and share information

this is often what's called a

retrospective and like the agile

frameworks right that if you have these

types of things

that's that activity its reflection

right opening up for everyone to talk

and share one thing I found it's

actually really difficult is both giving

and receiving feedback

it could be brutal right but it's

necessary these are the things that are

really important for making sure that

people learn and grow and I think if you

commit to teaching and empathy these

things help with that but it's still

really hard right everyone has a

responsibility to do this though in my

opinion this is not just reserved for

someone who's in charge of a team you

should be comfortable giving your peers

feedback and that's how they grow that's

how you can coach them and they can

coach you open up those lines of

communication be comfortable with that

they're doing it because they care so

[Music]

I'll give you a silly example and this

is like the famous thing a team member

was giving a demonstration and it was

you know on a live demo right I love

live demos they never work yeah on top

of the fact that the live demo like

failed miserably cuz the internet went

out or something happened

they also forgot to turn off slack

notifications and so they were sharing

their screen and like you know oh hey

how was that tequila you had last night

oh crap and there's like scramble

scramble scramble and you know not very

professional I'm not super classy so you

know these things happen though you only

make that mistake once right you know so

Sheldon on the other hand I but you know

after the demo hey we got together we

held a little mini retrospective and we

discussed it and now we actually might

back and then we updated our handbook

like hey you know please don't discuss

tequila during class turn off your

notifications so he's gonna do feedback

light to the entire team hopefully

others got it

only those who dare to fail greatly can

ever achieve greatly so I've now used

this quote and probably four of my last

talks now because I've not found it

I've found it to just be so elevated

that's Robert F Kennedy some people are

afraid of failure they're afraid of it

like they're it's like freaks them out

right you know and there's good reason

right so failure can jeopardize super

high profits or can introduce risks to

projects and put make people crabby and

unhappy right but let's just face it

let's actually let's ground ourselves

collectively failure is going to happen

naturally regardless of how hard we try

to avoid it let's just embrace it it is

the most critical mechanism for learning

it has the most impact on you right

especially the big failures like oh wow

it's a grounding moment

[Music]

this helps people to achieve great

things now or into the future you need

to support that and maybe you'll fail

maybe you actually end up crushing it

and you know you just cured cancer or

something crazy Hey

so there's an agile I'm a big a jewel

advocate I believe in it and it's like a

framework I think it's important leaders

need to be comfortable sharing these

things they've learned and people need

to be comfortable sharing things that

they've learned as well there needs to

be a good open forum we talked about

trying to spread knowledge throughout

the organization right so in my

experience agile ceremonies are a great

way to make sure that these things

happen fairly regularly and the lines of

communication are open and agile is

really based on iteration right so it's

not doing one doing this you know

sharing one time it's actually doing it

every couple weeks or maybe once a month

right and trying to learn over time and

continually improve I believe very

firmly that a good agile practice should

be open to the entire team it's not just

for certain members to participate like

every single person needs a seat at the

table everyone needs to participate

openly and authentically and blamelessly

as I talked about previously but it

really things like retrospectives give

people a great chance to collaborate and

share and they're facilitated

conversations that are around

brainstorming improvement right like

what was your experience oh it took me

stack on my project well okay so why

don't we cut that down to a monthly scan

and let's do targeted testing man

perfect hey what's happening

the iteration is the key part right

because the learning doesn't just happen

one time it happens forever happens as

long as you're working with people you

need to do it ongoing

the other great thing especially for

managee people super managee or people

is you can actually reduce institutional

knowledge if you're more open about

things yeah who's ever heard of tribal

knowledge right so you know you have

this amazing Rockstar person who does 50

percent of the work and they understand

every part of the system right and you

just dumped everything on their plate

and then they get hit by a bus

you kinda should avoid these sorts of

things like this kind of kind of

important right so having these process

to share and sort of like disperse

things through the team and learn from

one another like that's that's really

important that's tops with hiring and

bringing new people in and out of teams

so it's good at scale

the next point I want to discuss is

around trust I think Trust is in the

forefront of this conversation George

MacDonald has a quote it's States to be

trusted is a greater compliment than

being loved that's pretty cool if your

goal is to bring out the best in other

people you have to trust them right

great things can happen if people trust

one another really really great things

like I've seen it firsthand but one of

the things that people overlook they'll

say oh yeah I trust you

here's a ticket I trust you go handle

the ticket great but it goes beyond that

it actually affects your relationship

with that person right the relationships

are the key part of your peers and your

ears and everything so on and so on

everyone up and down the chain these

relationships are the key and they

should never never be brushed aside for

short-term wins so as an example there

we have a sprint planning meeting where

you know you all get together and say

okay who's going to be dividing up the

work and doing what it's in pieces and a

team ever really wanted to take a task

that they had no experience in they're

like oh my god I'm like super into this

and I want that ticket I'm like okay but

from my perspective I was seeing risk

and I decided to assign the ticket to

another person who's more capable I'm

like I'm sorry like this isn't this

isn't the right time you know I have to

make sure this spring Co smoothly this

isn't the right opportunity I later

learned though that my team ever thought

that I didn't

[Music]

and I could have and probably should

have given them the work and then been

there at their side to help them learn

give them the support and grow the

skills that they needed to be better

Dameon kind of hit on this a little bit

and Chris urban he's actually cure crazy

dude so yeah Damian said a good leader

can let things go and delegate my

response was I feel like Trust is the

key here

Chris Urban my right-hand man I feel

like Trust is the single most important

thing here I think he's ready

section three lessons learned in this

section I try to share some more

experiences or things that I feel like

we're just very impactful all right

the first one is presents I think I've

used the word a few times already

throughout to talk but like let's bring

it home right what is it about

presidents well first if you're a

technical leader are really a leader at

all recognize that people are probably

looking up to you isn't it scary

your presence is critical like you need

to maintain good presence how does that

happen well first you need to make sure

that you communicate thoughtfully your

communication has to be on point right

and you need to recognize the

differences in other people to both be

empathetic and to make sure that you're

communicating well with them right you

have to maintain that presence you have

to be aware I also think to be present

you need to maintain a vision you have

to have a vision you have to project

that vision

good leaders will be able to take things

that are happening in the world around

them and make connections to a broader

strategy that's based on that vision and

they need to have the presence to both

demonstrate acknowledge and reflect that

vision it's critical if you maintain a

vision others will naturally follow it

actually happens like if you have a goal

and people buying the net goal they're

right there by your side supporting you

so is a silly example someone on my team

wanted to do some professional

development with react.js the person was

sitting you know and a whole other

project at the time was totally

disconnected but I knew that that person

wanted to do that we had shared that

during a feedback session like a

professional development session and I

was sitting there a couple weeks later

and we were planning work out for a new

project and I found out that we had some

real work and I'm like oh hey there's

this thing going on over here that I

think you might want to be doing I was

able to make that connection get her

reassigned and another part of the team

and now she's rocking in love with on

something that she really cares and

wants to do and helps her girl so you

didn't have that sort of presence would

you miss that opportunity maybe

the end result was we were able to

invest in her you bolster her

capabilities not just for the short term

but in the future and all it took was

the recognition of how to make that

happen

Carrie Fisher awesome community member

also put 42 team members yay I recently

wrote about cultivating positive company

culture I think it also applies to the

leaders themselves enforcing work-life

balance making diversity a priority

being transparent and flexible but most

importantly listening to people with

respect every single one of those points

are around your presence your actions

and their leaders will reflect that

fun book the no asshole role talks about

this you know kind of cultural

phenomenon and toxicity in the workplace

right so if your presence is super

important and people are looking up to

you whether you know you know that or

not as I said I learned the hard way so

it's imperative that you as a leader do

not promote or support toxicity I have

seen toxic environments and they are

horrible they rip teams apart so Robert

Sutton explores this phenomenon in the

book the no asshole rule he shares a lot

of thoughts on just how detrimental

toxic behaviors can be within a business

or a team and I would submit that as a

leader you have a role and making sure

that you promote a civilized workplace

even aside from your presence there are

good and bad ways so instead of blaming

others which can create a divided and

hinder trust try to listen and empathize

just do it right

my gotta grieve it listen like be

supportive one of the main things that I

have found is always assuming good

intentions first it is so natural when

something happens to say oh god Joe just

screwed this thing up again oh well and

then you know you go and you look and

his dog died earlier that morning right

so assume good intentions people don't

you know try to do things all the time

right and I would also submit that

competition and getting ahead which has

talked a little bit about in this book

it's someone else's expense

is toxic watch out for it so as leaders

how do you promote that well your

presence is critical we talked about

that but you need to try to recognize

and mediate toxicity when it occurs not

later not in the next annual review no

now right

in my experience toxicity comes up

everywhere it can come up in client

meetings check-ins with people it can

happen while you're coding it could

happen on slag it can happen in ticket

management systems like seriously people

post stuff constantly everywhere you

need to be aware right Robert's claim in

the book is toxicity is contagious you

gotta put a stop to it what do you stand

for

the next part of some stuff is being

informed okay so it can be I found you

know that it can actually be very

challenging to be informed if you're not

you know working on a project minute by

minute so in my role I often oversee

many projects like I could be look you

know looking at five or six different

projects main point in time so I'm not

following what's going on on a

second-by-second basis or the minutiae

of what is happening in the team hey guy

just can't I don't have enough time that

would be horrible but being informed is

is really really critical to making sure

that you don't make any assumptions so

here's an easy example right so if one

of your team members goes over on an

estimate or suppose they miss a deadline

talk to them get informed right listen

to what happened it actually might shed

some light into some disconnects that

can be really easily fixed like oh hey

okay in sprint planning we're gonna add

this new field in here and we're gonna

fill this out while we're doing this so

we don't have this issue in there for

you help that person you hope every the

rest of the team and the rest of the

process moving forward right I was also

like to have kind of weekly meetings to

be informed with different project teams

and different people that I'm working

with and I loved to attend the Sprint

retrospective it's like my favorite

thing I like get to hear all the

different experiences going on what

people are learning and that's a good

way to be informed getting back to the

agile stuff right

for me personally I've always tried to

maintain an open-door policy I tell

people they could pay me at any point in

time especially on slack how whenever

I'm needed I might not always be free

but I always will become free and I will

always prioritize people as soon as I

possibly can and I want people to feel

comfortable reaching out to me I feel

like that's really important

I also advocate for something called the

about me it's also about making sure

that people have the support that they

need right so 30 minute roll is if

you're blocked on something for more

than 30 minutes reach out to appear

reach out to me reach out to somebody

else that's doing the work or can help

you to make sure that you don't get

stuck so being informed is not really

grandma's strengths I love this meme I

had to find some way just like sneak

this in here probably super awkward but

yeah so she's not super informed about

what memes are but hey that's okay be

flexible

technical leaders often have to take the

responsibility for interacting with

people right you need to own that

responsibility it's not about the other

person it's actually about you I think

it's really natural to say Oh John you

know so-and-so over here was just so

mean today it's like well okay maybe I

wasn't supportive enough it's flipping

the table right who has that

responsibility you will interact with

people that have varying degrees of

skills they'll have different

backgrounds I mean like I I'm astonished

just I have to do a quick aside like how

many people in the Drupal community that

I interact with and I work with have

degrees and things that are like you

know environmental studies and liberal

arts I'm like wow that's awesome like

you know that we can promote that kind

of diversity you know in the community

and backgrounds and people that come

from everywhere International it's

awesome but they're all every person is

bringing their own unique experience and

their varying degrees of knowledge and

experience it comes with that right

technically and interpersonally so as a

as a technical leader I believe it

requires you to be extremely flexible

you have to have excellent soft skills

and an situational awareness to tailor

your communication to other people's

needs not yours I also feel like you

need to be able to demonstrate technical

concepts in a non-technical way I know

that sounds really stupid and

straightforward but I just feel like

it's important technical leaders need to

understand that things come down to

impact and risk and differences in

opinion and trying to communicate things

in a way that you can get shared

understanding so in my experience one

critical way to do that is actually

visualizations like visuals are so

important words can be misunderstood

especially written words right you could

write something and some looking for

yeah misunderstand

put a flowchart together like it's so

easy takes five minutes and you could

say this is exactly what

like to see happen I want this thing to

go here and this thing to go here and

this thing good here here's a picture

right having that sort of thing is so

useful because people like immediately

resonate with that right and it could

save you like three weeks of writing a

spec document and just have it you know

still be kind of cracking just saying

haven't experienced that before so

understanding others and being flexible

and how you interact with them is

probably the very critical skill to have

one point I always say is that no job

has ever beneath you right if sweeping

the floor is what needs to be done to

make sure that things go really well

within the team all right it's cool

don't stick to some fixed perspective

about what you think a technical leader

should be based on the situation and the

people involved you actually might find

yourself working in tons of different

areas you should be comfortable

performing any of the work because

you're asking or you might be asking the

rest of your team to do it this helps to

promote empathy and gives you a really

good perspective on what people are

dealing with so recently I ended up

having to do a deployment for an

engineer that was out sick in a given

day

no big deal right but for months I have

been hearing about all these performance

issues with these deployments like oh it

takes forever it's oh it's horrible it's

crappy unless I was able to see it

firsthand oh my god

I like immediately recognized how how

much of a lack of

empathy I had for what the person was

saying they're saying it's so nice and

so calmly like onions takes really a

long time coming okay

oh my god this took me four hours to do

holy crap this just wasted my entire

morning once I've realized that and it

hit me firsthand what a different

perspective I had right evolution

evolved I feel like I should like have

like a statue change is inevitable it is

everything changes technology changes

staff changes businesses change the

world changes all the time

leaders need to be able to adapt to this

change you need to recognize that and

try not to promote but who knows what

fun is yep beer uncertainty though there

you go as a leader I guarantee you that

during times of change you will be

looked up to to provide a sense of

stability and calm because change is

really hard on people very hard but

change is the end result of true

learning we talked about being a

continuous learning organization right

that that's critical to succeeding it

all change may be hard it's a necessity

you have to do it technical leaders need

to have the ability to adapt to this

change your strategies your vision your

communication all of it needs to be

change friendly if you're trying to

communicate something you need to say

hey I'm this might change in a week or I

might be open to new ideas later but

right now let's put that right in my

experience though the worst situations

to deal with are the ones where changes

occur very drastically significantly and

suddenly if you're making major changes

try to do so gradually try to listen to

people's concerns so that they're heard

and they're supported and make sure that

people are invested in the change bring

them with you

so one example fairly recently is we

were having a hard time in the team

learning about specific subject area

experts expertise I should say the team

that that I was working with is

extremely cross-functional like everyone

can do everything we're full stack

engineer's I hate that word term

multiple words but we learned that for

us to be successful we needed to have

and develop up our expertise with

specific specialty areas right DevOps

and design and coding and front-end

craziness oh my god the front-end

craziness so we we learned that and even

though it was hard we started very very

gradually having people align with a

certain area based on their interest and

we started evolving those skills

technical people love to assume that

they only do technical things wrong

every technical person should maintain

some awareness of business factors and

especially one that is doing technical

leadership it's been my experience that

as you evolve one potential career path

for a technical leader is to go closer

into the business which could include

more money stuff or sales work or

anything like that

that's one career path but having

awareness of business factors is a

healthy thing to have across the board I

can tell you hands-down that if in my

experience if you are much more informed

about the broader business landscape or

the business factors of what you're

dealing with with a project whether it's

the budget or the needs of the business

that you're trying to serve or anything

like that right

it is so you're so much better at having

the ability to make better situational

decisions you have much more awareness

and can actually do things better there

might be times when you might have to

cut corners on a project because you

just don't have enough money it might

not be ideal you know and that stinks to

say but that's not the best technical

solution but you know you're doing it

consciously

I see this all the time especially when

we write up contracts so you might have

a request someone might come in and

client might say I really want this but

it's not in the contract so what do you

do if you have good business awareness

you can well first you should make sure

you read the contract right you should

know that you should pick up on it but

you might be asked to help brainstorm

ideas and those always have constraints

like I only have $500 for that request

right so having all of this stuff and

maintaining good technical strategies is

a great way to be a technical leader and

have good business acumen it's a

strategic thing in my mind this is kind

of like the view of you know a Salesman

in my mind like the you know kind of has

this like swarming slimy kind of feel to

it a little bit right but you know that

that's how I feel as a technical person

that's when I look at his sales going oh

my god I don't want to deal with this I

don't want your used car you know it

just looks like crap but that's the

wrong perception to have like sales

especially is a really critical part of

a business it's a part of business

health right thank you you need it you

know if you're running a business but

you need to realize that as a technical

leader you actually have a real

opportunity to influence what is sold

think about it right would you want

someone to sell something that wasn't

informed with any technical relevance

pre risky right

those activities can be incredibly

beneficial to a team they shouldn't be

something that people just shy away from

they can mitigate risk if you want to

get me on my soapbox for a long time

this is probably how to do it I am a

huge proponent for pragmatism okay there

will always and forever be a balance

between technical sexiness and

pragmatism it's a balancing act

many many many innovative new tools they

still need to be learned they need to be

explored and they need to be matured as

a community we have a responsibility to

do that that's actually why we're here

right and we have to contribute back to

Drupal to make sure that the innovation

that we put into it is sustainable but

technical leaders must be able to

recognize and balance this risk they

must be able to recognize that

innovation is critical but you can't do

it to a degree that you are introducing

such a massive risk to the work that

you're doing

right because you should be using the

right tool for the right job and

sometimes the innovative things are not

the right tool for that job bear it one

of my pros love this guy a good tech

lead loves new tech but approaches it

with caution a bad one loves it loves it

to abandon and goes all-in - really I

love that quote it's perfect right

how does that affect us today in the

Drupal community there's so many

examples in this I just even talked

yesterday about components like

component based design right this is a

classic example of a really cool

innovative tool

Brian Perry and I did a little very ad

hoc presentation Thank You Augie and we

talked about how as a community we've

really struggled to get our hands around

this innovation how do you do it right

and Brian use a term called like the the

immature years right like I'm doing this

type of work and it's time true but this

is a perfect example where you have to

balance innovation with you know

pragmatism right other examples that are

very relevant probably to all of us

today or a couple of drupal and react

that's like such a big growing space and

all this doggers stuff you know these d

dev and Doxil and all all these crazy

tools that are coming out Lando we're

still trying to figure all of that out

one of my favorite books is called the

pragmatic programmer it's kind of old

but it's like one of those kind of

evergreen books right it just never gets

old I could read it over and over again

and I still learn from it

pragmatism is really about sensibility

and practicality there's many different

things that Andrew hunt and David Thomas

talked about in this book about

delighting your users right like

understanding your audience we've

already talked about that

but one of the things that they talked

about is software rot software rot is

advocating for good architectural

technological choices right as a

technical leader you should be promoting

good technical choices when you can

limit complexity promote simplicity make

things easier don't write a thousand

lines of code when you could do

something in 50

[Music]

this helps solution scale with time it

helps with the maintenance it helps with

the onboarding that you know the hit by

a bus scenario right all of these things

comfort you know rate to the forefront

good solutions will scale if they are

pragmatic don't cut corners promote

quality that's another part of the book

right there are ways that you

do that they talked about automation and

in testing and yeah

test ruthlessly and effectively that's a

quote that they pull you know they

mention it all the time in the book like

cutting corners is the easiest way to

piss people off it always comes back to

hockey oh I could get this done really

really quick right now but I'm not going

to do it this way even though I know I

should try to avoid that if you can in

quality is key you have to have

automation in place to be predictable

you have to have automated tests and

really really strong good thorough

testing practices on your team one thing

that I've seen in my experience that has

hurt pragmatism is when an individual

person brings their own device to the

table like I have to do this this is

like I feel like really important but

being pragmatic

sometimes means that you have to put

your own biases aside and do what's best

for broader purpose

small acts when multiplied by millions

of people can transform the world that's

by Howard Zinn remember that as a

technical leader you can look at every

single interaction that you have as an

opportunity for good imagine the impact

that everyone in this room and everyone

at this camp and everyone in Chicago and

everyone in the nation to everyone in

the globe is capable of having if we all

made that commitment

imagine it gives me goosebumps I want to

thank you all very very much it is a

pleasure to be here thank you