0:07

It takes more than staring longingly at that

0:09

new programming language that you can't use in

0:11

production to be a great engineer. This is

0:14

episode 380 of the Soft Skills Engineering podcast.

0:16

I am your host, Jameson Dance. I'm your host,

0:19

Dave Smith. Soft Skills Engineering is a

0:21

weekly advice about all of the non-technical things

0:23

that go into the technical field of software

0:25

development, like how all of your problems

0:27

would be solved if you just

0:29

switched to other things.

0:31

Oh, Haskell, I will never know thee. You

0:35

know what would be great? If we had to find a new logging

0:37

library for

0:38

all the basic infrastructure stuff

0:40

that we already use, that we already have figured

0:42

out. If we had to re-figure all that stuff out.

0:44

Yeah, exactly. Oh, language?

0:48

Great. All the ripple effects? Not so fun.

0:51

Yeah. Unless you get to write

0:54

it yourself, and then it's actually fun. Which of course you would.

0:57

Yes. In

0:58

fact, that might be how you choose the thing. What

1:00

thing does not have an HTTP library?

1:03

Perfect. I

1:06

would like that to be my job for a while, please. This

1:10

is job crafting. Yeah.

1:12

Dave, do you want to thank our patrons? Yes,

1:14

I do. A big thanks to this crew. They

1:17

are typehero.dev, full stack contractor

1:19

looking for job corp to corp. Never is not

1:21

just a crater on Mars, flamingo emoji. I like chicken.

1:24

I like liver. Meow mix, meow mix. Please

1:26

deliver. Thank you very much. I almost

1:28

did a British slash New England accent

1:30

there with putting an R at the end. Trash Panda? Erner.

1:34

Trash Panda. Thecomputersciencebook.com,

1:38

Santa Hope, I can't see dods. Jenny Kim,

1:41

Owen Chartle, Craig Motlin, the Stochastic

1:43

Parrot, Alice Jost, Muskingum, Ohio,

1:46

patron.com. We're hiring. Ira Chan,

1:48

monkey face emoji, Jonathan King, Web Tao,

1:50

awesome end to end testing, Will Angel, Ragnar Nick Hathaway. Ragnar

1:52

Nick Hathaway. Travis, I still love that. Travis,

1:57

Braden Gaines, John Grant, Cody Sale, Nick Cantor.

1:59

If you would like to join this illustrious, just

2:02

the most illustrious of crews, go

2:05

to softskills.audio and click the support us on Patreon button.

2:08

If you put in enough numbers, the

2:10

right numbers, whose decimal

2:13

interpretation is greater than a threshold that we

2:15

decide, we will say whatever

2:17

you can type into the Patreon name field. And

2:20

if you contribute any decimal value greater than

2:22

zero, we'll send you a Slack invitation

2:25

to join our community of over a thousand people who

2:27

chit chat with each other, share comedy, share

2:30

job opportunities with each other, and

2:32

get advice, get real advice, unlike the stuff

2:35

you hear on the show. You can actually ask people

2:37

for real advice and it's good. Yeah,

2:40

and we'll send that to you at the beginning of every month. And

2:43

a hug, just a virtual one. Yeah,

2:46

it's more of a philosophical

2:48

hug, I guess. We

2:51

can just say that

2:53

NFTs are fake, right? I can just say like, there's

2:55

an NFT for the hug and you just

2:58

have to believe me and pay me money. Yeah,

3:00

that's how it works.

3:04

Okay, let's

3:05

answer some questions. But first that means

3:07

I have to read the question. Okay.

3:10

Which I will do. A listener named Ashley asks,

3:13

I'm a mid-level developer at a small company with

3:15

a non-technical manager. After several

3:17

months working on migrating our users from a legacy

3:19

system to our new system, our non-technical

3:22

business analyst discovered that

3:24

our current system reuses lots of code from

3:26

the legacy system. They

3:28

immediately escalated their quote concerns

3:31

about this to our manager. This quickly

3:33

resulted in a group message from our manager to

3:35

the BA, that stands for business analyst, our

3:37

senior engineer, me and another developer.

3:40

Without asking for more than a cursory explanation

3:42

of how two sets of users who need the same functionality

3:45

can use the same code base without breaking things for each

3:47

other, our manager made the decision to fork

3:49

the project and maintain two separate code bases.

3:52

The developers tried to explain why this was a bad idea,

3:54

that we were immediately shot down. This

3:57

has already resulted in issues in pre-production

3:59

environments. They were afraid that having

4:01

changes in one unified code base would break things

4:03

for both groups of users. We were given no opportunity

4:06

to make further arguments. Two months later,

4:08

I find that my motivation at work has tanked despite

4:11

being below market rate. I've

4:13

stayed because it allowed me to advance my skills

4:15

as a developer. But my trust in

4:17

our BA and management is completely

4:20

shattered. Is it worth staying in my current

4:22

role? Is salvaging our current situation a

4:24

hopeless cause that is likely to

4:26

just collapse again in the future? Or

4:28

would I be wise to get out ASAP

4:30

before things blow up and the blame is pushed on

4:32

our development team? I feel like I already

4:34

know the answer in my gut, but I'd like to hear your perspectives

4:37

on this. Mmm.

4:41

Oh, boy. It

4:42

kind of seemed like we're in the Dilbert cartoon

4:45

on this one. It

4:48

does. It does feel like that.

4:51

It feels like somebody thinks they're good at being decisive

4:54

without knowing what

4:56

they're deciding.

4:58

Honestly, it's situations like this. So,

5:01

James and I are both in leadership roles

5:03

right now. And honestly, every

5:05

time I make a decision, I have this

5:08

voice in the back of my head that's like, you're

5:10

this boss. I do as well.

5:15

It's so easy for me to look at everything I decide

5:17

and list all the downsides and say,

5:19

here's all the ways that this is wrong and

5:21

dumb. And like

5:24

enough of them might be true that this could be bad. Yeah.

5:26

Wouldn't

5:29

it be great to have a team that was just like, no,

5:31

great job, Jameson. Good decision. Yeah,

5:34

I need some yes men. No,

5:41

it's, I mean, in

5:43

some ways it would be temporarily great, but worse

5:46

overall, certainly. Yeah. I

5:50

don't think anybody should be trusted to only

5:52

employ yes men. I know.

5:54

Just amplify all my already bad decisions. What

5:57

you need are some maybe men. Maybe.

6:01

Yeah. Is this

6:05

a good idea everyone? People who? Maybe.

6:08

You're right. Let's not do this. People

6:10

who really bring a strong sense of

6:12

ambivalence. Not only do I not

6:15

know, I also don't care. Oh,

6:18

that is way worse than having someone who thinks your

6:20

ideas are horrible. You can at least

6:23

engage with that. If you just put

6:25

out an idea and you are met with shrugs,

6:28

I don't know. It just sucks

6:30

the joy out of me. Exactly. Give

6:33

me some passion. Anyway,

6:36

this is tough. I think having a non-technical

6:38

manager or even

6:41

a manager who's technical in a different domain or whatever

6:43

the case, just doesn't have enough context

6:47

or knowledge or skills to be properly

6:49

informed and opinionated on your day-to-day work

6:52

is really challenging.

6:53

It's,

6:56

yeah, it is challenging. I

6:58

don't think most

7:01

bosses have enough

7:03

context and experience to be more informed than

7:05

the folks they work with on everything,

7:08

but hopefully they have experience

7:10

on a lot of useful things. That

7:13

seems like kind of the difference here where if they

7:15

were a technical manager, they might, I

7:18

don't know, they might trust the engineers more

7:20

even if they don't really have a firm opinion

7:22

on this specific decision. It's

7:25

not like they would just know better and thus agree

7:27

with you. It's more like they kind of have

7:30

the same vibes as you. Yeah, like they might

7:32

be more willing to explore the trade-offs

7:35

with you rather than just saying, oh, I see

7:37

the problem. Fork the code bases.

7:40

Forks are good. I've heard of

7:42

that. Fork everything. Yeah.

7:45

Yeah. Oh, and

7:49

I'll take the devil's advocate on this one just a little

7:51

bit and say maybe the manager's right.

7:54

There's a couple of reasons why the manager might be right here,

7:56

not to get into too much technical detail.

8:00

the manager is only right by luck. But if

8:02

this legacy system is scheduled to be shut

8:05

down in like three months and no new feature

8:07

enhancements are going into it and bug fix rates have

8:09

been low, maybe it's fine. Maybe

8:12

just leave it alone and let it keep just

8:14

huffing and puffing while you work on the new system

8:17

unencumbered by how any of your code

8:19

changes might affect the legacy system. I

8:21

mean the question asker mentioned that trust, my

8:24

trust in management is completely shattered.

8:27

It seems like they did not

8:29

exhibit a lot of trust for

8:31

you, for the engineers in the way they made the decision

8:34

because it feels like you weren't heard.

8:37

Yeah. Your manager is not, their

8:39

job is not to do the things that you

8:41

think they should do all the time or make the decisions

8:44

you think they should make. So it's

8:46

normal for them to decide sometimes

8:49

in a way you disagree with. But

8:52

I think you should be able to expect

8:54

that even if you disagree, you

8:57

understand why

8:59

they're doing it and why they think it's the right

9:01

decision. And that old Amazon

9:04

like disagree and commit thing is a thing that

9:08

you should be able to do because

9:11

you kind of trust each other enough that you

9:14

can get over some

9:16

disagreements by saying like broadly we're

9:18

moving together on things. Yeah, I agree.

9:21

You don't have that here. Yeah,

9:24

I try really hard to do this and

9:27

it is challenging as a manager. Actually,

9:29

it's challenging for anyone to fully

9:31

understand the rationale that went

9:33

into your decision making. When you make

9:36

a choice, at least when I make a choice,

9:39

I sometimes it's just like, well, I feel

9:41

like it. Like that's what I want.

9:44

I can't explain why I want it. And

9:47

so as a leader, I try to

9:49

force myself to explain like the

9:51

underlying tenets that guided my decision

9:53

making and then try to explain

9:55

like, look, I understand there are pros and cons to

9:57

this decision. Here are some of the cons.

10:53

I've

12:00

heard the word Gucci though. Okay,

12:02

well. So yeah, this is hard.

12:05

Well, hang on, hang on. I think this means we're qualified

12:07

to decide what fashion is and what

12:10

is fashionable. We're

12:12

qualified by not knowing anything

12:14

about it? Is that the qualification? No, I mean,

12:17

I don't know. We're mirroring

12:19

the manager in this question. Oh, right.

12:22

I've heard of Gucci, but it's bad and

12:24

you should instead wear Prada. Another

12:29

day, another dollar. Another decision made. Yep. Man,

12:33

I am so decisive. Well,

12:37

yeah, what do you do about it? Well,

12:40

I don't know because you

12:42

can't just

12:46

wave of magic wand and have your manager turn

12:48

into someone who has the skills and knowledge

12:50

necessary to truly assess important

12:52

technical decisions. And what's

12:54

worse is that over time, let's

12:56

just assume this is a really bad technical decision. Over

12:59

time, this

13:01

bad decision is going to have little

13:04

babies that come out of it that are

13:07

also bad things that are happening. Little

13:09

gremlins. Yes, gremlins will be birthed

13:12

from this bad decision and the manager

13:14

will not have the technical knowledge

13:17

to know that this bad decision

13:19

actually is the cause of those downstream

13:22

problems. And

13:24

so that manager might chalk it up to bad

13:27

engineering, bad staff. So there's a lot of

13:29

ways this goes really wrong. And

13:32

I think that if you actually want to address this problem,

13:35

you need a strong technical leader on the

13:37

team who has simultaneously

13:40

earned the trust of the manager and also

13:43

can make really convincing

13:46

strong arguments that are good,

13:48

good engineering decisions. And I

13:50

just sense there's a little bit of a gap here because if this

13:53

business analyst and non-technical manager

13:55

felt not only empowered but also

13:58

felt justified in making a highly technical

14:00

decision without consulting the team.

14:03

I sense there's a gap on this team because where's that person?

14:06

If I were a non-technical manager and there was a technical

14:08

leader on the team who I trusted, I

14:10

would just take the feedback from the business analyst

14:13

and I would just aim my eyeballs

14:15

over at the technical leader and be like,

14:17

okay, what are we gonna do about it? Yeah.

14:22

We always talk about how as you become more senior

14:25

as an individual contributor, often

14:30

the demand on your soft skills or

14:32

you're asked to do more kind of coordination

14:35

and cross org stuff

14:37

and people things, even

14:39

if you're not managing them. This feels squarely,

14:41

this feels like it falls squarely in

14:44

that realm of like a

14:46

very senior engineer would have

14:48

the technical skill to know what the right

14:50

thing to do is and the organizational

14:53

skill to navigate this dynamic of like

14:56

getting the engineering managers trust and

14:59

helping them, guiding them to the right decision

15:02

instead of just being steamrolled by them. Exactly.

15:06

And I'm just saying, where's that person? Yeah,

15:09

I mean, if you feel like you can develop

15:11

into that or the

15:13

senior engineer on your team can develop into that, it

15:16

feels like you kind of needed a united front. You need

15:18

to like organize a cabal

15:20

of the engineers on this team and

15:23

kind of get together and... If

15:26

you wanna improve this, I guess. You're saying in the absence

15:28

of a strong technical leader, you need essentially

15:30

a union? Yeah,

15:32

I guess, yeah. I mean, yeah.

15:35

Demand your benefits and one

15:37

of the benefits is like, please

15:39

ask us and take our advice on technical

15:42

decisions. Don't

15:45

fire us and also don't

15:48

decide what source control

15:50

tool we're gonna use. There

15:53

is another option here, which is that, listen,

15:55

you got a non-technical BA, you got a non-technical manager.

15:58

Are they really gonna know if you forked the...

15:59

code?

16:00

Like, do they even really know? I can think about that.

16:03

Yeah. Just be like, what are they going to do? It's

16:05

forked. Yeah, we press

16:07

the fork button. Yeah.

16:10

Oh.

16:11

Yeah, I

16:13

mean, that road ends

16:16

in a bad place. But

16:19

as a person who does the thing, you

16:22

are ultimately in charge

16:24

of what thing gets done. Yeah?

16:28

At some point, someone's going to notice and say,

16:30

wait, I thought we were doing another thing. But

16:33

you can do the thing. And then when the thing goes

16:35

wrong, you can explain it away. Oh,

16:38

we actually, darn it, we clicked the spork

16:41

button. Sorry. We'll

16:44

get that fixed right away. Wow,

16:48

we really couldn't have sporked this code base. Yeah.

16:52

Oh, boy. That's why it's good to get

16:54

decisions in writing because we all

16:56

thought we clearly heard, spork in writing.

16:58

Yeah. There's

17:04

a possibility that you can

17:07

make this work and it can be kind of a

17:09

crucible that will forge you into a stronger,

17:12

more powerful engineer. But

17:16

I think I would be kind of looking for the door

17:18

here. Maybe, but it's so hard to go find

17:20

a new job right now. So, so hard. Yeah.

17:25

That's why good meta advice is always

17:27

to have

17:30

compelling alternatives because if

17:33

you can't get another job, then your options

17:35

are pretty limited to make it work here.

17:38

Yeah. And there are times where that will

17:40

be the better option. And there are times where you

17:42

think it will be worse and it actually ends up being better.

17:44

But it's nice to have the flexibility where if

17:47

you cannot afford to go look

17:49

for a job or can't afford the potential

17:51

downtime, the loss of income while you're looking or

17:53

whatever.

17:55

Yeah. I guess the question is answered.

17:57

You stick around and make it work. And so let me.

19:59

become unified. Ignore

20:02

the

20:02

implied violence. Okay,

20:05

have we answered the question? I think so. Good luck. Tricky

20:08

situation. Good luck. Dave, will you

20:10

read? I was going to say answer, but of course you'll answer

20:12

it. Will you read our next question? Yes, and

20:15

I'll answer it as well.

20:16

Thank you. We'll see if you will join me in answering,

20:18

but that's up to you. This comes from

20:20

a listener named Damison Jans.

20:25

Oh you. Damison

20:28

asks, I sometimes find myself struggling

20:30

to describe how software issues will affect product

20:32

designs to non software engineers. It

20:34

is hard for me to explain, quote, this seemingly

20:36

tiny change in user experience

20:38

that you've asked for is actually driven by this back-end

20:41

functionality that is totally transparent to users and

20:43

really no one besides back-end engineers has any reason to

20:45

know about it, but yeah anyway that small change

20:47

is going to require six months of work. I

20:49

changed to multiple services. So

20:53

true. I have found this approach quite ineffective

20:55

and I think it comes off as me sounding like,

20:57

quote, my way or the highway. I'm wondering

20:59

if you guys have any tips for explaining how

21:02

systems work to people who aren't software

21:04

engineers and don't necessarily have all the context

21:07

you do. Oh this is a great

21:09

question and I

21:11

have to link a YouTube

21:14

video in the show notes and

21:17

you can find this YouTube video if you search for

21:19

Omega Star. Damison do you know this

21:21

one? Is this the micro services one?

21:23

Yes. Yeah. This

21:26

is like three minutes straight of an engineer trying

21:28

to explain to a product manager why they can't add

21:30

what like a birthday field to a profile

21:33

page. It's like 50 micro

21:36

services. Oh

21:38

man it's so good. I'm putting this

21:40

in the show notes. I love that video because

21:43

it's both like a, it pokes

21:45

at both sides. It's sort of like, yeah

21:48

look how complex this thing is that you thought was

21:50

simple and it's also like, look how horrible

21:52

you made it to add a birthday field engineers.

21:54

Look at this monstrosity

21:57

you've built. But yeah there's

21:59

this weird. I don't know. I don't think we need to

22:01

focus too much on this. But there's this weird power

22:04

that comes with understanding the super complex

22:06

system. I get these brain tickles. It

22:08

feels good and so

22:10

much so that sometimes I worry that

22:12

I made the system complex so that my brain would

22:14

tickle. I feel good about it and I understand

22:16

it. Oh no. Well.

22:21

I'm just thinking, I was just kind of getting contemplative

22:23

there. Have I intentionally designed complex

22:25

systems just so that I can have the brain tickle?

22:27

I

22:28

don't know if it's intentional even. It's like.

22:30

Yeah, but even if it's of consciousness.

22:33

Yeah, whether or not it's intentional. It's like, did I create

22:35

this problem? I

22:37

don't think it's a. I got to get the

22:39

brain tickles from simplicity to retrain my brain.

22:42

It's like art. It's beautiful. Yeah. How

22:44

can the software do so much with so little

22:46

and so clear of code? To

22:49

develop a fine taste. A small

22:51

change can require. So unfortunately,

22:54

this is a boy who cried well situation,

22:56

I think, because guaranteed

23:01

these people you've talked to have heard this from other engineers

23:03

in the past. And some of the time it's

23:05

been true. And some of the

23:08

time they have been explaining

23:11

things, making assumptions

23:13

about what needs to happen

23:15

to the system and kind of deciding

23:17

that instead of more explicitly presenting

23:20

the trade offs. Often

23:22

there's some kind of trade off of like, yeah, we can

23:24

hack it in and it'll be small

23:26

and simple and it'll make our lives worse

23:29

in this way. Or we can clean

23:31

up this past mistake and touch all the

23:33

microservices and it'll take six months. And

23:37

yeah, people have been burned on both sides. Like engineers

23:39

get burnt all the time by quick

23:42

hacks that last longer than their

23:44

career. They have to maintain

23:46

forever and folks talking

23:48

to engineers get burnt by surely

23:51

it can't be this hard to add a birthday field.

23:53

So I feel like there's there's lots of baggage

23:56

to this. There totally is. I mean, as

23:58

an engineer, you've been burned so many times. times that

24:01

you just can't help but be super cautious

24:03

when telling anyone how long anything will take.

24:05

I don't even know how long it

24:07

takes me to open my editor anymore. Yeah

24:09

I don't think I can give a estimate

24:11

without saying several times this is an estimate

24:14

not a deadline. I don't I think those words just

24:16

come out of my mouth that's a version

24:18

of this of like I'm trying to

24:20

prevent future pains that I've felt

24:22

in the past. Yeah all

24:24

your scar tissue is like tingling. Yeah

24:27

but then it makes it take longer for me to say stuff.

24:30

It does and I you know I I

24:33

have how do I do this? I

24:35

feel like I've gotten to a really good place with this

24:37

but it really depends on the environment. If

24:40

you have a place or an

24:42

environment of trust where

24:45

everyone who's asking this question and everyone who's

24:47

answering it knows that we're all working

24:49

together to deliver a valuable

24:52

product as fast

24:54

as possible then you have

24:56

a little bit more leeway with this. But

24:59

if you've got adversarial people

25:01

on on the other side of this question or

25:03

if you've got a history of

25:06

poor shoddy workmanship or you know or

25:09

you've got or you have really crazily demanding customers

25:12

you know who are just like what I need to know exactly what day

25:14

and time this is going to shift you

25:16

know. Yeah. Then it's just there's

25:19

almost no technique that just fixes this problem

25:21

and so I would actually say you kind of have

25:23

to go back to the roots and

25:26

try to create an environment of trust

25:29

first and then you can navigate a

25:31

little bit more confidently in the in

25:34

this whole world. I worked with somebody

25:36

once who was in the product org who

25:38

was good at taking

25:41

the answers from engineers and

25:44

not just saying well can that number be

25:47

smaller like no give me tell

25:49

me a smaller amount of time but

25:52

like kind of pushing on

25:54

assumptions and saying like what can we change

25:57

to make this less work can we change

25:59

something about the solution, can we change something

26:01

about the requirements, and that

26:04

back and forth, I think it

26:06

is healthy and reasonable to

26:08

get pushback from people that you deliver

26:11

estimates to. You're not infallible.

26:13

Your estimates aren't always right. Also,

26:16

you might not have thought of

26:19

every way to solve the problem. You

26:21

might not be aware of some of the business constraints. So

26:26

you hear this complaint of like, when

26:29

I give an estimate, people just tell me to make the numbers

26:31

smaller. And yeah, you don't

26:33

want to do that. But you

26:35

kind of need to be able to work with each other to say,

26:37

here's how long it would take to do this

26:40

way. If we change these

26:43

requirements, there's a way to do it in half

26:46

the time. And here's the thing we

26:48

get from it. And maybe it's half as good, but that's the right trade

26:51

off to make now. I love that. You can offer trade-offs

26:56

in response to questions instead of just

26:58

say, there is one way that will take

27:01

six months. I 100% agree.

27:03

And I think what you're

27:05

describing is a phenomenon that I've observed happening

27:08

over the last 10 to 12 years,

27:11

where engineers have kind of relegated

27:13

themselves to this position of, look, product

27:15

managers tell me what to build. I tell them how

27:17

long it's going to take, and then I build it.

27:20

But actually, that's not a good

27:23

pattern for getting the best outcomes.

27:25

And I'll give an example. We had an epiphany recently, where

27:28

my product team came to the engineering

27:31

team and said, we want to build this feature.

27:34

And they laid out a whole bunch of cool Sigma

27:36

designs. And the engineering team

27:38

went back to work and figured out how they were going to build

27:40

this, designed a comprehensive system to meet all

27:42

the requirements, started implementing it.

27:44

And then halfway through, we discovered some new scope,

27:47

and we discovered some more new scope. And then suddenly, it

27:49

was going to take a lot longer than we expected. And

27:52

the product team in the middle of this

27:54

was like, hey, we love

27:57

this feature, but I'm not sure we love

27:59

it at this

27:59

lost.

28:01

And I thought, oh, that is so

28:03

true because so often when I'm purchasing

28:06

something just as a consumer, I

28:08

think, oh, I definitely want that product, but I

28:10

don't want it at that price. Or

28:12

I want a lesser version of the product at a lower price and

28:15

that'll meet my needs just fine. But as

28:17

engineers, if we just take this and make it a one-way

28:19

street where product gives us requirements and we

28:21

just take that and produce estimates and then final

28:23

work, then there's no opportunity

28:26

to have that discussion

28:28

of do I want it at that price. And

28:31

so this was kind of a slap in the face for all of

28:33

us on the team because we were like, oh my goodness, we marched

28:35

way too far down this road because product

28:38

came back and said, actually, if it's going to

28:40

take six months, we don't want it. It's

28:42

not worth it to our customers because the opportunity

28:44

costs are so high, we have a lot of other stuff we would like to build

28:46

in that time instead. So no, no,

28:48

thank you. We just won't build it. And we were like,

28:51

oh, man, that's interesting. And so I've adopted

28:53

a different pattern

28:55

recently where instead of just

28:57

saying, okay, product gives us requirements, we'll give you

28:59

estimates. Instead product

29:02

gives us requirements and then they say

29:04

also we're willing to pay this much

29:06

for it and the pay for it currency

29:09

is in terms of engineering time, which

29:12

we have a point system for, but that doesn't matter at all. It

29:14

turns into time in the end. And

29:16

we go, okay, cool. Now we have

29:18

something we can actually work with. We can come back and we can say, well,

29:20

we could do it. We could do this set of

29:23

requirements for this price, or

29:25

we could do this reduced set for this other price and then

29:27

we go back and forth. So the estimation

29:29

process is actually iterative. It's not one and

29:31

done. And we have found so

29:34

much more value in getting

29:36

to the right product with the right economic

29:39

balance by actually having estimation

29:41

be iterative instead of just this one big

29:44

bang estimation. I love that. Yeah.

29:47

But it takes tons of trust. It does. It

29:50

does take a lot of trust. It feels

29:53

better when you do it though too. I mean, everybody's

29:55

happier when you can come

29:58

to a thing everybody wants. and

30:00

kind of keep communicating while you're building it,

30:02

how it's going. Yeah. Yeah.

30:06

It's way nicer. There's

30:08

also maybe an opportunity here

30:11

to pitch some cross-cutting

30:13

improvements where if it takes six months

30:16

to do a lot of things, is there something

30:18

you can do that would take one or two months that

30:20

would make other things take much

30:22

less time in the future? This

30:25

is kind of a common

30:27

situation caused by some technical debt

30:30

or some architecture choices. That's

30:34

also a way to justify

30:36

investing in fixing those. You can say

30:38

it'll take six months, but

30:41

if we spend four months on this other project,

30:44

things like this will take three months instead, I don't know,

30:46

whatever the numbers are. Yeah.

30:49

We've talked a lot about estimation techniques, which I think is

30:52

kind of a really common use case

30:54

that triggers this kind of situation, but

30:56

there's a more general question here, which is how

30:58

do I just explain anything that's technical

31:01

to people who aren't technical when there's all

31:03

these intricacies? I've

31:05

seen a couple of techniques that help with this a lot. First

31:08

of all, metaphors. Now, as

31:10

an engineer, I hate metaphors. I

31:14

don't want you to give me an approximation of what

31:16

the thing is. Just tell me what the thing actually is. This

31:18

database is not like a mailbox at all. I

31:21

cannot drive down the street and hit

31:23

it with a baseball bat as a teenager. I

31:27

mean, it's like, look, I don't need a metaphor. I

31:29

know what a database is. Tell me. Just

31:31

tell me it's a database. I can't. I don't.

31:34

Oh, it's a relational database? I know what that is too. Oh,

31:36

it's got foreign keys. I know what that is too. There's

31:38

no need for a metaphor here anyway, but non-engineers

31:41

hate that stuff. They love metaphors. I

31:44

have found that metaphors get purchased

31:46

in people's minds and they stick

31:48

way better for people who are not engineers.

31:51

And so I can't think of a great metaphor at the moment,

31:53

but invest some time to

31:55

explain things in metaphors because people will remember

31:58

that if you can do it. Yeah,

32:01

it's sometimes tricky to,

32:04

all good metaphors are abstractions

32:06

and fail at some level. And

32:08

it can be hard as an engineer

32:11

who's used to thinking about exactness

32:13

and correctness and completeness to say,

32:16

it's kind of like this thing. It's really not

32:18

in all these ways, but to help

32:20

you understand, it is broadly

32:23

like this thing. Even though it

32:25

breaks down if you really dig into it. They're

32:27

not going to really dig into it. They're never going to dig into it. Great.

32:30

Now they understand it more and you can say

32:32

what it's actually like under the hood. So I

32:35

found that a thing that some people have to get over

32:37

is like, but it isn't actually, it

32:39

isn't that metaphor, but close

32:41

enough is what you are aiming for. And

32:44

then make, you have to be very careful that you don't create

32:46

a metaphor that also communicates falsehoods

32:49

about the thing because people pick up

32:51

different aspects of the metaphor that like James and said, don't

32:53

apply. So it's risky.

32:56

But if you say what was

32:58

written in this question, like, oh, we've got this back

33:00

end functionality. It's transparent to users. So

33:02

no one, it's like none of that is going to stick

33:05

and won't be helpful. But if you can

33:07

say, it's kind of like an apple. There's

33:10

a peel and, but underneath the

33:12

peel is a lot of material in there and we got a lot

33:14

of material that we got to change to make

33:16

this apple peel change colors. I

33:18

don't know. I just made it up on the spot. We got

33:20

to plant the servers. Got it. Okay.

33:24

Thank you. And then we'll harvest

33:26

the bits. Yes. Yes.

33:30

Yeah. So that

33:32

helps. Another thing I would, I would, a technique

33:34

that I would suggest is make

33:37

sure that the people know that you're on their

33:39

side when you're explaining things.

33:42

And it's easy for some

33:44

people to make incorrect assumptions about

33:46

your motives when you spam them

33:48

with technical details. And

33:51

some people might, and hopefully incorrectly

33:53

assume that you are avoiding the

33:55

question by spewing

33:57

mumbo jumbo at me, like all this jargon that I don't

33:59

understand. you want to avoid

34:01

that. I like

34:04

to say what

34:06

I'm feeling and what's motivating me before

34:08

I give the information that they asked for. For

34:11

example, if someone comes to me and says, hey

34:13

Dave, what would it take to add this birthday field? Rather

34:16

than explaining all the gory details, I could say, oh,

34:19

I can see that that would be a really cool feature.

34:22

That sounds like it would be really valuable. I would

34:24

love to help find a way to deliver that as

34:26

quickly as possible without causing a lot of downstream

34:29

problems. Let's talk about how that

34:31

could work. Then you can share. Now that you've established

34:33

kind of a common goal,

34:36

now you can shift to, okay, here's

34:38

why it's going to be hard. Then at the end you can

34:40

say, man, I wish it wasn't so hard. I

34:43

really want to help you with this. But

34:46

you can see that actually this is a little more complicated

34:48

than we thought. Maybe we should go and look at

34:50

the roadmap and see if we can allocate some time

34:52

there and see what else needs to shuffle in order to make

34:54

this happen. I've just

34:56

found that by stating up front in your intentions

34:58

that you're on the same team and understanding what their

35:01

reasoning is for asking you, then

35:03

explaining it, people are much more likely to think,

35:05

yeah, this person is on my team even though they spammed

35:07

me with all their jargon. I love that. It

35:10

also avoids a failure mode, which

35:12

is people being afraid to ask

35:14

you stuff because they feel like you're going to get upset at them.

35:17

How dare you? Don't you know how much work

35:19

it will be to change this system? You

35:21

might not be meaning to communicate that, but that's a

35:23

vibe that could come across if you

35:26

react in horror and

35:28

large numbers every time someone says, can

35:30

we do this thing? Can't we just? This

35:34

is why at this very moment you need to pause

35:36

this podcast and go watch the microservices

35:39

OmegaStar YouTube video. It's

35:41

just so perfectly describing

35:44

what Jameson is saying right now. Yeah,

35:46

yeah, like if they you

35:48

want to be on their side and the way you do that is say

35:51

like we are together. You're

35:53

like both hands

35:55

on your hips, standing back, looking up at a building

35:57

like how are we going to put new gutters on this?

36:00

I'm like inside it at the top

36:02

throwing down rocks saying, go

36:04

away, stop invading my, how

36:06

dare you peasant? And it is easy

36:08

for engineers to convey that sentiment, sometimes

36:11

intentionally because engineers have been burned by people

36:14

like the manager in the previous question. Yeah,

36:16

yeah. It's like, oh, are you one of these people that's gonna make

36:19

my life suck for no reason for the next six months?

36:22

Yeah, but you don't wanna retreat

36:24

into the castle. You wanna

36:26

both be looking at the castle together. Yeah, I

36:29

like that. I like that metaphor, hands on hips, looking up

36:31

at it. Boy, how are we gonna do this together?

36:33

Yep.

36:34

Well, have we answered the question? I think so, good luck.

36:37

Tell us how it goes. Yeah. Or,

36:40

you know what, make up a story about how well

36:42

it went. If the real thing is

36:45

too disappointing. Exactly.

36:48

Oh, your advice is always so helpful,

36:51

James and Dave. Yes, men. You

36:54

know, I feel a spring in my

36:56

step, I didn't before. Yeah, me too.

36:58

And people do if they want the same spring in their

37:00

step. Go over

37:02

to softgills.audio and click the ask a

37:05

question button where you can fill out our form and tell us

37:07

what questions you have. And two

37:10

things, number one, thank you. To

37:12

everyone who does that every week. We love reading

37:14

your questions. We answer some

37:16

of them, and we promise to answer all

37:18

of them eventually. Number

37:20

two, if you would like to tell us how we did,

37:23

we would love to hear it, especially if we did

37:25

bad. Oh, that's just, that's the best. Send

37:28

us your bad outcomes from all the advice you

37:30

followed, and we will go and

37:32

we will read it on the show. And

37:34

we'll have a good laugh at Jameson's terrible advice. You

37:38

know what, I'm happy to take all the blame. Perfect.

37:41

Because I am not. It'll be my fault.

37:43

Okay, well, there is no blame. Assignable

37:46

today. Perfect.

37:47

My ego's too weak to handle it. All

37:50

right. Thank

37:52

you for listening. We'll catch you next week. Bye

37:54

bye. you