0:00

We're going to talk about a working principle

0:02

in today's episode of Developer Tea. And

0:14

this principle is one

0:16

that is core to every agile discussion,

0:19

every lean discussion.

0:26

It's core to

0:29

another industry,

0:31

and that's the learning industry, or

0:34

specifically learning theory. And

0:37

this principle is based

0:40

on things that

0:43

come from behavioral

0:45

science and study

0:47

of psychology. The

0:50

principle is based on the idea

0:52

of feedback loops. Here's

0:55

the principle. It's very simple. Make

0:59

your feedback loops short enough that

1:02

any singular action is

1:05

cheap enough that

1:08

when you're wrong, the

1:10

value of learning outweighs

1:13

the cost of being wrong.

1:16

I'm going to say that again, because it's kind of a

1:18

long one. Make your

1:20

feedback loops short enough that

1:22

any singular action is cheap

1:24

enough that when you're wrong,

1:26

the value of learning that you get

1:28

from being wrong is

1:31

cheaper than the cost of

1:33

being wrong in the first place. Set

1:37

another way, shorten your feedback

1:40

loops so that mistakes provide

1:42

learning that outweighs the cost of

1:44

making those mistakes. There's

1:47

a very interesting underlying

1:50

structure here that I want to

1:52

expose, but I want to

1:54

focus first on the idea of shortening your

1:56

feedback loops. What does this mean exactly? It

2:00

can mean a lot of different things depending on

2:02

the context. Very importantly,

2:05

the requirement to shorten a feedback

2:07

loop in this principle is two

2:10

things. One, it allows you to, on a

2:12

regular basis, review in some

2:16

kind of retrospective way. You're looking

2:18

back at whatever decision, whatever action

2:20

you've taken and looking at measuring

2:23

some kind of result. You're

2:25

trying to understand what was the impact of the action that

2:27

I took. Matching the feedback

2:30

loop has all kinds of good effects that we're

2:32

going to talk about after our sponsor message today.

2:36

The important thing to qualify the

2:38

shortening of the feedback loop, you

2:41

need to be able to

2:43

change direction. It's

2:45

not enough just to continuously

2:47

retrospect on what you've been doing. You

2:49

need the agency to be able to

2:52

make adjustments. Otherwise, all of this ends

2:54

up being kind of a

2:56

lost cause. If

2:59

all you're doing is you're retrospectively

3:02

looking at what you

3:04

have done in the past two weeks but you

3:06

don't have any agency to

3:08

adjust your heading, you can't change

3:11

anything about what you're learning, then

3:14

it's not really fitting

3:16

the mold of shortening the

3:18

feedback loop. The feedback

3:21

loop includes, very importantly,

3:23

includes adjustment. The

3:27

parts of the feedback loop, very

3:29

briefly, the parts that you need to have

3:31

for the feedback loop to be complete. First

3:34

is an action, some

3:37

kind of action, whatever it is, decision,

3:41

maybe some kind of code deployment that you

3:43

do, whatever it is. Second

3:47

is a measurement of

3:49

that action, so

3:52

some kind of, hopefully some kind

3:54

of objective measurement in the best

3:56

case. Three, review

3:58

of that measurement. And

4:01

here we're looking to see if we believe that

4:03

the measurement is indeed tightly

4:06

cohesive with our

4:08

action for

4:12

some decision about the

4:14

decision. In other words, if

4:18

you're looking at the measurement, you

4:20

may make a decision about

4:23

the decision. That is, some kind

4:25

of judgment call about the decision

4:27

that is instructive for

4:29

the final piece, which is some

4:32

kind of adjustment before restarting

4:34

that loop. So

4:36

the adjustment acts as the

4:40

prompt for the next action. If

4:43

you're missing any of those pieces, then your feedback loop

4:45

is not complete. And

4:47

shortening just some part of

4:49

that does not actually check the box here for

4:51

this principle. We're going to take a quick sponsor

4:53

break and then we're going to come back and

4:55

talk about why. Why do we care about shortening

4:57

the feedback loop? What kinds of

4:59

effects does that have, etc. Right after

5:02

we talk

5:04

about feedback

5:07

loops. Thinking

5:09

of feedback loops, what was

5:11

the last time that you had a long

5:13

feedback loop? Because you're trying to answer a

5:16

question about your code base and you spent

5:18

hours digging through Slack channels, PRs, Jira tickets,

5:21

and wikis trying to figure

5:23

out what was going on. Or

5:25

perhaps somebody on your team has recently faced this and

5:27

then they had to ping you and you

5:30

had to bounce out of the IDE or you

5:33

got interrupted in a meeting or something

5:35

to answer this question. Maintaining

5:37

a shared understanding of the code base, it

5:39

does get harder. As

5:41

an engineering team grows and as code base grows, getting

5:44

answers to questions becomes more time consuming

5:47

when you're onboarding new team members or

5:49

working on refactoring existing projects. Our

5:52

sponsor today, Unblocked, helps solve

5:55

these problems. It

5:57

provides helpful and accurate answers to questions about your code base

5:59

and your code and seconds. Answers are specific

6:01

to your team and your

6:03

application because it complements source code

6:06

with relevant discussions from GitHub, Slack,

6:08

Jira, Notion, Confluence, and more. Like

6:11

an extended team member who never sleeps, Unblocked

6:13

is aware of every decision, every discussion,

6:16

for every part of your code base. With

6:19

Unblocked, teams are shipping faster by

6:21

spending less time digging for information

6:23

and dealing with their options. Check it out.

6:26

Unblocked. So

6:36

our principle today is

6:38

not just simply shorten your feedback

6:41

loops. That is a

6:43

good heuristic. Very

6:46

likely, most people can probably

6:48

benefit from shortening their feedback

6:50

loops. But the

6:52

economic principle here is

6:55

the one that I want to talk about,

6:57

and that is to understand why we care

6:59

about shortening our feedback loops in the first

7:01

place. And it's an

7:03

economics problem. And when

7:05

we say economics, we're not just talking about

7:07

necessarily money economics.

7:09

This could also apply to your time,

7:11

to your effort, to

7:13

your satisfaction. There are economics that

7:15

apply to all of those things. So

7:19

understanding why do we care about shortening

7:21

the cycle time? There's a couple of

7:23

reasons why we care about shortening cycle

7:25

time. First of all, one

7:28

sub-principle here is that shortening cycle

7:31

time, or rather shortening the

7:33

feedback loop time, we consider these things

7:35

very similar, cycle time and feedback loop

7:37

time. Shortening your feedback

7:40

loop time, generally speaking,

7:42

will result in a cheaper

7:44

loop. It

7:47

is a less expensive loop, a less costly

7:51

loop. And this makes intuitive

7:53

sense if you think about our

7:56

feedback loop is one day versus five

7:58

days. Well, our total loop

8:00

cost, if you want to call it that. Our

8:03

total loop cost is five times as much, in terms

8:05

of time at least, for the

8:07

five day loop versus the one day loop. Now

8:09

there's an important caveat here, and that

8:12

is that shortening your feedback loop to

8:14

too short of a period of time

8:17

will incur some kind of overhead,

8:19

you know, kind

8:22

of a curve that looks

8:24

like a J, where

8:26

the cost actually goes back up

8:29

compared to the value of the

8:31

learning that you get from

8:34

the retrospective portion of the feedback

8:36

loop. So let me

8:38

say that another way. There is a certain

8:41

length of time, there's

8:43

a certain kind of length of loop I guess,

8:47

where the loop is a little bit too short.

8:50

And so you need to lengthen the feedback loop to

8:53

the point where it's at the bottom of that

8:55

J curve. And the

8:57

bottom of the J curve here is essentially it's

9:00

the cheapest possible feedback

9:03

loop that you can have relative

9:05

to the amount of learning that

9:08

you can get out of

9:10

the feedback loop. To get the kind

9:12

of intuition for this, let's imagine

9:15

that your team commits in

9:19

sprints. Let's say

9:21

we have two teams, team A, team B.

9:23

Team A has two week sprints, and

9:26

team B has two month sprints. At

9:29

the end of every two weeks, team A is

9:32

able to do some

9:34

kind of retrospective and adjustment to whatever

9:36

their plans are, and team

9:39

B doesn't do that until the

9:41

two month mark. Going back to our

9:43

original principle here, we

9:45

can kind of see which one of these is more

9:47

risky, just naturally. In

9:50

team A's circumstance, the

9:53

risk of making a mistake in

9:55

the direction that you're going is mitigated

9:58

by the fact that you're likely to be able to do

10:00

that. to catch that mistake whenever that

10:02

two-week retrospective rolls around. You can

10:04

change direction after two weeks. However,

10:08

the risk of making a mistake for

10:10

Team B is that

10:13

it's very possible that you'll continue down

10:15

that mistake pathway and

10:17

you will not catch that for

10:19

the duration of two months. So

10:22

this could be very expensive. Now,

10:24

of course, there is a cost associated

10:26

with the interruptions

10:29

that the feedback loop reset

10:31

has. It is

10:33

kind of like the changeover process for

10:35

sprints, if you're used to using sprints,

10:38

that kind of retrospective, the

10:40

actual time that the retrospective takes.

10:43

And this is why it's important to recognize

10:45

that there is indeed a threshold

10:48

where you should have

10:50

long enough that the time

10:52

required to do that changeover is justified

10:54

by the amount of learning that you

10:58

get out of that retrospective. Now,

11:00

to be clear, I'm using terms that are

11:03

probably most familiar to folks who have practiced

11:05

Scrum, but this feedback loop

11:07

is not something that is software engineering

11:09

specific. This is something that you can

11:11

do with any kind of process, with

11:14

anything where you have

11:16

any level of uncertainty of the plan

11:18

and the pathway. You can apply the

11:20

same basic concepts, this idea that you

11:22

have some kind of action, you have

11:24

some kind of measurement to determine the

11:26

effectiveness of that action. You decide how

11:29

effective it was based on observing that

11:32

measurement and making a decision about

11:34

that. And then you decide what to do about

11:36

it. And you start that all over again.

11:38

You make some adjustment and you start the feedback

11:40

loop back over. Why is

11:42

this such an important principle? Why does

11:44

this matter so much that

11:46

we have this optimization curves,

11:49

J curve of

11:52

optimization for feedback loops? There's

11:54

a lot of reasons why it's

11:57

important to optimize for this. The most

11:59

important from a business

12:01

standpoint is risk mitigation

12:04

Especially in areas of uncertainty software

12:06

engineering tends to have a lot

12:09

of uncertainty and tends to have

12:11

this kind of pivot Need

12:14

on a regular basis. You probably want to

12:16

be doing a retrospective To

12:19

pivot and change your direction or change your

12:21

decision adjust your priorities, etc.

12:23

And so Having that

12:25

in software engineering makes a lot of sense But

12:27

I want to call out a one

12:29

that's not really intuitive That

12:31

is that one of the most important

12:34

things that this enables

12:36

is it reduces the friction into

12:38

action All right, it

12:40

reduces the friction to making a

12:42

decision and taking action on something

12:45

now this It

12:48

should be balanced out by thinking

12:50

about action bias or bias to

12:52

action Sometimes we

12:54

talk about this in a positive light

12:56

But there is a downside to the

12:58

bias to action which is that sometimes

13:00

we take an action because we don't

13:03

necessarily know what to do And we

13:05

default to using the heuristic of well

13:07

doing something is better than doing nothing.

13:09

It's not always true But

13:11

with a feedback loop we can find that out

13:14

With a short feedback loop we can find

13:17

that out and the cost of any given

13:19

action being low enough That

13:22

we learn from it and that we

13:24

gain more value out of that learning

13:26

than we did loss from the incorrect

13:28

decision This encourages

13:31

action Think

13:33

about this you want your

13:35

engineering team to be more Decisive

13:38

you want your managers to be more

13:40

decisive You want your

13:42

engineers to pick up tickets

13:44

and start working on them make decisions about

13:47

the product that they're working on You

13:50

want them to deploy code more regularly make

13:53

it so that the cost

13:55

of mistakes is very low

13:58

the cost of mistakes

14:01

being low encourages learning. This

14:04

is a direct correlation to how

14:06

often you are reviewing to ensure

14:09

that you are adjusting in response to your

14:11

mistakes. This is when the learning occurs is

14:14

in that feedback loop. If

14:16

you make your feedback loop shorter, you're much

14:18

more likely to learn. You're

14:20

much more likely to be able to make adjustments that

14:22

matter. Here's one

14:25

more kind of final bonus benefit that

14:27

we can't leave this episode without talking about. Making

14:30

your feedback loops shorter is going

14:33

to increase the quality of the messaging

14:35

within the loop. Think

14:38

about this. We've talked about the communications theory

14:40

stuff in recent episodes of the show. I'd

14:42

encourage you to go back and listen to

14:44

that to get more of a primer on

14:47

what that actually

14:51

means. But if we talk about that feedback loop

14:53

in the communications theory, if

14:56

you think about a very long feedback loop, imagine

14:59

this being like shouting

15:01

to somebody across the room in

15:05

a noisy room especially, and

15:09

shouting across a very long

15:11

distance or playing a game of

15:13

telephone. These are very

15:15

similar to very long feedback loops. A

15:18

short feedback loop has a

15:20

nearly directly provided message.

15:25

Reducing the likelihood that some random

15:28

effect, that some other confounding

15:31

variable, has entered the

15:34

picture. When we

15:36

do that measurement part of our feedback loop,

15:38

the measurement has a much higher cohesion to

15:41

reality. In other words, it's

15:43

much more correlated to some

15:45

effect from our decision. If

15:49

we're making a decision and immediately looking at

15:51

the feedback from that decision, making

15:55

an adjustment, and then repeating, we're trying

15:57

to figure out what part of our

16:00

of the decisions or the actions

16:02

that I'm taking, how are they affecting

16:04

the thing, the measurement that I care about? If

16:08

I have a long feedback loop,

16:10

then it's very possible that more

16:12

things are affecting that measurement. And

16:15

so we learn less. It's a leaky

16:19

feedback loop. And

16:21

so it's much harder to learn, it's much

16:23

harder to attach specific outcomes

16:25

to specific actions because our feedback

16:27

loop is too long, it's easily

16:29

corrupted, there's a lot of

16:31

noise in the system. So this

16:34

is an additional benefit. And also by

16:36

the way, that's part of

16:38

why shorter feedback loops are cheaper.

16:40

They are cheaper not only just

16:42

in direct spend, but they're also

16:44

cheaper because they're simply more efficient. The

16:48

system is more efficient. So

16:50

you don't have any additional waste on

16:53

top of that feedback loop. Thank you

16:56

so much for listening to another

16:58

principles of working episode of

17:00

developer tea. Once again, the simple

17:03

heuristic here for most of you is

17:05

to shorten your feedback loops. That's a

17:07

simple heuristic. There is an optimal

17:10

length for your feedback loops. And

17:13

there's multiple types of these. You

17:15

don't have to think about this just as your

17:17

sprint cadence. You can also think

17:19

about how tight can I get my feedback loops

17:22

when I'm writing code? Can I get

17:25

immediate feedback for my tests, for example,

17:27

which is a very common example to

17:29

try to tighten the feedback loop on. Thank

17:31

you so much for listening to this episode. If

17:34

you enjoyed this episode, please consider joining

17:36

the developer tea discord community or head

17:38

over to developertea.com/discord. Thank you again to

17:41

today's sponsor Unblock. Get

17:43

answers from pretty much every source

17:45

that you use from Jira to

17:47

GitHub to Confluence to Notion,

17:50

all of the above. Go and check it

17:53

out. Head over to getunblock.com. That's

17:55

getunblock.com. Thanks

17:58

so much for listening and until next time. Enjoy. our heads.