►
From YouTube: Is it Worth it? Four Metrics to Determine Platform Efficiency - Michael Stahnke, CircleCI
Description
Is it Worth it? Four Metrics to Determine Platform Efficiency - Michael Stahnke, CircleCI
Speakers: Michael Stahnke
A successful platform is normally measured by adoption and usage — important metrics to track to ensure you’re serving your internal customers. From a business perspective, though, you also need to show that your platform delivers a worthy return on the investment your organization makes to build, run, maintain and evolve it. Join CircleCI's VP, Platform, Mike Stahnke in this talk as he walks attendees through four key metrics to determine platform ROI and ways to put them into practice.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
So
if
you
want
to
talk
to
me
there
you
can,
as
I
was
thinking
about
the
title
more,
it
was
it's
not
about
silos.
It's
a
barn
and
I
think
that
really
what
we
want
to
talk
about
is
how
you
concentrate
your
efficiencies
into
a
platform
organization
and
then
how
you
know
if
that
organization
is
effective
or
working
properly,
and
so
for
the
last
number
of
years,
I've
worked
on
the
state
of
devops
reports
with
with
puppet.
A
I
was
at
puppet
for
a
while
and
then,
as
I
went
to
circleci,
I
kept
doing
this
work
with
them
and
we're
currently
working
on
the
2021
state
of
devops
report
right
now.
But
you
know
for
the
last
several
years
we've
had
kind
of
hey.
We
want
to
break
down
silos,
we
want
to
have
high
levels
of
collaboration,
and
we
want
to
you
know,
just
kind
of
do
a
lot
of
the
classic
things.
We've
talked
about
with
devops,
fast
feedback
loops
and
really
what
we
get
to
is
a
lot
of
times.
A
There's
there's
a
an
image
of
this
silo
just
falling
over,
and
you
know
it's
breaking
down
silos
right,
and
so
we
come
back
to
this.
This
is
kind
of
a
classic
devops
image,
but
then
you
then
comes
along
this
thing
with
team
topologies
and
what
you
end
up.
Seeing
is
a
bunch
of
stream
aligned
teams
emerging,
and
so
this
is
kind
of
having
to
do
with
value
stream
mapping
and
having
teams
that
are
out
there
delivering
value
to
a
user,
whether
that's
a
user
internal
to
your
company
or
external
to
your
company.
A
It
really
doesn't
make
a
ton
of
difference,
but
you
have
a
team
whose
sole
purpose
is
to
get
value
out
there.
They
usually
have
a
product
manager.
Perhaps
they
have
a
designer,
and
so
how
do
you
support
those
teams?
And
that's
really
what
we'll
start
talking
about
and
as
you
do,
those
what
you
start
to
realize
is
collaboration
is
really
expensive.
A
If
you
have
multiple
teams
that
all
need
to
work
together
or
have
things
happen
in
lockstep
to
get
things
out
to
customers
a
lot
of
times
that
coordination
effort
is
more
expensive
than
the
engineering
effort
or
than
the
design
effort
or
the
other
technical
efforts
that
have
to
have
to
occur.
Collaboration
is
expensive
because
it's
often
real
time,
it's
often
ad
hoc
and
not
repeatable,
and
it's
often
not
very
scalable,
and
so
that
seems
feels
a
little
antithetical
to
kind
of
the
devops
stuff.
A
We've
been
talking
about
where
it's
breaking
down
silos
and
working
together
and
developing
a
shared
sense
of
trust
or
empathy,
but
they're,
not
necessarily
totally
antithetical.
It
just
feels
a
little
bit
out
of
place
when
you
write
it
like
this.
That
collaboration
is
really
expensive.
Collaboration
is
very
expensive,
it
doesn't
mean
it's
not
valuable,
but
it
is
expensive,
and
so
you
come
back
to
this.
Well,
if
we're
gonna
break
down
silos,
what
are
we
really
doing?
A
A
Well,
basically,
what
we
want
to
do
is
extract
common
functions.
So
if
each
one
of
those
boxes
on
the
right
is
a
streamlined
team
or
a
streamlined
service,
perhaps
you
know
there's
there's
commonalities
in
almost
every
service,
and
so
if
you
can
pull
those
out
and
put
them
in
a
platform,
it
means
that
each
streamlined
team
doesn't
have
to
rebuild
them
themselves.
A
And
then
you
kind
of
get
okay
well,
what's
the
roi
of
this
platform
organization
and
I'll
go
back
a
little
bit?
If
this
is
a
platform
team
and
there's,
you
know,
we've
extracted
some
common
things
out
there.
So
now
we
have
a
team
operating
in
a
platform
mode
where
we
have
some
things
that
are
available,
perhaps
via
self-service
or
reuse,
for
streamline
teams.
How
would
I
measure
the
roi
of
that?
A
How
would
I
know
it's
working,
and
so
basically,
what
you
can
do
is
take
the
sum
of
all
your
platform
team
payroll
and
divide
by
something
let's
get
into
what
the
something
would
be,
because
we
know
what
the
we,
what
we
don't
want
is
to
get
into
a
cost
center
mentality.
If
your
platform,
engineering
or
your
common,
tooling
or
common
areas
turn
into
a
cost
center,
you
end
up
kind
of
back
with
the.
A
I
don't
also
want
to
think
of
it
as
subsidies
or
a
common
tax,
and
this
you'll
see
this
a
lot
with
security
organizations.
It's
just
like
well
for
every
n
number
of
engineers
we
have
to
have
x
number
of
security
engineers,
and
that's
just
the
tax
that
everybody
pays.
That's
really
not
a
way
that
I'd
like
to
operate.
I'd
like
to
have
much
more
thought
and
formula
and
systems
thinking
behind
that
than
just
let's
pay
our
taxes.
A
A
Well,
what's
the
business
actively
willing
to
invest
in
is
kind
of
the
question
that
I
start
to
ask
if
we're
actively
willing
to
invest
in
it,
it's
something
that
the
business
has
already
seen
value
in,
and
so
now
we
can
start
to
talk
about
in
terms
of
returns
that
they
really
want.
So
one
of
the
things
that
I
do
inside
of
my
platform
organization
is
that
we
haven't
seen.
A
We
have
teams
that
consult
on
security
and
you
know
single,
say,
consult
what
does
that
really
mean
well,
it
could
be
that
this
is
where
the
expertise
in
security
is
really
housed,
the
specialization,
the
specialized
knowledge,
and
so
when
we
have
a
new
service
to
get
built
or
new
capabilities,
we
have
some
people
that
go.
You
know,
review
the
architecture,
do
some
threat
modeling
partner
with
them
those
high
collaborative
activities?
So
that's
a
little
bit
of
security
as
a
service.
A
We
provide
a
lot
on
cost
management
so
right
now
we
do
a
lot
with
cogs
and
that's
the
cost
of
goods
sold
and
that
rolls
up
into
gross
margin
and
every
financial
professional
is
going
to
care
about
that.
And
so
I
can
talk
about
roi
in
terms
of
here's.
What
we
spend
to
run
our
platform,
here's,
how
we've
optimized
it
or
here's
how
we're
going
to
optimize
in
the
future
or
here's
decisions
or
trade-offs
we've
made
in
terms
of
you
know,
buying
more
compute
capacity
versus
maybe
reserving
compute
capacity
or
things
like
that.
A
Architecting
things
differently
drive,
availability.
Every
every
online
service
is
usually
very
interested
in
what
their
availability
numbers
are.
You
want
to
make
sure
that
your
availability
is
above
the
threshold
of
your
customers
of
pain,
the
threshold
of
pain
for
your
customers.
We
want
to
make
sure
that
our
customers
can
feel
good
and
feel
promised,
and
they
they
want
to
know
that
they're
they
have
confidence
in
the
service
that
they're
purchasing
and
I
think
most
online
services
and
online.
You
know
companies
would
agree
with
that.
A
We
also
do
a
lot
with
common
infrastructure,
and
so
we'll
take
a
bunch
of
things
and
just
pull
them
back
and
make
it
so
that
every
stream
aligned
team
doesn't
have
to
figure
out
how
they're
going
to
run
their
own
monitoring
or
their
own
container
scheduler
or
their
own
egress
and
ingress
network
handling
and
routing
and
traffic,
shaping
you
know,
or
exception
draining
or
metrics,
and
and
that's
just
common
infrastructure
stuff.
We
pulled
back
into
a
common
infrastructure
team,
because
these
are
shared
services
that
everybody
should
be
using
and
we'd.
A
A
We
also
do
a
lot
with
common
libraries
and
to
me
this
is
where
the
difference
between
kind
of
the
beginning
of
the
abstraction
of
a
platform
and
then
kind
of
the
second
order
cut
starts
to
happen
is
when,
when
you
start
building
tools
that
application
developers
can
use
to
assemble
and
build
out
their
own
services
faster.
Whether
this
is
you
know,
connection
handling
for
for
queues
or
it's
got
database
components
or
tracing
for
observability
all
the
way
through
in
a
common
way
or
being
able
to
update
dependencies
and
services
in
a
uniform
automatic
mode.
A
So
one
of
the
things
you
want
to
figure
out
is
how
much
does
availability
really
cost?
If
you
want
to
convert
that
into
roi?
Well,
you
can
take
your
annual
revenue
and
divide
it
by
time
and
you
can
figure
out
how
much
your
a
minute
costs,
and
so,
if
you're,
a
hundred
million
dollar
company,
you
divide
by
the
number
of
minutes
in
a
year
and
you
get
roughly
190
dollars
a
minute
is
what
it
costs
and
downtime
now
are
you
losing
all
190?
A
Every
time
you
have
a
minute
of
downtime,
you
know
obviously
there's
some
new
ones
and
some
variants
there,
but
you
can
start
to
build
formulas
kind
of
directionally
correct
with
that
all
models
are
flawed.
We
just
hope
that
this
one
is
less
flaw
than
some
of
the
others
that
have
been
used
to
kind
of
calculate
the
back
end
of
platform.
A
A
Do
you
know
how
you're
driving
that
for
to
me,
this
is
the
most
straightforward
one
and,
as
coming
from
a
you
know,
a
strongly
technical
background
where
finance
and
accounting
wasn't
my
thing.
It
was
interesting
that
this
was
the
one
that
I
think
we
were
able
to
get
a
handle
on
kind
of
the
fastest.
From
an
roi
perspective.
It
makes
sense
because
it's
already
in
the
same
common
language
of
currency,
but
from
just
how
did
you
handle
it?
And
how
do
you
manage
it?
A
There
was
a
lot
of
new
things
to
figure
out,
and
so
we
have
a
lot
of
jobs
that
go
through
and
parse
out.
You
know
our
detailed
aws
bill
and
our
other
cloud
bills
and
they'll
parse
it
into
something
and
every
day
we'll
get
a
cost
structure
and
say:
hey
here's
what
it
costs
this
week
or
here's
what
it
costs
today,
here's
what
here's,
how
many
credits
were
burned,
which
is
basically
the
account
of
workload
happening
on
it
here,
was
our
cost
per
that
credit.
A
You
know,
for
every
single
credit
burn
here
was
our
spend
in
ec2
and
s3
and
other
things
and
basically
day
over
day,
and
sometimes
in
about
four
hour
increments.
We
can
figure
out
if
something's,
really
out
of
whack,
you
know,
do
we
have
an
auto
scaler
that
accidentally
scaled
up
like
past,
where
we
should
have,
or
did
we
forget
to
turn
off
a
bunch
of
things?
We
can
get
alerts
on
that
pretty
quickly
and
therefore
we
can
keep
our
cost
in
control
pretty
easily.
A
We
also
do
a
lot
of
designing
of
systems
where
we
look
at
okay.
We
think
we
can
lower
the
cost
of
this
over
time,
as
we
understand
the
workload
more
or
we
can
move
it
into
this
or
we
can
buy
pre-reserved
instances.
If
we
understand
exactly
how
it's
going
to
work,
you
know
or
bigger,
commits
with
our
cloud
vendors,
then
you
get
into
security
and
I
think
security
is
a
lot
more
challenging
than
cogs,
because
it
doesn't
have
this
immediate
dollar
impact.
A
The
only
thing
you
can
really
tell
about
security
is:
if
people
say
are
you
good
at
security?
If
the
answer
is
no,
you
have
a
very
clear
answer.
If
the
answer
is
yes,
you
actually
have
much
more
challenging
problems
ahead
of
you
or,
if
you're,
not
sure,
it's
challenging,
because
you
just
don't
know
how
do
you
show
that
you're
really
good
at
security
that
that's
just
not
the
simplest
thing
in
the
world?
What
we
actually
do
in
a
lot
of
cases
from
an
roi
standpoint,
is
map
security
onto
compliance
from
a
technical
standpoint.
A
I
don't
like
doing
this
because
I
don't
think
security
and
compliance
are
the
same
thing
at
all,
but
from
an
outbound
capability
talking
to
the
rest
of
the
business.
Compliance
is
something
that
is
much
more
understood
if
you're,
not
compliant,
say
with
saktu
or
with
sarbanes-oxley
or
whatever
your
mandates
are
in
your
industry
or
country.
A
So
what
we
try
and
do
is
we
maps
compliance
and
security
requests
into
like
revenue
enablement,
and
so
we
have
a
system
where
we
have
a
lot
of
tracking
about
what's
going
on
for
prospects
and
existing
customers
and
people
that
are
free
and
if
they
mention
that
they
want
to
see
our
security,
documentation
or
security
reports
or
they
ask
security
questions,
we
can
track
that.
And
so
then
you
can
start
to
say:
okay,
well,
here's
my
customers
that
are
asking
about
these
things
and
here's
the
dates.
They
requested
those
things.
A
And
then
you
know
here's
the
revenue
that
comes
in
from
those
and
then
you
can
try
and
build
a
proportional
model
and
say
well,
if
there's
security
and
you
know,
would
we
have
been
able
to
land
this
revenue
without
having
these
types
of
compliance
reports?
Would
we
have
been
able
to
renew
this
customer
without
these
types
of
compliance
reports?
Again,
you
can
build
a
model
around
this.
A
Is
it
simple,
not
necessarily,
but
I
think
it's
a
lot
farther
than
most
people
go
trying
to
dig
into
security
and
just
say:
well,
it's
a
tax
that
everybody
pays.
I
think
here
is.
We
know
that
we
gain
customers,
because
we
have
more
compliance
demonstrated
than
what
some
of
our
competitors
do,
and
we
see
that
on
a
regular
basis,
and
so
we
continue
to
raise
the
bar
and
what
are
we
compliant
for
because
it
allows
us
to
attract
a
different
type
or
a
new
type
of
customer,
and
then
you
get
into
developer
productivity.
A
Well,
one
of
the
things
I
really
like
to
look
at
is
merged
prs
per
dev
in
over
a
period
of
time,
and
I
like
to
put
the
trend
there,
not
necessarily
the
raw
number,
but
is
that
going
up?
Because
if
it
used
to
be
that
you
know
the
average
developer
is,
is
merging
3.2
pull
requests
a
week
and
then
later
gives
it
to
3.5.
A
Is
that
because
we've
done
some
work
to
make
merging
more
easy,
more
easy?
Is
it
because
they've
realized
they're
being
measured
here
in
their
game?
They're
gamifying?
It
is
it
because
you
know
we
just
had
a
bunch
of
people
that
had
time
off
and
they
came
back
and
worked
a
lot
harder.
It's
hard
to
know
for
sure.
That's
why
you
want
to
look
at
a
trend
over
a
longer
period
of
time.
A
One
of
my
favorite
things
about
this
metric
is
that
if
you
attempt
to
gamify
it,
what
ends
up
happening
is
people
break
their
work
into
smaller
and
smaller
chunks,
which
is
pretty
much
what
I've
been
asking
people
to
do
since
I've
been
an
engineering
leader,
so
you're
welcome
to
gamify
how
many
prs
you
merge
time
to
your
fifth
pr.
For
us,
this
is
kind
of
an
onboarding
metric
and
usually
the
first
few
prs
are
kind
of
not
that
meaningful
to
the
business.
A
Sometimes
it's
like
adding
an
ssh
key
into
a
terraform
repository
things
like
that.
I
want
to
get
to
your
fifth
pr,
where
I
imagine
that
business
is
starting
to
happen,
you're,
starting
to
make
meaningful
commits
the
time
to
the
first
time
you
can
do.
An
on-call
shift
is
another
thing,
that's
kind
of
an
onboarding
metric,
and
then
we
track
investment
types
for
all
of
our
different
tickets,
whether
it's
a
bug
or
a
feature
or
maintenance.
A
A
So
what
makes
the
streamline
team
more
effective
is
kind
of
the
next
question
as
you
get
to
developer
productivity,
and
it's
really
about
leverage,
and
so
it's
can
you
give
your?
Can
you
give
multiple
teams
leverage
by
centralizing?
Something?
Can
I
get
leverage
on
tooling
one
of
the
things
that
we
do?
Is
we
try
and
bake
it
so
that
when
you
want
to
update
your
dependencies
for
services,
that's
done
more
or
less
by
one
team.
They
update
a
common
thing.
It
opens
up
the
pull
requests.
A
The
pull
requests
automatically
get
run
through
tests
and
even
in
the
pull
request,
it'll
say
so
far.
This
has
worked
on
12
of
you
know,
say:
60
micro
services
in
our
platform.
Well
now
it's
up
to
14
and
they're
good,
and
now
it's
up
to
18,
and
so
you
can
kind
of
get
a
read
of
how?
How
successful
has
this
set
of
changes
been
leverage
on
libraries?
Can
we
make
sure
that
every
time
we
update
a
library
to
give
it
new
capabilities
that
everybody
else
gets
that
leverage?
A
You
know
it
used
to
be
that
perhaps
on
rabbitmq
we
weren't
doing
publish
confirms
properly,
and
then
we
fixed
that
and
now
everybody
can
do
publish
confirms
properly,
because
that's
in
the
library
that
everybody's
using
to
talk
to
rabbitmq
leverage
on
process.
This
is
this
is
an
interesting
one,
where
I
think
you
can
actually
unlock
a
lot
going
forward.
But
the
more
you
have
a
common
engineering
process
and
not
let
every
team
do
their
own
thing.
A
You
can
kind
of
start
to
instrument
those
processes
and
start
to
figure
out
where
the
optimizations
are
across
them.
So
if
more
teams
develop
in
a
more
similar
way,
it
does
a
few
things
one
is
it
lets
you
instrument
things
and
understand
them,
but
the
other
thing
it
does
is:
if
you
need
to
have
people
or
people
want
to
change
jobs,
they
want
to
change
teams,
they
want
to
change
what
area
they're
working
in.
They
can
become
successful
more
quickly
because
it's
a
similar
process.
They
don't
have
to
unlearn
everything.
A
So
one
of
the
things
I
look
at
is
kind
of
hiring
roi
is
you
know
I
have
these
streamlined
teams
on
the
on
the
right
and
then
platform
teams
on
the
left.
So
if
we
have
say
10,
streamlined
teams-
and
I
have
two
platform
teams
supporting
these-
you
know
I
can
hire
a
person
on
a
streamline
team.
So
I
hire
one
person
and
now
I've
made
one
team
out
of
10
better
well.
A
The
other
option
here
is:
I
could
hire
somebody
in
platform
and
now
I've
made
10
teams,
maybe
20
percent,
better,
maybe
10
percent,
better,
maybe
5
percent
better.
But
that's
a
larger
distribution
of
improvement
than
what
it
was
to
get
one
person
totally.
You
know
up
to
speed
here
and
I
guess
by
my
stick
figure
drawings.
I
would
assume
that's
about
20
of
a
person,
because
one
leg
it's
about
20,
if
I'm
doing
my
stick
figure
math
correctly.
A
So
that's
kind
of
the
question
that
I
keep
asking
is:
when
is
it
more
effective
to
hire
enablement
or
efficiency
engineers
than
to
hire
those
streamlined
engineers
and
that's
kind
of
a
balance
we
have?
And
honestly,
our
platform
engineering
team
has
been
growing
pretty
quickly
because
we're
still
seeing
value
in
growing
that
side
of
the
business.
A
So
once
you
have
a
platform
there's
a
few
other
things
you
want
to
know
in
terms
of
roi,
do
developers
like
using
it
and
you
can
kind
of
just
get
their
sentiment
pretty
easily
like
I'm
happy
or
I'm
meh,
or
I'm
pretty
angry
or
not
happy
about
it,
and
you
can
also
measure
adoption
like.
Are
people
choosing
to
use
this
or
are
they
going
around
it?
Are
they
building
their
own
connection
pooling?
Are
they
building
their
own
libraries
to
do
things?
A
A
So
then
we
get
into
what
does
the
platform
provide
and
how
do
we
do
we
mandate
people
use
it
or
do
we
just
ask
them
to
use
it,
and
so
that's
kind
of
the
paved
roads
versus
water,
slides
argument
paved
roads.
You
know.
Yes,
it's
really
easy.
If
you
drive
down
this
road
because
it's
nice
and
paved
it's
been
cleared
for
you,
you
can
go
off
and
do
your
own
thing
if
you
really
want
to.
But
you
know
there
might
be
a
lot
of
rocks,
bumps
hills,
other
hazards
on
a
water
slide.
A
A
You
make
the
right
things,
the
good
things,
easy
and
people
will
likely
choose
them
and,
as
you
see,
if
a
bunch
of
people
are
starting
to
blaze,
a
new
trail,
you
know
many
teams
are
saying
well
we've
added
this
this
feature.
Well,
then,
maybe
you
can
pull
it
back
into
platform
and
make
it
available
to
everybody
else
and
just
pave
that
little
trail
that
they've
been
making.
A
So
in
a
quick
summary
here.
What
we
have
are
the
pillars
of
platform
and
to
me
those
break
down
to
availability,
cogs,
security
and
developer
productivity,
and
that's
really
what
I
want
to
show
for
roi,
because
the
business
has
proven
that
they
want
to
invest
in
those
things.
On
the
side,
you
kind
of
have
your
platform
as
a
product
to
metrics
which
are
developer,
sentiment
and
developer
adoption,
and
so
thus
far,
I
think
the
availability
formula
is
fairly
clear.
A
I
think
you
can
figure
that
out
using
kind
of
a
downtime
calculation
and
what
you
want
to
spend
cogs
is
the
other
side
of
that
same
formula.
What's
it
costing
you,
you
can
break
that
down
through
you
know,
advanced
billing
and
really
getting
into
their
geeking
out
on
the
numbers
from
a
security
you
can
attach
the
the
you
can
do
it.
A
But
I
do
think
it's
a
really
interesting
place
to
spend
some
time
and
think
about
so
hiring
tradeoffs
and
time
to
value
are
kind
of
the
things
that
we
approach
there
so
for
some
further
reading
on
developer
productivity,
which
is
where
I
spend
probably
more
of
my
time.
Thinking
about
this
at
this
point
there's
an
article
from
twitter,
which
is
probably
my
favorite.
It's
called
what
let
1000
flowers
bloom
about
engineering
efficiency
and
then
we
get
into
some
of
the
metrics
from
git
lab
over
there.
A
On
mr
rate
and
recently
nefal
nicole
forsgen
at
all
published
a
thing
called
space,
so
developer
productivity,
which
was
some
measurements
and
sentiment
how
to
measure
developer
productivity,
which
is
also
pretty
pretty
interesting
and
came
out
rather
recently
anyway,
I'm
michael
stonke.
I
hope
you
learned
a
little
bit
about
thinking
about
a
platform
organization
and
how
you
would
measure
or
not
how
you
would
measure
its
effectiveness
and
see
whether
or
not
it
was
working
again.
I'm
michael
steinke,
thank
you
for
your
time
and
I'll
take
questions.
A
A
All
right,
thanks
for
the
comments,
I
guess
you
know.
One
of
the
questions
that
I
commonly
get
on
this
is
hey.
You've
talked
a
lot
about
business
value.
How
does
that
always
map
back
into
currency
and-
and
the
answer
is
that's
hard
and
like
that's
the
bottom
line?
Is
technology
is
really
hard
to
map
back
to
what
we're
spending
and
what
we're
getting
for
returns?
A
And
so,
while
I
encourage
you
to
kind
of
think
about
the
business
value
all
the
way
through
and
show
that
that
has
a
value,
I
think
there's
also
good
times
to
sit
down
and
partner
with
your
people
in
finance
or
in
other
parts
of
the
business
and
say
how
do
you
think
about
this?
Or
how
would
you
think
about
this
and
is
being
more
efficient
and
effective,
something
that
we
truly
value?
And
how
do
we
show
that?
A
Because
today
I
think
a
lot
of
organizations
don't
have
a
good
handle
on
what
they're
really
spending
and
why
they're
spending
it
in
r
d
and
obviously
r
d
costs
are
very
high,
and
so
what
you
know
as
we're
spending
the
money
at
circle
ci.
I
want
to
make
sure
that
we're
getting
the
return
for
it
and
it's
an
area
that
I'm
trying
to
grow
in.
A
You
know
as
much
as
everybody
else
is,
I
think,
as
leading
an
engineering
department,
you
really
want
to
make
sure
you're
into
good
roi
and
and
intelligence
ben
w
of
your
capital.
So
I
guess
that
would
be
my
only
kind
of
final
point
that
I
didn't
get
to
really
cover
too
much
in
the
conversation
there.