What is this?

The following is a user guide for me and how I work. It captures what you can expect out of an average week working with me, how I like to work, how to get the most out of me. It is not a replacement for actually getting to know me!

This is a living document that will change as I learn more about myself and how we can best support each other.

I am interested in continually iterating and fine-tuning these beliefs. Constructive feedback is always welcome. If you see a conflict between this and my behaviour, please tell me!

My Job

I’m here to help and support you, to set the context for what you’re working on, to advocate for you and the teams with the rest of the company and externally.

I believe managers work for their direct reports. I will work for you by:

• Providing context Most of my day is spent collecting, filtering and sharing context/information from across other projects, domains, and product lines. I’ll try to push information to you as much as I can but feel free to ask about anything else. Context should help you more easily complete a feature, fix a bug, or deliver a product.
• Cheering I will celebrate your successes. If you're not a person who self-promotes, please let me do it for you. Tell me when things go well, share the things which make you proud, and I'll cheer/share appropriately.
• Firefighting “If my favourite opening line is "I could use a hand with...", my second favourite is "I screwed up...". A mistake, if shared, becomes a challenge; if hidden, becomes a failure.”
• Retain and developing engineers To grow our teams with more talented individuals, to provide appropriate resourcing, I will actively strive to improve you, as well as bringing fresh talent into the team.

Because I am measured by our team’s ability to deliver valuable software to the business, it is in my best interest to provide the necessary context around your work and do whatever I can to help you grow as a human, engineer, and employee, in that order.

Process and Software Development

I strongly believe in putting people over processes and changing processes to accommodate our needs and goals. I’ve worked with and without Agile, with and without a form of Scrum. At the end of the day, within work settings, these are my values:

• I value transparency about what’s happened, what’s happening, and what’s going to happen.
• I value speed, including proactive efforts that keep us moving quickly (e.g. writing tests, refactoring legacy code before a new feature, pairing on work to improve our code quality and bus factor)
• I value learning and know that training up on a tech stack may not always be the fastest route to production.
• I value your time and don’t want you to do any process that is neither beneficial to you nor required by law, policy, etc.