As a manager, on-boarding is both tough and really important whether you’re joining a team or they’re joining yours. My very short list for on-boarding in either direction is:
- Share expectations
- Build trust
That’s it. Everything else comes later. Know what you need to do next? If you know what’s expected of you, you can start moving forward. Have questions? You need some level of trust to ask them.
With that in mind, I wrote a document that I share with new reports. I’ve shared this with people I’ve hired and with people whose team I’ve joined. In either case, I think it paints a picture of who I am and how I want to interact with them. I iterate on this with every new person I send it to, and I encourage discussion and feedback. If I’m joining their team, I tend to mention this during our first 1-1 and send it after. If they’re a new hire, I’ll incorporate it into a more verbose on-boarding document with key resources, names to know, and output expectations for their first month to a year.
Without further ado, here is my Manager README. As I encourage my reports to do, please let me know if you have any questions or feedback about it!
Matt, as your manager
I’m excited to get to know you more organically through chats, but a few up-front things about my philosophies that might be helpful.
I’m here to help and support you, to set context for what you’re working on, and to advocate for you and the team with the rest of the company.
My availability looks scary, but I’m here for you!
My calendar is full of meetings and it may be intimidating to schedule something with me. If you see a good time on my calendar, please schedule something (you don’t need to ask first). I’ll be there (my Google Calendar is 99.9% accurate excluding ad-hoc meetings). If there’s urgency and you can’t get a meeting with me for a while, send me a message on Slack or text and I’ll make time. If you need to reschedule something, that is not a problem! I endeavor to make all of my calendar events with modify privileges (I use this extension) and you should feel free to go ahead and move it to some other time slot that’s within business hours and not conflicting with other meetings.
I think highly of the DRI model.
- To clarify: you’re here because of your experience and your skills and I don’t want to override either of those. I’m here to help you succeed but not dictate how you should act.
- If I think you’re headed down the wrong path, I’ll definitely try to dissuade you, but disagreeing with my input does not indicate that you’re doing something wrong.
- You’ll still need to get consensus, agreement, and input from your teammates.
Process and Software Development
I strongly believe in putting people over process and changing process 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, 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.
Feedback is very important to me.
In situations where anonymous feedback is suggested, you’ll probably hear me suggesting that you provide direct feedback, though anonymous feedback is better than none. I’m dedicated to giving you clear and timely feedback and hope that you’ll give me the same. I believe that feedback requires three attributes:
- Safety (you should feel safe to give and receive candid feedback)
- Effort (neither you nor I should feel defensive about the feedback)
- Benefit (giving/receiving feedback should have impact)
Please let me know if I’m doing poorly on any of these attributes. I’ll return the favor!
I’m big on work/life balance.
Most folks work between about 8am (at the earliest) to 6pm (at the latest), and unless there’s an emergency, 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.
One on one meetings
I’m big on 1:1s. I believe that these meetings are for you to set the agenda. What would you like to talk about? What’s going well? What’s bugging you? These don’t need to be status updates unless you really want to talk about project status. For local chats, I really enjoy walking 1:1s; for remote chats, I have a difficult time focusing unless I can see your face over video. If there are things that I want to ask you, I’ll do it, but this is your time. The length, frequency, and medium are also up to you, but my hope is that we’ll have at least 30 minutes a week, with an optimal 60 minutes per week. This is only a minimum though, and not a maximum! I prefer to have separate meetings scheduled for agenda-driven chats (e.g. goals, reviewing 360 feedback, etc.) so that we still have room for more timely 1:1 chat.
I endeavor to have a great working relationship with you, and I would encourage you to have great working relationships with your peers and business partners (in the office and/or on your team), as well as other folks in other offices to get a sense of how things work outside of our team. I’m happy to make introductions for you or provide networking suggestions to help you do that.
Week in Review
I started writing a Week in Review blog (though my updates are super infrequent). I think of it as an annotated version of some topics that may come up in our 1:1s. Please consider this a living document to comment in, ask questions about, etc.
I’ve written a lot here about my philosophies but a fair amount of my job is adapting to your needs and philosophies, and I look forward to talking to you about them!
¹ It’s a pretty great place to learn things, network, and find a lot of kind and differing views on leadership and management. Check it out.
² I learned this trick from Lara Hogan who referenced where she learned it, along with an example post here. In the version I share internally, I’d link the WIR there.