This past week was GitHub Universe. Local SF Hubbers were invited to volunteer and I did: I worked the info booth and the swag shop. It was nice meeting lots of other local Hubbers that don’t regularly frequent the office.
Performance Review Season
It’s here again. As a manager, I have a template for how I like to receive self-reflections that I’ve been dragging around with me for the past 15 (?!) years.
- Laundry list all of your projects, contributions, and accomplishments during the time period [if this seems difficult, have some sympathy for your manager]
- What future growth areas (lined up in phrases from the Career Ladder) would you like to focus on developing?
- What specific project/work opportunities exist (or you’d like to create) that would help you develop the growth areas you described in the previous question? (or you would really, really want to work on).
And then it’s a matter of trying to shoe-horn those questions into the invariably slightly different organizational template. I wrote up a big document for my reports.
Here’s what I drafted for myself on the opportunities question:
Improve predictability of team output. I would like to better develop a proactive ability to predict team output. Two focuses:
- Tactical Planning: Improving my short/medium-term project management skills to improve how work is defined, broken down, and scheduled with target dates.
- Strategic Planning: Planning and championing high-impact projects that would be engaging for both the team and engineering leadership.
The end result of this, in addition to expanding impact, is growing the Ruby Architecture team and ensuring there is sufficient capacity (and buffers) for our core Areas of Responsibility.
Further develop “out”-ward communication. Improve my ability to brief and influence across teams and leadership at GitHub. Particularly focused on reinforcing the position and importance of Ruby and Rails within GitHub.
What is “Platform”
In my new department, UI & Monolith Platform, all of my sibling teams are platform, but look very different. We’ve been working on a document to share with the rest of the Engineering team about what we would say we do here. As part of that, I’ve been thinking about Maturity Models as an explanation for why our teams look so different. Some teams are early, where they’re still focused on adoption and “fit”, and other teams, like mine, that are so mature that I think our internal consumers are not always fully aware that they’re using the platform we’ve built with huge intention.
A universal playbook
The past week at Universe, continually responding to the question “oh, what do you do?”, has helped me reflect on what I’m working towards. And realizing it feels like the same playbook I’ve run at other jobs. Lots more to it than this, but man, write your end-to-end tests people.