►
Description
Scaling the Portfolio Wall
Guest Speaker: Christen McLemore (Red Hat)
OpenShift Commons Briefing
abstract: Alignment is something we frequently discuss but often frustratingly fail to truly achieve. Let's breakdown the planning steps that are truly critical for creating alignment across the company and the teams and how the Portfolio is a financial anchor that can steady or sink your business. We will review key concepts, take real scenarios from you and do breakout sessions to build a plan that you can take back to work immediately.
For upcoming briefings: https://commons.openshift.org/events.htm
#PMI
B
B
Most
of
my
life
is
actually
centered
around
doing
things
that
I
love
the
work
that
I
was
doing
as
a
consultant
prior
to
having
my
own
business
was
also
in
the
agile
space,
and
it's
not
everything
that
I
do.
I
don't
do
everything
really
focused
around
agile,
but
I
I
happen
to
like
it
because
it
is
so
flexible
and
it
allows
people
to
make
more
real-time
just-in-time
decisions.
B
I
was
attracted
to
it
probably
back
in
the
early
2000s
when
I
went
to
my
first
certified
scrum
master
class.
While
I
was
working
at
america
online
on
the
east
coast.
Since
then,
I've
done
quite
a
bit
of
work
with
managing
teams
who
were
doing
agile,
implementations
to
doing
large-scale
fortune.
100
and
500
transformational
plans
and
executing
on
how
to
get
better
at
what
they
were
doing
and
a
lot
of
companies
start
at
different
levels,
sometimes
ground
up
with
the
teams,
sometimes
top
down
with
the
management
or
leadership.
B
B
I'm
also
a
registered
pet
therapy
team
with
my
dog
here
in
the
photo
ripley
who,
unfortunately,
she
passed
away
the
first
week
that
I
joined
red
hat,
but
I
just
adopted
another
great
pyrenees
who's,
probably
behind
me
chewing
on
something
she's
not
supposed
to
be
chewing
on,
but
she's
being
quiet
about
it.
So
we're
gonna
ignore
it,
and
then
I
do
agile
stuff
on
the
side
too.
B
But
it's
like
a
list
of
things
to
do,
but
it's
not
connected
to
anything
that
we
understand
and
that
is
actually,
unfortunately,
very
common
across
the
u.s,
at
least
for
the
different
companies
that
I've
worked
with,
that
trying
to
build
a
portfolio
process
and
identify
the
people
who
are
responsible
for
that
portfolio
is
often
a
misstep,
it's
sort
of
forgotten
or
as
they're
trying
to
do
something
in
a
more
agile
way.
There's
a
clash
between
traditional
project
management
and
portfolio
management
and
what
agile
is
trying
to
do
so.
B
First
question
is:
do
you
know
what
these
acronyms
are
pmo
dpmo
projects,
programs
and
portfolios?
Does
everyone
feel
like
oh
yeah?
I
know
what
these
mean
and
we
can
use
show
hands
or
whatever
other
mechanism
we
have
in
blue
jeans,
even
in
the
chat
which
I'm
not
necessarily
following,
but
I
think
diane
can
probably
interject
if
you
see
any
comments
about
it.
B
So
if
you
were
to
go
to
the
experts
and
when
I
say
experts,
I'm
talking
about
google
and
alexa,
when
you
ask
hey
alexa
what
is
a
pmo,
then
you
will
find
things
like
this.
Pmo
is
supposed
to
be
project
management.
Office.
Ppmo
is
project
portfolio
management
office
projects
are
temporary
supposed
to
undertake
some
sort
of
unique
product
service
results.
B
B
B
Customer
input,
okay,
market
awareness,
possibly
strategy,
yes,
philippe,
that's
it!
We
need
strategy.
If
we
don't
have
a
strategy,
then
how
do
we
know?
All
of
these
projects
are
actually
connected?
If
we
start
with
a
strategy,
then
we're
talking
about
now
that
we
have
it?
What
do
we
need
to
do?
What
are
the
different
parts
of
the
business
or
the
organization
that
need
to
take
action?
Not
every
strategic
goal
impacts
every
single
organization
in
your
company.
Sometimes
they
do,
but
not
always
so
to
scale
across
the
organization.
B
B
B
B
So
it's
obvious
that
the
child
knows
that
there's
a
goal:
there's
a
strategy
here
now
watch
even
from
behind,
without
seeing
the
facial
expressions
there's
a
little
bit
of
a
let's
try
this.
No
that's
not
going
to
work
I'll,
try
something
else,
and
that
would
be
what
we
would
call
a
stretch
goal
and
she
made
it
and
she's
still
going
getting
some
reassurance.
B
B
B
D
B
D
D
B
B
B
The
idea
is
that
we
don't
all
know
how
to
do
this
so
perfectly
that
nothing
ever
fails
that
everything
always
happens
perfectly,
and
I
think
that
is
something
that
is
somehow
permeated
the
entire
world.
Frankly,
that
if
you
try
something,
it
has
to
be
right,
the
first
time-
and
that
is
so
not
true-
and
it
is,
it
is
so
beyond
what
we
should
be
expecting
from
each
other.
We
don't
expect
perfection,
we
expect
to
give
it
a
shot
cry
and
then
see
what
worked
and
what
didn't
work
and
then
fix
it.
B
It's
funny
that
the
video
we
showed
of
the
success
was
a
toddler
who
probably
can't
even
complete
full
sentences
quite
yet,
and
yet
still
had
the
tenacity
to
continue
to
go
and
find
a
new
place
to
put
her
footing
or
a
new
place
to
put
her
hands
and
then
got
to
the
top
and
didn't
really
make
a
big
deal
and
probably
went
right
back
down
to
to
do
it
again.
So
there's
a
tenacity
that
that
young
people
have
that.
B
I
wish
more
of
us
in
the
in
the
adult
world
frankly
had
is,
if
you
have
permission
to
fail,
and
we
have
permission
to
give
something,
a
try.
But
to
keep
going.
And
that's
really
the
message
I
was
hoping
to
share
with
all
of
you
and
then
to
also
acknowledge
what
are
the
challenges
that
you
face
when
you
are
trying
to
build
a
portfolio
process
within
your
company
or
even,
if
you're,
just
trying
to
build
a
portfolio
within
your
line
of
business
within
red
hat.
B
So
if
you
can,
if
you're
not
familiar
with
mentimeter,
you
can
either
go
to
this
website
and
plug
in
this
code.
But
I
would
actually
recommend
it:
just
take
your
phone
open
up
the
camera,
app
on
your
phone
and
point
it
at
the
screen,
and
it
will
automatically
notice
this
barcode
and
give
you
a
link
to
open
it
up
in
whatever
browser
that
your
phone
has
plug
in
what
you
think
the
challenges
are,
and
I
think
this
thing
is
actually
giving
me
a
different
look.
So
I
apologize.
I
just
checked
this.
B
B
So
now
think
about
the
way
that
your
organization
is
structured
and
we
go
back
to
the
question
that's
closed.
What
do
you
think
are
the
challenges
you
experience
right
now
within
red
hat,
to
build
out
a
solid
portfolio
process
that
manages
the
intake
priorities
and
strategies
down
through
to
the
teams
that
are
actually
doing
the
day-to-day
activity
and
plug
those
into
the.
B
B
B
B
So
these
are
common
right.
I,
how
many
of
you
worked
at
other
companies
where
they
had
all
of
this
perfectly
aligned,
and
they
were
absolutely
no
problems,
probably
not
too
many,
and
if
you
did
have
that,
it's
probably
because
they
did
a
lot
of
work
to
get
there.
So
when
we
talk
about
how
do
you
get
there?
That's
really
what
I
was
kind
of
hoping
to
share
with
you.
B
B
B
For
this
event,
it's
usually
a
day
or
two,
and
we
need
to
interview
them
ahead
of
time
to
find
out
what
is
it
that
they
believe
will
describe
success
of
implementing
a
portfolio
as
well
as
what
challenges
they
anticipate
so
that
you
as
an
organizer
or
facilitator
you're
able
to
pull
this
together
and
then
communicate
the
agendas
ahead
of
time
so
that
they're,
aware
of
what
are
the
necessary
people?
Excuse
me
who
are
the
necessary
people
and
what
are
the
necessary
steps
that
need
to
be
addressed
while
they're
in
the
session?
B
You
want
decision
makers,
you
don't
want
folks
who
are
just
going
to
show
up
as
a
proxy
and
then
not
be
able
to
make
any
decisions,
otherwise
you're
going
to
end
up
with
multiple
meetings,
one
after
the
other.
The
session
itself
typically
would
include
the
next
four
things
on
the
list.
One
is
mapping
out
the
value
stream
which,
if
you're
not
familiar
with
that
karen
martin-
and
I
can't
remember
the
other
author's
name-
wrote
a
really
effective
book
about
value
stream
mapping.
B
It
is
not
necessarily
tied
directly
to
agile,
but
is
a
very
complementary
tool
for
the
a
lot
of
agile
folks.
It
is
meant
to,
in
this
session,
to
map
out
what
they
currently
do,
not
what
they
want
to
do.
They're
going
to
definitely
want
to
start
correcting
things
and
making
changes
and
fixing
all
the
problems
that
they
already
know
they
have,
but
as
a
facilitator,
you
want
to
kind
of
pull
that
in
and
say
parking
lot
those
great
ideas.
B
It's
definitely
something
you
want
to
look
at,
but
right
now
we're
trying
to
map
out
what
do
we
currently
do?
How
does
work
come
in?
What
are
the
triggers
for
new
work
and
ideas
who
provides
those
and
where
do
they
come
from?
What
tools
do
they
use
to
communicate?
Is
it
close
to
notes?
Is
it
jira?
Is
it
aha?
Is
it
a
spreadsheet?
Is
it
some
sort
of
a
customer
service
application
that
you
use
where
customers
submit
their
requests
through
that
pipeline,
that
plus
all
the
steps
to?
B
So
what
is
that
cycle
for
an
end
to
end
for
the
company,
or
if
it's
a
subset
of
the
company,
the
organization
or
the
business
unit,
then
we
want
to
identify
what
are
the
decision
making
models
we
will
use
to
just
say
you
know,
there's
500
things
we
just
got.
We
can't
do
all
of
them
right
now.
So
what
decision-making
model
are
we
using
to
say
yes
or
no
or
probably
just
not
yet
do
all
of
those
requests
coming
in?
B
It
also
has
an
economic
element
to
it,
which
is
why
we
call
it
an
economic
decision
making
model,
and
then
we
also
evaluate
all
of
the
work
against
the
effort
to
get
the
work
done
and
then
capture
the
current
work.
That's
already
in
flight,
in
what
we
call
a
portfolio
kanban,
so
that
then
they
can
see.
Here's
all
the
work
that
you
already
have
in
flight
right
now
and
let's
go
back
and
look
at
all
the
decisions
that
we
just
made
about
what
we
should
say
yes
or
no
to
and
apply
them
to
stuff.
B
That's
in
flight.
Should
we
have
started
those
or
should
we
actually
cancel
those
projects,
possibly
or
delay
them,
because
there's
some
more
important
things
that
we've
already
identified
using
the
economic
decision
making
model
that
tells
us
that
we
actually
made
some
incorrect
choices
on
what
we
decided
to
put
money
into
and
then
the
close
is
a
consensus
on
all
the
attendees,
the
cadence
and
the
agenda
for
any
portfolio
review
meetings
that
you're
going
to
have
in
the
future.
B
I'm
not
going
to
go
into
detail
and
I
believe
daniel
is
going
to
share
a
pdf
version
of
the
whole
site,
so
you'll
be
able
to
get
to
this
later,
but
highlighted
all
the
things
that
will
change
based
on
what
your
organization
wants
to
focus
on.
So
those
interviews
that
I
mentioned
earlier,
those
are
inputs
into
the
development
of
this
kickoff
summary.
So
what
are
the
key
findings
that
I
found
during
the
interviews?
B
These
are
the
things
that
we
want
to
address
by
having
portfolio
planning
put
in
place
and
then
the
limit
of
scope
of.
What's
in
or
out,
we
lifts
that
and
then
the
cadence
of
meetings
is
proposed,
that
we
have
business
theory
and
quarterly
planning
and
system
demos.
Things
like
that,
and
you
would
refine
that
to
the
language
within
your
own
company-
and
I
admit
these
are
terms
that
I've
used
for
probably
the
last
eight
years
in
red
hat.
B
I've
already
seen
that
there's
different
terms
that
we
use
so
obviously
we
would
have
to
change
that
internally
now
going
back
to
who
gets
invited
depending
on
the
span
of
portfolio
management's
responsibility,
if
you're
doing
a
whole
company,
then
you
can
imagine
a
lot
of
these
folks
need
to
be
included.
If
you're
only
doing
a
subset
of
the
company,
then
you
might
not
want
such
high
level.
B
You
know
this
operation
person
off
and
sit
in
the
room
with
them
and
they'll
come
up
with
it.
The
purpose
is
not
just
to
map
out
the
value
stream,
but
also
to
get
agreement
from
all
of
those
individuals
that
that
is
actually
the
way
that
work
does
get
done,
because
what
often
happens
is
by
writing
it
out
and
starting
to
to
pull
out
certain
things
about.
B
B
I've
actually
had
a
vp
literally
say
those
very
words,
because
he
was
recognizing
that
he
was
not
aware
that
we
were
doing
a
certain
step
as
part
of
the
intake
of
new
work,
but
we
all
agreed
yeah.
We
don't
like
that.
We
do
this
either,
but
that
is
actually
what
we're
asking
people
to
do
today
so
immediately
they
were
recognizing
not
only
break
places
where
they
could
improve
it,
but
they
were
also
recognizing
the
disparity
of
their
understanding,
of
how
work
got
done.
B
So,
there's
the
value
of
common
understanding
and
visibility
about
the
whole
process
across
the
company
or
within
the
division,
and
a
very,
very
honest
discussion
about
well
that
that
should
change.
We
can
be
so
much
more
efficient
if
we
remove
that
step
or
make
it
simplified.
So,
even
while
we're
only
talking
about
the,
as
is
process
we're
also
starting
to
see,
people
go
oh
yeah
now.
I
know
why
it
takes
so
long
to
get
stuff
done
here,
because
we're
doing
all
these
extra
steps
or
we're
doing
things
that
are
just
not
that
efficient.
A
What
well
it's
it's
in,
but
I'm
just
gonna
ask
pose
it.
This
way
is
that
since
joining
red
hat,
most
of
the
red
hat
projects
and
products
also
incorporate
people
external
to
red
hat,
not
just
you
know,
bret
hat
pms
and
engineers
and
sales,
or
you
know,
and
even
customers,
but
this
whole
other
layer
of
upstream
projects
and
trying
to
incorporate
how
we,
how
we
do
all
that.
A
B
Well,
I
say
my
first
initial
reaction
is:
it
has
not
changed
because
I
think
there's
a
lot
of
similarities
between
what
red
hat
does
and
this
particular
class
customer
that
I
worked
for
worked
with.
Excuse
me
if
you'll
notice,
here
it's
a
little
bit
hard
to
read,
but
there's
a
section
here
of
triggers.
We
have
business
themes
where
they
are
generating
their
own
work
and
ideas
what
they
think
their
customers
will
want,
but
they
also
have
a
pipeline,
but
they
called
it
their
innovation
pipeline,
and
this
was
where
customers
were
telling.
B
Sales
people
or
customers
were
doing
their
own
requests
to
us
directly
and
saying.
Well,
we
want
this,
and
so
we
would
compare
what
does
the
business
internally
to
the
company
think
the
customers
want
and
what
is
the
customer
actually
saying
they
want,
and
in
that
way
I
can
compare
that
to
what
we
do
at
red
health
we've
got
an
internally
product
management,
driven
backlog
and
strategic
goals,
but
we
also
have
an
upstream
community.
B
That's
also
telling
us
something
possibly
different,
but
they
are
getting
merged
at
some
point,
which
is
exactly
what
this
company
needed
to
do.
Is
they
had
a
separate
team
of
developers
that
were
mostly
architects
and
senior
designers
who
were
taking
all
of
the
customer
requests,
pulling
together
design
solutions,
putting
together
project
plans
and
then
throwing
over
the
press
to
the
same
team?
Who
was
working
on
the
business
themes
and
saying
here's
some
more
work,
but
they
were
never
coordinating
the
priority
of
that
pipeline
and
the
business
pipeline.
B
A
Yeah,
I
I
think
it's
an
interesting
stage
in
the
pipeline,
so
you
were
talking
about
customers
there
and
customer
interests
and
upstream
interest
at
being
at
the
sort
of
the
front
end
or
the
beginning
of
that
set
of
arrows.
But
it's
the
work
effort
like
trying
to
coordinate
with
upstream
projects
to
get
the
things
that
you
need
done
up
there
that
that
I
think,
impacts
this
in
a
in
an
interesting
way
or
just
adds
another
layer
to
it.
A
B
Did
we
actually
achieve
a
percentage
of
those
goals?
Did
we
make
progress
because
usually
strategic
things
take
several
years
to
accomplish
the
goal
that
was
designed
as
an
outcome,
so
we're
managing
that
on
a
cadence
as
well?
So
as
throughput
is
coming
through,
we
take
themes
and
we
measure
and
how
is
that
progressing
over
time?
Are
we
reaching
those
goals?
The
economic
decision
making
model
is
also
measured
through
value
measurements,
so
we
are
establishing
different
type
of
measurements
to
say.
B
Well,
we
thought
that
if
we
made
this
decision
that
we
would
increase
or
decrease
a
certain
elements
within
our
business
like
lower
our
cost
or
increase
our
customer
value
or
whatever
those
are
so
now
we're
measuring
that
over
time
budget,
then
we
also
look
at
what
we
said.
We
were
going
to
spend
x
number
of
dollars.
How
much
did
we
actually
spend
and
how
much
did
we
acquire
or
what
was
our
revenue?
So
this
is
the
roi
piece
of
it.
B
So
those
are
the
two
sides
that
are
always
being
measured
and
if
the
things
on
the
left
change
over
time,
then
we
also
have
to
reevaluate
our
metrics
and
where
we
expect
our
thresholds
to
be,
and
now
I'm
going
to
focus
on
the
center
part,
which
is
the
guts
of
it.
This
is
the
sausage
making.
So
we
took
the
value
stream
and
we
said
okay
well.
This
is
what
we
do
and
we
did
collapse
the
value
stream
of
the
customer
and
community
into
the
pipeline
instead
of
having
them
as
two
separate
ones.
B
B
We
wanted
this
to
be
able
to
turn
on
even
when
people
were
moving
and
getting
promoted
and
all
of
that,
and
then
we
also
started
to
look
at
the
tooling
aspect
and
the
data
of
how
are
we
communicating
that
information
and
what
level
of
detail
is
necessary
at
each
stage
of
the
process,
while
it's
going
through
the
stream.
So
when
we're
still
talking
to
customers
who's
involved
and
what
are
they
expected
to
develop?
B
And
this
particular
company
was
using
rally
software
some
of
their
development
teams
were
using
jira,
and
so
we
said
well,
there's
a
lot
of
different
language
across
those
different
tools,
but
within
this
time
frame
we
should
at
least
have
the
initiatives
confirmed
and
approved,
as
well
as
any
of
the
other
things
that
are
in
other
systems
called
projects
or
epics
or
a
contract.
Because
this
this
particular
customer
did
a
lot
of
work
that
was
contract-based.
They
were
contracted
to
do
work
and
they
were
driving
some
of
their
own
internal
work.
B
B
Once
you
get
to
this
process,
then
for
each
of
the
initiatives
or
capabilities
we
have
how
many
features
are
involved
and
the
user
stories
and
so
forth
for
the
portfolio
kanban
system,
we
needed
to
also
map
out.
How
are
those
being
managed?
What
are
the
flows
like
when
it
starts
in
as
an
idea?
Then
it
becomes
a
business
case.
Then
prioritize.
Then
we
build
it.
B
Then
we
start
measuring
it,
and
then
we
archive
it
because
we're
done,
but
this
is
at
the
initiative
level,
which
is
why
it's
an
I
something
I
number
12.
I
number
the
idea.
Member
number
13..
The
second
step
is
once
we
get
to
capabilities,
then
we're
breaking
those
initiatives
down
into
capabilities.
B
B
So
we
said
all
right:
what
are
the
economic
decision-making
models
and
frameworks
that
we
want
to
use
consistently
for
any
new
thing
that
comes
through
the
system,
and
so
they
developed
their
own,
and
I
had
to
block
out
some
of
this
because
it
was
confidential
with
this
particular
customer
with
some
names
and
things
like
that.
But
they
also
associated
that
with
what
their
budget
and
within
their
area,
they
actually
had
a
certain
dollar
amount
that
was
allocated
for
that
business
unit,
and
then
they
had
to
decide
of
that
dollar
amount.
B
Then
we
sat
down
and
looked
at
prioritization,
because
what
we
were
finding
is
that
there
were
so
many
projects
in
flight
that
nothing
was
getting
done
sound
familiar.
Not
not.
It
is
a
very
common
problem,
so
we
said
all
right:
we're
going
to
have
the
business
and
technologies
actually
separate
into
two
groups.
B
First,
we're
going
to
ask
the
business
to
stand
in
front
of
this
big,
huge
poster
and
we
didn't
have
enough
wall
space.
We
had
to
put
it
on
a
table
and
the
left
line.
The
y
axis
is
the
low
to
high
cost
or
effort
to
get
something
done,
and
the
bottom
x
axis
from
left
to
right
is
low
to
high
value
to
the
business.
B
So
we
asked
the
business.
Could
you
take
all
of
these
projects,
which
are
represented
by
those
jelly
stickies
and
you're,
just
going
to
move
them
from
left
to
right
and
compare
them
relative
value-wise
move
it
all
the
way
to
the
right?
If
it's
the
highest
value
project
on
this
whole
list,
move
it
to
the
left
by
comparison
of
how
much
lower
in
value
that
is,
but
you
cannot
move
it
up
or
down.
You
can
only
move
it
left
or
right.
B
B
B
Do
we
want
to
cancel
any
of
those,
because
if
we
compare
where
they
showed
up
on
the
priority
list
and
what
we
actually
are
doing,
sometimes
we
were
identifying
in
almost
50
percent
of
the
time
we
were
identifying
that
it
was
a
lot
of
work
that
we
really
never
should
have
started
that
we
should
have
delayed
and
done
later,
because
the
value
was
not
higher.
The
effort
was
was
too
high
compared
to
the
wire.
B
Now
we
also
added
these,
and
some
people
use
exit
criteria
as
a
term,
and
we
did
not
use
that
for
this
exercise.
We
just
said
that
when
a
card
at
the
initiative,
level
or
project
level
is
currently
let's
say
in
in
progress
like
people
are
building
solutions
for
it
right
now.
That
means
that
all
of
these
things
are
being
done
and
all
of
these
things
have
already
been
done,
so
it
was
basically
like
a
checklist
of
before
we
can
pull
it
into
the
next
state
of
the
portfolio
kanban.
B
We
need
to
make
sure
that
these
things
are
finished
and
we
also
identify
templates
and
documentation
and
people
who
were
responsible
for
doing
those
things
as
it
progressed
through
the
kanban
system,
and
I
won't
go
into
a
ton
of
detail.
But
if
you're
familiar
with
condom
kanban
excuse
me
and
the
pull
system
it
is
based
on,
you
never
push
something
into
a
state.
You
wait
until
the
people
who
are
in
that
state
have
the
capacity
to
pull
it.
B
B
Oh,
I'm
actually
in
the
portfolio
area,
and
I
need
to
do
some
of
this
stuff
and
to
talk
about
what
are
those
challenges
that
you're
facing
and
what
part
of
the
excuse
me
portfolio,
planning
steps
that
we've
described
so
far
might
be
helpful
to
you,
and
why
would
they
be
helpful
to
you
and
knowing
we
have
a
smaller
audience?
We
don't
necessarily
need
to
go
into
separate
breakout
rooms,
but
if
you,
if
we
have
the
capability
to
turn
on
microphones
for
folks
and
just
have
a
discussion
together,
that
would
be
great.
A
Now
that
this
is
great
and
I'll
offer
to
anyone
here,
if
you
want
to
unmute
yourselves
and
and
join
in
this
conversation,
now
we'll
take
a
a
short
pause
here
before
we
go
on
with
the
presentation,
but
this
has
been
it's
really
interesting.
I've
done
this
so
many
iterations
of
this
this
task,
and
so
it's
really
nice
to
see
it
laid
out
this
way.
A
So
thanks
christian
for
taking
the
time
to
do
this
today
and
it
there's
so
many
different
roles
that
I
think
I've
played
over
the
ages
at
red
hat
and
at
other
companies
in
this.
But
now
in
a
lot
of
ways,
I'm
just
the
observer,
because
I'm
on
the
open
source
side
of
things,
so
I'm
seeing
you
know
I
get
to
bring
the
upstream
story
to
to
the
table
when
we
do
these
portfolio
exercises,
but
a
lot
of
the
times,
I'm
just
really
the
person,
that's
trying
to
understand
how
the
decisions
were
made.
B
A
Listening
to
people
are
being
a
little
shy
here.
Let
me
see
in
the
chat
if
anyone's
asking,
adding
anything,
but
I
think
they're
being
a
little
shy
today.
So
that's,
I
think,
that's
one.
One
of
the
things
is
there's
actually
quite
a
few
red
hatters
on
which
is
really
fun,
because
this
is
also
an
external
facing
thing.
So
sometimes
you
get
the
interplay
of
that.
But
I
think
today
is
very
tilting
towards
the
red
hat
side
and
a
lot
of
folks,
I
think,
are
just
learning
these
processes
too.
A
C
Mac,
thank
you
very
much
for
the
structured
insight
to
to
how
how
you
know
we
need
to
think
about
this
right
and
I
think,
linking
back
to
some
of
the
questions
that
came
up
earlier
around
how
this
pertains
to
red,
hat
and
and
so,
and
you
know,
especially
with
community
being
the
open
source
roots
driving
a
different
model
for
development
for
most
of
our
life
right.
But
then
I
I
do
want
to
sort
of
like
give
the
other
side
of
it.
C
You
know,
if
you
take
something,
that's
like
cf
or
something
like
that
that
we
acquired
six
seven
years
ago
and
where
that
is
right
now,
you
know
has
probably
shifted
in
terms
of
what
the
level
of
community
influences
in
that
versus
when
we
first
acquired
that
project
right.
So
so
I
think
it
it
varies.
C
The
emphasis
on
and
then
figure
out
what
we
need
to
do
in
terms
of
negotiating
and
modulating
what
we
can
do
with
the
things
that
less
out
of
the
control
right,
the
community
will
will
also
gravitate
towards
things
that
are
of
higher
value
if,
if
that
is
where
they
know,
that
the
emphasis
long-term
emphasis
or
strategic
direction
is,
I
think
the
challenge,
though,
is
articulating
it
in
terms
of
strategic
imperative
that
is
backed
by
economic
data,
or
you
know,
market
opportunity,
data
or
or
addressable
market.
You
know
and
so
on.
C
What
we
are
doing
is
very
much
trying
to
link
existing
work
that
we
do
into
what
we
think
the
strategy
is
and
trying
to
build,
an
association
which
is
not
clearly
think
it's
almost
like.
Maybe
it
should
have
been
an
output
of
the
planning
process,
but
just
as
we
have
rolled
up
the
stuff
that
is
in
the
community
and
made
products
out
of
it,
we
are
caught
in
that
transitional
phase
right.
So
at
the
top
level,
where
portfolio
planning
is
done.
B
About
having
visibility
to
prioritization
in
the
process
of
doing
that,
that
was
one
of
the
really
important
things
that
I
started
to
think
about
for
readout
is
we're
open
source
for
so
many
things?
Why
wouldn't
we
be
open
source
on
our
own
decision
making
models
on
when
we
decide
to
do
something
or
not
to
do
something,
so
I
think
not
only
internally
should
that
be
well
known
and
understood,
but
possibly
even
externally,.
A
Yeah,
I
think
it's
an
interesting
thing,
because
we
have
the
open
organization
book
and
we
have
an
open
culture
and
a
lot
of
this.
Luckily,
for
me
from
the
position
where
I'm
in
community
development
but
tied
into
the
cloud
platform
bu
very
tightly,
I
get
to
see
all
of
that
like,
but
I
and-
and
I
think
I'm
a
bit
of
an
influencer
in
some
of
that
stuff.
A
I'm
not
sure
I
didn't
think
I
saw
my
title
in
any
of
those
lists,
but
I
think
my
voice
got
gets,
hurt
a
lot
and
I
get
to
see
a
lot
of
that
decision.
But
it's
it's
it's
interesting.
I
think
one
of
the
biggest
challenges
we
have
at
red
hat
is
there
are
we
have
a
huge
number
of
products
and
a
number
of
portfolios
and
the
decision-making
process?
It's
a
hard
thing
to
communicate,
you
know
and
it
and
that
I
think
that's
the
that's.
A
The
biggest
challenge
I
have
is
is
one
keeping
up
with.
What's
in
all
the
portfolios,
let
alone
why
we're
there
and
I
think
every
large
organization
has
that
I
don't
think
that's
unique
at
all
to
red
hat,
but
the
communication
process
is.
It's
sometimes
overwhelming
delete.
How
many
things
that
you
know
we're
talking
about
edge
now
and
then
there's
a
whole
conversation
about
data
science
and
there's.
You
know
you
know
the
telco
space
and
then
there's
healthcare
and
and
then
there's
just
the
core
infrastructure
pieces.
A
B
We
did
the
spartan
race
in
northern
virginia
quite
a
few
years
ago
as
a
team
building
event
and
as
you
can
see
the
before
and
after
we
still
have
smiles,
we
didn't
all
go
at
the
same
pace.
We
all
finished
at
the
end
of
the
race
at
different
times,
but
we
were
all
at
the
finish
line
for
each
other,
and
that
is
the
part
that
makes
this
work
there's
so
many
cliches
out
there.
B
You
know
teamwork
makes
the
dream,
work
and
people
just
roll
their
eyes
like
okay,
but
if
we
don't
figure
out
how
to
do
this
together,
it
won't
feel
like
we
cross
the
finish
line
and
reach
the
goals
together.
So
that's
the
most
important
thing
that
I've
learned
is
that
don't
try
to
push
through
all
this
stuff.
B
On
your
own
gather,
other
people,
who
also
want
to
make
a
change,
work
and
figure
out
a
way
to
do
it
together
and
bring
all
the
right
folks
into
the
room,
which
is
why
I
listed
so
many
people
across
the
organization,
because
the
tendency
is
that
we
just
do
engineering.
We
just
do
business
and
engineer,
but
we
forget
marketing
sales
and
finance
have
a
part
of
this,
we're
all
part
of
a
family
trying
to
make
a
business
run
and
without
considering
their
needs
and
what
they
will
do
to
support
us.
B
The
give
and
take
that
we
give
to
each
other.
It
won't
work
well,
we'll
end
up
forgetting
stuff,
we'll
end
up
taking
some
missteps.
So
if
you
can
start
out
grabbing
the
right
folks
and
saying
I
want
to
partner
with
you,
I
want
you
to
be
part
of
this
team.
So
we
can
make
this
work
together.
A
lot
more
people
will
be
willing
to
start
having
the
tough
discussions
about
what
we
need
to
change.
A
And
also
also
add
in
is-
and
it's
not
just
an
internal
focus
too,
with
at
red
hat,
we
have
partners
and
gsis
and
isvs
and
end
users
and
open
source
upstream
people.
So
it
makes
the
network
of
communications
about
this
and
the
people
that
we're
incorporating
in
these
conversations
really
sometimes
it's
quite
amazing,
the
things
that
we
can
do
together
when
we
we
do
collaborate
and
we
do
it
in
the
open
and
and
we
have
a
common
language.
A
So
I
am
incredibly
appreciative
of
you
taking
the
time
today
to
walk
us
through
all
of
this
and
and
to
leap
for
joining
us
and
and
making
this
happen.
So
this
is.
This
has
been
really
interesting
for
me
and
and
I'm
just
going
to
leave
with
one
anecdote
when
we
here
in
british
columbia
and
canada
do
this
mud
race
we
have
to
carry.
We
have
to
carry
a
k
so.
A
D
A
All
right
and
I
put
the
link
to
the
slides
in
the
chat,
so
if
you,
if
anyone's
looking
for
them
there
and
I'll
post
this
video
up
on
our
youtube
channel
shortly
as
well
and
tweet
it
out
under
the
openshift
commons
twitter
handle
later
today.
So
thanks
again,
everybody
have
a
wonderful
weekend-
everybody,
I
hope,
you're
recuperating
from
kubecon
eu.
I
know
chris
short,
our
producer,
a
big
shout
out
to
him
because
he's
been
up
since
I
think
3
a.m
or
4
a.m.
A
My
time,
I
don't
even
know,
I
think,
he's
in
central
time
zone,
I'm
in
pacific
we've
all
been
had
a
great
week.
This
was
a
great
way
to
end
kubecon
week.
So
perfect,
perfect.
We
learned
so
much
at
kubecon
and
now
we
know
how
to
put
it
together
and
use
it
to
influence
the
portfolio
development
process.