Updates to job description
This commit is contained in:
87
one.org
87
one.org
@@ -273,11 +273,38 @@ be diligent about shaping your role over time or you'll end up
|
|||||||
over-burdened and unable to do a good job at any of your
|
over-burdened and unable to do a good job at any of your
|
||||||
responsibilities.
|
responsibilities.
|
||||||
|
|
||||||
Here's an outline of my job;
|
My formal job title is (I think) "Director of Engineering"
|
||||||
|
|
||||||
|
My reponsibilities include
|
||||||
|
|
||||||
** Stated title
|
|
||||||
Director of Engineering (formerlly technical lead)
|
|
||||||
** Actual responsibilities
|
** Actual responsibilities
|
||||||
|
*** Software design
|
||||||
|
I don't design all of the software here by any means, but I am either
|
||||||
|
doing the design myself or I'm involved in the design conversation of nearly
|
||||||
|
any non-trivial component.
|
||||||
|
|
||||||
|
We're starting to outgrow this but it's proving a little difficult for
|
||||||
|
both me to let go of being involved in everything and for others to
|
||||||
|
let me be less involved.
|
||||||
|
|
||||||
|
*** Keeping production from breaking
|
||||||
|
At the end of the day, if the system is on fire then I have to make
|
||||||
|
sure it gets fixed.
|
||||||
|
|
||||||
|
Fortunately, our system is fairly resilient and we have a rotating
|
||||||
|
"support" role that everyone gets a turn at - so I am not personally
|
||||||
|
responding to every issue that comes up.
|
||||||
|
|
||||||
|
However, if we do have a big enough or hard enough problem then I need
|
||||||
|
to be able to provide support. And that usually means the situation is
|
||||||
|
urgent so I have to know the details of the system well enough to
|
||||||
|
resolve issues quickly.
|
||||||
|
|
||||||
|
Truly, though, this responsibility is a long-view one - I need to
|
||||||
|
ensure that the software we're building is not falling over on
|
||||||
|
itself. Thankfully, our tech stack is faily reliable compared
|
||||||
|
to many others I've used in companies prior.
|
||||||
|
|
||||||
*** Business goal prioritization
|
*** Business goal prioritization
|
||||||
Providing technical input to and vetting of business goals.
|
Providing technical input to and vetting of business goals.
|
||||||
|
|
||||||
@@ -302,30 +329,40 @@ While we don't have a lot of "hard dates" on deliverables compared to
|
|||||||
either ensure we hit them or to understand why we didn't so we can
|
either ensure we hit them or to understand why we didn't so we can
|
||||||
better [[#/managing-expectations][manage expectations]] in the future.
|
better [[#/managing-expectations][manage expectations]] in the future.
|
||||||
|
|
||||||
*** Keeping production from breaking
|
|
||||||
At the end of the day, if the system is on fire then I have to make sure it gets fixed.
|
|
||||||
|
|
||||||
Fortunately, our system is fairly resilient and we have a rotating
|
|
||||||
"support" role that everyone gets a turn at - so I am not personally
|
|
||||||
responding to every issue that comes up.
|
|
||||||
|
|
||||||
However, if we do have a big enough or hard enough problem then I need
|
|
||||||
to be able to provide support. And that usually means the situation is
|
|
||||||
urgent so I have to know the details of the system well enough to
|
|
||||||
resolve issues quickly.
|
|
||||||
|
|
||||||
*** Software design
|
|
||||||
|
|
||||||
** Expectations (from others)
|
|
||||||
*** Discuss story details, expectations, changes, etc
|
*** Discuss story details, expectations, changes, etc
|
||||||
[[https://en.wikipedia.org/wiki/User_story][A user story is a promise for a conversation]]. Very often I am the one keeping that promise and this puts me in the middle of a lot of conversations.
|
[[https://en.wikipedia.org/wiki/User_story][A user story is a promise for a conversation]]. Very often I am the one
|
||||||
*** TODO Adjudicate technical disagreements
|
keeping that promise and this puts me in the middle of a lot of
|
||||||
** Expectations (on myself)
|
conversations.
|
||||||
*** TODO Maintaining technical quality
|
|
||||||
*** Primary interrupt
|
|
||||||
This responsiblity is a hold-over from my tech lead days and it's one I need to get rid of.
|
|
||||||
|
|
||||||
Being the primary interrupt means protecting the team from interruptions and allowing them to focus on executing the current plan of work (i.e. the stories in the iteration)
|
*** Adjudicate technical disagreements
|
||||||
|
Fortunately this doesn't happen all that often - and usually when it
|
||||||
|
does it's around more trivial things (bikeshedding affects us all),
|
||||||
|
but it does happen.
|
||||||
|
*** Maintaining technical quality
|
||||||
|
When we have code quality issues I feel personally responsible.
|
||||||
|
|
||||||
|
It's my job to either prevent them in the first place, or plan an
|
||||||
|
execute work to alleviate quality issues.
|
||||||
|
|
||||||
|
Balancing that work with business deliverables is a skill unto itself.
|
||||||
|
|
||||||
|
*** Primary interrupt
|
||||||
|
This responsiblity is a hold-over from my tech lead days and it's one
|
||||||
|
I need to get rid of.
|
||||||
|
|
||||||
|
Being the primary interrupt means, to me, protecting the team from
|
||||||
|
interruptions and allowing them to focus on executing the current plan
|
||||||
|
of work (i.e. the stories in the iteration, our current deliverable or
|
||||||
|
goal otherwise).
|
||||||
|
|
||||||
|
In practice this means it's hard for me to focus.
|
||||||
|
|
||||||
|
We've made some changes to the support structure this past year that
|
||||||
|
have helped with this immensely.
|
||||||
|
|
||||||
|
However, at the same time we've grown the development team so now my
|
||||||
|
other responsibility of feeding the machine (i.e. writing stories) has
|
||||||
|
chipped away at some of the focus gains I've made.
|
||||||
|
|
||||||
* TODO Managing Expectations
|
* TODO Managing Expectations
|
||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
|
|||||||
Reference in New Issue
Block a user