diff --git a/one.org b/one.org
index 2e0cb80..aaafd79 100644
--- a/one.org
+++ b/one.org
@@ -1,12 +1,10 @@
-* I'm being willfully obtuse
+* You're being willfully obtuse
 :PROPERTIES:
 :ONE: wfot-default-home-list-pages
 :CUSTOM_ID: /
 :END:
 
-Hello,
-
-Here's what I've been thinking about
+Here's what I'm thinking...
 
 * HTTPS @ Homelab
 :PROPERTIES:
@@ -268,10 +266,74 @@ I've never liked working at [[#/large-companies/][large companies]]. Mostly beca
 they complicate things, but some things are more complicated at small
 companies.
 
+Specifically, leadership roles tend to be fluid in their definition
+where they grow organically over time. Also, as I'm learning, old
+responsibilities don't tend to get pruned on their own. So you have to
+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;
+
+** Stated title
+Director of Engineering (formerlly technical lead)
+** Actual responsibilities
+*** Business goal prioritization
+Providing technical input to and vetting of business goals.
+
+This is basically a combination of saying
+- "X will take (days|weeks|months|years)"
+- "Y will be (easier|better|less risky) if we do it after X"
+- "We can get 90% of the benefits of A if we do B - at half the cost - instead"
+- etc...
+
+*** Writing stories and technical plans
+Many (but not all) of our "tickets" "cards" "stories" what-have-you
+end up getting written directly by me. This is, in some sense, an easy
+job to delegate out but it's risky to do so because getting this part
+wrong can lead to a lot of re-work amongst other costs.
+
+*** Iteration planning
+Deciding what the team will actually do in a given week. 
+
+*** Ensuring timelines get met
+While we don't have a lot of "hard dates" on deliverables compared to
+[[#/large-companies/][large companies]], we have them sometimes and it's my responsibility 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.
+
+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)
+
 * TODO Managing Expectations 
 :PROPERTIES:
 :ONE: wfot-default
 :CUSTOM_ID: /managing-expectations/
 :END:
 
+:DRAFT:
+
 I'll figure this out one day. Until then I'll just keep saying yes and burning myself out making everyone happy.
+:END: