0:00

Hi, I'm Stu Miniman. I'm a

0:02

Red Hatter and I've been in the tech industry for more than 20

0:04

years. Before your episode starts, I

0:06

wanted to let you know that Red Hat has been

0:08

named a leader in the first ever Gartner

0:11

Magic Quadrant for Container Management. Check

0:13

out the post my colleague Aubrey Molluck

0:15

wrote about this very topic over on

0:17

the Red Hat blog at red.ht slash

0:20

read the blog. That's

0:22

red.ht forward slash

0:24

read the blog. Alright,

0:26

enjoy the show. IT

0:30

automation is kind of a big deal right now.

0:33

Everyone's trying to figure out how and where

0:35

they can make the best use of this

0:37

technology. We tend to think of companies deciding

0:39

on a system that works for them as

0:41

a unit, but that's not always

0:43

the case. Sometimes you

0:46

get multiple teams trying separate

0:48

solutions. That can be good

0:50

for discovery, but eventually you have to

0:52

make a decision and corporate

0:54

politics can be a real stick in the

0:56

wheel. In

1:02

this episode, Vincenzo Spasito, Director

1:04

of Intelligent Automation and Transformation

1:07

at Discover, shares how

1:09

they consolidated their efforts to build their

1:11

automation systems. It wasn't easy

1:13

to harmonize so many independent voices.

1:16

To say that it's all systematized and beautiful,

1:18

like I guarantee some internal team members would

1:21

not totally agree with that statement. I think

1:23

it's pretty solid. While

1:25

strong opinions and debate can be

1:27

intimidating, they can also be vital

1:29

elements of a company's development process.

1:32

We want people invested in this. They had

1:34

a burning passion or reason for automating to

1:36

begin with and that fire you can't replicate.

1:39

Passion, dedication, and determination help

1:41

propel development and motivate teams

1:44

to implement automation. They

1:46

see a goal and develop a vision to accomplish

1:48

it the best they can. Or,

1:51

as we've heard in previous episodes, companies

1:54

have found that passion can be a

1:56

hindrance to getting buy-in or changing culture.

1:59

Consensus can be difficult to achieve. But

2:01

when that argument is shaped into a productive

2:04

debate, it can help lead to a

2:06

better solution. That's exactly what they

2:08

do at Discover. I don't want

2:10

people just checking the box and moving along. I

2:12

don't think there's a single topic we

2:14

have where you get unanimous agreement across

2:16

the entire program that it's like, oh,

2:18

we figured it out. Because if everyone

2:20

unanimously agrees and there's no one contradicting,

2:23

I get a little concerned like, okay, is

2:26

there a devil's advocate here? Without

2:28

that debate, how do you know if you're

2:30

considering all your options to their fullest potential?

2:33

How do you know if you've thought through all

2:35

the possible problems? Discover

2:38

has fostered a culture that invites

2:40

discussion and consideration. Vincenzo

2:42

is confident that in the long run, it

2:44

has helped the company make the right technical

2:46

decisions, and that spirit of debate

2:49

doesn't happen on its own. So

2:51

we have a lot of different forums

2:53

and conversations. There's a developers

2:55

forum where it's engineers from across the

2:57

company that are putting automations in place,

3:00

and they discuss topics, ideas, thoughts. If

3:02

we're trying to decide on an enterprise

3:04

pattern, we'll actually shop it with that

3:06

group to see what are

3:08

folks' thoughts, where are the opinions, where

3:10

do we get backlash. It's a real

3:13

consideration that if a large majority of

3:15

the organization doesn't agree with the direction

3:17

we're going in, are we doing

3:19

the right thing? Again, it's an

3:21

inflection point sometimes. It's a minority opinion

3:23

that's actually the right answer. That's

3:26

the key that we're going to hear more about. Discover

3:29

has a great mechanism for people

3:31

to openly assess and share their

3:33

opinions about the benefits and drawbacks

3:35

of certain solutions. At

3:37

the end of the day, a decision is made.

3:40

Going against the majority opinion isn't

3:43

popular, but it can be

3:45

the right decision based on factors not considered

3:47

in the technical discussion. Vincenzo

3:49

explained that these discussions aren't just a

3:51

place for people to debate the finer

3:54

points of technical efficiencies. Discover's

3:56

forums are a place for dialogue.

4:00

It's a genuine conversation like, we're thinking about

4:02

this, this is our rationale, here's why we

4:04

think this is the right approach, like give

4:06

us your arguments. And in some cases we

4:08

wind up taking a different strategic direction because

4:10

of some insight that we gained from one

4:12

of those forums. If you didn't

4:15

come in and you just kind of steamrolled

4:17

the conversations as an organization, you wouldn't get

4:19

value out of doing that. It has to

4:21

be that it's a genuine and open conversation

4:23

with the team members. This

4:26

played out when Discover took its first steps

4:28

in their automation journey. Vincenza

4:30

likened it to convergent evolution,

4:32

where organisms that aren't closely

4:34

related end up independently developing

4:36

similar traits. Think of

4:39

bats and birds developing the ability to

4:41

fly, even though they're in very different

4:43

evolutionary paths. We had a

4:45

bunch of different groups in the organization saying,

4:48

we need some form of process or task

4:50

automation a few years ago. And

4:52

maybe one team is going to go work with

4:55

a vendor to try and stand that up.

4:57

Maybe one team was trying to develop something themselves

4:59

in-house to tackle the same problem. And

5:01

that's great. And the value though

5:04

that you get as a conco-operated

5:06

company organization is the economies of

5:08

scale. Having all these

5:10

teams try out different solutions was great

5:13

for the discovery process. Here's

5:15

what works for us, here's what doesn't, and

5:17

here's why. This

5:19

tapped into their passion to build and put some

5:21

stakes behind the systems they were building. But

5:24

at some point, a company needs to choose

5:26

one solution. It was time to

5:29

centralize. Some would see their

5:31

solutions become the norm, while others would

5:33

have to adapt. Centralizing

5:37

really allowed everybody to kind of like

5:40

take advantage of being a part of

5:42

one bigger system. We didn't need 17

5:44

different groups all running the platform basically

5:46

in their own despairing processes. It made

5:48

more sense for one team to run

5:50

the platform and everybody just leveraged those

5:52

licenses and kind of build in their

5:55

own delivery space. But it didn't necessarily

5:57

make sense to centralize all development activity.

8:00

original process gets what

8:02

they need to build the automation system. Discover's

8:05

Advisory Council considered all these questions

8:07

and many more when looking at

8:09

the options. And as a

8:11

group, they picked the most viable option to

8:13

build a framework that everyone would then adopt.

8:17

The next step was to go from a recommendation

8:19

to a formal structure. The

8:22

first step was, identify yourselves as a

8:24

program. This is a company-wide initiative and

8:27

we are going to collectively come up

8:29

with the answers. If you

8:31

view yourself as a bunch of disparate groups trying

8:33

to work together, you're never going to come up

8:35

with those common elements because it wouldn't

8:37

even occur to you that those are common

8:39

elements. You would view them as your own

8:41

individual problems to solve. So first is the

8:43

vision, then comes the pragmatic approach

8:46

to breaking down the vision. Once you get all

8:48

the elements, then it's just a matter of figuring

8:50

out what's the most effective and efficient way of

8:52

handling this. All together

8:54

now, we love collaboration! Discover

8:58

created a formal structure from which

9:00

to organize and connect their automation

9:02

efforts. From there, they've worked

9:05

to identify collective issues and systematize

9:07

how to solve them. When

9:13

we return, we hear all

9:15

about the framework they've developed to

9:17

consider and complete automation projects. Discover

9:25

put a framework in place for how

9:27

to assess an opportunity, consider

9:29

the risks, and build a solution

9:31

that addresses any issues. And

9:33

that framework relies on what they like

9:35

to call, inflection points. These

9:39

inflection points are a series of moments

9:41

in the timeline of a project that

9:43

the teams use to determine whether to

9:45

continue with automation and what kind of

9:47

resources the project is going to need. Centralization

9:50

has helped discover systematize, to a

9:53

certain extent, a common set

9:55

of questions that apply to most potential

9:57

projects. Bencenzo describes a few

9:59

of these. common inflection points at

10:01

the evaluation stage. Great, fantastic. Like, that is

10:03

a great idea to automate, but like we

10:05

need to know a few more things about

10:07

it. What exactly are these reports

10:09

that you're reconciling? You know, if it winds

10:11

up being just an internal system output to

10:13

make sure that a batch ran overnight, like

10:16

cool, if not a huge amount of risk

10:18

with that data, that's all internal stuff. So

10:20

if it's a low-risk process, it's pretty

10:22

safe to continue. But some

10:25

projects touch data that's more sensitive,

10:27

accounting statements, credit dispute management, and

10:29

more. Before even thinking

10:32

about making changes to those sorts of

10:34

systems, Discover ironed out its

10:36

workflow so they knew what questions to

10:38

ask and how the answers would affect

10:40

outcome. That way, when they

10:43

do make any changes, they've considered and

10:45

planned for any associated risks. So

10:47

even just in that first question of like, what

10:50

are you working with? What is this

10:52

process described to us what you're doing?

10:54

We've already found possibly three different levels

10:56

of risk associated with how we're going

10:58

to develop this thing, and it'll weed

11:00

you down different paths. There's

11:04

a protocol for following each of these paths.

11:07

It helps move things along, rather

11:09

than coming up with custom plans from scratch

11:11

at the start of each potential project. It's

11:14

about asking the right questions in the

11:16

right moments. And experience has

11:18

helped develop that set of questions and the

11:20

knowledge of when to ask them. But

11:23

these inflection points don't just determine how

11:25

each project will proceed. There

11:27

will be inflection points where it's just like,

11:29

hey, not today, right? Like the environment we've

11:31

got the, you know, the scrutiny that we're

11:33

under. Also just, can we safely protect this

11:36

data along the path? It's like, if we

11:38

can't, then no, do not pass go, do

11:40

not collect 200, please continue doing your, you

11:42

know, your manual process. But a lot of

11:44

times it really just tells us like, how

11:46

difficult is this problem to solve and how

11:48

many folks are we going to have to

11:51

bring in to kind of figure this thing

11:53

out? Discover

11:55

wants to automate as many processes

11:57

as they can and benefit from

11:59

the efficiencies. The

14:01

way Discover modeled their teams encourages

14:03

mobility and actually makes use

14:05

of their team members' distinct backgrounds. They

14:08

call it the hub and spoke model. The

14:10

hub we view is like, or what

14:13

some organizations might call like a platform

14:15

team. It runs the central stack that

14:17

actually maintains a lot of the licenses

14:19

we use for the automation. It's not

14:21

just a wooden tool, it's a combination

14:24

of tools that we put in place

14:26

for every step of the process. So

14:28

the elements we need for actually designing

14:30

the automations themselves, putting the automations in

14:32

production, how do we monitor those activities.

14:35

So they kind of manage stuff

14:37

that every engineer would need. And

14:40

then when you actually get to the

14:42

spoke teams, they're dedicated product teams within

14:44

each of the core lines of business

14:47

who go out and actually develop the

14:49

automation. Remember

14:52

earlier when we were talking about not

14:54

centralizing everything and leaving the implementations

14:56

to those closer to the product?

14:59

The hub and spoke model is how Discover

15:01

achieves that. The spoke

15:03

teams are able to specialize, work

15:06

with specific business partners and product teams,

15:08

and identify unique opportunities to

15:11

automate that a generalist team

15:13

might not have the expertise to identify.

15:18

As specialized as the spoke teams are, they

15:20

still share a common set of activities,

15:22

processes, and trends. The solutions

15:24

they build get reported back to the hub,

15:27

and in many cases, redistributed to

15:29

other spoke teams. It's this

15:31

really fun relationship between I'm trying to build

15:33

something, this group needs this, you know, in

15:35

the next three weeks, and we've never had

15:38

a human in the loop process before. Great,

15:41

cool. I think other teams are going to need

15:43

human in the loop. Like other spoke teams, is

15:45

this also something they'll go, yeah, we turned away

15:48

like seven use cases because we didn't have this.

15:50

That's kind of how the hub spoke relationship works.

15:52

We have the teams out there going and deploying,

15:54

and we have the platform team that kind of

15:57

maintains the structure. the

16:00

platform, helps develop the tools, and provides

16:02

technical support to the spoke teams when

16:05

needed. The spoke teams do the

16:07

work of building out the solutions, following

16:09

a playbook of how to assess and

16:11

take on potential automation projects. There's

16:14

a fair amount of training and mentorship to

16:16

get people up to speed. And

16:19

though the spoke teams may have deep knowledge of

16:21

the products they're working with, signing

16:23

on to a specific spoke team doesn't mean they

16:25

need to stay there. It's quite the

16:28

opposite. Some amount of mobility is

16:30

encouraged. Even a talent perspective,

16:32

conversations back and forth to make sure there's

16:34

growth and opportunity between the groups. Like, okay,

16:36

it looks like someone on the engineering team

16:38

would really love to see how this applies

16:40

to the entirety of the company. Great, maybe

16:43

that's a time for them to shift into

16:45

the hub team for a little while, help

16:47

us build out two or three cool new

16:49

capabilities and functionality. And

16:51

then maybe if they want to go

16:53

back into the delivery world, they can.

16:55

And it's a nice relationship between kind

16:57

of taking the enterprise view versus the

16:59

individualized view, moving between spoke teams to

17:01

get different areas of context from

17:03

like a product perspective. So really

17:06

at like a technology, a process

17:08

and a people level, the hub

17:10

spoke relationship has this like dialogue

17:12

of what should be centralized, what

17:14

should be decentralized, and how do

17:16

we both get the best efficiency

17:18

of each situation. People

17:21

move around. They learn from each other.

17:23

They grow. According to

17:25

Vincenzo, it's also a great way to keep

17:27

people engaged with their work. And

17:30

it helps foster a closely knit community.

17:33

Also from a problem solving perspective, that's probably

17:35

one of the most untapped things that we're

17:37

trying to add a little bit more structure

17:40

to. You solve a problem in your situation

17:42

in your unique case. And you think that

17:44

it is a unique case until you start

17:46

looking around and seeing like, oh,

17:48

no, actually, everyone deals with that problem. I've

17:50

actually solved something that 17 other teams would

17:53

benefit from. The

18:00

solutions they've built can be quickly applied to

18:02

their new situation. Having

18:04

a number of spoke teams available helps spread

18:06

the workload and keeps the work close

18:08

to the product. That doesn't mean

18:10

the spoke teams cover every aspect of the business.

18:13

But the number of spoke teams isn't static either.

18:17

It definitely plateaued a little bit

18:19

there. Like you kind of understood

18:21

after the first two or three,

18:23

okay, where are other like processes

18:25

like this happening within the organization

18:27

and what really is the leftover

18:30

opportunity. We kind of talked with a

18:32

few of the leaders and we kind of preempted where

18:34

we thought spokes would go. In

18:36

the places where they didn't plan to have a spoke

18:38

team, the hub picked up any projects

18:40

that might come up, especially when

18:42

they were complex problems that span multiple

18:45

products. When requests from

18:47

a certain uncovered part of the business start

18:49

to stack up, it's time to consider

18:51

an addition. They handle teams

18:53

that don't have a spoke team but

18:56

do need automation and make sense for

18:58

them to automate. So what we

19:00

would wind up seeing is like, actually, we're getting a ton

19:03

of requests coming over from this product group. Like, it

19:05

might make sense for them just to get a dedicated

19:07

resource. Like let's go talk with a director over there

19:09

and see if they're ready to stand the

19:11

same. In the first few years

19:13

of the program, that scenario played

19:16

out many times until it

19:18

didn't anymore. They

19:21

found a sort of equilibrium where the spokes

19:23

were handling requests at a good pace and

19:25

the number of teams hit a platoon. But

19:28

nothing stands still forever. I

19:30

think we're about to, you know, if I

19:32

can stretch the metaphor, it's like we're about

19:34

to like add on to the wheel again,

19:36

because as we find more capabilities, it opens

19:39

up new problems and maybe groups that may

19:41

not have had the more generalized task automation

19:43

needs will have a consolidated set

19:45

of problems with these more advanced technologies we're

19:47

putting in place. If

19:49

their expertise grows in tandem with the

19:52

sophistication of the systems they're creating, they're

19:55

finding they can handle more complicated challenges

19:57

than before. Maybe Even

19:59

some of those. Previously blot with as

20:01

the risk was too high the

20:03

time. All of that was possible

20:05

thanks to the judicious application. A

20:07

centralization A nasty get everyone working

20:10

together and sharing their work but

20:12

not too much to lose out

20:14

on the benefits of individual agency

20:16

and discovery. That's not an easy

20:18

balance to find. But

20:20

thanks to their common set of tools, a

20:23

standardized framework, and the freedom to move around,

20:25

it sure seems like it's been worth the

20:27

effort for Discover. That

20:35

for soon to. Of code comments

20:37

but don't fret. Season three is

20:39

coming soon. Stay tuned for more

20:41

words and with some for me

20:44

your superlative host Jamie Parker and

20:46

our guess to of course. You

20:51

can read more at Red. Head. That pub says

20:53

code payments protest or visit redhat.com

20:55

to find out more. About our

20:58

automation solutions. Many. Thanks to Vincent's

21:00

us to sito for being our guest and

21:02

thank you for joining us. This

21:05

episode was produced by Johann

21:07

Philippine Some Fun, Caroline Craighead

21:10

and Brit Seminar or audio

21:12

engineer is Robyn Edgar. The

21:14

audio team includes Lead Day

21:16

Stephanie Wunderlich, Mike Essar. Nick

21:19

Burns, Aaron Williamson, Karen Chain

21:21

Jared Oats Rachel or

21:23

to carry to Silver Mirror

21:26

Cyril. Ocean Matthews say

21:28

Stroud Ellis, Trouble See and Victoria

21:30

Lion. I'm Jedi Parker and this

21:32

has been towed, comments and original

21:34

thought. Kids from with him.