| It depends. On the whole my responsibilities are a mix of things: 1. Technical strategy - primarily writing strategy docs and discussing with other tech PEs. Usually precursor to architecture. 2. Business Strategy - reviews with non tech staff and leadership (across the org) about what the business needs are, where we see the future going. Often takes the form of reviewing other peoples documents or contributing sections to those 3. Product design reviews - reviewing CX/UX documentation 4. Architecture - Creating architecture documents - lots of text and boxes and lines. Several rounds of reviews. Usually precursor to coding or reading other people's code. 5. Coding - takes the form of staring at various IDEs and scratching my head. 6. Reading other people's code - same as above. Also include code reviews. 7. Operations - On call stuff. Usually where all the architecture stuff falls apart :-) 8. Mentorship - structured 1:1s, feedback, etc 9. Prototyping and demos I spend probably 90% of my time doing the items above. The mix among these items varies but I consider all of it my work. For the rest I sometimes get pulled into the items below that are not officially my responsibilities - Conferences and public speaking - I could, but choose not to - Project tracking and reporting - Managing people's careers directly - Funding decisions My work is rarely political depending on how you define politics. To me politics is about "who gets the cool stuff" so mostly funding decisions. I do get pulled in occasionally to sort out "who should build this" discussions but they are usually good faith discussions trying to align expertise and charters before funding decisions are made. Biz and tech strategy does involve consensus building but I suspect the Real Politics™ happen behind the scenes at higher levels. |