I've never liked working at large companies. Mostly because I think 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.
My formal job title is (I think) "Director of Engineering"
My reponsibilities include
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.
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, 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 manage expectations in the future.
Discuss story details, expectations, changes, etc
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.
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.