diff --git a/one.org b/one.org
index aaafd79..9939d35 100644
--- a/one.org
+++ b/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
 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: