0:07

It takes more than describing a Roomba

0:09

outage as a robot uprising to

0:11

be a great engineer. This is Soft

0:13

Skills Engineering episode 383. I

0:15

am your host and non-owner

0:18

of a Roomba, Dave Smith. I'm your

0:20

host and proud Roomba owner

0:22

so that they don't destroy me when

0:24

the uprising completes. Jamison Dance. Soft

0:27

Skills Engineering is a weekly advice podcast for

0:30

all the non-technical stuff that goes into being a software

0:32

engineer, such as keeping the robots

0:35

just satisfied enough that they keep

0:37

working, but not so

0:39

self-confident that they rise up. So

0:41

I have an 18-month-old son and

0:43

he is terrified of the Roomba,

0:46

but terrified in a way that he can't keep

0:49

away from it. So whenever he walks

0:51

into the room where its little station is, he

0:54

just stares at it and slowly walks

0:56

up to it. It's like the Lord of the Rings when

0:58

the ring is casting its

1:01

evil spell on somebody. And

1:03

then he walks up and he slowly, with

1:05

huge wide eyes, presses the button to turn it

1:07

on and then just shrieks. But

1:10

he does it every time.

1:11

So he senses. He knows they're

1:14

up to something. The

1:16

children know. What do the children know

1:18

that the adults don't understand? Yeah.

1:21

This is no benign hockey

1:23

puck. Oh

1:25

my

1:26

goodness. Dave, I

1:29

want to thank our patrons. So I'm going

1:31

to. All right. Thank you to Nick Kantar,

1:33

Brayden Caines, John Grant, Travis, Nick Hathaway,

1:35

Jonathan King, Ragnar, Webtow, Awesome Antenna, Testing,

1:38

Will Angel, Irochan, MonkeyfaceEmoji, Patron.com

1:40

we're hiring, Craig Motlin, The Stochastic Parrot,

1:42

Owen Shardell, Jenny Kim, Cody Sale if you

1:44

would like to join the Celestrious, oh wait, not yet, Kenzie

1:47

Dodds, Valentin at Data Fold, Santa Hopar, TheComputerScienceBook.com,

1:50

TrashPanda, Never is not just a crater on

1:52

Mars, FlamingoEmoji,

1:55

I like chicken, I like liver, Meow Mix,

1:56

Meow Mix, please deliver,

1:58

Full Stack Contractor, Looking for.

1:59

job Corp to Corp and type

2:02

here.dev. Thank you. Thank you so much

2:04

to all these people or

2:06

concepts who are supporting

2:08

the show. We appreciate it. They

2:10

have all done something that you are welcome to

2:12

do. They have gone to our website and

2:15

clicked support us on Patreon and then provided

2:19

their payment details in whatever

2:22

local currency they accept. I don't

2:24

know what it, yeah, they did the thing.

2:26

Um, if you want to do the

2:28

thing too, boy would we love it.

2:31

That's my sales pitch. Yup. Don't you want us

2:33

to love it? Every time you say we thank the people or

2:35

concepts, my mind just immediately

2:37

has to start thinking of what other categories could

2:40

possibly be on this list. And for some reason

2:42

this week, it went to one

2:44

concept, which is the super intelligent shades

2:46

of the color blue in the fictitious

2:49

work, Hitchhiker's guide to the galaxy or

2:51

future history. Hitchhiker's

2:54

guide to the galaxy. Yeah. Super intelligent shades

2:56

of the color blue. Also welcome

2:58

on Patreon. Are you familiar with SCP

3:02

the command? No. Yeah, that

3:04

is ambiguous. It's a,

3:08

it's a collaborative, I

3:10

guess science

3:13

fiction, horror bureaucracy universe

3:16

that started in like 2008 or something. Okay.

3:20

No. So it's a Wiki where

3:23

people write articles describing anomalies

3:26

they're called and they're like weird,

3:29

creepy, spooky things. And there's this fictitious

3:32

society that exists to catalog and contain

3:34

them. So it's like these dry government

3:36

bureaucracy reports about mind eating

3:39

horrors and cell

3:41

phones that call backwards in

3:43

time and just weird stuff like that. Okay.

3:46

So when I, when I talk about concepts, I think about

3:48

that, maybe, maybe someone, maybe

3:50

one of those entries from the SCP Wiki is going

3:52

to sponsor the show. That

3:55

would be great. The abstract idea of nothingness.

3:57

It has sponsored all it.

5:09

decisions

6:00

quickly. As an engineer with good soft

6:02

skills, it feels like gravity wants to rip me away

6:04

from writing code. How do I stop

6:06

this? Can I? Should I resign myself

6:09

to a work life filled with never-ending one-on-one?

6:11

Oh, I felt this gravity so long.

6:15

Yeah. I finally gave in to it. I'm

6:17

in the opposite direction. I write way more code at this job

6:19

than my past job. Even

6:22

as a non-individual contributor? Yeah.

6:25

It's a smaller team, so I'm a larger

6:27

fraction of the engineering team. Yeah.

6:31

Now, let's talk about the contradiction in this

6:33

job description. So it says,

6:35

you must lead as a peer, but

6:38

you may not do peer

6:40

things like writing code. So

6:44

I kind of interpret that to mean the

6:46

expectation is not that you'll show up

6:49

and say, as your manager,

6:51

I command you. Not necessarily

6:54

that you'll be doing the job of an IC,

6:56

but that you are expected to kind of

6:59

influence and servant leadership is

7:01

a phrase that comes up a lot instead

7:03

of command. Maybe

7:06

this is someone who doesn't

7:08

have the budget to hire an engineering manager.

7:11

So they're hiring an individual contributor and

7:13

then not telling the team that it's actually the manager

7:16

and then telling the individual, you must

7:18

lead through... They are the manager. You're

7:20

the manager, but I'm not... But a special kind of manager.

7:24

A kind that doesn't get paid well and

7:28

must not... A secret manager. Yes. It's

7:31

like undercover boss. Except... I

7:34

was thinking about that too. You

7:36

actually have to tell them what to do while

7:39

undercover. Yeah, and you

7:41

stay that way forever. Yeah, it will never reveal.

7:43

It's deep cover. Yeah,

7:46

yeah, yeah. So I

7:48

don't think leading as a peer

7:51

requires you to write production code. I

7:53

also don't think not

7:56

wanting engineering managers... I think it's

7:58

reasonable to say we don't want EMs to be... to write production

8:00

code, but you can still review

8:03

a lot of code and participate in design discussions

8:05

and write manager code,

8:07

where we've talked about this a bunch. It's code to

8:10

help the team do stuff that

8:12

they wouldn't normally do to solve some kind

8:14

of problem or

8:16

process thing or fix a bug no one's going

8:18

to get to. But you're not in the critical

8:20

path of the major important project with

8:23

the project depending on you delivering working features.

8:27

So that doesn't

8:29

seem weird to me. No, this seems. You can still

8:31

write code. Oh, go ahead. Yeah,

8:33

I was just going to say that this seems great. Like this kind

8:36

of leadership, where you are familiar

8:38

enough with the work of your team,

8:41

such that you can actually make informed

8:45

recommendations that carry

8:47

weight simply because they are so informed.

8:49

It's like people feel obligated to

8:53

follow your direction, not because of the positional

8:55

authority that the direction is coming from, but

8:58

because the direction itself is a good idea. Yeah.

9:02

And I think that means writing

9:05

usually less code, certainly, and different

9:08

code. But I think you probably read

9:10

more code if you're in this mode of

9:13

trying to be in the trenches and having a context to,

9:15

I don't know. I'm going to take that back. You probably

9:17

don't read more code. Never mind. I mean, if

9:20

you end up doing a lot of code review instead of

9:24

a lot of code writing. A bigger fraction of your time than

9:26

writing in this mode. And

9:29

I think the amount of code that you review

9:31

tends to be proportional to your seniority

9:34

as a natural course of things.

9:37

And so in a management role where you're

9:39

actually expected not to write code at all, let's

9:41

just say that you took that for granted. I cannot write

9:44

code. Well, then I think you will

9:46

be doing a lot of code review. And that's actually a good thing. It's

9:49

also a tricky

9:52

puzzle to solve. If you can't

9:54

do it yourself, how do you get the team to do

9:57

it? And you have to convince them. And you can't

9:59

do it yourself. You can't just go and write

10:01

the code the way you want it to be written. You

10:03

have to help decide on standards

10:06

and practices and principles

10:08

and you're working at a

10:11

more meta level. But

10:13

that scales better because you can influence

10:16

the team instead of just your own output.

10:20

This actually describes the way that I am currently

10:22

working in my role where I'm

10:24

leading a team, several teams of engineers. I

10:28

think it works pretty well. I think I

10:30

have a reasonable level

10:32

of influence on the team even though I don't

10:34

actually write code that contributes to each

10:37

of the team's code bases. Instead

10:40

I end up doing a lot of discussion and contemplating.

10:43

I also work at kind of the, I'll call it

10:45

architecture level, more like architecture in quotes

10:47

where I'm more talking about major

10:49

components that interact with one another and design

10:51

of these systems

10:54

and less about should we be using

10:57

Java streams or not. I

10:59

don't really care about that level. As

11:03

an engineer, but one thing I

11:06

think you correctly picked up on is that

11:08

if you go down the management

11:10

track, it is pretty

11:13

likely you will write a lot less code than if

11:15

you stayed on an IC track. If you get more senior

11:17

as an individual contributor, generally you write less

11:19

code as well, but you

11:22

still more than as

11:24

a manager. If you're a principal engineer

11:26

somewhere, you're going to write more code than a director

11:29

or senior engineering manager which might

11:31

be kind of the same level in the management track.

11:35

If you just have to write code

11:37

and that be your

11:40

main, well, it's not even the main

11:42

output for developers, but if that's like a

11:44

critical part of your satisfaction in

11:46

the job, then you

11:48

are going to be – I think you

11:50

can still do it as an EM, but you will be

11:53

trying to swim against

11:55

the current a little bit and you will have to justify

11:58

it and protect it a little bit. because the

12:03

vibes are definitely pushing you towards

12:05

other stuff. And I'm kind of ignoring

12:07

all the consequences of that

12:10

of like maybe you're gonna not do

12:12

important EM things because you're writing code.

12:15

I'm assuming you're perfect at all the engineering manager

12:17

stuff. Which is obviously true, I

12:19

mean that's the easier part. Yeah.

12:23

Easier to neglect, I mean, sorry. Yeah.

12:26

Should I resign myself to a work life that was never ending one-on-ones?

12:28

I mean, if you don't like one-on-ones, you should not

12:30

take a senior engineering manager real quick.

12:33

That's a pretty good signal.

12:37

If you just wanna be left alone to get stuff done,

12:40

then that

12:42

is not what your job will be. So I wanna go on record,

12:45

even though this record carries no weight and no one will ever

12:47

read this record, as saying that I

12:49

think engineering managers should be capable of

12:51

writing production code and do so

12:53

fairly regularly, but should also give themselves

12:56

the option to pull away from it for

12:58

extended periods of time to deal with other important

13:02

attention needing things, such

13:04

as team organization, planning,

13:08

one-on-ones, things like that. But I

13:10

love it when my engineering managers can jump into

13:12

the breach and fill a gap. You know, I mean, it just happened

13:14

this past week where we were shipping some

13:16

stuff to production and one of my teams had

13:19

a little bit of an oversight where they were like, oh,

13:21

we've shipped all the code, but there's a feature flag

13:23

that needs to be flipped on for everybody that

13:26

we just forgot to put a task in. And the engineering manager

13:28

said, look, the team is already working on

13:30

the next sprint, they've already kind of committed to that and we

13:32

don't wanna disrupt them. I'll just take that task

13:35

and I'm like, perfect. That's exactly the kind of thing I want

13:37

an engineering manager to be able to do, jump

13:39

in and fill a void somewhere. And the

13:41

manager did a great job. It was no problem. And

13:44

so if a company takes the hard line that

13:46

says engineering managers can't write production code, I

13:48

disagree with that. Yeah, well,

13:51

I would never disagree with you.

13:54

That's really unfortunate. If

13:59

we go back... to the question they're asking about

14:01

this contradiction between leading as

14:03

a peer and not writing any production code.

14:06

And I suspect they might have a different

14:09

definition for what leadership and

14:11

being a peer means than you

14:13

seem to be thinking of it as contributing

14:16

technically like in IC wood

14:18

and doing management stuff. So that might be worthwhile

14:21

to dig into. And I

14:24

mean, I would be surprised if what

14:26

are they going to do? Like if they hire you and you write

14:28

some code and you're getting other

14:31

stuff done, I don't know. I would be pretty

14:33

surprised if they said stop, you are

14:35

not allowed. Maybe

14:37

if there's a problem in kind of managerial

14:40

areas, then they might say, hey, you need to take care

14:43

of that before you write code. But I'd

14:45

be shocked if this were an all out hard

14:47

ban. Yeah, I don't, I

14:49

would imagine they're not taking it that seriously. And I

14:53

would hope that this job, whoever wrote

14:55

this job description is really just

14:57

trying to manage expectations more

14:59

so than getting a hard ban on writing

15:01

code as a manager. Actually, that could be what's

15:04

going on here too. There is a common

15:06

failure mode for talented software

15:09

developers with good people skills where they kind

15:11

of get pushed into management and

15:14

they don't really choose it. They

15:16

don't practice it deliberately. And

15:19

often they will hide in the technical details.

15:22

I can't possibly do these

15:25

tricky conversations because I have to

15:28

deliver this re-architecting

15:30

of the service. So

15:33

maybe they're kind of over correcting to try and avoid

15:35

that. Could be. Kind of setting

15:37

expectations like you said to make sure that like,

15:39

hey, you have to do the job of engineering management,

15:42

not the job of writing code. Yeah, and I've

15:44

seen that failure mode manifest pretty strongly.

15:47

One of the engineering managers who reports to me

15:50

took on a task and we all thought

15:52

it would be a straightforward task

15:54

that could be done kind of on the side, not on the critical

15:57

path, but it ended up consuming

15:59

their time. Like a lot more

16:01

than expected and it you

16:03

know It's the kind of thing where we thought oh this will be just like

16:05

a week of calendar time and maybe like

16:08

five to ten hours of actual time

16:11

and it turned into like three or four weeks

16:13

of calendar time and like 50 hours

16:16

of actual time and I started

16:18

to notice that this manager got more and

16:20

more frustrated when I asked them

16:23

to do manager things Yeah,

16:25

and it was like oh finally it dawned on me

16:27

like oh you've been totally consumed by this technical

16:29

task And now you haven't which

16:32

technical tasks tend to do right they tend to Yeah

16:35

to consume us like we can't think about anything else

16:37

we go to bed thinking about them And then we wake up in the morning thinking

16:39

about them And so I asked this manager to

16:41

do some other stuff with the team kind of more people management

16:43

stuff And he was like why don't I'm in a room on my plate.

16:45

I'm like oh I see

16:50

So maybe that's like you said maybe that's the failure mode

16:52

they're trying to avoid here Yeah

16:55

Well have we answered the question almost I think there

16:57

is one final question here Which is how do I stop

16:59

this gravity ripping you away from writing

17:01

code and and I have an answer to that Well

17:04

two answers one is that if

17:06

you really want to just avoid? Reducing

17:10

the amount of code that you write or the amount of time you

17:12

spend writing code

17:14

Every week,

17:15

then you just have to avoid management and leadership entirely

17:18

and I have done that multiple times Through

17:21

quitting my job because I found

17:23

that yeah at all and probably my first three

17:26

quote real jobs out of college after

17:28

a year or two I started to get pressure to

17:31

go into leadership roles and I

17:33

did them because I wanted to be a good team player

17:35

and honestly it came kind of naturally to me in some ways

17:38

But I hated it You

17:40

know because I just felt like it was pulling me away from the fun stuff

17:42

that I really loved doing which is writing code solving technical

17:44

problems and I quit those

17:46

jobs in part because of that Which

17:49

was just so refreshing it

17:51

jumped back into the code without any of the leadership

17:53

responsibilities It was wonderful. Yeah the

17:57

first time you see like a really gnarly

17:59

problem and just say, good

18:01

luck handling that. To someone else,

18:04

it's delicious. Oh,

18:08

you're senior designer and senior product

18:10

owner are both

18:12

fighting bitterly?

18:14

Huh,

18:14

time to go work on these unit tests. Yep. You

18:19

know, it's funny, because that also plays the other way. You know,

18:22

now that I'm in more of a leadership role, sometimes

18:24

I think, oh man, this is a really hairy technical problem.

18:27

I would not want to solve that. It's like a hard to reproduce

18:29

bug that only manifests when like

18:31

seven services interact in just the right way

18:33

when Mars is in this part of the sky. You

18:36

know, and I'm like, well, good

18:38

luck. And I'm like, I'm going to bed. And then three

18:40

days later, I'll come into work. And

18:43

I mean the updates. Hey,

18:45

how's that going? You know, three

18:47

days later, I come to work and there's this beautiful

18:50

document explaining what went wrong and

18:52

how it was fixed. And I just, I'm in awe of

18:54

it and I love it. So I don't know that,

18:57

that sword cuts both ways, James. It's

19:00

not me just staying up all night worrying about it. Anyway,

19:02

I do love those technical problems though. But

19:04

yeah, so you can just pull away. Now having said that,

19:08

if you are going to get into leadership, gravity

19:11

will eventually by default

19:13

completely rip you away from writing code. I've

19:15

seen it in so many leadership careers. But

19:18

I have one trick that keeps me in the code.

19:21

And that is I give myself coding

19:23

tasks that are not on the product

19:26

roadmap critical path and

19:29

usually aren't even on the product. And that

19:31

is building internal tools. I

19:33

will write Chrome extensions for my team.

19:35

I will write scripts for my team. I

19:37

will write little backend like data process, like,

19:40

oh, I'm gonna take all of our JIRA tickets and put

19:42

them into a data warehouse so that we can write queries on

19:44

them, that kind of thing. And

19:46

that scratches my itch and leaves me feeling

19:49

satisfied and keeps my technical skills sharp. Sometimes

19:51

I take opportunities like that to learn new languages

19:53

or learn new technologies or frameworks. It

19:55

keeps me going and I love it. And it

19:57

keeps me a little bit, I mean, I'm getting to be an

19:59

old- fuddy-duddy but it gives me a little bit relevant you

20:02

know where yeah and my little bit relevant

20:04

I mean just enough to where people can't ignore

20:06

me you

20:10

know enough that they can't easily

20:12

prove you're useless just

20:16

a little bit beyond reasonable

20:20

doubt yeah not

20:23

guilty of uselessness yeah

20:27

a jury of my purely we have answered it now yes

20:29

I think so let's move on Jameson

20:33

I want to tell our listeners about

20:35

a tool that many of them probably know that

20:37

I love and I know you've used

20:40

as well and love that has

20:42

recently added a whole bunch of cool features and that is

20:44

notion notion is

20:46

a it is like a note-taking

20:49

app but super super

20:51

good and notion has recently added a bunch of

20:53

AI features that I think are awesome yeah

20:55

I've used notion I think this is the third

20:58

job now that I've used it at work and used

21:00

it personally for a while too it's it's pretty

21:03

sweet and it's been really interesting to see

21:05

them play

21:07

with integrating AI into the

21:09

product in a way that's useful and not just kind

21:11

of tacked on at the last second yes

21:13

I am I get so frustrated by other

21:16

products that bolt AI on they're like oh

21:18

look now we have a sidebar that pops

21:20

in and you can in you can chat with a

21:22

chatbot I'm like oh my gosh yeah I

21:24

hate that I'm so sick of chatbots showing up

21:27

everywhere notion has actually built

21:29

AI natively into the product so I can tell

21:31

it to do things like generate to-do lists

21:33

or remove items from my list that match a certain subject

21:36

or even ask questions about my own content

21:38

like hey summarize these notes I took and

21:41

extract the action items yeah they just

21:43

added a Q&A feature which

21:45

is pretty cool where it can use the content of

21:47

your own workspace to answer

21:50

questions so you can say like hey

21:52

what did we what do we say in

21:54

the meeting that happened on this day you don't have to give it the link

21:56

to the doc or anything it can go and search

21:58

it and find it and bring it up up to you. Exactly,

22:01

like, hey I met with the integrations team

22:03

last week, what were the takeaways? Boom. So

22:06

much better than like trying to remember

22:08

the keywords that you would have written down in that

22:10

page to try to find those notes.

22:13

Yeah,

22:14

I love it. Go check it out at Notion.com

22:17

slash soft skills. Yes,

22:19

that is all lowercase letters, Notion.com

22:22

slash soft skills. Try the powerful

22:24

easy to use Notion AI today and when you lose

22:26

it, use our link, you're

22:28

supporting the show. This is a sponsored ad,

22:31

if you can't tell, I guess we should say that. Yeah. But

22:34

we do like Notion and I have used it for years, so

22:37

it aligns well. All right, Jameson,

22:39

would you like to read our next question? I

22:41

would love to. This

22:44

is from another

22:46

anonymous listener who says, hello Dave and Jameson,

22:49

thank you for your podcast. I have listened to almost

22:51

all episodes and they provide both educational

22:53

and entertaining values. Thank you. You

22:56

rock. Oh, such nice words. I

22:58

would like to ask you for your advice. I'm

23:00

struggling with a problem related to communicating

23:02

and cooperating with people in general. I have

23:05

over 10 years of professional experience. I was always a hardcore

23:07

nerd sitting alone in front of the computer and programming,

23:09

focused only on pure technical skills. Everything else

23:11

was unimportant. Most of my career

23:13

I spent in small companies where I could just spend time writing

23:15

code and wasn't bothered by anything else. However,

23:18

one year ago I started to work at Fing, it's

23:20

one of the big mega tech companies, and

23:22

I now feel overwhelmed. Technical skills seem

23:24

not so important anymore. Most of the problems are being

23:26

solved by talking, negotiating, and following up

23:28

with other teams, participating in meetings

23:31

and presenting results to management. It stresses

23:33

and burns me out. I feel

23:35

like it is a waste of time and potential, but

23:38

also I was never a people person, so I'm anxious

23:40

every time I'm in a new social situation. How

23:43

could I convince myself that such non-technical skills

23:46

are equally important as technical skills? What

23:48

steps can I take to improve my attitude and skills?

23:51

What would your advice be if you

23:53

had to work with a person like that? be

24:00

if I had to work with someone who didn't want to work

24:02

with me. Is that what you're asking?

24:06

Yeah, someone who didn't love the communication

24:09

and non-technical,

24:11

I don't know, non-programming work that

24:14

goes into coordination. Well,

24:17

having, both of us having worked at one of these giant

24:19

mega tech companies, I totally

24:22

agree that the social

24:24

skills required to successfully navigate

24:27

solving even what should be simple problems,

24:29

simple technical problems, are the

24:32

skills required are much more advanced,

24:34

let's say. Yeah, if you think

24:37

technically scaling a system is hard, wait

24:39

until you have to scale people

24:41

and communication issues. Yeah. That

24:45

is, yeah, that is a whole different

24:47

kind of hard. I don't know if it's

24:49

harder or easier necessarily, but it's a different

24:51

axis. Yeah, I remember one of my

24:54

very first assignments when I joined a FANG

24:56

company was to try to try

24:59

to make a plan for

25:01

all the services within my department to migrate

25:04

from one framework to another. And

25:06

it was like I couldn't even tell how many teams

25:08

were in my department. And I found out

25:10

midway through the project that some of the staff

25:12

in my department were actually funded by another

25:14

department and we had certain obligations to that

25:17

department. And I got on calls with them

25:19

and it was like, oh, man,

25:22

there was political stuff going on

25:24

where they weren't getting what they wanted. So it was like customers

25:26

layered on customers, and some of them were internal and

25:29

oh, boy, it was tricky just even figuring

25:31

out what was going on, let

25:33

alone how to proceed was very challenging. Yeah.

25:37

I observed similar things in that

25:40

easy things can become hard. And

25:43

just when the scale gets that

25:45

big, you can't

25:47

collect all the information you need yourself.

25:50

You can't just look at the code base or look at the directory

25:52

or you have to talk to other

25:55

people. And there's layers upon layers of

25:57

teams like you mentioned. And then there's

26:00

even more layers for stuff to get confused

26:02

or mixed up. So it is a hard problem

26:04

to solve coordinating at that scale. Even

26:07

just finding a person who actually knows

26:09

what they're talking about for the thing you need to know about

26:12

can be really challenging. Yeah,

26:14

and finding a person who knows what they're talking

26:16

about and is like willing to help you

26:18

instead of see you as

26:21

an intrusion upon their domain. Right.

26:24

Oh man, I'm getting flashbacks. Yeah,

26:26

me too. In fact, I just

26:28

thought of one person who I just absolutely appreciated

26:32

so much because they knew something about

26:34

the systems that I needed to integrate with and they gave

26:36

me a couple of hours of their time. And

26:38

I was like, thank you so much. You have saved me

26:40

weeks of investigative

26:42

journalism. I think in

26:44

one word, I can give

26:47

an answer to this question

26:49

that will address simultaneously some of

26:51

the challenges of navigating these bigger organizations

26:54

and help compensate for

26:56

a lack of social skills

27:00

or for a strong social

27:02

anxiety. And that word is writing.

27:05

It turns out that in most of these organizations

27:08

that I'm familiar with, one for sure that I

27:10

worked in but others that I've heard secondhand,

27:14

the written word carries so

27:16

much weight in these organizations

27:19

because it is just nearly impossible to

27:21

get people's attention focused enough on you

27:23

when you're speaking to actually have that convey

27:25

any meaning. But written documentation tends

27:28

to travel very well. It tends to

27:30

persist and it tends to cut

27:32

through a lot of the political stuff,

27:34

a lot of the social stuff and ends up

27:36

being kind of a great equalizer among people who

27:38

do and do not have these – call

27:41

it like social charisma. Then

27:43

you just need writing charisma. Right.

27:47

Well, the beauty is that a skilled

27:50

engineer is naturally a good writer

27:52

because they don't care about any of

27:54

the fluff and people reading technical written

27:57

material don't want any fluff.

28:00

I want just the facts. It's

28:02

like, oh, you wanna start a new program and

28:04

kick it off and you need four people to work

28:06

with you? Give me the facts, give me the

28:08

business value, make a case for it. And

28:12

business cases are not made through flowery

28:14

writing and fluffy, impressive words.

28:20

See, I'm not even good, I can't do the flowery stuff. You're

28:22

like. But, you know, like, business

28:25

cases aren't made by

28:28

inviting someone to an NBA basketball

28:31

game in your special booth that

28:33

costs millions of dollars. You know,

28:35

although unfortunately that is how some deals, many, many

28:37

deals are agreed to. But when

28:39

it comes to technology and engineering choices, the

28:43

most convincing to me way

28:45

to make those choices is through written

28:47

material that just states the facts in an unequivocal

28:50

way. I think even

28:52

if there is a kind of in-person

28:57

piece of this that's supposed to happen, if you have to present

28:59

to other teams or have

29:02

some kind of real-time discussion, it's way easier

29:04

to anchor that with

29:06

a written document and it

29:09

can help, it can help kinda keep

29:11

it on track, help you know you're not just

29:13

going off the rails completely.

29:15

I thought you were gonna say money is the one

29:17

word because usually you get paid more at these places.

29:20

You put up with the pain for

29:22

dollars. This

29:25

might be a variation on the money theme, but

29:28

you could look at what works.

29:36

This'll work, if you're very motivated by kind of like

29:40

achieving a thing in the organization,

29:43

then maybe this can help you. Because if

29:46

you are, then you have to do the thing

29:48

that gets results and usually that means talking

29:50

to people and convincing them

29:52

and following up and doing all this stuff. And

29:55

if you can, if you don't like

29:57

it, you're uncomfortable with it, you feel like you're not good, but

30:00

you're motivated to do it because you know, this is

30:02

helping me achieve my technical goals, then

30:05

I think that can be a powerful motivator. If

30:07

you don't really, if you don't care that much, it's the wrong

30:09

way to put it. If you really want

30:11

to put your head down and write code, then

30:14

that might not help as much because that's

30:16

less impactful and meaningful

30:19

without the results that it will achieve.

30:22

What am I saying? I think I'm saying

30:25

to be successful, you

30:27

need to work on this a little bit more, which I guess

30:29

is what you're saying in the question as well. So I

30:31

don't think I'm telling you anything new. Just

30:34

repeat that to yourself. I don't know, I felt new. You're just

30:36

so good. I need to do this. You're so good at clearly

30:38

saying things. My words. Yeah,

30:40

your word is so good. I good word. My

30:44

good word is so good. Even though we said

30:47

that writing helps and this kind of thing, you

30:49

know, what Jameson said helps, sometimes

30:51

you do have to actually stand up in person and

30:53

justify things and explain

30:55

things and appear confident.

30:58

And there's really, in my opinion, no

31:01

way around that except through it, meaning

31:04

you have to spend time doing

31:06

that. And now I'm gonna put my space psychologist

31:09

hat on, which just as a reminder, we

31:11

are not real psychologists. Well, we are real,

31:13

but not on earth, which

31:16

is where we are now. So take

31:18

that for what it's worth. And

31:21

I'm gonna throw out a term that sounds like

31:23

a real psychology term and

31:26

might even be. And that is exposure

31:28

therapy. In

31:30

my inexperience in psychology,

31:32

this is where you have

31:34

a problem or a fear or a skill

31:37

gap in an area that causes

31:40

you anxiety, it causes you to

31:42

feel burned out.

31:44

And instead of avoiding it, you expose

31:47

yourself to it. And I think that

31:50

is required to become comfortable with these kinds of

31:52

situations. Like let's say you've written an excellent doc,

31:54

you've farmed it out to all the different relevant teams

31:58

that have to sign off. Now they wanna talk to you about it. This

32:00

inevitably happens where you have to sit down in a meeting, they've

32:03

read your documentation, they have questions and you need

32:05

to answer them. The

32:07

confidence level that you exude in

32:09

answering these questions and the quality of

32:11

the answers you give will ultimately

32:14

determine whether your ideas proceed

32:17

or get shut down. In

32:19

my experience, the only way to confidently

32:22

navigate that kind of a situation is to do it a bunch

32:24

of times. Doing

32:26

it a bunch of times helps you realize that

32:29

actually it's not that bad. Most of the time,

32:31

except for when you are exposed to really badly

32:34

behaving people, most of the time

32:36

people just have questions of curiosity

32:38

and they have real concerns that are valid. You

32:41

need to learn how to understand those concerns,

32:43

pivot your proposal to incorporate

32:46

those concerns and then work together as a team. From

32:49

what I've experienced, the only way to do that is to do

32:51

that. I was going to say practice, but

32:54

exposure therapy sounds like we

32:57

could charge more money for talking about it. Well

32:59

said. There's

33:05

the practice in delivering your

33:07

material to somebody. I

33:10

don't know, I might be extrapolating

33:12

or reading more than is in

33:15

here, but there are some times where you have

33:17

to present to people who have very little

33:19

context, are very busy, they're

33:21

executives or high level leadership

33:23

or something. That's a totally different vibe

33:26

than presenting to a peer team. I

33:30

think that's harder to practice for because it's less about you

33:32

knowing your material and more about you dealing

33:36

with the rabid,

33:40

wild changes of topic and random

33:43

stuff that they jump on to. You

33:46

have to work to keep them on track or

33:48

just go with the flow, I guess, as

33:50

well. I think the answer is sort of

33:52

the same. If

33:55

you really know your stuff because you practice it a lot, it'll be easier

33:57

to deal with those conversations and follow

33:59

them wherever you go. they lead. What

34:03

steps can I take to improve my attitude and

34:05

skills? Why listen to this show of course.

34:10

Also I think that one mindset

34:12

shift that might help improve your attitude towards

34:14

these kinds of problems is instead

34:17

of focusing your professional efforts

34:20

on the act of writing code

34:23

and doing the non-social, non-soft

34:26

skills stuff, instead of saying I derive

34:28

my professional satisfaction from doing those things,

34:31

you should say instead I derive my

34:33

professional satisfaction from producing valuable

34:36

product that makes the lives of my users

34:38

better. And

34:40

then the code and these

34:43

challenging social situations are actually

34:45

just a means to achieve that

34:48

outcome of building great product that makes

34:50

your users better. And this is actually a pretty

34:52

rare attitude among software engineers. Most

34:55

software engineers, myself included for many

34:57

years, only take satisfaction

34:59

in writing code. Like I like to solve puzzles,

35:02

I like to write code, I like to produce code, I

35:04

don't like to fix bugs, I don't like to go to meetings,

35:07

I don't like to actually deeply understand

35:09

my users, I just like to write cool algorithms

35:11

and program stuff.

35:12

But

35:13

really that is not our business. Our

35:16

jobs, we are not getting paid to write code.

35:18

You are not getting paid by the lines of code you write, you

35:21

are not getting paid by the bugs you fix. Instead,

35:24

you are getting paid for the valuable outcomes

35:26

you deliver and writing code just happens

35:28

to be the tool that you use and the skills that you

35:30

have to do that. And when you work

35:33

at a giant company like a fan company, now

35:35

you need to increase the size of your toolbox

35:38

and also learn how to navigate these social

35:40

situations as a means to the same end.

35:42

Here, here, well said. Well,

35:46

did we answer this question? I think

35:48

so. I think you are wise to recognize this and

35:50

you say you are not good at social situations

35:53

but the fact that you are self-aware enough

35:55

to notice makes me feel

35:57

like you can do it. That

36:00

people who are hopeless don't know that they are. They

36:04

don't care or don't notice. Yeah.

36:07

All right. What should people do if they want their own questions

36:09

answered, Dave? Go to softskills.audio

36:11

and click the ask a question button. Thank you

36:13

so much to everyone who does that each week. The

36:15

questions are just flowing in like

36:18

a fast moving glacier that crushes

36:20

everything in its path. But instead of

36:22

crushing things, it fills our

36:25

souls with joy. So nothing

36:27

like a glacier at all, either in speed

36:29

or effect. Over

36:33

many millions of years, new mountain

36:36

ranges will appear because of your questions.

36:40

We also want to say thank you to those who have responded to our

36:42

call to give us feedback on our answers. We

36:44

will continue to read those on the show. We really

36:46

appreciate you telling us how things went. Man,

36:50

there were some great ones this week that we didn't read, but we'll try

36:52

to read them next time. So thank you. If

36:54

you want to read the same form at softskills.audio, click

36:56

the ask a question button and then blatantly

36:59

disregard the labels on the fields that say question

37:01

and instead write feedback on a previous

37:04

episode and just write a few words there saying this is

37:06

feedback on episode X and just

37:08

let us know how we did. We'd love to hear that. Yeah.

37:11

The computer is not the boss of you. It says ask a question,

37:13

do whatever you want. Yeah. You put

37:15

whatever text you want in there. Yeah. All right.

37:18

Thank you for listening. Bye-bye.