Samuel/README
READMEs are a sort of high-level overview of some library, project, or API. In the same way, this document is a sort of high-level overview of myself: how I like to work, what I expect of others, some philosophies, and how best to interact with me.
My hope is that by working together, through our one-on-ones, and healthy communication, you’ll quickly come to know me and what my expectations are. I plan on doing my best to understand you, what your goals are, and how to help you be productive and grow in your role. It’s just nice to have easily accessed documentation, and that’s what this is.
My Role
TL;DR: My role is to make sure our team is productive, successful, and working on the things that are most important to help our customers, improve our product, and improve our business.
More granularly:
- I am here to make sure you are both successful and happy: I want you to improve your technical skills, grow your career, enjoy your work, and achieve your goals.
- I am here to make sure our team is successful and aligned with the goals of the organization.
- I am here to make sure our team is getting what we need from other teams, and that other teams are getting what they need from us. I.e. I will work to remove speed bumps and barriers so we can all move quickly.
- I will also be writing code.
My job is not to tell you exactly what to do and how to do it. It is also not to be the "official decision maker" for our team. I might have thoughts on your code, and I expect you to have thoughts on mine. In the end, you own your code and if you have a good reason for doing something, you should do it.
Guiding Principles
Deep work: Programmers work best when they have uninterrupted stretches of time to allow them to focus on the problem at hand. It is through these regular uninterrupted periods that we are most productive, experience more breakthroughs, and can find great joy in our work. This state "deep work" can only be achieved by avoiding distractions and interruptions. I will do what I can to help you maintain the deep work state.
Meetings: I hate them as much as the next developer, but they can be valuable. You can expect the following from me in my meetings:
- There will be an agenda
- I'll end meetings early if everything in the agenda is met
- I'll cancel meetings if there's no point in having them or if I'm able to gather the necessary information without them.
Slack and email: Both tools are valuable in moderation. I regularly close my Slack and email clients in order to focus. I encourage you to do the same.
Bias toward action: You are never more ignorant about a project than at the beginning. The best choice then is to dig in and start uncovering the known and unknown quantities in order to ask better questions and discover what you don't know.
Assume positive intent: We primarily communicate in a text medium. Unfortunately, that misses out on more than 80% of what is communicated in a face-to-face conversation and can lead to hurt feelings, misunderstandings, and conflict.
The idea of assuming positive intent is to give the other person the benefit of the doubt: that they weren't trying to upset you and instead just weren't aware of the consequences of their actions.
Remember, we're all on the same team, striving for the same goals.
One-on-Ones
I'm a firm believer in the value of one-on-ones and as such will schedule weekly 30-minute blocks of time to touch base with you. If you need more time, let me know and I will adjust.
One-on-ones are your time. I will likely have things to discuss with you, but these meetings are your opportunities to let me know how you're doing in general, what you need, what you wish could be different, how you feel about our team and your teammates, what your career goals are... etc.
I encourage you to write down some things you want to chat about ahead of time, because they can be hard to think of or bring up in the moment. If you struggle with bringing them up, feel free to send me a vague agenda ahead of time. If you don't know what to talk about, say so. We can use that as a topic.
Feedback
TODO
Feedback (how to give & how you give) — What type of feedback do you want? Are you comfortable with people being blunt with you? How do you prefer to give feedback? How do you expect your team to react to feedback?
How to interpret my calendar — Sometimes a manager’s calendar can be packed. Almost every manager above wants their team to know that they are the most important part of their job, so they’re explicit in saying so. Message them on slack if you need to talk. They’ll make time.
This document is incomplete. I will update it as I discover what I'm lacking and where it's lacking, and would appreciate your feedback.