►
From YouTube: Engineering Career Development Framework Discussion
Description
Discussion between Roos and Jean around competency and behavior grouping as it relates to the Engineering Career Development Framework.
A
Hello,
everybody.
So
this
is
a
conversation
between
rose
and
myself,
where
we
were
discussing
slack
feedback
around
the
career
development
framework.
You
know,
specifically,
how
do
we
structure
things
like
competencies
and
behaviors?
Do
we
differentiate?
Do
we
group
things,
and
so
we
decided
we'll,
have
a
quick
synchronous
conversation
to
discuss
this
further
and
maybe
see
if
we
can
come
up
with
some
better
kind
of
like
way
forward
I'll
start
by
sharing
some
context
that
lead
to
this
conversation.
A
So
I
I
nominated
myself
to
to
try
out
a
new
career
development
framework
competencies
that
we
developed,
and-
and
so
I
because
I
was
due
to
do
career
development
with
my
team
members,
and
so
I
said,
okay,
you
know
we
need
to
try
this
out
and
I'll
offer
to
to
have
a
look
at
it.
What
I
then
did
and
I'll
share
my
screen,
so
this
is
on
in
the
recording
as
well.
A
Is
I
had
a
look
at
all
the
kind
of
like
kind
of
like
her
career,
developing
competencies
that
we
have
at
github?
You
know
looking
both
at
the
the
company-wide
ones,
which
are
the
values
and
and
and
remote
competencies,
as
well
as
the
engineering
specific
ones
that
we
worked
on,
and
you
know
for
those
who
aren't
familiar.
What
we've
worked
on
is
is
to
have
like
a
cascading
effect,
so
we
will
have
some
competencies
at
the
engineering
level
and
then
at
the
development
level,
and
you
know
in
this
example.
A
For
instance,
you
know
I've
got
a
team
member
who
is
a
back-end
engineer
in
dev,
so
they
found
competency
as
well.
What
what
ended
up
becoming
quite
apparent
quickly
is
that
there
is
a
lot
of
behaviors
defined.
You
know.
Initially,
it
was.
It
was
close
to
90..
I
picked
up
that
we
had
some
duplication
between
engineering
and
dev
on
the
leadership
leader,
engineering
development,
on
the
leadership
front,
and
so
I've
already
submitted
an
mri
to
clean
that
up,
but
we
still
have
a
lot
of
behaviors.
A
You
know
there's
like
85
in
total
and
the
initial
kind
of
like
response
whenever
I,
when
I
took
team
members
through
this
was
wow.
This
is
a
lot
yeah
and
it
was
overwhelming,
and
that
made
me
think
like
this,
doesn't
feel
right.
You
know
like
we,
you
know
these
things
are
all
you
know
individually.
Looking
at
the
wording
and
things
you
know,
they
all
make
sense,
and
these
are
good
things,
but
what
I,
what
I
started
thinking
about
was:
are
we
getting
too
granular
in
these
things?
You
know
our.
You
know.
A
We've
had
feedback
previously
that
the
career
framework
felt
a
lot
like
a
checkbox
exercise.
You
were
having
to
take
things
off
and-
and
I
was
like
feeling-
you
know-
maybe
we're
getting
into
that
into
that
space
again.
You
know,
because
we
have
a
whole
bunch
of
things
here
and
how
do
we
make
sense
of
this?
How
do
we?
How
do
I
take
what
what
is
here
and
effectively
manage
that
with
a
team
member
and
and
help
them
evaluate
themselves
against
these
things
that
we've
defined?
A
I
explained
the
challenge
I
have
and,
and
then
he
proceeded
to
explain
to
me
how
they
go
about
it.
Well,
he
goes
about
it
and
similar
to
what
we
have
where
we
have
these,
these
kind
of
like
categories
of
values
and
remote
and
technical,
lead,
competency
and
leadership.
You
know
they
have
similar
broad
categories
and
what
they've
done
is
in
in
those
categories.
They
define
outcomes
that
they
would
like
somebody
to
speak
now.
A
An
outcome
could
be
something
as
simple,
as
you
know,
be
an
effective
communicator
and-
and
that
is
you
know
what
we
probably
consider
a
competency
of
offices
and-
and
they
would
have
have
this
outcome
across
levels.
So,
let's
say
across
junior
intermediate
senior
staff
and
all
the
manager
you
know
whatever
the
levels
are,
they
would
have
that
as
as
something
that
they
want
to
see
in
a
person
you
know
even
in
their
juniors.
A
You
know
at
a
senior
level
you
need
to
be
effectively
communicating
across
the
team
and
so
forth
and
as
a
manager,
you
need
to
communicate
effectively
across
teams
as
an
example,
this
kind
of
like
resonated
with
me
in
the
sense
of
we
had
we
have
all
these
these
kind
of
like
behaviors,
in
a
way
that
we've
defined
you
know
act
as
a
coach
for
open
source
contributors
able
to
work
with
third-party
services,
regardless
of
the
quality
of
documentation.
You
know
these.
A
These
all
feel,
like
you
know,
behaviors
of
of
something
that
we
want
somebody
to
to
to
be.
You
know
in
under
technical
competency
and-
and
so
my
my
thinking
and
and
initial
feedback
that
I
gave
to
to
working
group
is
that
I
don't
feel
like
this
list
that
we
have
here
is
is
implementable.
Just
as
is
you
know,
like
I'm
struggling
to
conceptualize.
How
do
I?
How
do
I
effectively
work
with
a
team
member
with
this
list?
How
do
I
make
this?
A
You
know
engaging
for
them
and
also
not
overwhelming
you
know.
I
I
mentioned
to
him.
I
asked
my
mentor,
for
instance,
you
know
like
you
know,
what
would
you
say
is
the
maximum
number
of
of
competencies
or
outcomes
that
somebody
should
evaluate
himself
against,
and
you
know
he
said,
probably
between
10
and
15
and
and
that
kind
of
like
made
me
think.
A
We
were
mostly
concerned
with
with
the
with
the
individual
kind
of
like
line
items,
but
I
my
feedback
is
that
having
having
the
the
line
items
in
front
of
me,
I
don't
I'm
struggling
to
to
to
relate
this
into
how
I
effectively
manage
this.
With
my
with
my
team
members
and
and
that's
that's
kind
of
like
what
started
this
conversation.
Where
I'm
saying,
I
think
we
need
to
look
at
reworking
the
structure
potentially
of
of
the
content
that
we
have
here
and
how
we
go
about.
Managing
that
without
remembers.
B
Yes,
thanks
for
laying
this
out,
I
must
admit
it's
indeed
a
lot.
If
I
look
at
them,
I
think
it's
a
loss
and
I
and
I
wonder
like
to
what
extent
do
you
think
so
I
think
categorizing
is
a
good
idea,
so
we
could
make
indeed
like
competencies,
which
have
outcomes,
of
course,
so
so
indeed
like
hey,
we
want
to
be
so
effective.
Communication
is
a
competency.
B
The
outcome
should
be
that
you're
an
effective
communicator,
and
this
is
what
that
looked
like
right,
and
I
wonder
if
it
to
what
extent
the
values
part
of
development
is
overlapping
with
the
values
part
which
is
defined
by
the
company.
Like?
Is
that
the
case?
Because
I
wonder-
and
this
might
be
an
open
question-
do
we
need
specific
values,
competencies
in
development.
A
B
A
I
and
I
think
that
that
predates
having
you
know
the
company
defined
competencies
like
it's
recently
been
added
to
them
and
so
I've.
My
view
is
that
we
should
not
have
development
specific
values
in
here.
I
think
we
need
to.
We
need
to
align
with
the
company
values
and
say
that
is
it,
and
if
there
are
things
in
here
that
we'd
like
to
see
as
behaviors,
we
should
put
it
in
the
right
and
in
the
right
category
of
of
outcomes
that
we
want
people
to
share.
A
So
I
I'm
in
agreement
that
I
think
that
the
values
for
development
should
should
go
away
and
we
should
align
with
the
company
values.
That
is
again,
these
things
aren't
unvaluable,
but
I
think
overall,
they're
adding
too
much
over
to
the
to
the
process,
and
I
think
the
yeah.
My
understanding
is
that
trying
to
get
to
the
values
confidence
is
being
company-wide
and
adopting
a
company.
B
So
I
think
we
did
some
cross-work
here
because
we
just
looked
at
so
when
we
were
in
this
effective
efficiency,
a
project
group.
We
said:
okay,
we
need
to
determine
company
company
competencies
and
these
all
need
to
be
having
a
training
aligned
right
so
and
then
we
actually
looked
at
okay.
What
do
we
already
have,
and
then
we
saw
in
development
and
also
in
customer
support
that
we
already
had
a
sort
of
a
framework,
so
we
went
based
off
of
that.
So
actually
I
think
there
should
be.
B
That
would
be
a
part
which
we
can
take
out
and
say:
okay,
we
could
really
bring
this
down
to
we.
I
think
I
have
the
the
page
open
of
competencies
and
if
I
look
at
it
so
each
each
value
has
one
competency
for
each
level,
so
that
would
already
narrow
the
first
part
down
and
and
as
well
the
remote
working
competencies
down
too,
because
there's
four,
I
think
it's
being
a
manager
of
one.
So
I
think
that
would
already
crop
it.
And
then
we
maybe.
A
B
A
So
to
your
point,
you
you've
got
it
right
there.
I
must
actually
move
this
column
here.
So
under
the
remote
category
you
know,
there's
actually
only
four
competencies
manager
of
one
effective
communication
handbook
first
and
using
gitlab
and
and
the
the
lines
here
that
I
have
in
column
b
is
actually
the
behaviors.
A
This
does
not
mean
it's
the
beginning
and
end
of
what
I'm
being
a
manager
of
one
is.
These
are
example,
behaviors,
and
that
we
that
we
give
for
you
to
understand
what
we
mean
you
could
be
exhibiting
something
else.
Potentially,
that
also
speaks
to
manager
of
one,
and
so
when,
when
and
and
this
is
now,
you
know
going
a
little
bit
more
practical
and
it's
like
how
do
we
communicate
this
with
team
members?
I
would
say:
okay,
you
know
at
a
senior
level,
you
know
you
you
should
you
know
you
need
to
you
know.
A
We
expect
you
as
company-wide
to
be
a
manager
of
one
as
part
of
our
remote
working
focus,
and
these
are
the
behaviors
that
you
know
that
speaks
to
being
a
senior
in
in
manager
of
one.
You
know,
let's
talk
around,
you
know
how
how
you're
exhibiting
these
behaviors,
but
what
we
should
actually
absolutely
not
do
is
to
say,
okay,
you're
doing
this
you're
doing
this
one
you're
doing
that
one
and
and
kind
of
like
treat
it
as
a
checkbox.
We
should
be
speaking
at
the
level
of
of
the
competency,
which
is
okay.
A
B
Because,
yes,
if
we
look
at
this
page,
for
example,
we
looked
at
so
this
is
the
company
company-wide
competencies
page,
and
here
it
says
we
have.
This
is
a
structure,
but
we
have
values,
competencies
which
all
have
one
for
each
level
which
all
have
one
behavior
of
each
level
and
the
remote
working
competencies.
B
Here
and
then
you
have
like
functional
competencies
right,
which,
which
is,
I
also
like
the
leadership
and
technical
part,
and
I
think
what
what
we've
tried
to
come
up
with
is
sort
of
a
framework
saying
like
okay
as
a
senior
you're,
showing
being
a
manager
of
one
in
your
cross-functional
work.
For
example,
instead
of
only
showing
that
on
your
own
work,
right,
that's
more
of
the
associate
or
or
within
the
team
is
more
of
the
intermediate
level.
B
So
so
this
is
sort
of
how
we
try
to
fix
that
in
in
the
company-wide
competencies,
and
so
that
could
be
so
so
you
could
sort
of
also
have
these
with
communicating
this
out.
You
could
also
say
like
to
what
level
what
is
the
scope
of
impact
for
each
each
level,
and
then
you
can
just
have
examples
of
behaviors.
B
So
then
it
doesn't
really
make
a
checklist
right
which
what
what
we're
constantly
worried
about,
I
think
so
that
could
that
could
sort
of
help.
But
I
think
this
is
foul
we're
just
talking
here
right.
So
this
is
maybe
maybe
good
for
others
in
the
working
group
also
to
consider
and
maybe
share
thoughts
on
what
we
have
just
discussed.
A
I
think
that,
right
now
it
doesn't
feel
consistent
to
me,
for
instance,
if
you
know
I'll
share
my
screen
quickly
again,
but
if
I
go
down
to
you,
know
technical
competency
across
engineering,
development
and,
and
there,
for
instance,
like
I
can't
necessarily
identify
what
is
the
competency
we
want
to
see
like
these,
for
me
feel
more
like
behaviors
than
they
are
competencies.
We
talk
about
coaching,
others.
We
talk
about
mentoring.
You
know
that
there
is
such
essentially
similar
things,
and
so
you
know
what
we.
A
What
we're
actually
stating
is
is
a
bunch
of
behaviors
here.
What
we,
I
think,
what
we
need
to
do
is
more
look
at
competencies
and
then
group
these
behaviors,
underneath
those
which
will
give
us
a
more
condensed
kind
of
like
framework
to
work
with,
which
is
what
I
think
would
is
where
we
need
to
go
next.