jbrechtel/willfullyobtuse.com
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updates to job description

Browse Source
This commit is contained in:
James Brechtel
2024-10-09 08:28:09 -04:00
parent 4ff168940a
commit 1d2fa80c73
1 changed files with 62 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

87
one.org
View File

@@ -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
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
*** 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
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
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
[[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.
*** TODO Adjudicate technical disagreements
** Expectations (on myself)
*** 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.
[[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.
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
:PROPERTIES: