# George Medve's Manager Readme **Software Development Manager III at AJ Bell** # Disclaimer This document is a living document.  You might find this document close to some you may encounter online and that’s OK, it just means I couldn’t put it in better words. # Motivations behind this document Having been inspired by several documents/posts on the importance of a Manager’s README, I've decided to kick things off with my own edition. Few reasons for this document to exist: - Writing and maintaining this document helps me refine my thoughts, and hold myself accountable. - To share some of my expectations of you and me. - Establish guiding principles to enable you to do your job efficiently, effectively and with confidence. - For you to help me improve and  **hold me accountable.** - Lay down the foundation for a symbiotic relationship between us. # Hi, I'm George!  I'm looking forward to getting to know you! This document is not intended to replace or override the relationship and mutual understanding we will build as we work together. Its intention is to give you an idea of how I think and how I work. # As your Manager > _I am here to make sure our team is successful, happy, 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 believe in both our team's and our company's mission. - I am here to make sure our team is successful and pushing in the right direction. - 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 am here to help make sure we are working on the right things, which is not necessarily everything we're asked to do. - I am here to represent the team, and the business both internally and externally. - I am here to give you honest feedback. - I am here to hire great people. These are in approximate order of importance. If you are not successful and happy, our team is not successful (or happy). If our team is struggling, writing code will most likely not be my top priority. Additionally: 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. However, I am _accountable _for the decisions the team make, even if I’m not the one making them most of the time. I might have thoughts on your code, and I expect you to have thoughts on my suggestions. In the end, you own your code and if you have a good reason for doing something, you should do it; "use good judgment" is a key part of our culture, and it applies to code as much as everything else. # Feedback If you have feedback for me, please give it. It could be something you liked and would like to see more of, something you thought I could do better or something you thought I could have handled in a better way. It could be something that doesn't fit in any of these categories. Even if you think it might not be the case, I _do _want to hear it. If you think I don't want to hear it, I would like to hear why you feel that way. If you can give me this feedback face-to-face (Zoom or in person), that's my preference. If you're only comfortable kicking off a discussion with an email or a Slack message, I would rather you do that than not bring it up at all. If you're not comfortable giving me some feedback yourself, I'd love for you to give it to someone above me in the management chain so they can anonymously relay it to me. Similarly, if you have feedback for a team member or colleague, I encourage you to give it to them directly; if you're not comfortable doing so, let's chat and I can either get the feedback to them or we can figure out a way to deliver it that makes you comfortable. # One-on-ones The duration and frequency are up to you, but I generally start with 45 minutes every week and adjust the cadence once we’re settled in and used to each other based on what _you_ need. I will probably schedule our first one-on-one for an hour just to be sure we have time to go over the team mission and other introductory things; don't feel the need to prepare for it. One-on-ones are _your time_. I will probably have some things to discuss with you, but this is first and foremost your opportunity to let me know how you're doing, what you need, what you wish could be different, how you feel about our team and your teammates, what your career goals are, etc...  These are for the conversations you might not necessarily have with me when we're sitting at our desks amongst coworkers. If you'd like to give me a brief status update on things you're working on or that you're stuck on, that is fine with me, but those are generally better-suited to a quick chat while I'm at my desk, an @ on a Github issue, a Slack message, or a separate meeting. I encourage you to write down some things throughout the week that you want to chat about if you think that will help, since it can sometimes be hard to think of or bring up things in the moment. If you have things you want to talk about but 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. # Performance I will give you feedback on how you're doing continuously, including in our one-on-ones. If I'm worried about your performance, I will let you know. My goal is for you to never be unsure about how you're performing (and how I think you're performing). If you ever feel unsure about either of these things, please let me know. # My schedule Due to the coronavirus pandemic, we are currently working entirely remotely. At some future point when it is safe to be in the office again, I will likely work from the office twice or three times a week and otherwise will work from home. When working from home, I generally consider my work hours to be 9:30am to 5:30pm, though this varies somewhat depending on meetings. If I am not available during these hours for some reason, I will mark it in my Slack status (and will mark longer absence on my calendar). # If you need something - Find me at my desk. If I'm about to run off for a meeting, I'll let you know and figure out a better time to chat. - Slack me or email me. Even if you want an in-person or Zoom meeting, just message me to let me know you want to talk and I'll make time. If you would rather talk about something over email or message, that's fine too. - Add something to my calendar. If I am scheduled for something and if you invite me to a meeting then I may chat with you and reschedule. If I'm working from home, you can expect me to be as available as I would be if I was in the office. I think we're all used to the idea of a quick Zoom call, so without hesitation, if you think chatting face-to-face or screen-sharing will be more useful than textual communication, then please do. # After-hours communication I will make a strong effort not to message you outside of office hours. I will sometimes send emails outside of your working hours (especially if we're in different time zones). I don’t expect to communicate with you outside of these hours with respect to your local time. I try not to respond to e-mails or Slack during off-hours and **under no circumstances expect you to unless it’s an emergency.** # Expectations of you - I expect you to deliver on time and uphold our standards. - **Bring me bad news sooner rather than later** ; If things aren’t going well, let me know as early as possible. It gives us both the opportunity to take positive action (whatever might be needed) sooner. - I expect you to keep learning. I like to think I provide the tools, the budget and the time for you to learn new things and improve your knowledge. If you need guidance on what you should focus next, I will do my best to direct you to the right place or person. - 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). - During technical conversations, I like when the best solutions come from a healthy level of debate. I may challenge your ideas with the goal of coming to the best possible solution. - I do care that you attend the meetings you have accepted, be available for your team and deliver on what's agreed. # Transparency I value transparency and will be as open with you as policy, legal and broader company/personal sensibilities allow. Thank you for taking the time to read all this! Any feedback is welcome.