0:05

Hey everyone, just wanted to give you a

0:07

quick heads up. The

0:09

second Global Product Owner

0:11

Summit is coming soon.

0:13

You can get all

0:15

the details at bit.ly/product

0:17

owner 2024. That's

0:21

bit.ly/product owner 2024. And

0:25

it's all lowercase, all one word. Oh

0:28

and stick with us until the end of

0:30

the episode to know the dates and the

0:32

tracks that we have for you in this

0:34

year's summit. But for

0:37

now, let's dive into today's episode.

0:40

Hello everybody, welcome to our Team

0:42

Tuesday this week with Joe Schärler.

0:45

Hey Joe, welcome back. Hey,

0:47

welcome. So

0:49

Joe, on Tuesdays we talk about teams

0:52

of course and how sometimes they dig

0:54

their own holes. But before we dive

0:56

into that, do share with us what

0:58

was the book that most inspired you

1:00

in your career as a Scrum Master?

1:04

Yeah, as a manager

1:07

in remission, I'm of course also

1:09

interested in management books. And there's

1:11

one that has gotten

1:13

recommended to me by a leader

1:17

that I had when

1:19

I had my first Scrum Master job.

1:21

And that's Radical Candor by Kim Scott.

1:25

That's a really cool book that

1:27

talks about how

1:30

to lead and how to

1:32

care personally and the

1:34

impact of caring personally while

1:36

challenging things directly.

1:40

When you think about that book and what you read,

1:44

is there like a specific lesson

1:46

or a technique, something you learned

1:48

from the book that you would like to highlight

1:51

for us? Yes,

1:53

and that's how

1:55

important it is to

1:58

actually speak. and

2:01

criticize the thing that

2:03

we see. It's not about the person, it's

2:05

about what they do when they do it

2:07

wrong. Because by not telling

2:09

the kids, we're doing them a

2:11

disservice. But

2:13

we shouldn't do it in a careless

2:15

way. That's something that

2:18

Kim Scott calls obnoxious aggression.

2:21

But we should do that from

2:23

a place of caring personally,

2:27

really with compassionate candor. So

2:30

we should give feedback from

2:33

a position of caring. And

2:36

of course, I

2:38

understand the words, but I would like to

2:40

understand what those words

2:42

mean for you, Joe. How

2:44

do you show caring when

2:46

you're giving feedback that might

2:48

not necessarily be the most

2:50

positive feedback? When

2:54

applying that specifically, I tend

2:56

to use a structure that's

2:58

called SBI, that's

3:01

situation, behavior, and

3:03

impact. And then go

3:05

one step further and ask the

3:07

person, so as you did that or as

3:10

that happened, what was your intention? Because

3:13

I wanna learn about what

3:15

has happened for the person for them

3:17

to do X. Yeah,

3:20

and that's very important to understand the

3:22

other side, right? Like to understand what

3:24

might have driven someone

3:26

to do something that in your eyes was

3:29

either unexpected, maybe

3:32

aggressive, and et cetera, et

3:34

cetera. And

3:37

that for me is actually quite

3:39

critical tool for us to

3:41

learn to empathize with other people, right?

3:44

I'm reminded that, especially in the

3:46

software world, there's a lot of

3:48

different personality types and

3:50

some personality types are more

3:52

extreme on the autism spectrum,

3:54

for example. And they

3:57

have a totally different way to relate to

3:59

people. Like,

4:02

for example, they really like

4:04

rules and they get

4:06

really angry when those rules are not followed.

4:09

And it's not that they are being disrespectful,

4:11

it's that that is important for them. The

4:13

way they see the world needs

4:15

the rules to be respected. And

4:18

when we ask a question like you

4:21

said, what was your intention, we start

4:23

to understand how people think and what

4:25

is valuable, what is important for them.

4:31

Yeah. And there's also

4:33

another aspect, I think,

4:35

especially in this world where everybody's

4:37

so fond

4:39

of titles and little

4:43

abbreviations behind their name. It

4:46

is really important to the military

4:48

to be able to not just

4:51

give them titles and promote them for

4:54

them to have more money. It's

4:57

about learning how to manage your

4:59

talent and basically send

5:02

them on a growth path

5:04

and help manage their growth

5:06

versus just throwing titles at

5:08

them or having

5:10

them in a place where they shouldn't be. And

5:13

not everybody's a high performer. That's such

5:15

a bad word. But

5:17

maybe there are superstars and rock stars, which

5:19

is you need the people who are the

5:21

rocks and the team, but they have a

5:23

place to. Yeah,

5:25

absolutely. In

5:27

football terminology, that

5:30

is soccer for our friends in

5:32

the northern hemisphere of the Americas.

5:36

In football, we talk about you need

5:38

violin players, but you also need piano

5:40

carriers. Right. And

5:43

you can't get an orchestra to play if you

5:45

don't have the piano and the violins. That's

5:49

right. So Joe, of

5:51

course, today is Tuesday and we also want

5:54

to talk about teams and how sometimes they

5:56

create their own reasons

5:58

for self destruction. Now

6:00

it's not always that dramatic but

6:02

we know that teams have these

6:04

behaviors or patterns that if

6:07

left unchecked over time can develop

6:09

into something seriously bad for the

6:11

team so tell us that story.

6:14

Walk us through the context of the team so

6:16

that we know more or less you know how

6:18

big it is what is what are the key

6:21

stakeholders and actors around the team and

6:23

then walk us through those steps of

6:25

how those small little things grew and

6:27

grew and eventually became a problem for

6:29

the team. So

6:35

I had a team that

6:38

was a team of tech leads and

6:40

I was working with them on on

6:42

basically aligning the team so that they

6:45

could. Could

6:48

be more productive could could have

6:50

less boxing the software so that

6:53

they would have less friction. And

6:57

they have grown really fast.

7:01

And they didn't have a scaling

7:03

framework in place and when you

7:05

say they had grown really fast

7:07

you mean the organization had grown

7:10

really fast. Yes, right. That's right.

7:12

So they grew to more than 10 teams. In

7:17

quite short of time. The

7:21

thing was that they had sold

7:24

that by putting people

7:26

who formerly were on the team and

7:29

were working in the team on creating

7:31

their products they put them in a

7:33

position where they now have to.

7:37

Approve of changes where they have

7:39

to review changes for the decided

7:42

how it is implemented and

7:45

that was effectively taking away empowerment

7:48

from the teams. So

7:50

basically what you're saying is that they had

7:52

tried to solve the scaling problem by

7:55

creating a hierarchy of decision making

7:57

where somebody at a higher level.

8:00

leads would need to approve everything that

8:02

the team wanted to do. Yes,

8:05

that's correct. Yeah. So

8:08

what happened was there

8:11

were so many people in

8:13

the teams who were unhappy with what

8:15

was going on. They started

8:18

to not speak up anymore. And coming

8:20

back to what

8:22

I just said about Kim

8:25

Scott's radical candor, he is overhanded,

8:27

but they did not really care

8:30

about the person. It was just

8:32

about pushing for

8:34

more output

8:37

or even pushing for more results, but at

8:39

the expense of the people in the team.

8:42

And that showed up as people

8:44

crying in their perspectives that

8:47

showed up as people saying, I'm done with

8:49

my spirit. And

8:52

all those symptoms, that

8:55

was pretty tough one to deal with

8:58

for them. So

9:01

if I hear you correctly, you're saying that

9:04

the organization had scale, so

9:07

they were bigger. Then they

9:09

used a hierarchical approach

9:11

to, I would say coordination, but in

9:13

this case, it was not really, it

9:15

was just decision making. So they put

9:18

the decision up one level in the organization

9:20

where these tech leads were making decisions for

9:22

the team. And then the

9:24

team kind of gave up, they resigned from

9:27

making decisions on their own, they just gave

9:29

that all back to the manager and say,

9:31

you decide. But you're

9:33

also saying that this was perhaps the

9:35

most obvious outcome. But there were also

9:38

other things that maybe these leaders weren't

9:40

seeing, which were that

9:42

people were demotivated, disengaged, and

9:44

even crying in retrospectives. Yeah,

9:48

when taking a step back, it was

9:51

really a pattern

9:53

of this drama triangle where

9:56

you have the villains

9:58

putting people and

10:00

telling people and the people in

10:03

the team, they were

10:05

victims and they behaved like

10:07

victims. They were blaming the

10:09

circumstances instead of pulling

10:11

themselves out of the mud, maybe

10:14

also with getting help. And

10:17

whenever everything was in shambles,

10:20

the managers would rush in and

10:22

save them. And

10:25

now, okay, let's all sit down

10:27

and hands on and I'm going to help you.

10:29

So this is interesting because what

10:31

I heard you say was quite different from what you

10:34

just said. You said when the

10:36

situation was in, I guess, chaos, I don't,

10:38

that's not what you said, but when there

10:40

was a problem, then the managers would come

10:42

in and save the teams. Right.

10:46

So what I understood

10:48

earlier was that what was

10:50

happening is that the managers

10:52

were making all of the

10:54

decisions, including the decisions that

10:56

caused the problems. The

10:59

teams were not countering those decisions and

11:01

they were not making any other proposals

11:03

because they had basically resigned, right? They

11:05

gave up on contributing.

11:08

So the managers were creating the problems

11:10

that then they had to come in

11:12

and solve. And because the teams felt

11:15

so disengaged and so resigned,

11:17

they welcomed that solving,

11:19

not because they thought it was better,

11:21

but maybe because they thought that we

11:25

can't solve this ourselves

11:27

anymore. Absolutely.

11:31

So basically this, you called it the

11:34

triangle of drama, right? Like this victim

11:37

savior pattern.

11:39

So if I hear

11:42

you correctly and now coming

11:44

back into my scrum master

11:46

role, what you're

11:48

describing is a pattern by

11:51

which the teams perhaps

11:53

tried maybe even

11:56

timidly to give an

11:58

idea, but the manager always said no. always

12:00

said I know best or the managers

12:02

because there were several and

12:05

that taught the teams, educated the teams

12:07

to never give an idea and to

12:09

just wait for the manager to come

12:11

in and save them. Yes

12:15

and I think that's ultimately

12:20

a waste of potential in the team,

12:22

right? Not

12:24

just potential if you ask me

12:26

but yes potential. Yeah sure. Well

12:29

potential is probably a good word

12:32

to introduce a

12:34

manager and I'm really used to say

12:37

that word. But yeah

12:39

my judgment would be that is

12:41

a waste of the teams. I

12:43

think it is but the

12:45

way I would phrase it something I heard a long

12:48

time ago from Deming and

12:50

also people in the Toyota production

12:52

system which is the biggest waste is

12:54

the waste of a human mind and life.

12:57

And what that system created was

13:00

literally the biggest waste possible which

13:02

is all team members

13:04

were discouraged from bringing themselves

13:06

their thinking and their creativity

13:08

to work. Yeah

13:11

that's true

13:15

and one way of looking

13:18

at it is how can

13:20

you de-scale that organization

13:23

and try to get the

13:25

responsibility and the accountability

13:28

back to the team. And

13:30

do you have some ideas on how to do that? It's

13:35

a tough conversation with the leader

13:37

again and maybe this time the

13:39

conversation is a different one. It's

13:41

about hey where

13:43

is your comfort zone? Where

13:45

is your comfort zone in delegating?

13:47

Because it's about delegation of

13:50

decision making and

13:53

in an agile team we would wish

13:56

for the delegation to be at the

13:58

lowest responsibility. level

14:01

in the organization and that's at the

14:03

front line. For so

14:06

many things that leaders, especially

14:08

in an organization that grew

14:10

fast, especially in a startup

14:12

context, the leaders

14:14

who have done the job, they think they know that.

14:17

And it takes quite a while

14:20

until they realize that

14:23

yes, they have 40 people. Those

14:26

40 people will learn 40 times

14:29

as much in a day as they do because

14:31

it's 40 times 24 hours. So

14:35

at some point, you need as a

14:37

manager, as a leader, you need to

14:39

let go. And

14:41

as a scrum master, I want to go in

14:43

and have that conversation where

14:47

I use some risks of the

14:49

delegation poker from

14:52

management 3.0. Where

14:54

are you trying to find out where's your comfort level? And

14:57

now let's talk about where should

15:00

that delegation level be for

15:02

your team to be effective and

15:06

for your team to be more

15:08

productive and more independent and

15:11

more self-managing. And

15:14

how do you want to get them there?

15:16

What do you need to do as

15:19

your internal work? And

15:21

what do you need to have a

15:23

conversation about with the team? The

15:27

way I look at it is like

15:29

taking that conversation and then turning it

15:32

into, if you have

15:34

five minds on a problem, you

15:36

have five more, five times

15:38

more brain power to

15:41

find a solution. If you only have one mind

15:43

on the problem, no matter how skilled that mind

15:45

might be, you still only

15:47

have one mind on the problem.

15:50

And this is a pattern that of course,

15:52

we all have witnessed in

15:54

our organizations where somebody thinks

15:57

that they need to come up with a

15:59

solution and basically. that's not necessarily wrong,

16:01

they might need to come up with a solution,

16:04

but they don't need to do it alone. And

16:06

when you take that loneliness

16:09

and lonely decisions,

16:11

then you're also effectively discouraging

16:14

others from bringing their thinking

16:16

into the problem, therefore preventing

16:18

you, and in this

16:21

case the leader, from achieving your

16:23

potential. Because here's the thing that Scrum

16:25

Masters know very well that many leaders

16:27

don't really realize is that

16:30

our potential is the team's potential.

16:32

It's not ours as a person,

16:34

it's the team's potential. And it is

16:37

our job as leaders, whether Scrum Masters

16:39

or managers or tech leads, it is

16:41

our job to help the team reach

16:45

that potential because it reflects positively

16:47

on us too. And

16:51

there's another, there's another riff to it.

16:56

How about we think about

16:58

finding and defining the problem as

17:00

something that we should do together?

17:04

Because if the managers come in and

17:06

say, here is the problem, they

17:08

might be wrong. They

17:11

might only have a partial view of

17:13

what the actual problem is. And

17:17

that happens so often. That

17:19

was a great story. Thank you for sharing, Joe. You're

17:22

welcome. Thank you. Hi

17:26

there, agile friends. Thank you

17:28

for sticking around and listening to the

17:30

details of the Product Owner Summit, this

17:32

year's global summit dedicated to

17:34

a critical Scrum role, the Product

17:36

Owner role, of course. We'll

17:39

have some amazing keynotes and

17:41

four tracks filled with firsthand

17:43

stories and experiences for

17:45

product owners to learn more about that

17:47

critical Scrum role. The

17:50

summit will take place between April 23rd

17:53

and 25th, so book your calendars,

17:55

there will be loads of sessions for you

17:58

to attend. Keynotes

18:00

will be Dave West, the product

18:02

owner and CEO at scrum.org, one

18:05

of the largest scrum organizations in

18:07

the world. If you

18:09

want to know more, check

18:12

out the details at bit.ly/product

18:14

owner 2024. That's

18:17

all one word, all

18:20

lowercase bit.ly/ product

18:22

owner 2024. We

18:26

will also have four tracks. The

18:28

four tracks will cover cross-functional

18:30

product ownership. That's track one.

18:33

As Pixar's Ratatouille said, not

18:35

every idea can be a

18:37

great idea, but a great

18:39

idea can come from

18:42

anywhere. And this quote emphasizes the

18:44

importance of a product owner being

18:46

open to all ideas, regardless of

18:49

the source, and also challenges us

18:51

to focus on getting

18:53

good ideas from everywhere and

18:56

involving the whole team in

18:58

the product owner role

19:01

and responsibilities. The

19:04

second track is designing products

19:06

for growth, where we explore

19:08

how to craft products ready

19:10

for scalable growth, merging

19:12

practical strategies with innovation. The

19:14

idea here is to learn

19:17

to design products for

19:19

growth, whether it is sales or

19:21

customer acquisition. The

19:25

third track is know your

19:27

users, user-centric approaches for agile

19:29

development. In this track, we

19:31

learn to master user-centric techniques

19:34

in agile development, to deeply

19:36

understand customer needs and transform

19:38

insights into meaningful UX

19:41

designs that focus on

19:43

engagement and satisfaction. This

19:45

is a track ideal for innovation-focused

19:47

agile teams. And

19:49

the fourth track, one of the

19:51

most exciting tracks, in my opinion,

19:53

is product development with AI, ideas

19:56

for product owners. Not only do we

19:58

discuss about using... AI

20:00

in the products but also AI

20:03

for product owners to learn to make

20:05

a bigger impact with the help of

20:07

the AI tools that we already have.

20:10

The Product Owner Summit will also present

20:13

to you great opportunities to network with

20:15

your peers. So get your

20:17

ticket and join our Slack. You can get the

20:19

ticket and join the Slack at bit.ly/product

20:22

owner 2024. As

20:25

always we have free tickets and also

20:28

the paid tickets that help to support

20:30

these podcasts. So

20:32

check them out at

20:35

bit.ly/product owner 2024. That's

20:38

all lowercase, all one word,

20:40

product owner 2024. I'll

20:43

see you in the Summit floor.