Hubspot
Hubspot

Hi, I'm Molly

Meet Molly White, a former tech lead at HubSpot. In her README, Molly offers a detailed and insightful account of her working style, philosophy, and preferences in order to facilitate a productive and positive relationship with her reports from the get-go.

As her primary focus is ensuring the success and happiness of her team, Molly emphasizes the importance of aligning the team's efforts, collaborating effectively with other teams, and working on tasks that truly matter. While supporting her team's growth, Molly explains that she actively maintains her coding skills and encourages open discussions on code. She values feedback and encourages open communication, both in-person and via messaging. Reflecting her commitment to creating a diverse and inclusive work environment where everyone can show up as themselves, Molly's README makes sure to provide insight into her working schedule, after-hours communication, and her interests outside of work.

Molly's clear and open approach to introductory READMEs creates a foundation of transparency and trust in the working relationship, making future collaboration easier and more successful.

Hi, I'm Molly

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.

My role as a tech lead

TL;DR: 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:

  1. 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.
  2. I am here to make sure our team is successful and pointed in the right direction. You might hear Dharmesh talking about aligning vectors: I am here to make sure our team is all aligned and pushing in the same direction.
  3. 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'm also here to help make sure we are working on the right things, which is not necessarily everything we're asked to do.
  4. I write some code too!

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. When I asked some other people for feedback on this README, one asked about this point, and then said something I thought was poignant: "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 mine. 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 the HubSpot 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, something you thought I totally screwed up, or 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. And if you think I don't want to hear it, I'd love 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

I will put thirty minutes on your calendar each week for a one-on-one. If you need more time, let me know and I will adjust. 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.

These are some interesting articles I've read about one-on-ones, though I don't necessarily agree with all of the points: 12. If you have thoughts on either, that might make a good topic to include in a one-on-one.

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

Because of the coronavirus pandemic, I am currently working entirely remotely. At some future point when it is safe to be in the office again, I will be a @flex employee, meaning that I will work from the office once or twice a week and otherwise will work from home.

When working from home, I generally consider my work hours to be 10am to 6pm, 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 on my calendar if I am out for a day or more).

This readme used to have a section on my in-office schedule, but so much has changed since I last worked in the office regularly that I have removed it and will update it when that becomes an option again.

After-hours communication

I will get a sense of your normal working hours as we begin working together, and I will make a strong effort not to message you outside of these hours because I know many people have Slack notifications sent to their phone. I will sometimes send emails outside of your working hours (especially if we're in different time zones), as emails don't tend to notify people quite as intrusively. You should not feel obligated to read or respond to any emails or messages you receive from me outside of your normal hours. If you are receiving after-hours messages from me with any frequency, please let me know—it may mean I'm misunderstanding the hours you normally work.

If for any reason I do urgently need you outside of your normal working hours, I will page you. This will happen extremely rarely (if ever).

Similarly, if you email or Slack me outside of my working hours, I may not respond quickly. I do try to keep up with notifications in case there's anything urgent, but if I read a message and it's non-urgent, I may leave it until the next working day. If you have something non-urgent you want to tell me and it's outside of my work hours, I don't mind if you Slack me, though I always appreciate an explicit note that it's non-urgent! If you need me urgently outside of work hours, paging me is the best way to get hold of me, though you can always try Slack too first.

A note on diversity and inclusion

Diversity and inclusion are extremely important to me. I would not necessarily mention this in my README, except that it ties in a bit with my schedule: I choose to work from home part of the time because it helps me manage my anxiety disorder, which I prefer to be open about. This will not affect our working relationship–I will be available on Slack, email, Github, or video calls regardless of whether I am in the office or not (see below).

If you need something

  1. Snag me at my desk. If I have headphones on, it does not mean I am "in the zone" and expect not to be interrupted. I'm probably just enjoying some music. Feel free to grab my attention, preferably by waving in my periphery or tapping my desk. If I'm about to have to run off for a meeting or somesuch, I'll let you know and figure out a better time to chat.
  2. 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.
  3. Throw something on my calendar. If I am scheduled for an interview or something else I can't reschedule and you invite me to a meeting, I may chat with you and reschedule. If you see that I've blocked off the day or time block as "meeting-free", that does not apply to you—it's more to discourage folks from scheduling non-urgent meetings that day that could be scheduled otherwise. If you need to talk, schedule over this as much as you need.

If I'm working from home, you can expect me to be as available as I would be if I was in the office. Although it may feel weird to schedule a brief Zoom meeting when you'd normally just swing by my desk for five minutes, please do so without hesitation if you think chatting face-to-face or screen-sharing will be more useful than textual communication.

Caveat

Take this document with a grain of salt: I wrote it! I have never experienced having me as a manager. If I'm your TL and something here seems off, open a pull request or issue, or (probably more comfortably) bring it up to me in one-on-one or over Slack.

Expectations of you

This document is meant to focus on how I work and what to expect from me. We will discuss expectations I have of you and the rest of the team soon after we begin working together, and I will link you to an internal onboarding document with some HubSpot-specific onboarding information.

My interests

Here are some things I love. If you ever want to strike up casual conversation and don't know what to talk about, these are good bets 😃

  1. Animals. I used to foster cats and kittens, and you'll inevitably hear about Max and Ruth, both former foster cats of mine who are now my permanent cats. I love dogs as well, and I try to meet and get to know as many office dogs as I can. If you see a dog in the office, I always like being told about them so I can go say hi.
User-uploaded Image
Add a caption
User-uploaded Image
Add a caption
  1. Cooking and baking. I love trying new recipes and new cooking techniques. I always want to hear about new recipes you've tried or want to try, or just chat about cooking and baking in general. I also want to know about your favorite baked goods for celebratory purposes.

Meet Molly White, a former tech lead at HubSpot. In her README, Molly offers a detailed and insightful account of her working style, philosophy, and preferences in order to facilitate a productive and positive relationship with her reports from the get-go.

As her primary focus is ensuring the success and happiness of her team, Molly emphasizes the importance of aligning the team's efforts, collaborating effectively with other teams, and working on tasks that truly matter. While supporting her team's growth, Molly explains that she actively maintains her coding skills and encourages open discussions on code. She values feedback and encourages open communication, both in-person and via messaging. Reflecting her commitment to creating a diverse and inclusive work environment where everyone can show up as themselves, Molly's README makes sure to provide insight into her working schedule, after-hours communication, and her interests outside of work.

Molly's clear and open approach to introductory READMEs creates a foundation of transparency and trust in the working relationship, making future collaboration easier and more successful.

Related examples in User Manuals
GitLab
GitLab
Sid Sijbrandij
Stripe
Stripe
Working with Claire: an unauthorized guide